This Week in Cybersecurity: Atlassian's File-Read Flaw, a FortiMail Zero-Day, and Denmark's 8.8 Million-Person Breach

Explore this content with AI:

ChatGPT | Perplexity | Claude | Google AI Mode

Atlassian patches a critical file-read flaw across eight Data Center products as exploitation attempts begin

Atlassian disclosed CVE-2026-21589, a critical flaw (CVSS 9.3) that lets an unauthenticated attacker who knows a file's exact name and path read files in the web root directory. It affects the self-hosted Data Center versions of Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo, Crowd, Crucible, and Fisheye. Atlassian's cloud customers were patched automatically, but Data Center administrators need to move to the fixed releases listed in Atlassian's bulletin, such as Confluence 9.2.26 or 10.2.19.

The timeline is what makes this one urgent. Atlassian published its advisory on October 5, and watchTowr then released a technical report and a public proof of concept. The Hacker News reports that Previdian's honeypots recorded exploitation attempts within two hours of that publication, and Previdian's sensors had logged 187 attempts from 31 IP addresses in nine countries by October 8. watchTowr says it has observed in-the-wild exploitation, Infosecurity Magazine reports that VulnCheck saw activity targeting Bamboo Data Center, and no post-compromise activity has been reported so far. Eight Atlassian flaws are already in CISA's Known Exploited Vulnerabilities (KEV) catalog, so attackers know this product family well. As of October 8, CVE-2026-21589 was not yet in CISA's catalog, though VulnCheck's list added it on October 7.

Why it matters: Collaboration and ticketing platforms hold design documents, credentials pasted into tickets, and links into everything else, so a file-read bug is rarely "just" a file-read bug. Patch Data Center instances now, restrict external access to anything that doesn't need it, and review access logs for the path-traversal patterns described in Atlassian's bulletin. When public exploit code lands within days of an advisory, a monthly patch cycle is too slow for internet-facing systems.

Read more at SecurityWeek

Fortinet's FortiMail zero-day is under attack, and CISA gave federal agencies three days to respond

Fortinet disclosed CVE-2026-104286 on October 1, a critical (CVSS 9.8) flaw in FortiMail that combines path traversal with improper handling of NULL bytes, letting an unauthenticated attacker write arbitrary files through crafted HTTP or HTTPS requests. Fortinet confirmed exploitation in the wild, though it hasn't said when the attacks began, how many appliances were hit, or who is behind them. CISA added the flaw to its KEV catalog the same day and set an October 4 deadline for federal civilian agencies.

Affected releases include FortiMail 8.0.0 through 8.0.1, 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9. Fixes were not ready at disclosure, but Fortinet's advisory (FG-IR-26-175, last updated October 7) now lists fixed releases: upgrade to 8.0.2, 7.6.7, or 7.4.9 or later, and move 7.2 customers to the 7.4 branch or later. Fortinet says FortiMail Cloud was fixed on October 5, so Cloud customers need no action. For anyone who can't upgrade immediately, the workarounds are to disable the IBE service, restrict access to the FortiMail webmail interface to trusted private networks, or, if a web application firewall sits in front, block POST requests to /ibe that contain "../".

Why it matters: Email gateways sit in front of stored mail, credentials, and connected systems, and this flaw needs no login. If you run FortiMail, upgrade to a fixed release now, and until you do, apply the IBE workaround and take the webmail interface off the open internet. Because exploitation began before a patch existed, treat any previously exposed appliance as potentially compromised and look for unexpected files and new accounts.

Read more at Cybersecurity Dive

A poisoned tensorlake npm release steals developer secrets and wipes machines if you revoke the stolen token

Tensorlake version 0.5.144 was published to npm on October 8 carrying a Shai-Hulud-style credential-stealing worm. According to StepSecurity, the first malicious commit landed on the project's main branch on October 7 under a maintainer's name, and the release went out through the project's own release workflow, so it carries a valid npm provenance attestation. Aikido reports the package has more than 100,000 lifetime installs and that Tensorlake's PyPI and Cargo packages were not reported as compromised.

The payload is built for developer machines. A preinstall hook skips CI environments, downloads the Bun runtime, and runs an obfuscated script that steals GitHub and npm tokens, cloud keys, Kubernetes and Vault secrets, SSH keys, saved browser logins, and AI tool configurations. It spreads by republishing the victim's npm packages with a stolen token and by committing .claude and .vscode files to the victim's repositories so it runs again when someone opens the project in Claude Code or VS Code. The nastiest detail: with a GitHub token, it installs a monitor that checks the token every 60 seconds for up to 24 hours and deletes the user's home directory if GitHub rejects it, so revoking the token triggers the wipe. No threat actor has been named. [Mollie: both sources describe the payload as Shai-Hulud-style; I did not link it to TeamPCP or any group because neither source does.]

Why it matters: A valid provenance attestation proves where a package was built, not that it's safe, and this release was built from the project's own compromised repository. If anyone on your team installed tensorlake 0.5.144, treat that machine as fully compromised: isolate it, remove the token monitor before rotating anything, then rotate every secret it could reach. Longer term, disable install scripts by default, pin dependencies, and hold brand-new package versions for a short cooling-off period before they reach developer laptops or build systems.

Read more at Aikido

China-aligned TA419 impersonates AI policy figures to steal Microsoft logins

Proofpoint says the China-aligned espionage group TA419 has been posing as prominent economists, AI policymakers, and even a senior Anthropic employee to reach AI policy experts at US think tanks, universities, and law firms. According to The Hacker News, a February email sent to a think tank analyst carried the subject line "Request for Feedback on Military Integration of Claude," and around July the group impersonated a former White House science-policy official. The activity fits a pattern: Proofpoint has tracked TA419 phishing think tanks, defense contractors, universities, and law firms since at least April 2025.

The attack chain is patient. The first email is a harmless invitation. Only after the target replies does the attacker send a shortened link, which passes through a redirect chain and a Cloudflare Turnstile check before landing on a fake OneDrive page. That page uses a browser-in-the-browser technique and an adversary-in-the-middle proxy that relays credentials to the real Microsoft sign-in, so the login succeeds, and the victim sees nothing unusual while session cookies are stolen. Proofpoint assesses the goal is "likely" to understand US AI policy and regulation, and no victim counts or confirmed compromises have been reported.

Why it matters: There's no malware to detect here, only a convincing conversation and a login page that works. Move users with access to sensitive policy, legal, or research data to phishing-resistant authentication such as passkeys or hardware security keys, because one-time codes and push approvals can be relayed. And teach people that an unsolicited invitation to advise, speak, or review something is a reason to verify the sender through a separate channel first.

Read more at Nextgov/FCW

Hackers abuse a private company's registry access to expose 8.8 million people in Denmark

Denmark's Central Person Register (CPR), the national civil registry, disclosed this week that attackers abused the legitimate access of a private Danish company to pull personal data on about 8.8 million people, roughly 80% of the 11 million records in the system.

BleepingComputer reports that the incident occurred in September, that CPR became aware of it on October 2, and that the Danish Data Protection Agency says the attackers used some form of brute-forcing to enumerate valid CPR numbers and then extract the related data. The exposed data includes names, addresses, and CPR numbers, Denmark's equivalent of Social Security numbers, for both living and deceased people. People who registered name and address protection were not affected.

CPR has blocked the company's access, and police have opened an investigation. Denmark's digitalization minister called it an "extremely serious incident" and urged residents to be wary of unsolicited calls and emails, even from someone who knows their name, address, and CPR number. No threat actor has been named, nor has it been explained how the company's access was compromised.

Why it matters: The weak point wasn't the registry's own perimeter; it was a trusted third party with lawful access. Inventory every partner, vendor, and integration that can query your sensitive data, and ask whether each one is rate-limited, scoped to the minimum records it needs, and monitored for enumeration patterns like thousands of sequential lookups. Also expect the stolen identifiers to fuel convincing phishing and fraud attempts for a long time.

Read more at SecurityWeek

Final thoughts

Look at this week's stories side by side, and the pattern is speed. Public exploit code for Atlassian's flaw drew attack attempts within hours. FortiMail attackers got a head start because no fix existed when the flaw became public. A poisoned npm release went from commit to credential theft in about a day, with a trap that punishes the obvious cleanup step. In Denmark and in TA419's phishing, attackers didn't need to break anything, because a trusted login or a believable conversation did the work.

If there's one action item, it's to shrink your own response time: know which internet-facing systems you run, keep management interfaces off the open internet, slow down how fast new package versions reach developer machines, move high-value accounts to phishing-resistant sign-in, and prioritize fixes by what's being exploited right now.

Check back next Thursday for the next edition of This Week in Cybersecurity.