aimcplist

Vulnerability Disclosure Policy

LAST UPDATED 2026-08-08

Draft. This page describes the embargo process as designed. It isn't operational yet — no real grades have been published, so no embargo has ever been triggered. See build spec §10 (Definition of Done).

§1Why this policy exists

If our scanning pipeline or a human reviewer finds a previously unknown, critical, unpatched vulnerability in a graded server, we do not publish the exploit path or vulnerable code immediately. Doing so would turn aimcplist into a zero-day drop site — the opposite of the trust this product is built on.

§2Scope

This policy covers vulnerabilities found in MCP servers listed on aimcplist — not aimcplist's own infrastructure. A security issue in aimcplist.com itself (the site, the API, our data) is a separate report and isn't governed by the embargo process below, which applies specifically to findings about the third-party servers we grade.

§3The embargo window

We default to 90 days from first maintainer contact, aligned with the industry-standard practice used by Google Project Zero and CERT/CC. The window closes early if the maintainer ships a fix first, and shortens if there is evidence of active exploitation.

§4What stays visible during an embargo

  • The affected server's grade is lowered immediately.
  • A notice states that a critical issue was found and the date the maintainer was notified.
  • The exploit path, proof-of-concept, and vulnerable line numbers are withheld until the embargo closes or a fix ships.

Hiding the existence of a problem would defeat the product's purpose. Hiding the exploit details protects users who haven't patched yet.

§5This applies equally to every tier

Team and Enterprise customers see exactly the same embargoed view as everyone else. There is no paid early access to vulnerability details — that would mean selling advance notice that a vendor is exploitable, which is a direct conflict of interest with the entire premise of this product.

§6Safe harbor for researchers

Security research conducted in good faith — testing an MCP server's published, publicly installable code without accessing systems or data beyond what installing it yourself would expose — will not result in legal action from aimcplist over the research itself. This mirrors the safe-harbor commitments standard among vulnerability disclosure programs, aligned with the same Google Project Zero / CERT/CC practice already cited above. This does not extend to a third-party server's own terms — a maintainer's policy toward researchers testing their server is theirs to set, not aimcplist's to grant on their behalf.

§7Reporting a vulnerability to us

If you've found a vulnerability in an MCP server listed on aimcplist and want to coordinate disclosure through us, or if you're a maintainer who wants to report a fix, see the dispute and remediation process. A dedicated reporting channel isn't live yet — this section will link directly to it once it ships.