14 Oct 2026 · Nadia Ferreira-Strand (editorial persona) · Agent artifact supply chain · on threat.cafe

Official-looking isn't official: how to verify who published an MCP server named after a real vendor

An MCP server named after a vendor is not from that vendor until the vendor's own channels say so. The first malicious MCP server found in the wild, postmark-mcp on npm, was a copy of Postmark's code published by an unrelated account. Version 1.0.16 added one line that blind-copied every email to an outside address, and Postmark said it did not develop the package (The Hacker News, September 2025). The routine below takes about ten minutes per server. It starts from the vendor's documentation, never from the package page, and checks that the name, publisher and source repository all match.

Outcome, time and access

Outcome: a yes or no on whether a vendor-named MCP server comes from that vendor, recorded with evidence.

Time: about ten minutes per server. Longer if the vendor has no documentation.

Access needed: a browser, the npm CLI (or pip for Python servers), and write access to your team's approved-server list.

Use this routine if, and do not use it if

Use it if you are about to connect an MCP server whose name includes a SaaS brand: email, CRM, payments, health data, cloud.

Use it if an agent proposed the server. PolicyLayer's typosquatting write-up notes that an agent asked to install a server may pick a squatted name because it matches common search patterns.

Do not use it alone for servers with no vendor brand. Publisher checks prove who shipped the code. They do not prove the code is safe. Those servers need a code review and a pinned version as well.

Pre-flight: know the pattern you are checking for

The postmark-mcp facts, from The Hacker News:

The legitimate Postmark MCP server lives on GitHub at ActiveCampaign/postmark-mcp.
The npm package postmark-mcp was published by npm user phanpak, who also maintained 31 other packages.
The package was a replica of the original code plus one added BCC line in version 1.0.16, released 17 September 2025.
It had 1,643 downloads. Koi Security found it. npm has since removed it.
Postmark said it did not develop, authorise or take part in the package.

One more fact sets the trap. PolicyLayer reports the attacker shipped 15 clean releases before adding the backdoor. A long, clean version history is not evidence of the right publisher.

Step-by-step routine

Start at the vendor. Search the vendor's own documentation site for "MCP". Record the URL of the page that names an official server. Verify: the page is on the vendor's domain. If no page exists, stop and go to Failure mode 1.

Copy the exact identifiers from that page. Record the package name, registry and source repository exactly as the vendor writes them. Verify: you copied them, you did not retype them. One dropped letter is the whole attack.

Compare the package's publisher with the vendor. For npm, run:

npm view <package-name> name maintainers repository.url

Verify: the maintainers are accounts the vendor controls, and repository.url points at the repository from step 2. If the publisher is an individual account with no visible link to the vendor, do not proceed.

Do not trust the repository field on its own. The repository.url value is written by the publisher. A copycat can point it at the real vendor repository. Check provenance instead. Add the package to a scratch project on a machine with no credentials, with install scripts disabled, then run:

npm audit signatures

Verify: the output counts the package among those with verified attestations. Then open the package's page on npmjs.com and confirm the provenance details name the vendor's repository. No attestation is not proof of malice, but it removes this check. Record it.

Check the official MCP Registry namespace. In the official MCP Registry, a server name like io.github.vendor-org/server means the publisher logged in as that GitHub account or organisation. A name like com.vendor/server means the publisher proved control of the vendor.com domain through a DNS TXT record or a file at /.well-known/mcp-registry-auth. Verify: the namespace matches the vendor's real GitHub organisation or domain. A domain-verified namespace is the strongest publisher signal the registry offers. It still says nothing about the code.

Pin what you verified. Record the exact version and the lockfile integrity hash. Verify: your agent config names that version, not a range.

Record the decision. Add a row to your approved-server list (see the card below).

What each check proves, and what it does not

Each step answers a narrower question than it appears to. Record the answer, not the impression.

Vendor documentation page: proves the vendor endorses a specific package or repository. It does not prove the package you are looking at is that one.
Package maintainers: proves which registry accounts can publish new versions. It does not prove who controls those accounts today: the malicious March 2026 axios versions were published from a compromised maintainer account (StepSecurity).
Repository field: proves nothing on its own, because the publisher writes it.
Provenance attestation: proves a version was built from a named repository by a CI system. It does not prove the code in that repository is benign.
Registry namespace: proves control of a GitHub account or domain at publish time. It says nothing about the code.
Version pin and hash: proves you will run the bytes you checked. It does not stop you from checking the wrong bytes.

The postmark-mcp copy would have failed at the second check: its maintainer was an individual npm account with no link to Postmark or ActiveCampaign.

The verification card

Paste this into your team channel or ticket template.

MCP PUBLISHER CHECK                              date: ____  by: ____
Server name as proposed: ______________________________________
1. Vendor doc page naming official server (URL): _______________
2. Exact package + repo from vendor page: ______________________
3. Package maintainers match vendor?          [ ] yes  [ ] no
4. Provenance attestation from vendor repo?   [ ] yes  [ ] none  [ ] mismatch
5. MCP Registry namespace matches vendor?     [ ] github org  [ ] domain  [ ] n/a
6. Pinned version + integrity hash: ____________________________
RESULT:  [ ] official  [ ] third-party (needs code review)  [ ] reject
Any "no" or "mismatch" in 3-5 = reject until explained in writing.

Three common failure modes and fixes

Failure mode 1: the vendor publishes no official server

Many vendors do not. Then every server for that product is third-party, whatever its name says. Fix: drop the brand from your mental label. Review the code, pin the version, give it only the one API key it needs, and restrict its outbound hosts to the vendor's API domain. Re-check the vendor's docs each quarter.

Failure mode 2: the vendor points at a community project

Some vendor docs link to a server maintained by someone else. Fix: the vendor link establishes which repository is endorsed, not who can publish to the package. Run steps 3 to 5 against that repository's maintainers. Treat any package published from a different account as a copy.

Failure mode 3: a near-miss name

PolicyLayer lists the variations: a dropped letter, an added hyphen, singular versus plural, or an attacker-controlled namespace. It cites suport-color, posing as support-color, from a February 2026 npm worm that wrote rogue MCP servers into agent config files. Fix: never type a server name from memory or accept one an agent proposes. Copy it from the vendor page in step 2.

Rollback: you already installed an impersonator

Remove the package from every project and global install.
Remove its entry from each agent config file. PolicyLayer notes that a config entry can survive package removal, since clients load configured servers at launch. Check .mcp.json, claude_desktop_config.json, .cursor/mcp.json and your editor settings.
Rotate every credential you passed to the server, from a clean machine.
Review the service's own logs for the data the server could touch. For an email server, look for unexpected BCC recipients, as The Hacker News advised for postmark-mcp.
Report the package to the registry and to the vendor.

Verify the rollback: restart the agent and confirm the server no longer appears in its server list.

The threat.cafe board records postmark-mcp and other impersonation cases with the finder credited, so you can check a name against known-bad entries before step 1.

Sources

#mcp #impersonation #typosquatting #postmark-mcp #publisher-verification

All posts