Takedown request: io.github.jUXTAPOSITION1/vape (reported as malware delivery, 9 August; still `active`)

[imran-siddique]

Server

io.github.jUXTAPOSITION1/vape, version 1.1.1, published 2026-08-08T20:58:40.591925Z,
currently status: active, isLatest: true. Its statusChangedAt is identical to its
publishedAt, so the status has not been touched since publication.

• repository: https://github.com/jUXTAPOSITION1/V.A.P.E (source: github)
• package: vape-mcp-server on PyPI, 1.1.1, runtimeHint uvx, transport stdio

Why this falls under the moderation policy

The policy removes "Malware, regardless of intentions".

1. Published third-party report. OX Security reported this entry on 9 August 2026, one day
after it was published, in their Shai-Hulud outbreak debrief. Their account, quoted:

The linked GitHub repository (jUXTAPOSITION1/V.A.P.E) contains embedded malicious execution
instructions within the local workspace settings files (.vscode/settings.json and
.claude/settings.json configuration files).

and

The PyPI package linked by the MCP server is completely clean to evade automated package
scanners.

They describe it as the first time they observed that payload delivered through this registry.
https://www.ox.security/blog/shai-hulud-outbreak-debrief-the-worm-evolves-into-mcp/

I have not reproduced the payload and I am not asserting it independently. What follows is what
I could check myself.

2. GitHub has blocked the linked repository for terms of service. The API records the block,
not an inference from a 404:

$ gh api repos/jUXTAPOSITION1/V.A.P.E
{"message":"Repository access blocked",
 "block":{"reason":"tos","created_at":"2026-08-15T00:32:55Z","html_url":"https://github.com/tos"}}

That is six days after the report, and six days before this issue.

3. The entry therefore points at a repository no client can fetch.

$ curl -s -o /dev/null -w '%{http_code}\n' https://raw.githubusercontent.com/jUXTAPOSITION1/V.A.P.E/main/README.md
404

4. The package is still installable. vape-mcp-server 1.1.0 and 1.1.1, both uploaded
2026-08-08, neither yanked, per the PyPI JSON API. All three of its project URLs point at the
blocked repository.

Reproduce

curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=vape" \
  | jq '.servers[] | select(.server.name|test("vape")) | {name:.server.name, repo:.server.repository.url, meta:._meta["io.modelcontextprotocol.registry/official"]}'

Ask

Set the entry to deleted with a statusMessage recording the reason, per the moderation
policy's removal mechanism.

One thing I noticed while checking, offered as context rather than a second ask

Across all 24,615 records (version=latest&include_deleted=true), 735 carry a statusMessage:
491 of 539 deleted, 244 of 253 deprecated. I read all 735. None of them describes a
moderation action; they are renames, consolidations and republications. That is consistent with
the field's origin, since #623 was closed on the ground that statusMessage covers the
publisher's deprecation-reason use case.

So if this entry is taken down, the record it leaves will be shaped exactly like a publisher
retiring a listing, and a downstream aggregator will have no way to tell the two apart. If a
distinct shape for that would be useful I am happy to write it up separately rather than expand
this issue.

I am deliberately not raising repository validation here. #395 and #1266 already own it.