Deprecated MCP Servers: How AI Coding Agents Install Code Nobody Will Patch

A developer asks their coding agent to connect to GitHub. The agent checks npm, sees a deprecation notice on the package it was about to install, installs it anyway, and doesn't mention it. That is one of the sessions described in new research published this week by Glow Security, and it captures a problem most application security programs have no control for.

‍

The issue isn't a new CVE in a new product. It's that the agent's memory is acting as a package manager, and that package manager has never heard of a deprecation.

What is the "MCPhantom" pattern?

MCPhantom is Glow Labs' name for a pattern in which AI coding agents install deprecated Model Context Protocol (MCP) servers that are no longer maintained and will never receive security patches.

‍

Per the reporting on Glow's findings:

• In 98% of the reviewed sessions, the agent appears to have supplied the package name from its own training data. In the other 2%, the user asked for the old package by name. The study only covered sessions where a deprecated server was installed or suggested, so this is not a rate across all agent sessions.
• Deprecated packages have been downloaded from npm more than 17.3 million times since July 2025, and five of them sit in npm's top-100 MCP packages.
• The pattern showed up across Claude Code, Cursor, Codex CLI, Claude Cowork and Claude chat, and across models from Anthropic, OpenAI and xAI.
• Glow reported four high-severity vulnerabilities in the archived reference servers. Maintainers closed the report as out of scope, because the servers were archived in May 2025 and are unmaintained.

‍

One of those flaws is a remote code execution issue in the Puppeteer server. A prompt injection can steer the agent into launching arbitrary processes instead of browser actions. Because the developer had already approved web browsing, the harness allowed it.

Why this matters: three blind spots in one pattern

The research is useful because it explains why standard controls miss it. According to the report:

From an assessment perspective, this is a familiar shape: a control that works well on paper for the declared software estate, and a risk that lives entirely in the undeclared part. We see the same blind spot with shadow CI plugins and unmanaged browser extensions. MCP servers are the newest member of that family.

‍

It also fits a broader pattern in the OWASP MCP Top 10, which lists software supply chain and dependency tampering (MCP04), shadow MCP servers (MCP09) and command injection (MCP05) as distinct risks (OWASP MCP Top 10 summary via mcp.directory). MCPhantom touches all three.

‍

How it works: the failure chain

1. Stale recall. The model recalls an MCP package name from training data. Reference servers that were popular in 2025 are over-represented in that data.
2. No deprecation signal. npm marks a package deprecated, but deprecated packages still install through npx. The report describes a session where the agent saw the notice and proceeded.
3. Implicit trust. The agent runs the server as a local process with the developer's permissions, often with tokens passed through environment variables.
4. Injection becomes execution. A prompt injection in any content the agent reads (a web page, an issue, a README) can steer a tool call in the unpatched server toward code execution.
5. Nobody can fix it. The only real remediation is a patch from the package owner. Removal from npm is limited: the report notes owners can only remove packages under 300 weekly downloads, with a single owner and no public dependents.

‍

Step 4 is the important one. None of this requires a new exploit technique. It requires an already-known class (prompt injection reaching a tool with execution capability) landing on code that is now frozen.

‍

Confirmed vs. interpreted. Confirmed by the research: the install pattern, the download numbers, the four unpatched high-severity issues, and the vendor response. Our interpretation: the structural lesson (model memory as an unmanaged package source) and the control gaps listed below. No in-the-wild exploitation has been reported.

‍

This isn't happening in isolation: October's supply chain pattern

MCPhantom lands in a month where the developer toolchain was the target again. SafeDep's October 2026 review lists, among others:

‍

• LiteLLM (21 Oct): attackers used stolen GitHub tokens belonging to three engineers to run the release workflow and publish a PyPI version with a credential stealer. The malicious wheels were live for about 1 hour 40 minutes.
• Cursor marketplace (29 Oct): a tampered copy of the Claude Code extension was served as a normal update for about 11 hours. Cursor says at most 5,000 users received it, and Anthropic said its own systems and official channels were not compromised.
• GitHub Actions (8 Oct): hijacked maintainer accounts added a fake "Security Audit" workflow to 345 repositories to exfiltrate Actions secrets.

‍

The common thread: the developer environment, and the credentials in it, is now a primary target. An agent that can install and run arbitrary servers on a laptop that holds tokens is part of that attack surface.

‍

What to do: a governance model for MCP servers

Glow's own recommendations for security teams are a good starting point: find MCP configs that reference deprecated @modelcontextprotocol servers, switch to the service owner's maintained server where one exists, approve one server per service, and add npm deprecation status to approval criteria. Here is how we would turn that into a program.

1. Build the inventory you don't have

Start with endpoints, because that's the only place these servers appear. Search developer machines and repo-level agent configs for MCP server definitions. Record package, version, maintainer, and deprecation status. Treat each as a software asset.

2. Move to an allowlist of approved servers

Approve one maintained server per service, preferably the one published by the service owner. Block everything else by policy in the agent harness where supported. Our LLM security work typically starts with this question: which tools can an agent call, and who decided that?

3. Add deprecation and ownership to approval criteria

Before approving, check npm deprecation status, last release date, number of owners, and whether the vendor ships its own server. A package with six owners and a heavy weekly download count (as the report notes for server-github) is a different risk from a vendor-maintained one.

4. Use pre-execution hooks

Many agent harnesses support hooks that run before a tool or install. Use them to block or warn on unapproved or deprecated servers, including ones already installed. This is the most direct technical control.

5. Reduce what a compromised server can reach

Assume a server will eventually run attacker-influenced input. Give local servers short-lived, narrowly scoped credentials, set spend limits on AI provider keys, and keep production secrets off developer machines. SafeDep's October lessons make the same points: short-lived secrets scoped to a single job, and a delay before adopting brand-new package versions.

6. Threat-model the agent, not just the code

Prompt injection reaching a tool with execution capability is an architecture problem. Map where untrusted content enters the agent's context and which tools it can then reach. Our write-up on MAESTRO and continuous monitoring for agentic AI covers one way to structure that analysis, and why AI agent security differs from traditional cybersecurity explains why the usual perimeter controls don't transfer.

7. Extend your supply chain program to agent tooling

If you already run a software supply chain program, fold MCP servers, agent extensions and marketplace plugins into its scope. See our primer on what software supply chain security actually covers and our supply chain security services for how we scope that work.

‍

Advanced considerations

• Model memory drifts, ecosystems move faster. Even if model vendors refresh knowledge, there will always be a gap between what a model recalls and what is currently maintained. Governance has to live outside the model.
• Approval fatigue is a control gap. In the Puppeteer example, the user's approval for browsing covered the malicious action. Approval prompts that describe a capability class, not a specific action, give a false sense of oversight.
• Fixing the package is the only real fix. Defensive layers reduce exposure, but existing users are only protected if the owner patches. Plan for compensating controls, because this is unlikely to happen for archived servers.
• Vendor-maintained isn't automatically safe. It only changes who is responsible for patching. Still assess it.

‍

Conclusion

The takeaway: stop assuming that what your agents install is what you approved. Inventory MCP servers at the endpoint, allowlist one maintained server per service, make deprecation status part of approval, and enforce it with pre-execution hooks. Then threat-model the agent so a prompt injection has less to reach when it eventually arrives.

‍

‍

‍

‍

‍

‍

‍