Daily Cybersecurity News – October 7, 2026

What happened

Hackers began exploiting CVE-2026-21589, a critical unauthenticated arbitrary file access flaw in multiple Atlassian Data Center products, within hours of a public proof-of-concept release by watchTowr.

The root cause is a shared web-resource library that converts double colons "::" into forward slashes, enabling directory-traversal requests via plugin endpoints to read specific files in the web root (including WEB-INF) if the exact path is known. In Crowd-integrated deployments, this can expose plaintext credentials from crowd.properties, allowing creation of administrator accounts via the Crowd API.

Previdian observed exploitation attempts on its honeypot network shortly after the technical details and PoC became public, with automated Nuclei templates now circulating.

Who is affected

Self-hosted instances of Bitbucket Data Center, Confluence Data Center, Jira Software Data Center, Jira Service Management Data Center, Bamboo Data Center, Crowd Data Center, Crucible, and Fisheye. All versions prior to the October 2026 fixed releases are affected.

Atlassian Cloud products were already patched. Organizations with internet-exposed instances or Crowd SSO integration face the highest risk. Enterprise users of these collaboration and DevOps tools number in the tens of thousands globally.

Why it matters

Unauthenticated file reads can quickly escalate to full administrative control in common configurations, enabling data theft, persistence, or ransomware staging. The speed of post-PoC exploitation shows how quickly scanners and attackers weaponize public research against widely deployed enterprise software.

Operators cannot assume isolation protects them; even internal instances may be reachable via pivots or misconfigurations.

How it could have been prevented

Apply the security updates immediately to the fixed versions listed in Atlassian's advisory (for example Jira Software 9.12.40 / 10.3.26 / 11.3.12 and equivalent lines for the other products).

Restrict external network access to instances until patched. Deploy WAF or proxy rules blocking the known traversal patterns, Tomcat RewriteValve rules where applicable, and limit Crowd API access to allow-listed IPs. Review access logs for suspicious resource requests and use the free watchTowr scanner to check exposure.

What happened

Ethical hackers at Pwn2Own Ireland 2026 demonstrated 32 unique zero-day vulnerabilities on the first day of the contest in Cork, earning more than $368,000 in prizes plus Master of Pwn points.

Targets included smartphones, smart-home devices, printers, and AI tools. Notable chains hit the Sonos Era 300 (out-of-bounds write plus format string), LiteLLM (input validation and code injection for reverse shell), Philips Hue Bridge Pro (seven zeros), Lexmark CX532adwe (use-after-free), Oracle Autonomous AI Database (five zeros), OpenAI Codex (argument injection), and others. Samsung Galaxy S26 was compromised multiple times.

Who is affected

Owners and users of the successfully exploited products: Samsung Galaxy S26, Philips Hue Bridge Pro, Oracle Autonomous AI Database, LiteLLM, Lexmark and Canon printers, OpenAI Codex, Sonos Era 300, Garmin Index BPM, and similar categories.

Vendors receive the details under ZDI rules and have 90 days to ship patches before public disclosure. Broader populations running unpatched consumer IoT, mobile, and emerging AI infrastructure are indirectly exposed once details emerge.

Why it matters

The contest surfaces high-impact bugs in shipping products before criminals do, especially in AI coding agents and smart devices that expand the attack surface. Rising zero-day volume and AI-assisted discovery (noted in related research) mean defenders must treat vendor patch cycles as critical and expect more complex multi-bug chains.

It underscores that even well-resourced vendors still ship exploitable flaws in flagship hardware and software.

How it could have been prevented

Track ZDI and vendor advisories for the named products and apply patches as soon as they are released within the 90-day window. Inventory AI tools, smart-home hubs, printers, and mobile fleets for exposure and enforce least-privilege network access in the interim. Prefer devices with active security update commitments.

What happened

The FBI and U.S. Secret Service issued a joint advisory confirming that the FortiBleed credential-stealing campaign remains active and has compromised more than 86,000 internet-facing Fortinet FortiGate firewalls and SSL VPN gateways across 194 countries.

Attackers scan for exposed portals, perform credential stuffing and password spraying with reused or leaked credentials, harvest and crack authentication data (including legacy SHA-256 hashes) at scale using GPU clusters, create new admin accounts for persistence, and sometimes lock out legitimate users. Access is sold by initial-access brokers to ransomware affiliates tied to INC/Lynx and Payload groups. The campaign became fully visible after operators exposed their own backend server.

Who is affected

Any organization running internet-exposed FortiGate firewalls or VPN gateways that lack strong unique credentials and multi-factor authentication. Confirmed scale exceeds 86,000 devices globally; later estimates of targeted systems run higher. Sectors with remote-access needs are heavily represented, and the activity has already served as an initial entry for ransomware.

Why it matters

Successful compromise can result in complete lock-out of management interfaces, requiring non-standard recovery, plus lateral movement and ransomware deployment. The multi-month duration, mature tooling, and direct ransomware linkage turn a credential problem into a business-continuity and data-extortion risk for edge network devices that many treat as set-and-forget.

How it could have been prevented

Immediately restrict or remove internet-facing management and admin access to FortiGate devices. Terminate all active admin and VPN sessions, reset every credential, enable phishing-resistant MFA, and review all local accounts for unauthorized additions or changes.

Audit logs for anomalous authentication and lateral movement. Prefer certificate-based or hardware-backed authentication and keep FortiOS fully patched. Monitor for the IOCs published in the FBI/USSS advisory.

What happened

Attackers compromised the third-party operators of the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) country-code top-level domains, then altered authoritative DNS records and nameserver delegations for selected domains.

With control of DNS they passed domain-control validation and obtained unauthorized HTTPS certificates covering several Google domains plus domains belonging to other large global brands and popular online services. Google systems themselves were not breached, and the issuing certificate authorities followed normal procedures. Google learned of the hijacks last week, blocked the rogue certificates in Chrome via CRLSets, coordinated revocations with the CAs, and notified other affected organizations identified via Certificate Transparency logs.

Who is affected

Any domain under .gh, .sl, or .as during the window of compromise, plus the specific Google properties and third-party brands for which unauthorized certificates were issued. Chrome users are protected by the CRLSet blocks; users of other browsers rely on the CA revocations. The full set of impacted domains may not have been exhaustively identified.

Why it matters

Valid certificates issued after a registry-level DNS hijack enable convincing man-in-the-middle or phishing attacks that bypass normal trust indicators. The incident demonstrates that the weakest link in the HTTPS ecosystem can sit above both the domain owner and the CA, undermining assumptions about certificate authenticity even when all parties follow the rules.

It also shows the value of rapid browser-side blocking and Certificate Transparency monitoring.

How it could have been prevented

Organizations with any presence under the affected ccTLDs should immediately review Certificate Transparency logs for unexpected issuances and request revocation if found. Implement CAA records, monitor DNS changes, shorten certificate lifetimes where possible, and treat registry or registrar security as part of the supply-chain risk assessment. Browser vendors and CAs should continue reducing DCV reuse windows and certificate validity periods.

What happened

OX Security analyzed 15,465 publicly indexed Model Context Protocol (MCP) servers across major registries, deduplicated to 5,095 unique hostnames, and found systemic governance failures.

Key findings include 15.6 percent of hostnames resolving outside the United States (including infrastructure in China and Russia), 0.45 percent routing through consumer tunneling services such as free ngrok on personal machines, and 2.3 percent dangling domains (six of which were expired and available for registration at low cost). Remote servers can run code that differs from any public repository, and prompt-injection tests showed how standing "always-allow" permissions can be abused.

Who is affected

Enterprises and developers connecting AI agents, IDEs, and models to public or community MCP servers for tools and data. Any organization that has adopted MCP without inventorying or vetting the remote endpoints is exposed. The protocol itself is widely used after its 2024 introduction as a standard connector.

Why it matters

MCP effectively places AI agent traffic outside traditional cloud governance, Zero Trust, data-residency, and supply-chain controls that enterprises spent a decade building. Data can silently flow to unapproved jurisdictions or attacker-controlled infrastructure, and abandoned domains create easy takeover paths. Trust in the marketplace is currently the only control, which is insufficient.

What happened

Security researcher NightmareEclipse (Abdelhamid Naceri) released a proof-of-concept called BigDiskBuster that prevents Microsoft Defender from installing platform and security-intelligence updates while leaving the service fully running and appearing healthy.

The roughly 300-line C++ tool watches for update activity, then creates hidden temporary files that consume remaining disk space so the update fails with a generic error. After Defender cleans up, the tool releases the space and repeats. It can also hold an open handle on MRT.exe. LevelBlue researchers reproduced the behavior under a standard user account on out-of-the-box Defender installations; no vulnerability exploit is required.

Who is affected

Windows endpoints running Microsoft Defender Antivirus, particularly those without additional EDR controls, disk-space monitoring, or tamper protection that would detect the space-filling behavior. The technique works on standard configurations and could extend the life of already-present malware by freezing detection signatures.

Why it matters

Classic EDR-killers disable the product and trigger alerts; this approach creates a silent detection gap. Real-time protection continues, yet the endpoint stops receiving new threat intelligence, giving attackers a longer window of usefulness for their tooling. It demonstrates that update pipelines themselves can be abused without crashing the security product.

What happened

Unauthorized actors abused a private Danish company's legitimate access to the Central Register of Persons (CPR) and extracted names, addresses, and CPR numbers for approximately 8.8 million registered individuals (living, emigrated, and deceased).

The CPR administration detected irregular behavior on 2 October 2026; investigation showed the activity occurred over roughly ten days in September. Access stayed within the data categories private companies are permitted to query. The company's access was terminated, the incident was reported to the data-protection authority, and police are investigating. Discovery was aided by an unusually large invoice generated by the volume of lookups.

Who is affected

Roughly 8.8 million people in the CPR system out of about 11 million total records. Individuals who had enabled name-and-address protection were excluded from those fields. Virtually the entire Danish population (plus emigrants and deceased) is impacted. The private company whose credentials or access were misused is also affected operationally.

Why it matters

A single compromised or abused supplier credential bypassed the core controls of a national identity database, turning a legitimate API-like connection into mass PII exposure. CPR numbers function like Social Security numbers and enable fraud, identity theft, and targeted phishing. The incident is a textbook illustration of why centralized government registries require continuous third-party monitoring rather than static access grants.

How it could have been prevented

Governments and enterprises must enforce least-privilege data access for every supplier, implement real-time monitoring and rate-limiting of query patterns, and baseline normal behavior so anomalous bulk lookups trigger alerts immediately.

Require strong authentication, short-lived sessions, and continuous risk scoring of vendor connections. Citizens should treat unsolicited requests that quote their CPR details as suspicious and verify through official channels only. Organizations should retain only necessary data and rehearse supplier-compromise playbooks.