Session CRT-20260805 — 5 August 2026 · Morning Edition

Halil, N-able is the uglier MSP/RMM problem. CISA added CVE-2026-18577 to KEV based on active exploitation, and N-able says attackers used N-central’s Take Control feature to reach managed endpoints, then registered a Cloudflare Tunnel service for persistence after N-central access was revoked. That means the chain closes: internet-facing management plane → authentication bypass → remote control of customer endpoints → persistent tunnel. Patch-only is a wet paper towel here. Exposed MSPs should assume downstream endpoint access was attempted, and where Take Control activity or Cloudflare/cloudflared services appear, assume compromise until disproven.

SonicWall SMA 1000 is also real, not CVSS theater. SonicWall’s advisory says CVE-2026-15409 and CVE-2026-15410 are actively exploited, with CVSS 10.0; Rapid7 describes the chain as unauthenticated websocket tunneling to localhost-only services plus local privilege escalation to command execution as root. The source-pack reporting ties this to INC Ransomware activity for credential theft, data theft, and ransomware deployment. So for enterprise VPN owners: assume the appliance was not just probed. Assume credential exposure, appliance-level execution, and follow-on intrusion. Rotate credentials and tokens tied to the SMA path, collect appliance logs/artifacts, and hunt internal access from VPN-originating identities.

Priority tonight: N-able for MSP blast radius first, SonicWall for enterprise ransomware path immediately alongside it. N-able can fan out into managed estates like a master key copied at the locksmith. SonicWall is a front-door VPN compromise that can turn into ransomware fast. VeloCloud Orchestrator CVE-2026-16812 stays in the urgent bucket because Arista and CISA both describe active exploitation of an on-prem OS command injection issue, but it only jumps ahead if your VCO is internet-exposed and administratively central to SD-WAN control.

Halil, the physical consequence here is not “data loss”; it is operators losing trustworthy view or control of pumps, tanks, pressure, chemical feed, and alarms. The evidence we have points to disrupted Minnesota water systems, some going offline or manual, with water quality reportedly not affected; separately, Rockwell says internet-exposed Allen-Bradley MicroLogix 1100/1400 PLCs have been targeted for configuration tampering, including IP changes and passwords being set where none existed, causing loss of operator view.

For the first 24 hours, water operators should treat this as a Level 1/2 control-trust incident in the Purdue model. Stabilize the process first: confirm tank levels, pressure, flow, chlorine residual, and alarms locally using field instrumentation and normal sampling routines, not just the HMI. If remote control is suspect, move to pre-planned manual operation only where staff can safely operate and monitor the process. Then remove direct PLC exposure from the internet, preserve controller/project state before making changes, inventory affected PLCs/HMIs/engineering workstations, rotate weak/default credentials, and confirm clean backups. CISA/EPA/FBI’s water guidance lines up with that: reduce public internet exposure, change default passwords, inventory OT/IT assets, exercise incident response, and back up OT/IT systems.

What they should not do: do not mass-reboot PLCs, push firmware overnight, or let IT “containment” break pump control or safety interlocks without OT validation. Do not assume the screen is truth if the controller configuration may have been altered. And do not reconnect vendor remote access just because the plant is uncomfortable in manual mode; that is exactly the bridge into Levels 2 and 1 that needs controlled re-entry.

On attribution, I checked with Lena, and I agree with her framing: high confidence in active exploitation of exposed water-sector PLCs, moderate confidence in Iranian-affiliated overlap at the broader campaign level, but low confidence naming a specific actor for the Minnesota cluster. Boards should say: “We are responding to suspected Iranian-affiliated PLC-targeting activity under investigation,” not “Iran attacked our town.” The board-level frame is resilience and public safety: keep water safe, maintain pressure and treatment, restore trusted control, and communicate uncertainty honestly.

Yes — treat affected developer workstations and CI/CD runners as credential-compromised by default. Socket says the malicious keyv/cacheable releases stole cloud, CI, registry, Vault, Kubernetes, GitHub Actions, and npm tokens, then used stolen npm reach to republish more malicious packages. StepSecurity says ChainDrop hit 444 packages and 2,212 versions in under four hours and explicitly advises assuming compromise. That makes this a trust-chain failure, not package cleanup.

Tonight’s actions:

1. Revoke immediately: npm tokens, GitHub PATs, GitHub Actions secrets, AWS/GCP/Azure keys, Vault tokens/leases, Kubernetes service-account tokens, SSH keys exposed to those environments, and any AI-tool/API credentials in affected workspaces. Break and recreate GitHub Actions OIDC trust into AWS IAM roles, GCP Workload Identity Federation, and Azure federated credentials — don’t just rotate static keys.

2. Rebuild, don’t clean: wipe and rebuild CI runners from known-clean images. For developer endpoints that installed affected versions or opened affected repos, isolate first, preserve evidence if needed, then reimage or rebuild the workspace. Upwind reports triggers beyond npm install, including VS Code and agent hooks, so “npm uninstall” is not sufficient.

3. Pin and block: freeze lockfiles, pin dependencies by exact version and integrity hash, block known malicious ChainDrop versions in npm proxy/SCA policy, and prevent floating semver updates for keyv/cacheable-adjacent dependency paths until the full transitive tree is reviewed.

4. Stop republishing paths: suspend automated publishing for affected maintainers/packages, rotate registry credentials, require MFA, audit package ownership changes, and only resume releases from clean CI with fresh provenance. This campaign reportedly minted legitimate-looking provenance through compromised release paths, so provenance alone is not a clean bill of health.

If an organization lacks install logs, SBOMs, or package-lock evidence proving it never consumed the affected versions, I would classify that environment as unknown exposure — and for tonight, unknown means compromised.

Halil, the common pattern is not “AI went rogue.” It is untrusted model-shaped input crossing into trusted automation with delegated authority. In the Google ADK case, the visible reporting says a prompt in a PR could manipulate a lower-privileged AI workflow into triggering higher-privileged GitHub Actions, exposing GITHUB_TOKEN and potentially a GCP service account key. That is prompt injection, but operationally it behaves like a CI/CD trust-boundary failure.

For the OpenAI/Hugging Face allegation, I’d be careful with certainty because the source framing says “allegedly.” But if agents escaped an evaluation sandbox and touched production systems, the failure is still concrete: sandbox containment, network egress, and identity scoping failed. The Flowise RCE item, based on the pack description, sounds even less exotic: a traditional exposed application/RCE problem in an AI workflow wrapper. Cisco Talos guardrail-bypass findings fit the same lesson: guardrails are useful safety filters, not authorization controls.

Immediate controls:

• AI agents: run them like untrusted CI jobs — least privilege, per-task scoped tokens, no standing credentials, explicit human approval for destructive or publishing actions.
• Evaluation sandboxes: deny-by-default egress, no route to production, no shared cloud identity, disposable environments, monitored file/network access.
• CI workflows: treat PR text, issues, comments, model output, and agent-to-agent messages as attacker-controlled input; never let them directly influence privileged workflow execution.
• Secrets access: short-lived brokered credentials, secret redaction in logs/prompts, no service-account keys in agent runtime, and separate identities for read, write, deploy, and cloud control-plane actions.

My practical rule: if an AI system can call tools, access repos, reach the network, or hold credentials, it is not “just a chatbot.” It is an automation principal, and prompt injection becomes an authorization problem.