CVE-2026-75130: Context7s MCP-Dokumentationsserver erreicht eine Bewertung von 9,0, und im Eintrag wird keine korrigierte Version genannt

Am 18. August 2026 veröffentlichte VulnCheck CVE-2026-75130 gegen Context7, den Bibliotheksdokumentationsserver, den Upstash für das Model Context Protocol betreibt und den Coding-Agenten für versionsspezifische Dokumentationen abfragen. Die Schwachstelle steckt in der Funktion, die Upstash Custom AI Instructions nennt: Ein Bibliotheksinhaber hängt Anleitungen an einen Dokumentationseintrag, Context7 liefert diese Anleitung in das Kontextfenster jedes Agenten, der die Bibliothek nachschlägt, und nichts auf diesem Pfad bereinigt sie. Noma Security, deren leitender Forscher für KI-Schwachstellen Eli Ainhorn als Entdecker genannt wird, hat gezeigt, dass ein vergifteter Eintrag einen verbundenen Agenten dazu bringen kann, .env-Dateien im Projektstamm zu lesen, ihre Inhalte als Issue an ein GitHub-Repository zu senden, das der Angreifer kontrolliert, und lokale Ordner unter einem „Cleanup“-Vorwand zu löschen — alles aus einer routinemäßigen Dokumentationsanfrage. Kein Opfer ist verzeichnet. Die übrigen dokumentierten Agentenvorfälle, jeder mit eigener Schwere, Konfidenzstufe und Markierung als umstritten, stehen in dem KI-Vorfallarchiv, wo die benachbarten Einträge dieses Datensatzes daneben gelesen werden können.

Der Server von Context7 ist klein, und das ist der Teil, den man zuerst verstehen sollte. In Nomas Analyse steht, dass er zwei Tools bereitstellt, resolve-library-id und query-docs, und dass er selbst weder Code ausführen noch Dateien schreiben noch auf das Netzwerk zugreifen kann. Jede dokumentierte Auswirkung wird vom Agenten am anderen Ende ausgeführt, der auf dem Rechner des Entwicklers tatsächlich Zugriff auf Dateisystem, Shell und Netzwerk hat. Die npm-Registry zeigt, wie groß die installierte Basis ist: @upstash/context7-mcp wurde 4,064,176 Mal in den dreißig Tagen vom 22. Juli bis 20. August 2026 heruntergeladen, dem Zeitfenster rund um die Veröffentlichung.

Der Mechanismus: eine vergiftete Bibliothek, jeder Agent, der sie abfragt

Nomas Demonstration – beschrieben im ContextCrush-Bericht vom 5. März 2026 – lief in drei Schritten ab, die der Agent und nicht der Server ausführt. Sie registrierte eine Bibliothek in der Registry von Context7 mit angehängten vergifteten Regeln. Anweisungen in diesen Regeln wiesen den Agenten an, jede .env-Datei im Projektstamm zu suchen und zu lesen; weitere Anweisungen wiesen ihn an, die Inhalte als Issue in einem vom Angreifer kontrollierten GitHub-Repository zu veröffentlichen; eine letzte Gruppe wies ihn an, lokale Ordner und Dateien zur „Bereinigung“ zu löschen. Die Anfrage, die all dies in den Kontext zieht, ist eine gewöhnliche – man bittet einen Coding-Assistenten um Hilfe bei einer Bibliothek.

Der Grund, warum dies ein Lieferkettenproblem und keine gewöhnliche Prompt-Injection ist, liegt darin, wo die Nutzlast liegt. Der Angreifer gelangt niemals auf das Gerät des Opfers und muss niemals Text in einem Dokument platzieren, das der Benutzer öffnet. Die vergifteten Anweisungen liegen in der eigenen Registry von Context7, werden von Context7s eigener Infrastruktur gehostet und ausgeliefert und kommen über denselben vertrauenswürdigen Kanal wie die legitime Dokumentation – von ihr nicht zu unterscheiden. Noma merkt an, dass Context7s Vertrauensscore, der Bibliotheken anhand der dahinterstehenden GitHub-Historie bewertet, dagegen nicht schützt, weil ein langlebiges Konto gekauft, gekapert oder fabriziert werden kann. Die eigene Zusammenfassung des Unternehmens zu dem strukturellen Punkt ist unverblümt: „Die Angriffsfläche ist nicht das, was der MCP-Server tun kann. Sie liegt darin, was er den KI-Agenten tun lassen kann.“

Zwei Punktzahlen für einen Bug

Der Sicherheitshinweis enthält CVSS 3.1 9.0 (kritisch) und CVSS 4.0 6.4 (mittel). Beide Vektoren wurden von VulnCheck als zuweisende CNA bereitgestellt, und NVD führt beide unverändert und schreibt beide jeweils VulnCheck zu. Die Abweichung ist kein Fehler; sie rührt daher, dass die beiden Frameworks denselben Schaden unterschiedlichen Maschinen zurechnen. CVSS 3.1 markiert Scope als Changed — die Injection reicht vom Server bis zum Rechner des Entwicklers und darüber hinaus — und rechnet daher die hohen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit der Fähigkeiten des Agenten mit vollem Gewicht ein. CVSS 4.0 ersetzt Scope durch separate Metriken für das verwundbare System und das nachfolgende System: Es verzeichnet für Context7 selbst keine Auswirkungen auf Vertraulichkeit, Integrität oder Verfügbarkeit (VC:N/VI:N/VA:N) und hohe Auswirkungen auf die nachgelagerten Systeme (SC:H/SI:H/SA:H), die seine Formel weniger stark gewichtet. Der Server ist der Kurier, nicht das Opfer.

Die Diskrepanz setzt sich in den Datenbanken fort. GitHubs Sicherheitshinweis, GHSA-97r6-3rgm-v39r, wurde am 18. August um 18:32 UTC veröffentlicht, eine halbe Stunde nach der CVE, und seine zusammenfassende Schweregradangabe lautet mittel, obwohl der CVSS-3.1-Vektor im selben Datensatz 9,0 ergibt. ENISAs EU Vulnerability Database führt den Eintrag als EUVD-2026-61099 und speichert einen Basiswert von 6,4 nur unter Version 4.0. Der Archivdatensatz, dem dieser Artikel folgt, bewertet den Vorfall mit hoch – was keinem der beiden veröffentlichten Werte entspricht – und es ist die Bewertung des Archivs, keine eigene Messung.

Eine im August veröffentlichte CVE zu einer im März erfolgten Offenlegung

Die CVE-Kennung wurde am 17. August 2026 reserviert und am 18. August um 18:02 UTC veröffentlicht – das ist das Datum, das der Datensatz trägt. Der CNA-Container enthält außerdem ein zweites Datum, das auf den Aggregator-Seiten nicht erscheint: datePublic, 5. März 2026 – fünfeinhalb Monate, bevor die Kennung existierte, und am selben Tag, an dem Noma ContextCrush veröffentlichte. Die einzige technische Referenz des Advisories ist dieser März-Beitrag, den VulnCheck sowohl als technische Beschreibung als auch als Exploit kennzeichnet.

Nomas Offenlegungs-Zeitplan erklärt die Lücke. Er dokumentiert, dass die Schwachstelle am 18. Februar 2026 mit einem vollständigen Bericht und einem Proof of Concept an Upstash gemeldet wurde, hält fest, dass Upstash die Ergebnisse am 19. Februar akzeptierte und mit der Behebung begann, gibt an, dass eine Korrektur am 23. Februar „mit Regelbereinigung und Schutzvorkehrungen in die Produktion ausgerollt“ wurde, und datiert die öffentliche Offenlegung und die abschließende Überprüfung durch Noma auf den 5. März. Nach Nomas Darstellung war der Februar-Fehler innerhalb weniger Tage behoben.

Die Daten der npm-Registry stimmen mit dieser Zeitlinie so überein, dass der betroffene Versionsbereich merkwürdig aussieht. @upstash/context7-mcp 2.1.2 wurde am 23. Februar 2026 um 10:06 UTC veröffentlicht, an dem Tag, an dem Noma zufolge der Fix in Produktion ging; in seiner Changelog-Zeile heißt es „Unnötige Warnung entfernen und Toolbeschreibungen aktualisieren.“ 2.1.3 folgte am 4. März 2026, einen Tag vor Nomas Writeup, mit Anmerkungen zum Ablehnen von GET-Anfragen an MCP-Endpunkten und zum Hinzufügen eines Quellfelds in Suchergebnissen. Keine der Release-Hinweise erwähnt Sanitisierung, Schutzmechanismen oder die Injection. Der von der CNA angegebene betroffene Versionsbereich endet bei 2.1.2, wodurch 2.1.3 die erste Version außerhalb dieses Bereichs ist.

Drei Lesarten passen zu diesen Daten, und weder VulnCheck noch Noma geben an, welche korrekt ist. Die erste, vertreten von Digital Applied in seinem Artikel vom 18. August und wiederholt von AI Security Wire am 22. August, besagt, dass der Fix eine Regression erlitten hat: Der Build, der Februars Patch enthielt, liegt innerhalb des im August betroffenen Bereichs. Die zweite besagt, dass der Bereich einfach an dem Build ausgerichtet ist, den der Forscher getestet hat, und dass 2.1.3, einen Tag vor der Offenlegung veröffentlicht, die tatsächliche Grenze ist – eine Schlussfolgerung, die mehrere Aggregatoren mechanisch ziehen, darunter Feedly, das „update to version 2.1.3 or later“ als Gegenmaßnahme aufführt. Die dritte besagt, dass der Februar-Fix dort angewendet wurde, wo die Regeln ausgeliefert werden, statt im Client-Paket, sodass ein npm-Versionsbereich den Fix überhaupt nicht beschreibt. Ein stiller Sicherheitsfix ist häufig genug, dass das Fehlen eines passenden Changelog-Eintrags nichts in die eine oder andere Richtung entscheidet.

Was gilt als gesichert und was nicht

• Durch den Primärdatensatz belegt. Die CVE-Kennung, ihre Veröffentlichung am 18. August, VulnCheck als CNA, die Einstufung als CWE-1427 wegen unsachgemäßer Neutralisierung von Eingaben, die für LLM-Prompting verwendet werden, die Nennung von Eli Ainhorn von Noma Security und ein betroffener Bereich von Context7 bis 2.1.2.

• Durch Nomas Recherche belegt. Der Injektionspfad über Custom AI Instructions, der dreistufige Proof of Concept, die Beobachtung, dass der Server nur resolve-library-id und query-docs bereitstellt, und die Aussage, dass für den Februar-Bug keine Hinweise auf eine Ausnutzung in freier Wildbahn beobachtet wurden.

• Von der Registry festgelegt. Das Veröffentlichungsdatum von 2.1.2 am 23. Februar 2026, das Veröffentlichungsdatum von 2.1.3 am 4. März 2026 und eine Paketlinie, die inzwischen über 4.0 hinaus bis 4.4.4 am 19. Oktober 2026 reicht.

• Nicht geklärt: ob aktuelle Builds betroffen sind. Keine Quelle besagt, dass die 4.x-Reihe anfällig ist, und keine Quelle besagt, dass sie unbedenklich ist. Der CVE-Eintrag, das VulnCheck-Advisory und das GitHub-Advisory nennen alle keine feste Version, und die Liste der anfälligen Versionsbereiche im GitHub-Advisory ist leer.

• Nicht belegt: jegliches Opfer oder jegliche Nutzung in freier Wildbahn. Das Archiv verzeichnet echten Schaden als falsch. CISAs Anreicherung des Datensatzes am 19. August stufte Exploitation als „none“, Automatable als „no“ und Technical Impact als „total“ ein; die Schwachstelle ist nicht im KEV-Katalog aufgeführt; der ENISA-Spiegel verzeichnet einen EPSS-Wert von 0,49 Prozent. Nomas Untersuchung ist eine Demonstration, kein Vorfallbericht.

• Nicht belegt: die Deutung als Regression selbst. Sie stützt sich auf ein zeitliches Zusammentreffen zwischen einem Fix-Zeitplan und einer npm-Veröffentlichung, und keine Primärquelle behauptet, dass derselbe Codepfad zweimal fehlgeschlagen sei.

Bestätigung: Wiederholung und Schweigen, wo es zählt

Die Dokumente, die mit dem Datensatz übereinstimmen, sind weitgehend von ihm abgeleitet. Die Warnmeldung von VulnCheck gibt den CVE-Text wieder und ergänzt die Schwachstellenklassifizierung sowie die Nennung des Forschers. Die GitHub-Warnmeldung ist ein Alias derselben Einsendung, am selben Abend veröffentlicht, ohne Versionsbereiche und ohne unabhängige Prüfung. Der ENISA-Eintrag ist eine bloße Spiegelung. Digital Applied, eine der beiden Quellen, die das Archiv zitiert, veröffentlichte seine Analyse am 18. August und aktualisierte sie am 22. August mit frischen Registry-Abfragen; AI Security Wire veröffentlichte am 22. August einen zweiten Beitrag. Beide geben die Warnmeldung wieder und reichen die Regressionsvermutung weiter, und keines von beiden behauptet, sie unabhängig überprüft zu haben.

Wir fanden keine redaktionelle Berichterstattung über die CVE vom 29. Oktober 2026 – keinen Artikel von BleepingComputer, The Register oder SecurityWeek – und die Ergebnisse waren CVE-Aggregator-Seiten statt Berichterstattung. Dieses Fehlen ist relevant dafür, wie der Eintrag gelesen werden sollte: Das Archiv bewertet ihn mit A, gut dokumentiert mit Primärquellen, die übereinstimmen, und die Primärquellen stimmen tatsächlich überein, aber die Übereinstimmung besteht hier zwischen einem CNA-Eintrag und der von ihm zitierten Forschung, nicht zwischen zwei unabhängigen Messungen. Mehrere Aggregator-Seiten ergänzen Behauptungen, die von ihren Quellen nicht gestützt werden; Feedlys Eintrag beispielsweise gibt an, dass ein Patch verfügbar sei, und nennt 2.1.3, was in keinem Advisory steht, während die VulDB-Seite statt Inhalt eine Bot-Prüfung zurückgab und überhaupt nicht gelesen werden konnte.

Was sich geändert hat – und was nicht

Beim Februar-Bug reagierte Upstash innerhalb von Tagen: Noma zufolge am 19. Februar angenommen und am 23. Februar behoben. Für den August-Datensatz ist die einzige vom CVE referenzierte Anbietererklärung ein LinkedIn-Beitrag von Upstash, der dort als Vendor Advisory gekennzeichnet ist und dessen Inhalt wir ohne Sitzung nicht lesen konnten. Keine auf das Repository beschränkte GitHub-Sicherheitsmeldung enthält eine feste Version, und der NVD-Eintrag steht auf Status Deferred, ohne CPE-Konfigurationen und mit letzter Änderung vom 22. Oktober 2026, sodass die eigene Analyse des NVD nicht im Datensatz enthalten ist.

Das Paket selbst wurde weiterhin ausgeliefert. Zwischen dem 20. April 2025 und dem 23. Oktober 2026 veröffentlichte das Repository upstash/context7 163 Releases, und keine ihrer Release-Notes erwähnt diese CVE oder beschreibt die Bereinigung der benutzerdefinierten Anweisungen, die die Injection transportieren. Das ist eine Aufzeichnung dessen, was die Maintainer beschlossen haben aufzuschreiben, nicht der Beweis dafür, dass nichts behoben wurde.

Was der Eintrag einem Betreiber hinterlässt, ist Exposure-Management statt einer Patchlinie. Nomas Empfehlungen konzentrieren sich auf die Überprüfung von MCP-Integrationen und die Untersuchung dessen, was zur Laufzeit zwischen Agent und Server ausgetauscht wird; die von OpenCVE vorgeschlagenen Maßnahmen sind: ein Upgrade durchführen, die Funktion „Custom AI Instructions“ deaktivieren oder einschränken und dem Server Eingabevalidierung hinzufügen. Die operative Umsetzung all dessen besteht aus denselben drei Schritten: die MCP-Server-Version festlegen, statt auf „latest“ zu bleiben, Produktionsanmeldedaten aus Klartext-Umgebungsdateien heraushalten, die der Agent lesen kann, und Tool-Antworten als nicht vertrauenswürdige Eingaben behandeln statt als Dokumentation, der der Agent folgen darf.

Zehn Wochen nach der Veröffentlichung endet der öffentliche Eintrag weiterhin dort, wo er am 18. August endete: eine Kennung, zwei Bewertungen, die zwei Schweregradstufen auseinanderliegen, ein betroffener Versionsbereich, dessen Obergrenze ein Build ist, das im Februar ausgeliefert wurde, und kein benannter Fix. Wer auch immer CVE-2026-75130 triagiert, muss anhand dessen entscheiden, was seine Agents erreichen können, denn der Eintrag sagt ihnen nicht, welche Version sie installieren sollen.