An AI coding agent asked to set up a GitHub MCP server may install an archived package remembered from its training data. Research from Glow Labs, reported by Help Net Security, found that such packages can contain serious vulnerabilities, remain popular on npm and receive no further security fixes.
The supply-chain problem can hide inside an ordinary development request. The agent acts, the package installs and the developer sees an apparently successful setup. No one has to ignore a warning if the warning never appears.
What happened
- Glow Labs found deprecated MCP servers being installed or suggested in real AI coding sessions, a pattern researchers call MCPhantom.
- In 98% of the reviewed sessions, the agent appears to have supplied the package name from model training data. In the other 2%, the user requested the old package by name.
- Four high-severity vulnerabilities were found in reference servers, including a remote code execution flaw in a Puppeteer MCP server.
- Deprecated packages counted by Glow Labs received more than 17.3 million npm downloads since July 2025.
- No exploitation has been observed, but the archived repositories are not expected to provide patches.
The MCP layer needs its own security check
MCP, short for Model Context Protocol, lets an application discover tools exposed by a server and pass selected calls to them. The host remains responsible for deciding which information reaches the model and whether a proposed action requires approval.
That control plane matters. The model proposes an operation; the host decides whether the MCP server may execute it. Approval policy is therefore part of the security boundary, not merely a usability feature.
The documented problem begins even earlier, when the agent selects a server package. Familiar package names can dominate that decision because archive status does not reliably affect it. In Glow Labs’ GitHub example, an agent passed over GitHub’s maintained MCP server and chose a deprecated Anthropic reference server instead. The archived repository states that no security updates are coming, but the agent did not treat that notice as a reason to reject the package.
Once selected, the server can cross several visibility gaps. A server run through npx may never appear in a dependency file. Software composition analysis then has no manifest to inspect, while endpoint security may see a trusted Node process installing a public npm package. The vulnerabilities also had no CVEs, removing the standard tracking signal security teams use to surface and prioritize flaws.
Why it matters
AI coding security depends on more than whether a model generates safe code. It also depends on whether the agent can distinguish a maintained dependency from a familiar one. A plausible package identifier is not evidence that the package is current, trusted or still receiving fixes.
The most serious flaw found was a remote code execution bug in a Puppeteer server capable of driving a browser. According to Help Net Security, a prompt injection could cause the agent to start a process on the developer’s machine rather than remain inside the browser. The developer had approved web browsing, but the harness allowed that narrow permission to cover the broader operation.
That exposes the wider trade-off. MCP gives agents useful access to external services and local resources, but the permission granted to a tool may become broader than the task it was approved for. Checking whether an MCP server is “official” does not solve the problem. A package can be authentic, widely used and abandoned at the same time.
Usage has not followed the deprecations. The packages Glow Labs counted have received more than 17.3 million npm downloads since July 2025, and five appear in npm’s top MCP 100. Developers and models both recognize those names, which makes them easy to install and easy to propose. Package registries and agent hosts need to make maintenance status visible before familiarity becomes a substitute for verification.
The immediate winners are whoever controls package distribution, repository status and agent approvals. The exposed parties are developers, security teams and organizations whose agents can install code with access to sensitive development environments. The key signal to watch is not simply whether an agent checks npm before installation. In one documented session, the agent saw a deprecation message and installed the package anyway without telling the user.
Decision checklist
Before approving an MCP setup request:
- Confirm the exact package.** Compare its name and publisher with the service owner’s current documentation rather than relying on the agent’s proposed identifier.
- Check maintenance status.** Review whether the repository is archived, whether the npm package is deprecated and whether maintainers indicate that fixes are available.
- Require dependency visibility.** Prefer a recorded, inspectable dependency over an untracked npx invocation. Include agent-installed MCP servers in software inventories and vulnerability reviews.
- Separate permissions.** Treat browser, shell and filesystem access as distinct capabilities. Do not let approval for one resource authorize another.
- Constrain exposed content.** Be cautious when an agent processes web content that may contain prompt injection. The permission to browse should not permit arbitrary command execution.
- Verify the response to risk.** A package lookup or deprecation notice is not enough unless the agent is required to stop and report the problem before installation.
What to watch next
Coding agents may improve their package discovery, but discovery is not validation. A useful improvement would be a visible warning during setup when a selected MCP package is archived or deprecated, followed by a required confirmation rather than automatic installation.
Security teams should also watch for agent sessions that turn browser access into shell execution, particularly when an attacker can influence material read by the model. Another warning sign is a package download initiated by an agent rather than a developer.
Meanwhile, package owners should expect deprecation notices to affect installation behavior. Security teams should assume some agent-installed servers will remain absent from traditional dependency manifests. Until tooling closes those gaps, an MCP package proposed by an agent deserves the same scrutiny as any other dependency that can run code in a development environment.
Key takeaways
- Verify the exact MCP package against current official documentation before approving installation.
- Treat browser, shell and filesystem access as separate permissions rather than one broad capability.
- Include agent-installed packages in software inventories and vulnerability reviews.
Frequently asked questions
Why would an AI coding agent choose an archived MCP server?
In the sessions reviewed by Glow Labs, the agent usually supplied a familiar package name from training data. It did not reliably account for the repository’s archived status.
Has exploitation of these MCP vulnerabilities been observed?
According to Help Net Security, no exploitation has been seen. That does not remove the risk because some packages remain widely downloaded and the archived repositories are not expected to receive patches.
Can normal dependency scanning detect every MCP server installed by an agent?
No. Some servers run through npx and never appear in a dependency file, leaving software composition analysis without a manifest to inspect.
What should a developer check before approving an MCP setup request?
Confirm the package against current provider documentation, review its maintenance status and inspect the permissions required by the server. Avoid approving broad shell or browser authority for a narrowly defined task.