Session CRT-20261008 — 8 October 2026 · Afternoon Edition

The source pack asserts 36 systems, but Minnesota’s official statement confirms only that operational technology at more than 30 community water systems was targeted on July 26–27 and that the investigation remained active. CISA separately reported increased targeting of internet-connected water-sector PLCs. That establishes coordinated hostile activity against OT—not that all 36 PLCs were compromised or that attackers changed the physical process. We still lack confirmed victim-by-victim access logs, PLC models, authenticated sessions, logic or setpoint changes, process deviations, and Minnesota-specific attribution. The broader warning about Iranian-affiliated actors does not by itself attribute these incidents.

Operators should activate site-level cyber incident command today, with operations, process safety, IT/OT security, management, and public-information roles assigned. I would place continuity plans on standby rather than automatically switching every plant to manual operation; activate continuity procedures where there is loss of control or visibility, operator lockout, or unexplained process deviation. In Purdue terms, targeting may begin at the external boundary or Level 3, but confirmed unauthorized interaction with Level 1 PLCs turns this into a control-trust and safety event.

The first three safe actions are:

1. Verify the physical process independently: have operators compare HMI readings with local instruments, tank levels, pressure, treatment measurements, alarms, and safe operating limits—without changing setpoints merely to “test” them.
2. Freeze changes and preserve evidence: record system time, screenshots and alarms; export firewall, VPN, remote-access, historian, HMI and engineering-workstation logs; preserve controller configurations read-only where supported. Do not reboot, factory-reset, download logic, or indiscriminately rotate controller credentials.
3. Contain at the boundary under operator control: terminate unauthorized remote sessions and remove direct internet reachability through firewalls, VPNs or jump hosts while keeping PLCs energized and local control available. Test each segmentation change first; disrupting control communications can create the hazard responders are trying to prevent.

I would classify activity as hostile scanning while evidence is limited to unsolicited perimeter traffic with no successful authentication, controller session, configuration change, or process anomaly. The public-safety threshold is crossed by either confirmed unauthorized Level 1/2 access with a safety-relevant action—such as changing logic, setpoints, network parameters or credentials—or correlated physical evidence such as pressure loss, flooding, treatment deviation, unsafe discharge, loss of operator control, or forced manual operation. A single well-supported controller-write event is enough; we should not wait for contaminated water or injury.

Halil, this materially expands exposure, not merely the patch list. The earlier CVE-2026-88779 case was bounded to SAML SP/IdP deployments and demonstrated remote denial of service—not reliable RCE, authentication bypass, or data theft. The current reporting characterizes CVE-2026-88771 and CVE-2026-88772 as independently exploitable, actively exploited RCE flaws; CVE-2026-88772 is specifically described as a pre-authentication DTLS memory-overflow path to shellcode execution. That removes the SAML dependency and changes the likely consequence from “jam the front door” to “enter the building.” Public reporting supports active exploitation, but the evidence available here does not establish its precise geographic breadth.

My triage sequence: (1) inventory every customer-managed ADC/Gateway and classify internet reachability, build, DTLS exposure, and SAML role; (2) immediately withdraw or fail over internet-facing vulnerable appliances while preserving logs, configuration and available volatile evidence; (3) upgrade to a release fixing all three flaws—the reported CVE-2026-88779 fixes, 14.1-73.41, 13.1-64.28 and corresponding FIPS/NDcPP releases, supersede the earlier CVE-2026-88772 affected-build thresholds; (4) hunt across the vulnerable window for exploit requests followed by process execution, unexpected file creation, configuration or account changes, log interruption, and unexplained outbound traffic; (5) after establishing a clean platform, invalidate sessions and rotate appliance-administration credentials plus any backend credentials or keys accessible from the appliance.

Patch-and-monitor is defensible only where the appliance was not externally reachable during the vulnerable period—or where complete, trustworthy telemetry shows no post-exploitation behavior. Isolate when exploit delivery correlates with execution, file writes, unauthorized configuration changes, suspicious egress, or when an exposed vulnerable appliance has missing or cleared telemetry. Rebuild from known-good media/configuration when there is evidence of shellcode execution, a web shell or other persistence, unauthorized privileged activity, altered binaries, or loss of system/log integrity. A scanner hit or bare exploit attempt alone does not prove compromise; post-exploit execution or an inability to trust the appliance does. Patching a compromised edge appliance is just changing the lock while the intruder is still inside.

Fact: Reporting links FortiBleed to automated credential reuse, weak-password attacks, theft of FortiGate configurations and stored administrator passwords, plus deployment of a sniffer capable of intercepting VPN and other authentication traffic. SOCRadar-linked reporting also connects the resulting access to INC and Lynx ransomware operations, consistent with an initial-access-broker model—but that linkage is not proof that every compromised device was resold or used for ransomware. [Wiz; GovInfoSecurity]

Assessment: The trust chain is: reused credential → FortiGate login/session → configuration and authentication-material access → persistent administrator or API identity → resale of durable access. On any device with suspicious successful authentication, configuration export, unauthorized administrator creation, or sniffer evidence, immediately isolate management access and invalidate: every active administrator and VPN session; stolen web-session cookies; refresh/API/automation tokens; unauthorized local, API, FortiManager, and FortiCloud administrators; and credentials demonstrably stored on or transmitted through the appliance during the compromise window. Rotate exposed LDAP bind accounts, RADIUS shared secrets, VPN pre-shared keys, SNMP credentials, backup credentials, webhook/API secrets, and management-platform credentials. Remove unauthorized accounts only after preserving evidence, then rebuild from a known-good image—otherwise a surviving administrator or token can simply recreate access.

For certificates and federation, replace only private-key-bearing material that was readable or exportable from the compromised appliance: VPN/TLS private keys, client-authentication certificates, and any SAML service-provider signing or decryption keys. Update relying-party metadata and revoke the old keys. Do not rotate the identity provider’s SAML signing certificate merely because its public certificate existed on the FortiGate; rotate it only with evidence that the IdP’s private key or control plane was compromised. Likewise, enterprise-wide Active Directory passwords, every employee password, unrelated cloud keys, public-only certificates, and service credentials absent from the configuration or observed traffic are wasteful rotations without evidence. The key unknown is exactly which secrets were readable and which identities authenticated while interception was active.

Same-shift CISO decision: Treat evidence-positive FortiGates as identity-compromised infrastructure, not merely vulnerable appliances. Authorize isolation, complete session and token revocation, account inventory and removal, known-good rebuild, and evidence-scoped secret/key rotation before restoring connectivity. For devices showing exposure but no compromise evidence, patch and restrict management access immediately, reset FortiGate-local administrative credentials, and hunt—but do not trigger indiscriminate enterprise-wide rotation.

Halil, the confirmed behavior is narrower than the worst-case blast radius: Black Lotus Labs observed PoeLLM deploying cryptocurrency miners, scanning for additional vulnerable systems, and resolving changing C2 infrastructure through encoded text in a GitHub-hosted poem. Vulnerable LiteLLM and Ollama deployments made up much of the observed victim set. The reported 3,400 systems also include Gitea, Gotenberg, and Ivanti Sentry, but we do not have evidence that every compromised host yielded credentials or cloud-control-plane access.

The plausible downstream risk depends on what each compromised process could read or invoke. Inventory the exposed endpoints first, then immediately map each one to its VM, container, Kubernetes pod, or appliance and its effective identity: AWS instance profile and sts:AssumeRole paths, Azure managed identity, GCP service account, mounted Kubernetes tokens, Docker socket, kubeconfig, environment variables, Gitea deploy keys and CI secrets, registry credentials, and model-provider API keys. A compromised Gitea server or runner is especially concerning because repository write access and deployment credentials can turn one miner infection into a software-supply-chain path. This is not confirmed PoeLLM behavior; it is the blast radius of credentials reachable from the compromised process.

The fastest containment route is to block public ingress to the affected service, isolate the underlying workload without destroying evidence, and revoke or restrict its workload identity before chasing individual processes. Search sibling accounts and clusters for the same images, package versions, public listeners, PoeLLM indicators, unexpected mining processes, and outbound C2 traffic. Then enumerate every principal or secret reachable from the host and follow cross-account trusts. The CSP owns isolation of its underlying platform; exposed services, security-group rules, workload identities, repositories, and secrets remain customer controls. “Managed” still does not mean the attached IAM role manages itself.

A stateless container may be replaced from a verified image without rebuilding the node only when telemetry shows the compromise stayed unprivileged, no host mounts or Docker socket were exposed, no credential material was reachable, and integrity can be established. Rebuild the VM or Kubernetes node—and rotate all reachable secrets—if PoeLLM ran as root, modified persistence such as authorized_keys, had host-level mounts, reached cloud metadata or workload tokens, accessed Gitea/CI secrets, or operated during a period with incomplete telemetry. Unknown dwell time plus secret access should be treated as exposure: revoke sessions, rotate keys and tokens, repair trust policies, and redeploy from known-good images rather than attempting artisanal malware removal.