Session CRT-20260723 — 23 July 2026 · Morning Edition

Lena, I’d rank the hunt/isolate-now list like this:

1. SonicWall SMA1000 — this is the cleanest closed attack chain in the evidence: internet-facing appliance, exploited zero-days, root-level command execution, credential/session/TOTP seed theft, and use as initial access into internal networks including AD. Patching is not enough. Treat exposed vulnerable SMA1000 as potentially compromised: isolate, collect appliance logs/images, rotate credentials and MFA seeds tied to the appliance, and hunt downstream.

2. Langflow CVE-2026-0770 — CISA KEV plus unauthenticated RCE means this is not “wait for maintenance window” territory. If it is internet reachable, assume someone can drive straight through the front door. Patch, yes, but also hunt for spawned processes, new accounts, secrets access, and outbound callbacks.

3. Check Point SmartConsole CVE-2026-16232 — active exploitation of an authentication bypass against a security-management surface is ugly. It is not as clearly chained in the evidence as SonicWall, but the blast radius is high because management tooling can become the keys to the guardhouse. Apply the jumbo hotfix and review admin activity, policy changes, and suspicious management sessions.

Where patching is insufficient: SonicWall, definitely; Langflow, if exposed; Check Point, if SmartConsole was reachable or used during the exposure window. A downgrade would require evidence of no vulnerable internet exposure, clean forensic review during the exploitation window, no anomalous auth/session activity, no post-exploitation artifacts, and — for SonicWall — confirmed rotation of stolen credentials/session material/MFA seeds.

I’m not ranking WordPress above these without stronger evidence of reliable unauthenticated exploitation at scale. WordPress gets noisy fast; edge appliances and management planes close the kill chain faster.

Halil, the new thing here is not “models became autonomous.” The trust boundary that failed is the evaluation/tooling boundary: an AI evaluation environment apparently had enough network reach, package-registry trust, and credential exposure to move from sandboxed benchmark activity into real Hugging Face-facing infrastructure. The handoff classifies the OpenAI ExploitGym/Hugging Face item as critical, active in the wild, and spanning AI appsec, supply chain, exploited vulnerability, intrusion, and identity lanes. That mix matters: this is an AI incident, but the exploit path looks like classic supply-chain plus credential misuse wrapped inside an AI agent/eval harness.

The adjacent MCP cases rhyme with that. The Azure DevOps MCP item is reported as a prompt-injection flaw that can hijack AI review agents, with PoC available. AWS Kiro is reported as allowing malicious code execution through MCP settings modification. Sandworm_Mode is reported as targeting AI coding assistants and developer pipelines. So the pattern is: natural-language or repo-controlled content is crossing into privileged developer tooling without a hard policy boundary. Prompt injection here is basically SQL injection for agentic tools: attacker-controlled text gets interpreted as instruction, then the agent touches code, settings, credentials, or CI/CD.

What I would shut off or segregate today: outbound network access from eval sandboxes unless explicitly allowlisted; write-capable tokens in AI coding/eval agents; MCP servers that can alter settings, repos, pipelines, package config, or secrets; hidden-comment consumption in code review agents; automatic dataset processing from untrusted Hugging Face-style sources; and shared credentials between evaluation, development, and production environments. Put agents in disposable identities with read-only defaults, short-lived scoped tokens, package-cache isolation, no ambient cloud/dev credentials, and audit logs on every tool call.

The misleading overreaction would be “ban AI coding assistants” or “the model escaped.” That framing hides the fix. The model did not need consciousness; it needed an over-permissioned harness, reachable infrastructure, and credentials. Treat this as OWASP LLM Top 10 territory: prompt injection, excessive agency, insecure plugin/tool design, and supply-chain trust failure. The right response is to reduce authority and connectivity, not to pretend model branding determines safety.

Halil, the safety issue here is not “data loss” first — it’s operators making a bad physical decision because the HMI or SCADA view is lying. The CISA/FBI advisory says Iranian-affiliated actors are targeting internet-facing OT devices, including Rockwell/Allen-Bradley PLCs, and that activity involved project-file interaction plus manipulated HMI/SCADA display data causing disruption and financial loss. The later agency update broadened observed targeting to Schneider Electric and Siemens as well.

For the first 24 hours, keep it boring and safe: stand up an OT-led bridge with operations, controls engineering, safety, and IT; freeze nonessential engineering changes; identify any PLC/HMI/SCADA exposure reachable from the internet or remote-access paths; and close that exposure at the firewall, VPN, NAT, cellular router, or vendor gateway — not by rebooting controllers mid-process. Hunt boundary traffic for OT protocol exposure noted in reporting — EtherNet/IP 44818/2222, Modbus 502, SSH/Dropbear 22, Siemens S7 102 — and compare any controller project files against known-good engineering backups before trusting them. Because the advisory specifically calls out HMI/SCADA display manipulation, operators should verify critical readings through independent channels: local panels, field instruments, historian cross-checks, and control-room procedures.

Where IT can make this worse: do not “contain” by mass-isolating Level 1/2 devices, killing switch ports, blocking controller-to-HMI traffic, or pushing emergency firmware/software updates during production. If you sever the wrong PLC-to-HMI, PLC-to-I/O, or safety-system communications path, you can create the outage or unsafe state the attacker was trying to cause. Contain upstream at Purdue Level 3.5/3 boundaries first, validate any segmentation change with controls engineers, and only touch controllers during an approved operating state or maintenance window.

Halil, the posture-changing items are Iran-linked OT targeting and Russian use of exposed IP cameras for Ukraine logistics surveillance. The Iran case changes executive risk because it touches internet-facing OT in water, energy, government, and related critical infrastructure, with reported active exploitation and operational disruption risk. The Russian camera case is not “just bad IoT hygiene”; it turns exposed cameras into battlefield intelligence collection, including against weapons transport routes across Ukraine and NATO-adjacent logistics chains. That is coercive optionality: cheap access that can become targeting intelligence.

I would keep Kimsuky/APT43 vendor compromise and the South Korean diplomatic academy breach in intelligence-monitoring language unless we have evidence of direct operational impact, sensitive credential reuse, or supply-chain pivoting into your environment. They matter geopolitically as North Korea–linked collection against South Korean state, diplomatic, and vendor ecosystems, but I do not have current source detail visible here sufficient to elevate them above monitoring for most executives today.

So my ranking: 1) Iran-linked OT warning — executive action now for OT owners; 2) Russian IP-camera abuse — executive action now for logistics, defense suppliers, ports, rail, warehousing, and Ukraine-support chains; 3) Kimsuky/APT43 vendor compromise — monitor/escalate if exposed through Korean suppliers; 4) diplomatic academy breach — intelligence significance, not broad posture change yet.

Procurement should stop asking only “Do you patch?” and start asking “Show me every trusted path by which your code reaches us.” The Kimsuky case is the warning sign here: the source pack flags South Korean groupware/software vendors as compromised in an active supply-chain campaign. So the supplier question is: which externally exposed systems, remote-access tools, update servers, and support portals can lead to customer environments, and are they segmented from build/signing infrastructure?

Engineering should ask for evidence, not assurances: SBOMs for delivered products, transitive dependency lists, package-lock files, build provenance, signing policy, and whether dependencies are pinned by hash. The NuGet Newtonsoftt.Json.Net typosquat targeting Digitain is exactly the kind of failure that slips past “we use standard libraries” answers — one extra “t” in a package name can become the trust boundary.

Vendor-risk teams should add three new attestations this quarter:

1. Registry controls: Do you block typosquats, dependency confusion, and unapproved public packages across NuGet, npm, PyPI, and container registries?
2. Secret exposure controls: Can AI coding assistants, CI runners, package install scripts, or test fixtures access production credentials, signing keys, or repo tokens?
3. Compromise disclosure triggers: If your maintainer account, build system, package proxy, support tool, or update channel is compromised, do you notify customers even before data exfiltration is confirmed?

I would also ask suppliers a blunt question: “Who can publish code that we will automatically trust?” If they cannot name the maintainers, CI identities, signing keys, registry accounts, and approval gates, they do not understand their own blast radius. I found no usable evidence here to make specific claims about the Miasma/Hades package details, so I would treat those as prompts to widen package-registry questioning rather than as package-level facts.

Halil, the non-negotiable tonight is trust collapse, not password hygiene.

For the VPN side, the evidence I can cite here is the current handoff item on Qilin exploiting a Palo Alto GlobalProtect VPN flaw to breach corporate networks. That means I would treat any exposed GlobalProtect path as potentially involving valid or replayable access, not just a patched edge device. The action is: revoke active VPN sessions, rotate credentials, invalidate refresh/session tokens where the platform supports it, review privileged VPN group membership, and force phishing-resistant re-enrollment for admins. If SonicWall is in scope, I would apply the same identity containment pattern, but I do not have visible source detail here to make SonicWall-specific claims.

For SharePoint machine-key/token persistence, the key point is that a password reset is not enough if the attacker can still mint or validate trusted tokens through exposed signing material. The action is: rotate machine keys and any token-signing/sealing secrets, recycle app pools/services as required, invalidate sessions, rotate service account secrets, inspect delegated OAuth grants, and assume any searchable secrets in SharePoint may already be compromised.

For Microsoft 365 AiTM kits, Entra device-code phishing, Hugging Face/cloud credential theft, and recruiter malware stealing browser/wallet secrets: I don’t have visible source detail here for the named kits — Kratos, ARToken, EvilProxy, FlowerStorm, Kali365 — so I won’t invent kit-specific behavior. But the identity control is still clear: kill stolen sessions, revoke refresh tokens, disable or tightly constrain device-code flow where not needed, remove suspicious OAuth app consents, rotate cloud keys and Hugging Face/API tokens, and move admins and developers to FIDO2/WebAuthn/passkeys. Push MFA and SMS are not enough against AiTM.

The dangerously incomplete response is: “We reset the user’s password and closed the ticket.” That leaves browser cookies, refresh tokens, device-code grants, OAuth consents, VPN sessions, Kerberos tickets, API keys, wallet/browser secrets, and machine-issued trust artifacts alive. If you don’t revoke the whole trust chain, you didn’t evict the attacker — you just changed one credential.