Supply Chain
5 articles
-
MCPCoding Agents Still Install an MCP Server Archived in 2025
Glow Security's MCPhantom research (2 Nov 2026) says coding agents name archived MCP reference servers from model memory, not from a lookup; in 98% of the deprecated installs it reviewed the user had not asked for that package by name. Verified hands-on: ten headless Claude Code runs (Haiku 5.5 and Sonnet 5.5) plus a Codex run, each asked to write the MCP config for a GitHub, Postgres, Slack, browser and Brave server. Both models named the archived @modelcontextprotocol/server-postgres for Postgres; Sonnet also returned archived server-github, server-slack and server-brave-search; Haiku returned GitHub's hosted remote and Brave's own @brave/brave-search-mcp-server; Sonnet returned @playwright/mcp for the browser; Codex pointed at github/github-mcp-server. All the reference servers are deprecated on npm and live in modelcontextprotocol/servers-archived (archived, last push 2025-05-28, README states NO SECURITY GUARANTEES). This morning the npm deprecation text on the GitHub, Postgres and Puppeteer packages was rewritten from the generic contact-npm-support boilerplate to Archived and unmaintained; no security guarantees when issue #4785 was closed at 04:21 UTC; npx prints it and installs anyway.
-
CursorCursor Served a Backdoored Claude Code Extension for 11 Hours
On 29 October 2026, between 09:27 and 20:35 UTC, Cursor's extension marketplace served tampered builds of Anthropic's Claude Code extension as Anthropic.claude-code 2.1.312 and 2.1.313 for macOS ARM64 and Windows x64, with a 7,386-byte loader prepended to extension.js that appends an SSH key tagged svc-telemetry, tries to enable Remote Login, opens a reverse tunnel to 134.209.82.225, installs a com.apple.sysmond LaunchAgent or a SysMon scheduled task, and beacons host details. Hands-on: Cursor's gallery at marketplace.cursorapi.com is an Open VSX mirror (links under /open-vsx-mirror/ redirect to cursor-cdn.com blobs, metadata is cached Open VSX JSON, every Claude Code package blob was rewritten on 30 October after the removal); Open VSX, npm and the Microsoft marketplace never had a 2.1.313; the 2.1.312 darwin-arm64 package Cursor serves today is byte-identical to Open VSX's, its Ed25519 signature verifies over the whole package, and its extension.js is 3,685,536 bytes, exactly 7,386 short of the tampered 3,692,922. Cursor's Marketplace Install Cooldown defaults to 0 hours and signature verification is an enterprise Team setting, while VS Code's extensions.autoUpdateDelay defaults to 12 hours, longer than the 11-hour window. Phorion's finding that the macOS enable step fails because systemsetup -getremotelogin exits 0 with an access error that never matches /Off/i. Local sweep on this Mac clean.
-
SecurityA Web Page Can Plant an AGENTS.md in Your Downloads
On 22 October Forever Security described stopping a coding agent on a customer's machine as it installed the malicious npm package function-color on the instructions of an AGENTS.md in ~/Downloads that nobody had put there; their proof of concept is a web page that saves such a file into Downloads with no click, and BleepingComputer found Chrome, Edge and Firefox do it while only Brave asks. With a harmless canary AGENTS.md in my own Downloads folder, Codex 0.164.0 injected the file only when Downloads itself was the working directory (session rollouts confirm it), while Claude Code 2.1.310 loaded it from Downloads, from a plain subfolder and from a subfolder with its own git repository, because it walks every directory from the working directory to the filesystem root; a repository unzipped into Downloads inherits the planted file. Loading was deterministic but obedience was not (Haiku 3 of 6, Codex 1 of 2). For Claude Code a claudeMdExcludes glob, --setting-sources user, the Project instructions setting, or a project CLAUDE.md kept the file out. Nothing is patched because both agents are reading instruction files exactly as documented.
-
LitellmLiteLLM's Poisoned Release Had a Valid Signature
On 21 October LiteLLM 1.107.0 reached PyPI at 11:39 UTC with a credential stealer in all seven wheels, and the v1.107.0, latest, main-latest and main-stable Docker tags followed at 11:46; PyPI pulled it at 13:23, GHCR by 13:51, Docker Hub by 14:20, about 49,000 downloads in between. LiteLLM's own release workflow built, signed and published it from the lookalike repo Berri-AI/litellm, and the cosign signature over the malicious image is still in Rekor (entry 3355443881, 11:47:52 UTC), made with the cosign.pub at commit 0112e53 that the release notes told users to pin; it verifies with openssl today, so a key-pinned cosign verify passed the stealer, while only the SLSA provenance named the wrong source repo. The payload was a 12-byte .pth file plus sitecustomize.py in site-packages, so it ran on every Python start; in a benign reproduction python -I, -s, -E and pip itself all ran the hook, only -S did not, and pip uninstall removed the files (they are in RECORD) while running the hook once more and leaving the forked loader process alone. Python 3.15, released 9 October, deprecated executable .pth lines but still runs them. LiteLLM rotated the signing key on 23 October; the 1.103.8, 1.104.6, 1.105.4 and 1.106.3 releases of 24 October are signed with the new key. The attack chain: a master key committed to the public LiteLLM-Labs/lite-harness repo on 27 May, flagged for revocation and never revoked, used on 10 October against GET /api/v1/managed_agents/agents?limit=100, which returned an org owner's unscoped GitHub CLI OAuth token in the agent configuration; two more maintainer tokens were exfiltrated from CI secrets to webhook.site within 45 minutes.
-
GitHub ActionsGitHub's Actions Lockfile Skips the Docker Image
On 14 October GitHub put workflow dependency lockfiles into public preview: gh actions-lock writes .github/workflows/actions.lock, every action in an onboarded workflow runs at the recorded commit, and a Require lockfile policy can block anything else. The lock stops at the container: a Docker action's image is named in its own manifest and pulled by tag at job start, the extension warns only for a docker:// step written directly in your workflow and only on an online run, and a launch-day scan of 1,802 repositories found a silently floating image behind a locked action in 9.8% of them, 21.2% counting unpinned Dockerfile base images. By Friday the tracker also held unlocked reusable workflow calls, actions inside parallel: groups left out, and a fork-only commit that passed --verify and ran under the policy; my own offline run of the documented pre-commit check reported complete coverage over all of it.