The Watch

Why two federal agencies are working one firewall bug

The FBI and the Secret Service are jointly billed on FortiBleed. That pairing is the detail to brief upward. The bug is being handled as a national-security case and a financial-crime case at once, because the compromised asset is an edge device that sits on the perimeter and the control plane simultaneously. An attacker who owns a Fortinet firewall has no lateral movement to do. The keys are already on the box.

The kill chain is textbook valid-accounts abuse. Stolen credentials lead to account manipulation (T1098) and new admin creation (T1136). Owner lockout follows through password and account changes, and ransomware impact (T1486) closes it out. The access is either resold or used directly as a ransomware on-ramp. The reporting says more than 400,000 firewalls have been targeted. Targeted and compromised are different counts. With an active campaign minting admins, the only defensible working assumption for an internet-facing Fortinet device is that it is in scope.

The trap: patched firmware keeps the rogue admin

No firmware update deletes an administrator account an attacker already created. A rogue admin and an owner lockout persist straight through a patch. Remediation means reconciling every admin account against an approved list and revoking anything that can't be explained. It also means resetting credentials across the estate.

The same reporting cites a collapsing dwell time. Former NSA director Paul Nakasone's 29-minute figure measures the gap between initial access and impact. At that speed, manual containment loses the race. Runbooks that still depend on an analyst spotting the change and revoking by hand are already behind. FortiBleed is the business case for automating credential revocation and host isolation through SOAR.

The move

• Hunting comes before patching. The highest-leverage action is reconciling Fortinet admin accounts and reviewing logs for unauthorized account and password changes (T1136, T1098, T1078). The standard is to handle any anomaly as active compromise and not as config drift.
• The management plane gets locked down. That covers restricting external management-interface access and enforcing MFA on every admin and VPN identity. Admin secrets move into a vault or PAM.

FortiBleed is an identity incident being tracked as a firmware vulnerability. The fix that matters is deleting the attacker's admin account, and updating the firmware around it leaves that account in place.

The one line to carry out of both advisories

Dell and Atlassian shipped unrelated fixes that fail the same way against a competent attacker: the patch and the eviction are two separate jobs. Dell's 18 critical flaws include token forgery and credential theft on storage and server-management infrastructure. An attacker who forged a signing token or harvested stored credentials before the update still holds a working key after it. A token-forgery flaw means the signing material is burned. The fix for that is rotation.

The Dell scope is wider than one more critical patch because of where it lands. Auth bypass plus root on a storage or server-management plane puts the attacker beneath OS-level EDR. Control of the array is control of snapshots and replication, the recovery mechanism ransomware crews delete before they encrypt (T1490). Kubernetes storage integrations (CSI drivers) keep array credentials in Secrets, which makes them a two-way bridge between clusters and the storage plane. Dell's CVE IDs sit in Dell's own advisories. Scoping starts with pulling them and mapping all 18 to the CMDB.

Atlassian: a 9.3 unauthenticated file read reaches credentials

CVE-2026-21589 is an unauthenticated arbitrary file read in Atlassian Data Center products, including Confluence and Bitbucket, scored CVSS 9.3. The caveat that the attacker must know the exact path is thin. Data Center installs share a documented, standardized directory layout, so one working path works on thousands of installs, and a diff of the fixed build surfaces the targets within days. A 9.3 for a web-root-bounded read says Atlassian considers the reachable content sensitive. Config, properties and credential-bearing files are in play, along with the backups and tokens admins drop into web roots.

Internet-facing Confluence has been one of the most reliably exploited enterprise platforms for years. CVE-2022-26134 was mass-exploited as a zero-day. CVE-2023-22515 was tied to Storm-0062, and CVE-2023-22518 delivered Cerber ransomware. None of that attributes this CVE to anyone. It is the base rate for how fast this product class gets hit once a fix is public.

The work order

1. Internet-facing nodes get patched first, then rotation follows. On Dell, that covers admin credentials, API tokens, service-account secrets and the K8s Secrets holding array credentials. On Atlassian, it covers every credential readable from the web root.
2. A retro hunt belongs in the same window. In Atlassian access logs, the target is unauthenticated HTTP 200s on non-asset files (.xml, .properties, .cfg, archives). In Dell management-plane and K8s audit logs, it is new admin accounts and snapshot/replication policy changes.
3. The escalation trigger is agreed in advance. A public PoC, a CISA KEV listing or in-the-wild reporting moves internal-only nodes into the emergency patch window.

Patching closes the path. Rotation is what removes an attacker who already used it.

Where the failure actually lives

Most of your resolvers are already fine. Anything doing RFC 5011 automated trust-anchor updates picked up KSK-2024 months ago, because the key has been published in the root zone well ahead of the switch. The outage risk is concentrated precisely where that automation never reached: hardcoded trust anchors, golden images and containers with an old root.key baked in, appliances on stale firmware, and air-gapped or isolated resolvers. If the root key isn't trusted, validation fails at the top of the chain and essentially every lookup returns SERVFAIL — a full name-resolution outage, not a degradation.

Two properties make this nastier than a normal maintenance item. First, the timing: the rollover lands on a Sunday, and the root DNSKEY TTL is 48 hours, so cached data can mask the failure until Monday or Tuesday when the workforce logs back in. Second, the sharpest edge case — DANE-enforcing mail gateways, where a resolver failure doesn't just slow mail, it halts delivery outright.

Verify, don't assume

For reference, the old key is key tag 20326 (KSK-2017) and the new one is key tag 38696 (KSK-2024). Confirm any anchor you inject against IANA's published root trust anchor, not against this briefing. Verification is a few commands:

• BIND 9: rndc managed-keys status — confirm 38696 is trusted.
• Unbound: inspect root.key for the 38696 record.
• Windows Server DNS: Get-DnsServerTrustAnchor -Name . on validating servers.
• Appliances and firewalls: confirm the vendor build includes KSK-2024; rebuild any image carrying a static anchor.

Also confirm TCP/53 and large EDNS responses pass your firewalls, since DNSKEY responses grow during rollover periods. Seed any resolver stood up from an old image in the last 30 days directly — the RFC 5011 hold-down may not have finished.

The one break-glass rule that matters

Publish an on-call runbook with a SERVFAIL-spike alert and a known-signed canary domain whose AD (authenticated-data) flag you watch. The pre-approved fix is injecting the trust anchor — never disabling DNSSEC validation globally. That shortcut trades a visible outage for a silent downgrade that strips your spoofing protection and rarely gets reversed. Staff on-call Sunday through Tuesday to cover the cache tail.

This is the rare security deadline you can hit perfectly by doing nothing visible: verify every validating resolver trusts KSK-2024 before the weekend, and the rollover is a non-event.