studiomeyer-io/mcp-server-attestationLayer-2-Härtung der Lieferkette für MCP-Server — Ed25519-signierte Tool-Manifeste, Runtime-Spawn-Attestierung, Default-Deny-Argument-Sanitizer. Schützt vor Marketplace-Poisoning + CVE-2025-69256 + CVE-2025-61591.
<!-- studiomeyer-mcp-stack-banner:start --> > **Teil des [StudioMeyer MCP Stack](https://studiomeyer.io)** — Gebaut auf Mallorca 🌴 · ⭐ wenn du es nutzt <!-- studiomeyer-mcp-stack-banner:end --> # mcp-server-attestation <!-- badges --> [](https://www.npmjs.com/package/mcp-server-attestation) [](https://www.npmjs.com/package/mcp-server-attestation)    <!-- /badges -->Layer-2-Härtung der Lieferkette für Model Context Protocol-Server. Ed25519-signierte Tool-Manifeste, Laufzeit-Spawn-Attestierung, Default-Deny-Argument-Sanitiser. Direkte Antwort auf: - **OX Security Marketplace-Poisoning, April 2026** — 9 von 11 MCP-Registries akzeptierten bösartige Server. Die veröffentlichte Position von Anthropic: „erwartetes Verhalten". - **CVE-2025-69256** — Serverless Framework MCP RCE über Befehlsinjektion in `child_process.exec()`. - **CVE-2025-61591** — Cursor MCP RCE durch einen per OAuth installierten bösartigen Server mit Spawn-Hijacking. Dieses Paket bietet, was Anthropic bewusst weggelassen hat: kryptografische Verifizierung, welche Tools ein Server exponieren darf und welche Spawn-Aufrufe er tätigen darf. Es ist eine Drop-in-Abhängigkeit, kein Laufzeit-Ersatz. ## Eine Notiz von uns Wir bauen seit zwei Jahren Tools und Systeme für uns selbst. Dass dieses Repo klein ist und wenige Stars hat, liegt nicht daran, dass es neu ist. Es liegt daran, dass wir uns erst jetzt dazu entschieden haben, zu teilen, was wir gebaut haben. Es ist kein frisches Experiment, sondern eine lange Geschichte mit einem kürzlichen Commit. Wir lieben es, Dinge zu bauen und zu teilen. Wir mögen keine Social-Media-Taktiken, Growth-Hacks oder das Jagen von Stars und Followern. Deshalb ist dieses Repo klein. Der Code ist echt, er wird genutzt, Issues werden beantwortet. Urteile selbst. Wenn es dir hilft, helfen uns Teilen, Testen und Feedback. Wenn es besser sein könnte, ist ein Issue nützlicher. Wenn du etwas damit baust, sag es uns unter [email protected]. Das macht unseren Tag wirklich. Aus einem kleinen Studio in Palma de Mallorca. ## Pakete (npm-Workspaces) | Paket | Zweck | | --- | --- | | `mcp-server-attestation` (`packages/lib`) | Bibliothek: Ed25519 signieren/verifizieren, Manifest-Schema, Sanitiser, Spawn-Attester, TOFU-Vertrauensspeicher. | | `mcp-attest-cli` (`packages/cli`) | CLI `mcp-attest`: `keygen`, `sign`, `verify`, `inspect`, `fingerprint`, `check-pin`. | | `mcp-attest-demo` (`packages/demo-server`) | Referenz-MCP-Server (stdio, Spec 2025-06-18), der 5 Tools bereitstellt, die die Bibliothek demonstrieren. | ## Installation ```bash npm install mcp-server-attestation # CLI: npm install -g mcp-attest-cli # Reference MCP server: npx mcp-attest-demo ``` Node 20+. Keine externen Crypto-Abhängigkeiten — nutzt die Ed25519-Primitive von `node:crypto`. ## Server-Schnellstart in fünf Zeilen ```ts import { verifyManifestStrict, attestSpawnStrict, type SignedManifest } from "mcp-server-attestation"; import signed from "./signed/manifest.json" assert { type: "json" }; // 1. At startup: prove the manifest you ship is the manifest you signed. verifyManifestStrict(signed); // 2. Before every child_process.spawn: attestSpawnStrict(signed as SignedManifest, { command, args }); ``` Das ist die gesamte Integration. Zwei Funktionsaufrufe, kein SaaS, kein Daemon. Wenn du die Signatur bei jedem Spawn lieber erneut verifizieren möchtest (Defense-in-Depth gegen ein unverifiziertes oder ausgetauschtes Manifest, das das Gate erreicht), nutze stattdessen den einzelnen Fail-Safe-Aufruf — er verifiziert *und attestiert dann*: ```ts import { attestSpawnVerified, type SignedManifest } from "mcp-server-attestation"; attestSpawnVerified(signed as SignedManifest, { command, args }); ``` ## Tools (Referenzserver `mcp-attest-demo`) | # | Name | readOnlyHint | destructiveHint | | - | ---- | ------------ | --------------- | | 1 | `attest_verify_manifest` | true | false | | 2 | `attest_inspect_spawn` | true | false | | 3 | `attest_generate_manifest_template` | true | false | | 4 | `attest_sign_manifest` | false | false | | 5 | `attest_keygen` | false | false | Die Annotationen sind ehrlich: `attest_sign_manifest` und `attest_keygen` schreiben Dateien auf die Festplatte, sind also nicht schreibgeschützt, zerstören aber keine vorhandenen Daten, daher bleibt destructiveHint false. Siehe `docs/THREAT-MODEL.md` für die Fähigkeitentabelle pro Tool. ## CLI ```bash mcp-attest keygen --out-dir ./keys --name prod mcp-attest sign --manifest manifest.json --private-key keys/prod.key --out signed.json mcp-attest verify --signed signed.json --pin # TOFU pin mcp-attest verify --signed signed.json --sigstore # opt-in Rekor cross-ref mcp-attest inspect --signed signed.json --command /usr/bin/echo --arg "hello" mcp-attest fingerprint --public-key keys/prod.pub mcp-attest check-pin --server my-server --signed signed.json ``` `verify` beendet sich bei ungültiger Signatur mit Code 2, bei PIN-Abweichung mit Code 3. ## MCP-Spec-Kompatibilität | Spec-Version | Status | | --- | --- | | 2024-11-05 | im Manifest parsebar, kein Ziel des Referenzservers | | 2025-03-26 | im Manifest parsebar, kein Ziel des Referenzservers | | 2025-06-18 | vollständiges Ziel | Die Bibliothek ist transport-agnostisch. Der Referenzserver ist ausschließlich stdio-basiert. ## Sicherheitsmodell - **Trust-on-First-Use** ist die Standardeinstellung. Beim ersten Verifizieren eines Servers wird sein öffentlicher Schlüssel in `~/.mcp-attest/trust.json` gepinnt (überschreibbar über `MCP_ATTEST_TRUST_FILE`). Spätere Verifizierungen lehnen jeden neuen Schlüssel für denselben Servernamen mit `TRUST_PIN_MISMATCH` ab. Das fängt den Angriffsvektor bösartiger Updates im Cursor-Stil ab. - **Keine gebündelte Liste vertrauenswürdiger Schlüssel.** Dieses Paket fungiert nicht als Gatekeeper. Wenn du eine stärkere Absicherung möchtest, aktiviere `--sigstore`, um den Fingerabdruck des öffentlichen Schlüssels gegen das Sigstore-Rekor-Transparenzprotokoll abzugleichen. - **Default-Deny-Argument-Sanitiser.** `shellSafeString` blockiert jedes ASCII-Shell-Metazeichen, NUL, CR, LF, VT, FF, NEL, Nullbreitenzeichen, BOM, RTL/LTR-Overrides, Trojan-Source-Isolate und Vollbreiten-Latein-Konfusablen. Allowlist-Verhalten erfordert die expliziten Regelarten `regex` / `enum` / `prefix` / `literal`. - **ReDoS-sichere `regex`-Regeln.** Das Muster einer `regex`-Regel wird vom Autor signiert, aber der Argumentwert ist angreiferkontrolliert. Der Sanitiser erkennt statisch backtracking-anfällige Muster (verschachtelte unbegrenzte Quantoren wie `(a+)+`) und weigert sich, sie auszuführen, sodass ein einzelnes präpariertes Argument den Spawn-Hot-Path nicht einfrieren kann. `regex`-Regeln haben außerdem eine `maxLength`-Eingabebegrenzung (Standard 4096). - **Traversal-sichere `prefix`-Regeln.** `prefix`-Regeln lehnen `..`-Pfadkomponenten standardmäßig ab (`denyTraversal: true`, einschließlich der `%2e%2e`-kodierten Form), sodass `/safe/../../etc/passwd` blockiert wird, obwohl es `prefix: "/safe/"` erfüllt. - **Verify-then-attest.** `attestSpawnVerified` prüft die Manifestsignatur, bevor es den Spawn in einem einzigen Fail-Safe-Aufruf attestiert — verwende es anstelle von `attestSpawnStrict`, es sei denn, du hast gemessen, dass die Ed25519-Verifizierung pro Spawn außerhalb einer echten heißen Schleife liegt. - **Kanonisches JSON** ist die signierte Oberfläche. Eine erneute Serialisierung kann die signierten Bytes nicht verändern. Was dieses Paket NICHT tut (außerhalb des Scopes): - Den Serverprozess sandboxen oder containerisieren. - OAuth-Flow-Härtung (separater `mcp-oauth-shield`-Build). - Netzwerk-Egress-Kontrolle. - Automatisches Patchen bestehender Server. ## Tests ```bash npm install npm run typecheck npm test ``` Der Testkorpus umfasst CVE-Replay-Fixtures (`packages/lib/tests/fixtures/cve-2025-69256-payloads.json`, `cve-2025-61591-payloads.json`). Der Build ist ein Regressionstest: Jedes Payload muss blockiert werden. ## Distribution - npm-Publish über GitHub Actions OIDC mit `--provenance`. - Referenzserver bei mcp.so und im FastMCP Directory eingereicht. - Bibliothek separat als `mcp-server-attestation` veröffentlicht. ## Über StudioMeyer [StudioMeyer](https://studiomeyer.io) ist ein KI- und Design-Studio mit Sitz in Palma de Mallorca, das mit Kunden weltweit arbeitet. Wir bauen maßgeschneiderte Websites und KI-Infrastruktur für kleine und mittlere Unternehmen. Produktions-Stack auf Claude Agent SDK, MCP und n8n, mit Sentry, Langfuse und LangGraph für Observability und einer internen Guard-Schicht. ## Lizenz MIT, Copyright 2026 Matthias Meyer (StudioMeyer). Siehe `LICENSE`.
