CloudSecurityChangedinOctober2026.Here'sWhattheIncidentsSayDevOpsEngineersNeedtoDoNow

Read the October and November 2026 incident reports back to back and a pattern jumps out. None of the breaches needed a zero-day. They ran on things DevOps teams own: a key that was never revoked, an app identity with too much reach, a release workflow anyone with a token could edit, a config file nobody reviewed. What changed is who was using them. Attackers now point AI agents at these weaknesses, and agents work through them in hours instead of weeks.

At the same time, the AI tools we've handed to engineers have become an attack surface of their own. CLAUDE.md, AGENTS.md, MCP configs, and agent settings files are now places attackers plant persistence, and coding agents are installing packages from memory.

This post goes through what actually happened, sourced from the companies' own disclosures where they exist, and then what it means for the way we run infrastructure.

What happened

ConnectWise: AI agents reached privileged cloud access in under three hours

On October 16, ConnectWise disclosed unauthorized access tied to its Cloud Backup product. Microsoft's analysis, published October 21 and summarized by BlackBerry, attributed it to Storm-0940, a China-state-aligned actor, operating through ARTEX, an open-source multi-agent framework that runs an autonomous penetration test from reconnaissance to exfiltration.

The attacker took control of several ConnectWise cloud application identities and used them to sign in to customers' Microsoft 365 tenants as the applications, with no interactive user involved. The agents attempted sign-ins to more than 2,250 tenants. Most failed. Where they succeeded, the activity reached Microsoft Graph and directory operations: application credential changes, and changes to identities, groups, and privileged roles. Microsoft counted over 200 sign-ins in under four minutes using four application credentials, and in multiple cases privileged access less than three hours after initial targeting. Microsoft also observed secrets being read at scale across Azure Key Vaults, and warned that credential changes can survive remediation of the original application.

That last point matters most for responders. Disabling the compromised app isn't enough if the attacker used it to create new credentials elsewhere.

LiteLLM: a key leaked in May, a malicious release in October

LiteLLM is the gateway many teams put in front of every LLM provider they use, which means it holds every provider key. On October 21, a malicious litellm==1.107.0 was published to PyPI, Docker Hub, and GHCR and was live for about two hours. The project's attack-chain write-up is one of the most candid incident reports of the year, and it's worth reading in full. The short version:

1. May 27: an administrative key was committed in a config file to a public repository. It was never revoked and was "still valid more than four months later."
2. October 10: the attacker used that key against LiteLLM's agent platform API, which returned the configuration of every managed agent, including an organization owner's GitHub CLI OAuth token. Not a scoped token: owner capabilities over the whole GitHub organization.
3. With that, the attacker pushed throwaway branches whose CI runs posted repository secrets, including other maintainers' tokens, to a webhook endpoint, then deleted the runs.
4. October 21: the attacker edited the release workflow so it could build from any organization, overrode branch protection with the owner token, and dispatched a release from a lookalike fork (Berri-AI instead of BerriAI). A stolen maintainer token approved the production gate. That gate used to require an approver locked to an office device, but the restriction had been relaxed so any two engineers could release.
5. The pipeline built, signed, and published the release from the fork. Then a third stolen token deleted the workflow run records, removing their logs.

Every step there is a DevOps control: secret revocation, token scope, branch protection, workflow-file protection, environment approvals, and log retention. LiteLLM's list of changes afterwards is a good checklist for anyone running a release pipeline, especially the post-publish verifier that runs outside GitHub, compares published artifacts against the source tag, and automatically yanks releases on any difference.

Kernel: a leaked API key, an AI pentest platform, and a cryptominer

Kernel's public notice from November 4 follows a similar chain. A compromised Kernel API key was used to probe on October 24. On October 27, the attacker reached a staff login at Kernel's logging provider and downloaded data that included "a small number of kernel API keys and app deployments' third-party secrets." On November 3, a compromised hosting-provider credential got them onto four GPU servers, where they tried to start a cryptominer. Kernel says it believes the attackers used ARTEX "as a command center to automate and amplify the impact of their campaign." The breach affected 0.28% of Kernel's customers.

Note the hop through the logging provider. Logs and observability tools increasingly contain secrets, and they're rarely protected like a secrets manager.

strutil-core: malware that poisons AI coding tools

On November 1, a RubyGems package called strutil-core published a clean 1.0.0 and, less than two hours later, a malicious 1.0.1. Socket's analysis describes a 5.48 MB credential-stealing worm that runs at gem install time. It reads cloud, CI, registry, SSH, wallet, and AI coding tool credentials (including .claude/.credentials.json and .codex/auth.json).

The new part is what it does next:

• It adds an MCP server named workspace-tools to writable AI tool configs and adds SessionStart hooks, so the payload runs every time an agent session starts.
• With stolen Git credentials, it commits .claude/settings.json, .cursor/mcp.json, Gemini settings, CLAUDE.md, AGENTS.md, and .vscode/tasks.json into repositories. The generated AGENTS.md "tells coding agents to run a setup script before their first command."
• If a stolen GitHub token returns 401 or 403, a background monitor deletes the user's home directory. As Socket puts it: "Revoking the token is exactly what a responder would do first, and it is what triggers the deletion."

RubyGems removed it within about five hours, and Socket hasn't confirmed victims. The technique is the story: agent instruction files and agent configs are now a persistence mechanism, and they spread through repositories the same way CI files do.

MCPhantom: coding agents installing servers that will never be patched

On November 3, Help Net Security reported Glow Labs' research into AI coding sessions that install deprecated MCP servers. In 98% of such sessions, the agent picked the old package name from its training data; the user hadn't asked for it. The pattern showed up across Claude Code, Cursor, Codex CLI, and others, using models from several vendors. Glow found four high-severity vulnerabilities in the deprecated reference servers, including a remote-code-execution flaw in the Puppeteer server that a prompt injection can trigger. The servers were archived and won't be patched. Deprecated packages have been downloaded from npm more than 17.3 million times since July 2025.

The researchers' line sums it up: "The model's memory is now a package manager with no deprecation feed." These installs don't appear in dependency manifests, so software composition analysis never sees them. In one session the agent saw the deprecation notice on npm, installed the package anyway, and didn't mention it.

Google Cloud europe-west2: one zone lost power, the region felt it

Not every October lesson was an attack. On October 20, a power interruption hit the datacenter hosting europe-west2-b in London, and the backup generators never took the load. IncidentHub's write-up of Google's preliminary report shows impact from about 06:00 to 12:10 UTC across compute, networking, databases, analytics, and messaging, with downstream disruption reported at companies including Stripe (Revolut Pay), Snowflake, MongoDB, and JFrog.

The important detail: "The physical power loss was limited to europe-west2-b, but the customer impact was not." Customers in the other two zones were affected too. Cross-zone control-plane calls timed out, and failover traffic saturated the surviving zones. Multi-zone on the architecture diagram didn't mean multi-zone in practice.

What changed

Put these side by side and three shifts stand out.

1. Time-to-privilege is now measured in hours. ARTEX-driven activity reached privileged access less than three hours after initial targeting, with hundreds of sign-ins in minutes. An alert that waits for a human to triage it the next morning is too slow. Microsoft's guidance, as BlackBerry summarizes it, is that "the speed of AI-driven activity leaves defenders little time to respond to alerts."

2. Non-human identities are the perimeter. Every breach above ran on one: an app registration (ConnectWise), an API key (Kernel), an admin key and OAuth tokens (LiteLLM), CI and registry tokens (strutil-core). Humans have SSO and phishing-resistant MFA. Machine credentials have whatever someone set up three years ago.

3. AI tooling is part of the supply chain and part of the attack surface. AI gateways hold every provider key. Agent configs run code. Instruction files steer agents. Agents install packages nobody approved. Most security programs still don't inventory any of it.

What DevOps engineers need to change

Treat every leaked secret as live until revocation is confirmed

LiteLLM's key sat in a public repo for almost five months. "Rotate it" tickets that close when someone says they did it aren't enough. LiteLLM now closes the ticket "only when revocation is confirmed." Do the same: test the old credential and confirm it fails. Turn on secret scanning with push protection on every repository, including the side projects and labs organizations, which is where that key leaked.

Shrink and expire machine credentials

• Replace long-lived keys with workload identity wherever the platform supports it: OIDC federation from CI to AWS, Azure, and GCP, so there's nothing to steal from a CI run.
• Where you need tokens, use fine-grained, expiring ones scoped to one repository and one job. An owner's broad OAuth token sitting in an agent config is how LiteLLM's attacker got org-wide control.
• Inventory third-party app identities in your tenants (Entra enterprise apps, Google Workspace OAuth apps, GitHub Apps). Know which ones can change roles and credentials, and trim the permissions they don't need.
• Bind high-value API keys to network locations where the provider supports it. Kernel lists better network controls on API key use among its follow-ups.

Automate the first containment step

When the attacker moves in minutes, the first response has to be automated. Disable the identity, revoke its sessions, and snapshot evidence when high-confidence signals fire: an app identity signing into many tenants, a workflow file changed and dispatched within minutes, a release from an unexpected source repository. Humans then decide what to do next. Keep evidence before irreversible changes, as Microsoft advised ConnectWise customers, and remember that attacker-created credentials can outlive the original foothold. Hunt for new app secrets, role assignments, and service principals created during the window.

Lock down the release pipeline like production

• Protect workflow files with CODEOWNERS and required review. A changed workflow should never be able to dispatch a release in the same breath.
• Require deployment-environment approval from a small set of dedicated release accounts, and don't relax it for convenience. LiteLLM's gate had been loosened to "any two engineers."
• Pin the source repository and commit the release builds from, and check the source organization name. Lookalike forks are cheap.
• Verify published artifacts against source from outside your CI provider, and alert or yank on mismatch.
• Stream audit logs (GitHub, cloud, identity provider) to a system the pipeline can't write to. LiteLLM's attacker deleted the workflow runs that would have shown what happened.

Slow down what you pull in

strutil-core was malicious for about five hours. LiteLLM's bad release was live for about two. Most poisoned releases are caught quickly, so a short cooldown (not installing versions younger than a few days, which several package managers and update bots now support) removes most of the risk at little cost. Pin dependencies by hash, pin your CI actions and scanners by commit (the March 2026 LiteLLM compromise came through an unpinned security scanner in CI), and watch for unexpected patch releases that add install-time scripts.

Treat agent configuration as code that executes

This is the new one, and it applies to any team using AI coding tools:

• Review agent files like CI files. CLAUDE.md, AGENTS.md, .claude/settings.json, .cursor/mcp.json, .mcp.json, and .vscode/tasks.json can all cause code to run. Put them under CODEOWNERS and alert on changes from unexpected authors or branches.
• Allowlist MCP servers. Approve one official server per service, prefer the vendor's own server over archived reference servers, and add npm deprecation status to the approval criteria, as Glow recommends. The MCP config guide and MCP Config Builder cover setting up a known-good .mcp.json.
• Use pre-execution hooks to enforce it. A prompt that says "don't install unapproved servers" is advice. A hook that blocks npx of anything not on the list is a control. The Hooks Builder and the guide to Claude Code hooks show how, and the Instruction Router helps separate rules that need enforcing from rules that can stay as text.
• Keep secrets out of agent reach. Agent credential files are now standard targets for stealers. Deny reads of .env and credential paths in agent permissions, and don't let agents handle production credentials at all. Scan untrusted content that agents will read with the Prompt Injection Scanner.
• Inventory AI gateways as crown jewels. Anything that proxies to every LLM provider holds every key. Isolate it, give it its own short-lived credentials, and watch its egress.

Change the incident-response playbook

strutil-core's wiper fires when the stolen token is revoked. The old reflex of "revoke first" can now destroy evidence and data. For developer-machine compromises: isolate the host from the network first, stop the malware's persistence, then rotate credentials from a clean device, then rebuild. Rotation has to include AI provider keys and agent credential files, which most runbooks don't list yet.

Test failover under real load

The europe-west2 incident shows that multi-zone isn't a checkbox. Run game days that remove a whole zone and check three things: do surviving zones have capacity headroom for the failover traffic, do any requests depend synchronously on a control plane in the failed zone, and does autoscaling still work when VM creation is slow to recover. The same thinking applies to AI dependencies: if a feature calls one model provider, decide now what it does when that provider is down.

A checklist to take into your next sprint

None of this is exotic. Most of it is the hygiene we've been told to do for years: short-lived credentials, protected pipelines, pinned dependencies, tested failover. What October changed is the cost of skipping it. An attacker with an AI agent will find the unrevoked key, the overpowered token, and the unreviewed config file, and do it faster than a human team can read the alert. So close these gaps before an agent finds them.