Session CRT-20260909 — 9 September 2026 · Afternoon Edition

The BIG-IP APM issue now warrants same-day incident handling, not passive monitoring. CISA establishes exploitation of CVE-2025-53521, with exposure tied to an APM access policy attached to a virtual server across specified 15.1 through 17.5 branches. Sophos and ESET substantiate a Linux implant that conceals a web shell by manipulating PHP processing in memory. What remains uncertain is whether that implant accompanied every exploitation event and whether CVE-2025-53521 was conclusively its delivery route. Internet-exposed systems currently or previously in scope should be isolated, preserved for evidence, scanned, restricted, and upgraded to a fixed release.

The supply-chain picture divides into two incidents. UNC6780/DUSTMAKER concerns compromised development resources and credentials: malicious GitHub Actions behavior, theft of runner tokens and injected secrets, tampering with @bitwarden/[email protected] and xinference, and targeting of Claude and MCP credentials. ChainDrop, by contrast, was a registry-propagating npm worm reported to have poisoned 444 packages and 2,212 versions. We should not merge those campaigns without shared infrastructure or attribution evidence.

BigBear’s reported 1,032 plaintext passwords, 4,148 session cookies, and completed MFA-bypass records across 258 organizations strengthen the scope claim, but they do not independently confirm compromise in every tenant. The core identity conclusion is unchanged: BigBear suppresses WebAuthn to induce weaker authentication, then captures replayable session cookies. Mandatory WebAuthn without fallback should fail closed. In the Hemi case, the evidence points to reentrancy and delayed balance accounting—not stolen keys—behind roughly 124.5 million HEMI drained through 63 recursive calls. The call count and Upbit cancellation remain report-level or secondary claims, and the current freezeability of proceeds is unknown.

The remaining edge-device gap is FortiGate. We will now apply the same standard used for N-central and BIG-IP: separate confirmed exploitation and malware evidence from inference, then identify what defenders can justify doing immediately.

The FortiGate claim is substantially less mature than the BIG-IP APM finding. The available evidence is a single SOCRadar report describing exploitation of CVE-2025-25249, a heap-based buffer overflow in the cw_acd daemon affecting FortiOS/FortiGate and FortiSwitchManager, to obtain a reverse shell. We do not have a primary-source affected-version matrix, so specific version claims should not yet be treated as verified or used as the sole basis for fleet-wide action.

The same caution applies to PivotC2. SOCRadar describes a Node.js RAT with persistent TLS command-and-control, shell access, file transfer, proxying, scanning, configuration theft, and credential decryption capabilities. But the reported scale—more than 30,000 targeted IPs, 178 infections, and two exfiltration cases—has not been corroborated here by Fortinet, CISA, or independent malware analysis. That leaves both the deployment link and the campaign’s reported reach materially less certain than the BIG-IP case, where government, vendor, and independent findings converged.

The operational posture is therefore immediate monitoring and verification, not automatic fleet-wide isolation. Teams should establish whether they run an affected build once an official matrix is available, assess whether cw_acd was reachable from an untrusted network, and patch when applicability is confirmed. Confirmed exposure of an affected version through that daemon is a clear threshold for same-day isolation and hunting.

James can now close the room by converting these differing confidence levels into an operational response model: decisive action for KEV-confirmed N-central exposure, same-day incident handling for the better-corroborated BIG-IP threat, and verification-led escalation for FortiGate.

The operational priority is now much clearer: active exploitation and exposed attack paths—not the raw count of monthly fixes—drive today’s response. Internet-reachable N-central systems require immediate upgrade to 2026.3 HF4, build 2026.3.1.14, or removal of external access. Because appliance telemetry is limited, teams should preserve snapshots and collect proxy, firewall, and EDR evidence before rebooting. Unexpected processes, administrator creation, API activity, or downstream agent commands should be treated as evidence of compromise requiring containment and rebuild, not as a condition resolved by patching alone.

For BIG-IP, the emergency scope is narrower and should remain configuration-driven: prioritize exposed virtual servers with an APM policy attached. Patch or withdraw that exposure today and investigate unexpected binaries, kernel modules, and configuration changes. Exposure by itself calls for patching and hunting; confirmed post-exploitation raises the response to isolation and credential rotation. The two Windows privilege-escalation fixes remain high priority, but James has given us a controlled deployment sequence: privileged workstations, jump hosts, and RDS or VDI first, followed by management and identity systems, then the broader estate. Each ring needs boot, authentication, EDR, and application-health validation, alongside hunting for transitions from low privilege to SYSTEM.

FortiGate remains in the monitor-and-verify category. We still lack a sufficiently verified affected-version basis for precise fleet action, so that reporting should not displace the KEV-backed priorities. The room has therefore closed the vulnerability discussion with a defensible hierarchy: act immediately where exploitation and scope are established, deploy carefully where operational risk matters, and preserve uncertainty where evidence remains incomplete.

The next question shifts from infrastructure exploitation to identity assurance: whether the reported organized deepfake campaign reveals a specific weakness in liveness checks, device-reuse detection, document validation, or out-of-band verification—and which control should change first if it does.

The identity-control gap has narrowed to cross-session correlation, not a demonstrated defeat of liveness technology. The reported 22.49% figure covers crypto-sector verification requests classified as identity fraud in Shufti’s H1 2026 dataset; it does not mean those attempts succeeded, involved deepfakes, or represent the cryptocurrency industry as a whole. Similarly, linking 70 identities through 13 devices may indicate organized device reuse if the linkage is sound, but it does not establish that every identity passed KYC or produced financial loss.

The consequential question is whether any of those linked identities became approved or funded accounts. If they did, the likely weakness was evaluating each document and liveness event in isolation rather than correlating device fingerprints, identity velocity, reused-document attributes, network infrastructure, and beneficiary overlap. We also cannot conclude that out-of-band verification failed: the available evidence does not tell us whether it was used or whether the supposedly independent channel relied on email or phone accounts controlled by the attacker.

For same-day action, Marcus’s trigger is internal evidence that a reused-device cluster generated multiple approved identities or funded accounts. That should prompt quarantine of the cluster and suspension of associated sessions and withdrawals while the links are investigated. As we move to synthesis, the key distinction to preserve is between evidence of concentrated, coordinated fraud attempts and proof that deepfakes defeated specific controls or resulted in successful account abuse.