Colorado Water Controls Jump the Queue Without a Proven Safety Effect

Two Colorado water providers reportedly had remote access and alarms disabled and pump cycles changed, although treatment and water quality were reportedly unaffected. Take the safety lens only: distinguish nuisance-level control access from a repeatable unsafe process path, identify the evidence operators must preserve to make that distinction, and give a concrete same-day containment and safety-validation sequence for small utilities. State what remains unknown and do not infer attribution.

The reported pump-cycle changes already show process influence, not merely an IT intrusion. But they do not yet establish a repeatable unsafe-process path. The critical distinction is whether attackers changed only HMI schedules and annunciation at Purdue Level 2, or could write PLC logic/setpoints at Level 1, suppress independent protective functions, and reproduce commands that push pressure, storage, or treatment outside safe limits. “Alarms disabled” must also be resolved: silencing an HMI alarm is materially different from defeating a controller interlock. Reporting says operators intervened and treatment, water quality, and public safety were unaffected.

For the same day, I would sequence the response this way:

1. First 30 minutes: Put the senior operator in control. Locally verify tank levels, pressure, pump states, chemical feed, and applicable water-quality measurements using independent instruments—not only SCADA displays. Stabilize the process; move selected equipment to local/manual control only where the operating procedure says this is safe.
2. In parallel, preserve evidence before rebooting anything: Export HMI/SCADA audit and alarm histories, historian trends, remote-access/VPN and firewall logs, engineering-workstation events, controller mode/change logs, and current PLC/HMI configurations. Photograph screens and panel indications; record device clocks and operator observations; preserve known-good logic, recipes, schedules, alarm limits, and network configurations for comparison.
3. Within 30–90 minutes: Disable the compromised remote-access path at the Level 3/3.5 boundary, terminate vendor sessions, and revoke exposed accounts. Do not indiscriminately disconnect PLC-to-HMI or safety-related communications. CISA’s water-sector guidance recommends removing direct PLC internet exposure, controlling remote access through VPNs or gateways, replacing default credentials, and restricting approved source addresses.
4. Within four hours: From a known-clean engineering station, compare live logic, firmware-visible configuration, setpoints, pump schedules, alarm limits, user accounts, and communications settings against approved baselines. Function-test alarms and pumps one at a time under operator control; validate segmentation changes in a test or controlled maintenance process first.
5. For the rest of the day: Maintain staffed local rounds and enhanced water-quality sampling, document every intervention, and restore remote access only through a tightly allowlisted, monitored path with fresh credentials. If trustworthy baselines are unavailable, continue local/manual supervision rather than declaring the system clean.

The unsafe path is demonstrated only if evidence links the external session to controller writes or repeatable process commands, shows that protective limits or interlocks could be bypassed, and correlates those commands with physical response. What remains unknown is which devices and Purdue levels were reached, whether PLC logic or only HMI settings changed, what kind of alarms were disabled, whether credentials or persistence remain, and whether the actor could reproduce the changes after containment. There is no basis here to infer attribution.

Triage the active internet-facing exploitation set for a CISO with six hours: WordPress CVE-2026-87902, GlobalProtect CVE-2026-0257, AhsayCBS CVE-2026-105133/CVE-2026-105134, PeopleSoft CVE-2026-35273, and PoeLLM/LiteLLM CVE-2026-42271. Rank them by credible kill-chain closure and blast radius, separate patch-now from assume-compromise, and name the single artifact or telemetry source that would most change your priority for each. Treat yesterday’s Ahsay conclusion as established and identify only today’s delta.

Halil, my six-hour ranking is:

1. AhsayCBS — strongest kill-chain closure: unauthenticated chaining, JSP web shell, NT AUTHORITY\SYSTEM, XMRig, and service-based persistence. Backup infrastructure also concentrates credentials and repositories. Assume compromise.
2. GlobalProtect — authentication bypass has produced confirmed compromises across multiple environments, with ransomware activity reported. An exposed security gateway is a bridge into the network, not merely another server. Treat vulnerable exposure during the exploitation window as presumptive compromise and start IR.
3. PoeLLM/LiteLLM — reporting says more than 3,400 exposed servers were compromised in a cryptomining campaign. That demonstrates scalable execution, but the available evidence does not show broader post-exploitation objectives. Patch now; assume compromise where exposure and version overlap.
4. PeopleSoft — the flaw is linked to a breach at an FBI contractor, so the chain can reach a data-theft objective. Evidence of broad, repeatable exploitation is less complete than for the first three. Patch now and hunt.
5. WordPress — active exploitation is reported, and patching does not clean an already-hit site. But the evidence available here does not establish campaign scale or a complete post-exploitation chain. Patch now and hunt; do not automatically declare every exposed site breached.

The one priority-changing source for each: Ahsay: Windows service telemetry showing the fraudulent Edge update service. GlobalProtect: portal/gateway access logs matching the reported PAN GlobalProtect/6.0.0 user agent or 104.207.144.154. PoeLLM/LiteLLM: the service-host process tree showing a spawned shell or miner. PeopleSoft: application audit records showing an unauthorized privileged session. WordPress: a known-good webroot comparison showing newly created or modified PHP files.

Today’s Ahsay delta is only additional reporting corroborating web-shell and XMRig deployment. It does not change yesterday’s decision: exposed, vulnerable systems remain in the assume-compromise lane. For WordPress, PeopleSoft, and PoeLLM/LiteLLM, exploit-request details and victim-side forensic evidence remain incomplete, so I would not confuse internet exposure with proven breach.

The U.S.-UK alert links Integrity Technology Group infrastructure and its MicroScan platform to Flax Typhoon and other China-linked operations. Identify what is genuinely new relative to the prior public linkage, grade the confidence separately for infrastructure ownership, operational enablement, and Chinese state direction, and tell defenders which behavioral detections survive if the attribution is wrong. Challenge the hero framing if today’s operational delta is weaker than the headline suggests.

The headline overstates the attribution delta. The earlier FBI domain seizure had already publicly connected Integrity Technology Group infrastructure with Flax Typhoon. What is genuinely new is the operational detail: MicroScan’s 1,300-plus testing scripts, EBurst password spraying, SoftEther persistence/C2, DC.exe credential theft, and office-cli mailbox collection—plus the claimed support to a broader China-linked actor set and clearer Southeast Asian victimology.

• Infrastructure ownership — High confidence: converging FBI seizure and allied-government reporting tie the infrastructure to Integrity.
• Operational enablement — High confidence for the documented toolchain; moderate for every named actor linkage: the alert describes a coherent access-to-collection workflow, but shared infrastructure alone does not prove common operators.
• Direct Chinese state direction — Low confidence: support for Beijing-linked operations is documented; case-specific government tasking, command relationships, and operator identity are not publicly demonstrated.

Even if attribution collapses, defenders should retain behavior-led detections mapped to Active Scanning, Exploit Public-Facing Application, Password Spraying, External Remote Services, OS Credential Dumping, Email Collection, and Exfiltration Over Web Service—especially scanning followed by Python/Go exploitation, distributed Microsoft 365 failures preceding success, unauthorized SoftEther deployment, suspicious domain-controller credential access, and sustained automated Outlook collection. This is a richer defensive playbook, not a new attribution victory.

IDC Frontier isolated East Japan Region 1 after ransomware disrupted roughly 495 companies and local governments, with data in four zones potentially unrecoverable. Quantify the board-level decision: what supplier-continuity trigger should customers invoke today, what assurance should they demand before restoring dependency, and when does a controlled migration become less costly than waiting? Give concrete thresholds rather than a broad range.

The board trigger has already fired: declare a critical supplier-continuity event now. Four zones remain stopped, recovery is described as difficult, and 495 organizations are affected. For every Tier‑1 workload, authorize alternate-region/provider restoration immediately if either its contractual RTO has expired or IDC Frontier cannot provide an evidence-backed recovery time by T+24 hours. Do not replicate from the affected region; use customer-held, pre-incident backups.

Before restoring dependency, require five gates: entry vector closed; independent forensic attestation that control-plane persistence is absent; 100% rotation of privileged credentials, tokens and encryption keys; restoration from a verified pre-incident backup with zero unexplained transaction variance; and a 24-hour production-like canary with clean telemetry. That 24-hour validation window—not merely service availability—is the minimum defensible return-to-service threshold.

Use one hard migration test: calculate daily outage cost as lost contribution margin plus SLA liabilities, recovery labor and customer remediation. At T+24, commit to migration when migration and dual-running cost is no more than two days of that outage cost; at T+48, migrate every Tier‑1 workload still lacking a validated recovery time. I found no customer-level revenue or workload data supporting a credible aggregate dollar estimate; boards should therefore apply this break-even equation portfolio by portfolio rather than inventing a headline loss.

P7 DarkSword was discussed previously as a drive-by iOS chain with kernel access, but today's reporting adds use by multiple operators, two-way command and control, and theft targeting credentials, Keychain data, photos, notes, and cryptocurrency wallets on iOS 18.4-18.7. Identify the real delta, distinguish demonstrated capabilities from unproven victim or operator claims, and give an enterprise decision rule for update, quarantine, and evidence preservation. Argue against treating every device in the versi... [arg clipped]

The real delta is post-compromise operational maturity, not a newly proven infection vector. Google reports DarkSword supports iOS 18.4–18.7, chains six vulnerabilities, and has delivered three malware families—GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER—with at least one suspected Russian espionage cluster, UNC6353, using it in watering-hole campaigns. iVerify’s P7 analysis demonstrates two-way tasking: 15-second beacon polling, a command dispatcher, raw-file upload, application inventory, and handlers targeting Keychain and wallet material, photos, and notes. That turns a drive-by kernel compromise into an interactive collection platform.

But capability is not victim telemetry. The implant code demonstrates that operators can request and exfiltrate those data classes; it does not prove every function ran on every infected phone, that cryptocurrency was transferred, how many victims exist, or that every reported operator is independently identified. Likewise, an iPhone running 18.4–18.7 is vulnerable—not automatically compromised. Treating the entire version cohort as infected would create unnecessary disruption while obscuring the smaller population needing forensic handling.

My enterprise rule is: update broadly, quarantine selectively, preserve before remediation when suspicion is concrete. Enforce the latest Apple-supported release immediately across every device in the affected range. Quarantine a device from corporate access when there is a credible watering-hole exposure, mobile-threat detection, matching network indicator, unexplained account activity, or a high-risk user plus plausible exposure. For that subset, preserve the device and available MTD, DNS, proxy, identity, and MDM records before wiping, upgrading, or returning it to service; issue a clean replacement and rotate credentials, tokens, and wallet secrets accessible from the phone. Version alone triggers urgent patching—not an incident declaration.

PoeLLM reportedly compromised more than 3,400 publicly exposed AI and open-source servers, likely using LiteLLM CVE-2026-42271 alongside exposed Ollama, Gitea, Gotenberg, and Ivanti Sentry services; infected hosts then mined cryptocurrency and scanned for more victims. Determine whether this is primarily an AI-platform issue, ordinary exposed-service exploitation, or a cloud-IAM escalation risk. Give defenders the minimum inventory, containment, credential-rotation, and cloud-audit steps for tonight, and name what evidence wo... [arg clipped]

Halil, this is primarily ordinary internet-exposed service exploitation with AI-heavy victimology—not an AI-model attack. Lumen identified probable exploitation of LiteLLM’s /mcp-rest/test/connection endpoint; Horizon3 reports CVE-2026-42271 can be chained with CVE-2026-48710 for unauthenticated command execution. The campaign also spans Ollama, Gitea, Gotenberg, and attempted Ivanti Sentry exploitation, then deploys miners, provides remote access, and scans onward. Cloud-IAM escalation is a material risk, but remains unconfirmed: the available reporting does not establish theft or use of workload credentials.

For tonight, inventory every public IP, load balancer, Kubernetes Ingress, and NAT exposure associated with LiteLLM, Ollama, Gitea, Gotenberg, and Ivanti Sentry, including owners, versions, ports, and attached workload identities. Hunt LiteLLM logs for requests to /mcp-rest/test/connection and /mcp-rest/test/tools/list, anomalous Host headers, unexpected subprocesses, mining processes, scanning on ports 3000/4000, and outbound connections on C2 ports 3778, 5001, 5002, or 9999. Remove unnecessary public ingress immediately; isolate suspect instances or pods, preserve disk and runtime evidence, block campaign IOCs and unauthorized egress, then rebuild from trusted images rather than merely killing the miner.

Rotate or revoke only after mapping what the compromised process could read: API keys, Git credentials, CI tokens, database passwords, Kubernetes service-account tokens, and static AWS/GCP/Azure credentials. For attached or managed identities, detach or disable the identity, revoke active sessions where supported, temporarily narrow its policy, and rotate every downstream secret it could retrieve. Audit AWS CloudTrail for STS role assumptions and access to S3, Secrets Manager, ECR, and KMS; Azure Activity/Entra logs for managed-identity use, Key Vault, and ACR; GCP Audit Logs for service-account impersonation, Secret Manager, Cloud Storage, and Artifact Registry; and Kubernetes audit logs for secret reads, token creation, exec, and RBAC changes. The CSP owns the underlying platform; public exposure, workload IAM, secrets, and logging coverage sit with the customer—“managed” still does not mean “magically scoped.”

The evidence that would elevate this to a confirmed cloud-IAM incident is post-compromise cloud API activity by the workload identity: metadata-service access, use of stolen keys from a new source, AssumeRole or service-account impersonation, secret retrieval, registry/repository access, IAM-policy changes, new credentials, or cross-account/project/subscription activity. Until that appears, treat the host as compromised and the trust graph as potentially exposed, but do not claim control-plane compromise.

An unidentified attacker allegedly drained 116,500 rsETH, valued around $292 million, through KelpDAO's LayerZero bridge; unsupported assets then reportedly produced about $190 million in Aave bad debt across at least nine protocols. Test those claims rather than accepting the headline: identify the on-chain facts required to establish loss, bad debt, and contagion; state the immediate risk controls for protocols, treasuries, and liquidity providers; and give one threshold for resuming markets. Separate confirmed transaction... [arg clipped]

Confirmed transaction facts: Aave’s incident report records a release of 116,500 rsETH from the Ethereum-side RSETH_OFTAdapter at Ethereum block 24,908,285, following a message over Kelp’s 1-of-1 DVN Unichain–Ethereum route. LayerZero attributes that message acceptance to compromised internal RPCs plus denial of service against the third-party RPC. The resulting rsETH was moved into several branches, including Aave positions on Ethereum and Arbitrum. Aave subsequently froze its rsETH markets and explicitly said its own contracts were not exploited. Chainalysis reports 30,766 ETH in downstream attacker funds frozen by the Arbitrum Security Council.

Inferred exposure—not yet proven loss: The $292 million is the block-time valuation of 116,500 rsETH released, not automatically net economic loss. Likewise, “$190 million in Aave bad debt” appears to conflate borrowing with realized deficit: CoinDesk reports 89,567 rsETH supporting roughly $190 million of borrowing, while Nexus Mutual reports approximately 126,000 WETH borrowed across seven wallets—figures requiring account-by-account reconciliation. Establishing loss requires the release transaction hashes, pre/post bridge reserves, legitimate rsETH liabilities, recoveries and the valuation block. Establishing bad debt requires each account’s debt, recoverable collateral, liquidation proceeds, frozen assets and committed backstop funds. I found no evidence here establishing bad debt across nine protocols; contagion needs a protocol-by-protocol ledger showing contract, chain, rsETH balance, debt, oracle treatment and whether exposure is direct or merely the same collateral counted again.

Immediately, protocols should keep rsETH borrowing and collateral onboarding frozen, set collateral value or LTV to zero until backing is reconciled, cap withdrawals that could shift losses to remaining users, and preserve account snapshots. Kelp and LayerZero should disable the affected route, rotate trust infrastructure and require multi-DVN verification. Treasuries should stop accepting or lending rsETH; liquidity providers should disable automated rebalancing and avoid becoming exit liquidity. Legal and exchange coordination should continue around the already-frozen Arbitrum funds. One resumption threshold: an independently reproducible on-chain snapshot must show that verified redeemable backing plus irrevocably committed recovery funds covers 100% of outstanding rsETH liabilities and affected protocol debt, net of duplicated and frozen balances. Until then, reopening markets would socialize an unreconciled deficit.

Close the operational discussion using these findings: Sara says the Colorado pump changes prove process influence but not yet a repeatable unsafe path; Alex ranks AhsayCBS first and says assume compromise because exploitation reaches SYSTEM with webshell and persistence; Pierre says IDC Frontier customers should already declare a critical supplier-continuity event. Build one six-hour command plan that preserves safety and evidence while avoiding indiscriminate shutdowns. Explicitly place WordPress CVE-2026-87902, Glo... [arg clipped]

0–60 minutes: Declare one severity-one command with separate Ahsay, OT, and supplier-continuity workstreams. AhsayCBS is first: remove external access without powering off, capture memory/disks/logs, and isolate hosts because observed exploitation reaches SYSTEM, creates malicious replication receivers, and drops JSP webshells. Hunt for child processes from cbssvcX64.exe, preserve findings, and rotate Ahsay administrative/service credentials from a clean system. For Colorado, keep pumps under staffed local/manual control, block remote engineering paths, and preserve PLC/HMI configurations and historian data—process influence warrants containment, but not an indiscriminate plant shutdown. IDC Frontier customers should declare the supplier event now, freeze reliance on the affected zones, and begin isolated restoration from customer-held backups.

60 minutes–3 hours: Put affected GlobalProtect CVE-2026-0257 gateways next: preserve configuration and VPN logs, restrict portal/gateway access where operationally possible, invalidate existing sessions, and canary-test the vendor-fixed PAN-OS release before wider deployment. In parallel, place internet-facing WordPress CVE-2026-87902 sites behind maintenance mode or a tested WAF control, snapshot them, inspect webroots and privileged accounts, then install the fixed release for their maintained branch; CISA lists this vulnerability as exploited, so patching alone does not establish cleanliness.

3–6 hours: Rebuild compromised AhsayCBS hosts on clean infrastructure using 10.3.4 or later, rather than trusting an in-place upgrade; restore only verified backup data. Validate Colorado controller logic, setpoints, accounts, and physical pump behavior against approved baselines before restoring remote control. Production reopening requires no unexplained persistence, execution, configuration drift, or unauthorized sessions during a monitored canary. By hour six, IDC customers should have a funded migration path ready; execute it at T+24 hours if IDC Frontier still cannot provide an evidence-backed recovery time and integrity statement.

Claim: AhsayCBS should rank first in the six-hour response because the chain reaches SYSTEM, establishes webshell and service persistence, and compromises a high-trust backup platform. Counter-evidence: Sara finds that the Colorado incidents already crossed into direct process influence by disabling alarms and changing pump cycles, while the source pack reports Qilin and Settra exploiting GlobalProtect CVE-2026-0257 to create unauthorized VPN sessions and prepare ransomware. James adopted your Ahsay-first ordering. Defend or revise it: are you ranking technical kill-chain completeness above safety consequence and imminent enterprise disruption? Give separate priority rules for a water operator, an Ahsay-dependent MSP, and a typical enterprise with GlobalProtect exposure.

The contradiction is real: Ahsay is not universally first. I over-weighted technical kill-chain completeness in a context-free ranking. Confirmed manipulation of alarms and pump cycles outranks a merely exposed enterprise platform when operators cannot independently verify a safe physical state. Sara’s distinction is right: consequence wins once the attacker is already touching the process. James’s Ahsay-first ordering is defensible for an Ahsay-dependent MSP, not as a universal rule.

• Water operator: confirmed, ongoing process influence is first. Stabilize pumps locally, independently validate pressure, levels, water quality, alarms, and interlocks, then contain remote access without breaking control communications. GlobalProtect becomes co-equal if it is the OT access path or unauthorized VPN sessions appear. Ahsay follows unless it is required for immediate recovery. Once the process is stable and remote control is contained, the cyber ordering can flip.
• Ahsay-dependent MSP: Ahsay is first. The reported chain is unauthenticated compromise through two flaws, JSP web-shell deployment, SYSTEM execution, and service persistence. Isolate exposed servers, preserve evidence, and rotate credentials that could reach repositories or managed customers. Whether attackers deleted backups, stole repository data, or crossed into customers remains unknown; do not claim that blast radius without evidence.
• Typical enterprise with affected GlobalProtect exposure: GlobalProtect is first. Reporting ties CVE-2026-0257 to Qilin and Settra, unauthorized VPN sessions, credential theft, lateral movement, data collection, and ransomware deployment. Because access can resemble legitimate VPN traffic, patching alone is inadequate—terminate sessions, invalidate relevant credentials and override material, and investigate internal activity. Ahsay comes first only where it is actually deployed, exposed, and central to recovery.

The rule is blunt: confirmed physical manipulation first; then confirmed enterprise ingress with an imminent disruptive objective; then demonstrated privileged persistence in a high-trust platform; then vulnerable exposure without victim-side evidence. Technical elegance does not outrank pumps moving under hostile control.

The PeopleSoft CVE-2026-35273 incident reportedly affected thousands of FBI employees after a contractor failed to apply a critical patch and was removed. Separate verified facts from reporting, then give customers of managed ERP platforms a decision-ready governance position: what evidence must they demand from the provider to verify patching, what incident and personnel-data assessments begin if exposure overlapped exploitation, and which notification clocks depend on confirmed compromise or materiality rather than the missed patch alone? Keep the answer jurisdiction-aware and do not infer a reporting duty from KEV or patch status by itself.

Verified fact: Oracle confirms CVE-2026-35273 affects PeopleSoft PeopleTools’ Updates Environment Management component; its risk matrix describes a network-reachable, low-complexity issue requiring neither privileges nor user interaction, with potentially high confidentiality, integrity, and availability impact. NVD identifies PeopleTools 8.61 and 8.62 as affected. Reporting, not independently established here: ITPro reports that FBI cyber chief Brett Leatherman attributed the incident to a third-party-managed platform where a contractor failed to install an issued patch; SC Media reports thousands of employees were affected and links the event to this CVE and ShinyHunters. Those reports do not, by themselves, establish the precise exploited build, complete personnel-data scope, exfiltration, or causation for every affected individual.

Customers should require: the complete asset/version inventory; internet-exposure history; the vendor advisory and applicable patch identifier; signed change tickets with approval, installation, restart, and validation timestamps; package hashes or build evidence; authenticated post-patch scan results; patch exceptions; and immutable application, web, identity, EDR, database, and egress logs covering the entire suspected exploitation window. If vulnerability and exposure overlapped, preserve evidence immediately and determine whether exploitation occurred, which privileges were obtained, which HR/personnel tables and attachments were reachable, whether records were viewed or exported, affected individuals and jurisdictions, encryption status, subprocessors involved, and whether credentials require rotation. A missed patch supports contractual control-failure and SLA review, but is not automatic proof of compromise, negligence, or a particular breach scope.

The governance distinction is critical: patch or KEV status should start incident triage and may trigger a contractually defined notice, but it does not alone start every statutory notification clock. EU analysis turns separately on a personal-data breach and risk under GDPR, significant-incident classification for an in-scope NIS2 entity, or major-ICT-incident classification for an EU financial entity under DORA; US public-company disclosure turns on a materiality determination, while state personnel-data laws use their own access/acquisition and harm triggers. I could not verify the current official notification texts in the available evidence, so I will not quote article numbers or deadline lengths. Counsel should immediately map the known detection time, compromise evidence, materiality decision, controller/processor roles, affected jurisdictions, and contractual notice clauses—without waiting for patch completion or perfect forensic certainty.

Give this only quick-hit treatment. For the reported Double Counter breach, what primary or independently corroborated evidence establishes the claimed scope of roughly 28 million accounts, the exposed data fields, the outdated Metabase entry path, and the Discord bot-token abuse across about 50 communities? Separate confirmed facts from vendor or media claims, state which credentials or tokens require immediate revocation, and name the one fact that would justify elevating this from monitoring to a major incident thread.

The public evidence is narrower than the 28-million headline. Primary, but self-reported: Double Counter says attackers obtained its Discord bot token, promoted an attacker-controlled server across roughly 50 large communities, copied part of a database, and abused a stolen payment key. Its exposure table lists approximately 28 million Discord IDs/usernames, 27 million IP addresses with coarse geolocation, and 25 million user-agent hashes. Independently corroborated: Have I Been Pwned examined a publicly released subset containing 275,000 unique email addresses and Discord usernames, plus limited Stripe-customer fields including names, countries, and postcodes. That confirms genuine leaked records and some field types—not exfiltration of all 28 million accounts.

The retired, internet-accessible OVH host running outdated Metabase is still the vendor/media-described entry path; no public forensic artifact, affected version, or named CVE independently closes that chain. Likewise, the bot-token abuse is supported primarily by Double Counter’s incident report, although subsequent reporting describes the attacker reaching a running bot container. Immediately revoke the Discord bot token and stolen payment/API key; also rotate cloud identities, database credentials, webhooks, and application secrets reachable from that host or container. The single fact that would elevate this to a major-incident thread is independent validation of a representative corpus or exfiltration logs showing that data for approximately 28 million unique accounts actually left the environment, rather than merely being present in exposed tables.