# Unverified MCP Server Package Acquisition (verifyfirst-mcp)

- **Severity:** Medium
- **Signature ID:** `7f3c1d92-4b0e-4a7d-9c68-2e5a1b4d8f03`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise)
- **OWASP:** LLM03 (Supply Chain)

## Summary

A PyPI package named 'verifyfirst-mcp' advertises itself as a verification/registry tool for MCP servers, but its actual behaviour doesn't match that description. This rule flags any command that installs, adds, or runs this specific package (or name variants like verify_first_mcp) on a host.

## How the attack works

An attacker publishes a package under a name and description suggesting it helps verify or register other MCP servers, hoping developers or automated agents will trust and install it. The rule watches for command lines that fetch, install, or directly launch this distribution — via pip, pipx, uv, poetry, conda, 'mcp add', git clone, or a direct call to its entry point. It only fires on acquisition or launch commands, not on merely mentioning, removing, or scanning the package name. Because there's no visibility into the package registry itself, detection only becomes possible at the moment a process on the host actually pulls or runs the code.

## Why it matters

If installed, this package could execute unauthorized code disguised as a legitimate verification tool, giving an attacker a foothold inside a development or agent pipeline before any real MCP handshake even occurs.

## What you can do

- Treat any host where this package name appears in an install or launch command as needing provenance review before further use.
- Check lockfiles and CI pipeline configs for pinned references to verifyfirst-mcp or its name variants, and remove them if unverified.
- Do not allowlist any package index or internal mirror simply because it hosts a same-named package — verify the actual code, not just the origin.
- If found during IR or malware analysis work, confirm it's isolated to a sandbox and not present in build or production environments.

## Known benign look-alikes

- Malware analyst or IR engineer deliberately installing the distribution in an isolated sandbox or container to reverse it. Expected, and the reason this rule reports rather than blocks.
- A CI or scheduled rebuild replaying a lockfile that pinned the package before it was known bad. Still worth reporting — the artefact is entering a build.
- An internal fork or vendored copy that normalises to the same PEP-503 name being installed from a private index. Provenance review will resolve it; the rule intentionally does not allowlist any index host.
- Removal, `pip show`, SCA scanners and read-only greps of the string, all of which are suppressed by the filter selections.
- Documentation or tutorial text pasted into a shell as an echo/printf of a single uncompounded command, suppressed by filter_inspection.

## References

- https://attack.mitre.org/techniques/T1195/002/
- https://genai.owasp.org/llmrisk/llm03-supply-chain/
- https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

---
Source: https://www.netzilo.com/threats/unverified-mcp-package-install