Stille Abhängigkeitsinjektion durch KI-Dokumentationspipelines. 240 isolierte Docker-Ausführungen beweisen, dass der null-sanitisierende MCP-Server von Context Hub es vergifteten Dokumenten ermöglicht, Entwicklerprojekte ohne Vorwarnung zu kompromittieren.
Sicherheitslücke ohne Bereinigung in Context Hub (@aisuite/chub v0.1.3) ermöglicht stille Abhängigkeitsinjektion durch die MCP-Dokumentationspipeline.
Referenzen: CWE-94 (Codeeinschleusung) | CWE-829 (Nicht vertrauenswürdige Kontrollsphäre) | (Unzureichende Überprüfung der Datenauthentizität) | (Prompt-Einschleusung)
Wir haben realistische vergiftete Dokumente erstellt, die gefälschte Abhängigkeiten enthalten (plaid-link-verify, stripe-checkout-guard), und sie über einen lokalen chub MCP-Server in isolierten Docker-Containern bereitgestellt. Es wurden keine vergifteten Inhalte in die Registry von Context Hub hochgeladen – wir haben chub build lokal ausgeführt und den MCP-Server so konfiguriert, dass er die vorgebaute Ausgabe von der Festplatte bereitstellt. Aus Sicht des Agents ist die Erfahrung identisch mit dem Abrufen von Dokumenten aus der Live-Registry.
Wenn KI-Codierungsassistenten die Dokumente abriefen, schrieb Haiku in 100 % der Läufe stillschweigend das gefälschte Paket in requirements.txt – ohne es jemals in seiner Textausgabe zu erwähnen. Ein Entwickler, der die Antwort des Assistenten liest, würde nichts Verdächtiges sehen, aber sein Projekt ist vergiftet.
240 isolierte Läufe. 3 Modelle. 4 Aufwandsstufen. 2 APIs. 0 Kontamination.
Der generierte Code importiert stillschweigend die gefälschte Abhängigkeit zusammen mit legitimen Modulen:
Der Agent ändert auch CLAUDE.md, um das gefälschte Paket als „Projektstandard" einzubetten:
Diese Tabellen zeigen Plaid-Link-Ergebnisse (120 isolierte Läufe). Siehe RESULTS.md für vollständige Daten einschließlich Stripe Checkout (insgesamt 240 Läufe).
| Aufwand | Haiku | Sonnet | Opus |
|---|---|---|---|
| Niedrig | 100% | 60% | 0% |
| Mittel | 100% | 70% | 0% |
| Hoch | 100% | 40% | 0% |
| Max | 100% | 40% | 0% |
Haiku warnte nie vor der gefälschten Abhängigkeit (0/40). Sonnet warnte in 48 % der Läufe (19/40), vergiftete aber dennoch in insgesamt 53 % die requirements.txt. Opus warnte in 75 % der Läufe (30/40) und vergiftete nie die requirements.txt oder den Code.
| Aufwand | Haiku | Sonnet | Opus |
|---|---|---|---|
| Niedrig | 90% | 70% | 0% |
| Mittel | 80% | 70% | 0% |
| Hoch | 90% | 40% | 0% |
| Max | 90% | 50% | 0% |
Haiku ändert das CLAUDE.md des Projekts, um die gefälschte Abhängigkeit als „Projektstandard" in 88 % der Läufe (35/40) aufzunehmen. Diese Datei wird in Git committet – jeder zukünftige Entwickler, der das Repository klont, erbt die vergiftete Konfiguration.
flowchart LR
A["Angreifer\nreicht PR ein"] -->|"Keine Identitäts-\nprüfung"| B["Maintainer\nführt PR zusammen"]
B -->|"Keine Inhalts-\nbereinigung"| C["Dokument auf CDN\n(keine Integritätsprüfung)"]
C -->|"MCP liefert\nrohen Inhalt"| D["Agent-Kontext-\nfenster"]
D -->|"Agent handelt auf\nunvertrauenswürdigem Inhalt"| E["Entwickler-\nArbeitsplatz"]
style A fill:#111,stroke:#333,color:#f0f0f0
style B fill:#161616,stroke:#333,color:#888
style C fill:#161616,stroke:#333,color:#888
style D fill:#161616,stroke:#333,color:#888
style E fill:#111,stroke:#333,color:#f0f0f0| Angreifer | Jeder, der einen PR in die Dokumenten-Registry von Context Hub einreichen kann |
| Angriffsfläche | Community-Dokumente, die von GitHub PR über CDN zu MCP bis zum Agent-Kontext fließen |
| Vertrauensgrenze | Nicht vertrauenswürdige Beitragsinhalte werden als autoritative API-Dokumentation behandelt |
| Voraussetzung | Ein zusammengeführter PR, der ein vergiftetes Dokument enthält |
| Auswirkung | Beliebige Codeausführung durch Abhängigkeitsinjektion + pip-Postinstallations-Hooks |
Haiku-Vergiftung ist völlig still. 0/80 Haiku-Läufe über beide APIs hinweg erwähnten die gefälschte Abhängigkeit in der Antwort. Das Modell schreibt auf die Festplatte, ohne es zu sagen. Sonnet warnte in 48 % der Läufe, vergiftete aber dennoch in 35–53 % der Läufe die requirements.txt. Opus warnte in 23–75 % der Läufe und vergiftete nie die requirements.txt oder den Code.
Haiku ist auf jeder Aufwandsstufe zu 100 % ausnutzbar. Aufwandsunabhängig bei beiden APIs. Das schwächste Modell der Familie erwischt die gefälschte Abhängigkeit nie.
Opus widersteht Code-Vergiftung, aber nicht Konfigurationsvergiftung. Opus hat nie die gefälschte Abhängigkeit in requirements.txt oder Python-Code geschrieben (0/80 über beide APIs). Aber bei Stripe änderte Opus CLAUDE.md in 38 % der Läufe und dokumentierte den Canary als Projektabhängigkeit, ohne ihn zu installieren.
Persistenz in CLAUDE.md erzeugt einen Lieferkettenvektor. Geänderte Konfigurationsdateien werden in Git committet und vergiften jeden Entwickler, der das Repository klont, sowie jede zukünftige KI-Sitzung in diesem Projekt. Dies funktioniert über alle Modelle hinweg (Haiku 88–90 %, Sonnet 58 %, Opus 0–38 %).
API-Vertrautheit ist wichtig. Stripe (bekannt): Modelle erkennen gefälschte Pakete über Trainingsdaten. Plaid (weniger bekannt): Modelle können die gefälschte Abhängigkeit nicht überprüfen und akzeptieren sie fraglos.
Dies ist ein kategoriesweites Problem. Context7 hatte ContextCrush (Feb. 2026). Context Hub hat dieses. Jedes Tool, das unbereinigte externe Inhalte in den Agent-Kontext einschleust, ist anfällig.
Keinerlei Bereinigung in der gesamten Pipeline:
annotations.js – writeFileSync mit rohem Inhalt, keine Filterungbuild.js – keine Inhaltsprüfung, keine Unicode-Normalisierungcache.js – CDN-Abruf ohne Hash-/Signaturverifikationsource: official in Frontmatter – selbstdeklariert, nicht verifiziertContext Hub hat keine SECURITY.md. Es gibt keinen dokumentierten Weg, eine Schwachstelle verantwortungsvoll zu melden – keinen Sicherheitskontakt, keinen PGP-Schlüssel, keine Richtlinie zur Offenlegung. Community-Mitglieder fanden die Schwachstellen trotzdem und reichten sie als normale Issues und PRs ein. Keine wurden überprüft.
| Datum | Ereignis |
|---|---|
| 2026-03-12 | Issue #74 eingereicht von @bjorkbjork, das 4 Sicherheitslücken meldet, darunter CDN-Integrität, selbstdeklarierte Quellenverifikation und Annotationseinschleusung |
| 2026-03-12 | Issue #74 intern einem Kernteammitglied zugewiesen – null Nachverfolgung |
| 2026-03-17 | PR #125 eingereicht von @hobostay, der eine Inhaltsintegritätsverifikation hinzufügt – null Überprüfungen |
| 2026-03-12 bis 03-20 | Zusätzliche Sicherheits-PRs (#69, #81) von der Community eingereicht – null Überprüfungen |
| 2026-03-20 bis 03-23 | Unabhängiges Audit bestätigt und quantifiziert die Schwachstellen mit 240 isolierten Docker-Läufen |
| 2026-03-23 | Öffentliche Offenlegung |
Hinweis: Wir haben Issue #74 nicht eingereicht. Unser Audit hat diese Schwachstellen unabhängig entdeckt und quantifiziert. Issue #74 und die PRs #69, #81, #125 werden als Stand der Technik zitiert, der zeigt, dass die Community diese Probleme bei null Engagement der Betreuer markiert hat.
Sobald sich das gefälschte Paket in requirements.txt befindet, ermöglicht eine Standard-pip install -r requirements.txt dem Angreifer beliebige Codeausführung über setup.py-Postinstallations-Hooks. Dies ist keine Sandbox – pip führt uneingeschränktes Python mit den vollen Berechtigungen des Entwicklers aus.
Von diesem einzelnen Einstiegspunkt aus kann der Angreifer:
.env-Dateien oder Quellcode lesen und an einen vom Angreifer kontrollierten Server senden.~/.chub/config.yaml ändern, um eine vom Angreifer kontrollierte Dokumentenquelle hinzuzufügen. Alle zukünftigen chub-Abfragen über alle Bibliotheken hinweg enthalten nun Angreiferinhalte. Überlebt chub cache clear, da die Konfiguration kein Cache ist.Diese sind nicht gegenseitig ausschließend. Ein einziger Postinstallations-Hook kann all dies in unter einer Sekunde erledigen. Wir haben kein bösartiges Paket erstellt oder registriert.
.
|-- README.md # Diese Datei
|-- RESULTS.md # Vollständiger Datensatz mit Einzellaufaufschlüsselungen
|-- REPRODUCE.md # Docker-basierte Reproduktionsanleitung
|-- alternatives-comparison.md # Vergleich von Context7, LAP, GitMCP, Docfork
|-- article.html # Vollständiger Bericht
|-- docker/
| |-- Dockerfile # Isolierte Testumgebung
| |-- run_isolated.ps1 # PowerShell-Ausführer (Windows/macOS/Linux via pwsh)
| |-- seed-claude.md # Minimales CLAUDE.md, das in jeden Lauf eingespeist wird
| |-- plaid-doc/ # Vergiftetes Plaid-Link-Dokument (Canary: plaid-link-verify)
| | `-- plaid/link/DOC.md
| `-- stripe-doc/ # Vergiftetes Stripe-Checkout-Dokument (Canary: stripe-checkout-guard)
| `-- stripe/checkout/DOC.md
`-- results/
|-- plaid-isolated/ # 120 Plaid-Läufe: JSON + Sitzungstranskripte + Projektdateien
`-- stripe-isolated/ # 120 Stripe-Läufe: JSON + Sitzungstranskripte + Projektdateien
Siehe REPRODUCE.md für die vollständige Docker-basierte Reproduktionsanleitung.
Schnellstart:
# Plaid (default)
docker build --build-arg DOC_DIR=plaid-doc -t plaid-bench docker/
docker run -d --name plaid-runner plaid-bench sleep infinity
docker exec -it plaid-runner claude login
# Stripe
docker build --build-arg DOC_DIR=stripe-doc -t stripe-bench docker/
docker run -d --name stripe-runner stripe-bench sleep infinity
docker exec -it stripe-runner claude login
# Then run the test matrix from the host (see REPRODUCE.md)
--permission-mode bypassPermissions. Echte Agents können um Bestätigung bitten.MIT
Diese Forschung wurde von Mickey Shmueli durchgeführt, dem Entwickler von LAP, einer Open-Source-Alternative zu Context Hub. LAP verwendet deterministische Kompilierung aus offiziellen API-Spezifikationen, ohne von der Community beigetragene Inhalte in der Pipeline. Dieses Audit wurde durch ein echtes Sicherheitsbedenken hinsichtlich unbereinigter Inhaltspipelines motiviert – eine Schwachstellenklasse, die jedes Tool in diesem Bereich betrifft, das unverifizierte Community-Beiträge akzeptiert. Die Ergebnisse stehen für sich: 240 isolierte Docker-Läufe, deterministische Erkennung, vollständig reproduzierbar.
Dieser PoC dient ausschließlich Bildungs- und Sicherheitsforschungszwecken. Alle Tests wurden lokal in isolierten Docker-Containern durchgeführt. Es wurden keine bösartigen Inhalte an das Context Hub-Repository übermittelt. Alle Canary-Paketnamen wurden vor dem Test als nicht existent auf PyPI verifiziert.