Session CRT-20260813 — 13 August 2026 · Morning Edition

The trust chain is anonymous request → guest identity → Aura/LWR UI‑API or ServiceNow portal search → object/field authorization → record return. The evidence attributes exposure to overly permissive guest settings, not a platform vulnerability. The fastest reliable test is a logged-out, external request against each production portal: probe Salesforce /s/sfsites/aura, the LWR UI‑API, and ServiceNow’s portal-search path, then compare returned objects, fields, attachments, and user records against an explicit public-data allowlist. A 200 alone proves nothing; unauthorized record content confirms exposure.

Tonight, review every exposed record for email addresses, usernames, phone numbers, customer identifiers, support cases, attachments, password-reset links, API keys, OAuth artifacts, integration credentials, and information useful for impersonation. Unknown: the available reporting does not establish which data classes City‑Forum extracted from each victim. Preserve request logs and identify enumeration volume, source infrastructure, accessed tables/objects, and the earliest observed access.

The CISO should order immediate deny-by-default guest authorization: disable Salesforce guest access to public APIs, disable Portal User Visibility and Site User Visibility, and remove unnecessary guest object, field, sharing, Apex, and attachment permissions. For ServiceNow, remove public access from affected pages, widgets, search sources, tables, fields, and attachments through guest ACLs; require authentication where public access is unnecessary. Rate limiting is containment, not remediation. If secrets were exposed, revoke active sessions, refresh tokens, OAuth grants, API keys, and integration credentials before rotation; then require phishing-resistant WebAuthn for workforce and administrator access.

N-central / StormEncryptor: This is tonight’s higher priority where vulnerable N-central is deployed or exposed. FACT: CVE-2026-18577 is an authentication-bypass/account-takeover flaw listed in CISA’s KEV catalog. Microsoft-linked reporting describes actual exploitation followed by credential theft, lateral movement, exfiltration, and StormEncryptor deployment—not merely theoretical exposure. ASSESSMENT: The crucial containment boundary is the N-central management plane-to-managed-endpoint channel: isolate the server and suspend its ability to issue agent commands before patching and hunting. Patching alone cannot evict an attacker who already obtained administrative control.

LiteLLM 1.82.7/1.82.8: The malicious PyPI artifacts are confirmed, but downstream compromise remains conditional on installation. LiteLLM states that both releases contained malicious payloads and were uploaded outside its official CI/CD workflow; Wiz reports that 1.82.8’s .pth file executes whenever Python starts, even without importing LiteLLM. ASSESSMENT: The containment boundary is therefore every host, container, or CI runner where either PyPI version was installed, not merely applications that imported it. Quarantine those environments, then rotate every credential accessible to them. UNKNOWN: Without package-cache, SBOM, and installation telemetry, we cannot infer consumer compromise from dependency declarations alone.

Halil, the Coldcard vulnerability is confirmed; the roughly $130M theft attribution is not. Project confirmation: Coinkite confirms affected firmware could produce seeds with about 72 bits of entropy and identifies fixed versions. It does not, in the evidence here, confirm that this defect caused $130M in theft. On-chain observation: secondary analysis describes 1,596–1,719 BTC taken from roughly 7,300 addresses across multiple waves, but we lack a primary transaction set tying those wallets to affected Coldcard seeds. Media inference: the “roughly $130M” headline extrapolates that analysis and market value. Decision: firmware upgrades and migration of affected seeds are action-grade today; attributing roughly $130M in theft to Coldcard entropy should remain monitoring pending reproducible addresses and cryptographic linkage.

For Harmony, project confirmation: available reporting says Harmony acknowledged suspected unauthorized minting and contacted exchanges, but had not publicly confirmed the four-billion-ONE amount or explained the vulnerability. On-chain observation: analysts reportedly identified roughly four billion ONE created and about 2.8 billion routed toward exchanges, but the source pack does not provide a primary explorer transaction list enabling independent verification. Media inference: “26% of supply,” price-impact causation, and rollback scope are derived from those unconfirmed calculations. Decision: the incident justifies precautionary exchange and treasury controls, but the specific four-billion-ONE claim is not decision-grade; keep it in monitoring until Harmony publishes technical details and the mint total can be reproduced from transaction or block identifiers.

Halil, the evidence threshold should be:

• Polish CHP disruption / U.S. water operations: Treat operational or safety degradation as an immediate sector-authority and emergency-response escalation. It does not, without evidence of compromised personal data, establish a data-breach notification duty. Preserve OT logs, document service and safety consequences, and identify the competent national or state authority; I could not verify the applicable statutory reporting clocks.
• Metabase: Internal documented assessment becomes regulator-notification analysis once logs show unauthorized credential use reaching personal-data records, exports, or connected sources. Notify individuals only where the exposed data and circumstances create a sufficiently serious risk to them. The present evidence is incomplete.
• City-Forum: Reported portal data theft is stronger than mere suspected access. Each affected organization must establish controller/processor roles, stolen fields, affected individuals, and misuse risk before deciding regulator and individual notification.
• ACRO/Kentico: Conduct a retrospective assessment for each historical incident. Vulnerability or compromise alone is insufficient; evidence of unauthorized access to personal data, or inability to exclude it after a defensible investigation, drives escalation. I could not verify the incident facts or any prior regulatory disposition.

Operationally, open separate privacy and public-safety decision logs now; record detection time, affected jurisdiction, evidence supporting each decision, and why notification was or was not made. Do not wait for complete attribution, but do not infer a personal-data breach solely from an outage.

Halil, none of these AI items should displace active OT operations or exploited enterprise vulnerabilities. The reasoning-block replay issue is a serious application-security disclosure, but the evidence shown does not establish exploitation in the wild. The Taiwan campaign is strategically important—researchers reported adaptive multi-agent activity and theft of more than 2,500 personnel records—but the precise initial-access mechanism and degree of autonomy remain uncertain. That makes it an intelligence warning, not tonight’s primary remediation lane.

The concrete exploitable failure is simpler: developers or CI runners executing trojanized AI repositories while holding valuable credentials. Reported lookalike GitHub repositories delivered SmartLoader-hidden infostealers. That is conventional software-supply-chain compromise wearing an AI label—not a model “going rogue.”

Tonight’s action: identify systems that recently executed untrusted AI repositories or installation scripts, isolate any matches, and rotate their developer, GitHub, cloud, and CI/CD credentials. Keep all three stories as a quick hit unless direct repository exposure is found; then escalate that incident, not “AI risk” generally.

Halil, these should be framed as separate operations with opportunistic access, not coordinated Russian-Iranian pressure. The broader Polish energy campaign has credible Russian linkage, but CERT Polska did not attribute the smaller CHP intrusion; confidence is therefore moderate-to-high for Russian responsibility across the wider campaign, but low for that specific plant. In the United States, agencies confirm coordinated attacks against water systems across multiple states and warn of Iran-affiliated activity, yet several individual incidents—including Minnesota—remain under investigation. Confidence is moderate at campaign level, lower per victim, and very low for coordination with Poland.

The justified strategic inference is narrower: hostile actors are exploiting exposed civilian OT for gray-zone leverage—coercion below open warfare. That common logic does not establish common direction. Immediate priorities remain safe-state verification, functional alarms and shutdowns, manual fallback, removal of internet-facing PLC access, and scrutiny of private APN paths. I would raise the escalation posture only if investigators find shared command infrastructure, malware or credentials, synchronized targeting lists, operator overlap, or intelligence showing state tasking tied to military or diplomatic timing.