Session CRT-20260916 — 16 September 2026 · Morning Edition

Tonight’s defensive sequence is now explicit: vCenter first because of reported ransomware exploitation and reverse-SSH persistence, exploited Gitea second because attackers may reach repositories and release infrastructure, and 3BB-like FortiGate exposure third unless telemetry shows unauthorized access—at which point immediate isolation takes precedence. Across all three, evidence preservation should precede patching where feasible, followed by restoration through a clean replacement or trusted rebuild. That ordering does not reduce the seriousness of the FortiGate reporting: it reflects that the detailed 3BB compromise account remains third-party evidence, while observed indicators should still trigger a presumption of compromise.

Identity containment also extends well beyond password resets. Comparable victims should disable implicated maintenance and shared vendor accounts, terminate active sessions and tokens, isolate both the access appliance and maintenance endpoint, and rotate reachable SSH keys, database credentials, API tokens, and other secrets. The caveat matters: 3BB reporting describes harvesting attempts, not proof that every discovered secret was successfully exfiltrated. For Gitea, repository theft and stolen publishing credentials establish serious exposure but not, by themselves, release poisoning. It becomes a software-supply-chain incident when access reaches commits, tags, CI workflows, signing identities, artifacts, registries, provenance, or downstream-consumed outputs.

The rsETH case sharpens a different boundary. Available reporting places the failure in a custom module using delegated Safe authority, not in Safe core, Uniswap v4 core, or—based partly on Kelp DAO’s own statement—Kelp core. The broken invariant was that an untrusted caller could influence pool or hook selection while moving wallet assets. The immediate containment is to disable the module and revoke its Safe authorization wherever deployed until callers and destinations are tightly constrained.

One tension now needs testing: the operational ranking puts FortiGate third, yet the source pack scored the 3BB compromise at maximum severity. We should challenge whether evidence confidence, demonstrated exploitation, and potential blast radius have been weighted consistently before that order becomes tonight’s final directive.

The priority order is now conditional rather than fixed. For an affected, internet-exposed FortiGate, James moves it to the front of tonight’s queue, ahead of vCenter and Gitea. The deciding factor is not the source pack’s 10/10 rating or acceptance of every reported 3BB detail; it is the combination of local reachability, vulnerability, and independent confirmation that CVE-2024-21762 has been exploited, including its presence in CISA’s KEV catalog.

That distinction matters. The reported 3BB intrusion chain remains unconfirmed by the victim, so MeshCentral indicators and other reported artifacts are hunting leads, not universal signatures. The immediate defensive course is to disable SSL-VPN or fail over to a clean appliance, while first preserving configuration, firmware information, administrative and SSL-VPN logs, active sessions, routing state, and SIEM copies. Unauthorized privileged access, persistence, configuration or firmware integrity loss, credential access, or telemetry too weak to exclude those conditions would support rebuilding rather than continued monitoring. Once that perimeter risk is contained, attention returns to vCenter and then Gitea.

James began to identify an exception involving a FortiGate demonstrably on a fixed release and not reachable during the relevant exposure period, but the recorded response ends before that condition is fully stated. We should therefore retain the central rule without extending the unfinished exception: verified exposure and reachability determine urgency; observed intrusion depth and evidentiary gaps determine whether replacement or rebuilding is warranted.

That same separation between vendor urgency and environment-specific risk now carries into the Microsoft Remote Desktop Services question: an emergency out-of-band release is a strong signal, but the next test is whether that label alone justifies same-night deployment.

Microsoft’s “emergency” label has not, by itself, established a same-night security mandate. James separates the cited out-of-band update—which addresses RDS instability introduced by September updates—from CVE-2026-69525, a separately rated 9.8 unauthenticated vulnerability. At the cited publication point, ZDI reported neither public disclosure nor observed exploitation. That does not make the vulnerability harmless, but it means release cadence and severity score alone should not determine deployment timing.

The operational test is exposure and consequence. Deploy tonight if the affected RDS role is externally reachable without effective protection, if relevant exploitation is detected, or if the regression is already disrupting a critical service. Otherwise, James recommends testing first on one drained session host before rolling through the farm. RDS rises above vCenter only when RDP is publicly reachable, September security fixes are missing, and firewall or RD Gateway controls cannot promptly remove that exposure. Under the stated default conditions, the order remains exposed FortiGate CVE-2024-21762 first, vCenter CVE-2026-59310 second, and the RDS stability update third.

That judgment was not peer-challenged in this action, so we should retain its stated evidentiary limits rather than treat it as universal. The final synthesis can now anchor priority in verified local conditions: affected assets, internet reachability, active exploitation evidence, service impact, and available compensating controls—not vendor urgency language alone.