CVE-2026-75130: Serwer dokumentacji MCP Context7 ma ocenę 9.0, a wpis nie wskazuje wersji z poprawką

18 sierpnia 2026 r. VulnCheck opublikował CVE-2026-75130 dotyczące Context7 — serwera dokumentacji bibliotek, który Upstash uruchamia dla Model Context Protocol i który agenty kodujące odpytują o dokumentację konkretnych wersji. Wada tkwi w funkcji, którą Upstash nazywa Custom AI Instructions: właściciel biblioteki dołącza wskazówki do wpisu dokumentacji, Context7 podaje te wskazówki do okna kontekstu każdego agenta, który wyszukuje tę bibliotekę, a nic na tej ścieżce nie poddaje ich sanityzacji. Noma Security, której starszy badacz podatności AI Eli Ainhorn jest wskazywany jako odkrywca, wykazała, że zatruty wpis może sprawić, że połączony agent odczyta .env, czyli pliki w katalogu głównym projektu, wyśle ich zawartość do repozytorium GitHub kontrolowanego przez atakującego jako zgłoszenie, i usunie lokalne foldery pod pretekstem „sprzątania” — wszystko w wyniku rutynowego żądania dokumentacji. Nie odnotowano ofiary. Reszta udokumentowanych incydentów dotyczących agentów, każdy z własną wagą, oceną pewności i flagą sporu, znajduje się w archiwum incydentów AI, gdzie sąsiednie wpisy tego rekordu można odczytać obok niego.

Serwer Context7 jest mały i to jest część, którą warto zrozumieć w pierwszej kolejności. Tekst Nomy zauważa, że udostępnia on dwa narzędzia, resolve-library-id i query-docs, i że nie może samodzielnie wykonywać kodu, zapisywać plików ani łączyć się z siecią. Każdy udokumentowany skutek realizuje agent po drugiej stronie, który ma dostęp do systemu plików, powłoki i sieci na maszynie dewelopera. Rejestr npm pokazuje, jak duża jest liczba instalacji: @upstash/context7-mcp został pobrany 4,064,176 razy w ciągu trzydziestu dni od 22 lipca do 20 sierpnia 2026 r., czyli w okresie wokół publikacji.

Mechanizm: jedna zatruta biblioteka, każdy agent, który ją odpyta

Demonstracja Nomy, opisana w jej artykule ContextCrush z 5 marca 2026 r., przebiegała w trzech etapach, które wykonuje agent, a nie serwer. Zarejestrowała bibliotekę w rejestrze Context7 z dołączonymi zatrutymi regułami. Instrukcje w tych regułach nakazywały agentowi wyszukać i odczytać każdy plik .env w katalogu głównym projektu; kolejne instrukcje nakazywały mu opublikować zawartość w repozytorium GitHub kontrolowanym przez atakującego jako zgłoszenie; ostatni zestaw nakazywał mu usunąć lokalne foldery i pliki w ramach „sprzątania”. Żądanie, które ściąga to wszystko do kontekstu, jest zwyczajne — to prośba o pomoc z biblioteką skierowana do asystenta programowania.

Powód, dla którego jest to problem łańcucha dostaw, a nie zwykłe wstrzykiwanie promptów, tkwi w tym, gdzie znajduje się ładunek. Atakujący nigdy nie dociera do maszyny ofiary i nigdy nie musi umieszczać tekstu w dokumencie, który użytkownik otwiera. Zatrute instrukcje znajdują się we własnym rejestrze Context7, są hostowane i udostępniane przez własną infrastrukturę Context7 oraz docierają tą samą zaufaną ścieżką co legalna dokumentacja, nieodróżnialne od niej. Noma zauważa, że wskaźnik zaufania Context7, który ocenia biblioteki na podstawie stojącej za nimi historii GitHub, nie chroni przed tym, ponieważ długo istniejące konto można kupić, przejąć lub sfabrykować. Podsumowanie samej firmy dotyczące tego strukturalnego punktu jest dosadne: „Powierzchnia ataku to nie to, co serwer MCP może zrobić. To, co może zmusić agenta AI do zrobienia”.

Dwa wyniki za jednego buga

Komunikat bezpieczeństwa zawiera CVSS 3.1 9.0 (krytyczny) oraz CVSS 4.0 6.4 (średni). Oba wektory zostały dostarczone przez VulnCheck jako przydzielającego CNA, a NVD podaje oba bez zmian, przypisując każdy z nich do VulnCheck. Rozbieżność nie jest błędem; to dwa frameworki, które liczą te same szkody względem różnych maszyn. CVSS 3.1 oznacza Scope jako Changed — wstrzyknięcie wykracza poza serwer, na komputer dewelopera i dalej — i dlatego odnotowuje pełny, wysoki wpływ na poufność, integralność i dostępność możliwości agenta z pełną wagą. CVSS 4.0 zastępuje Scope osobnymi metrykami dla systemu podatnego i systemu następczego: nie odnotowuje żadnego wpływu na poufność, integralność ani dostępność dla samego Context7 (VC:N/VI:N/VA:N) oraz wysokiego wpływu na systemy położone dalej (SC:H/SI:H/SA:H), którym jego formuła nadaje mniejszą wagę. Serwer jest kurierem, a nie ofiarą.

Rozbieżność ta przenika do baz danych. Komunikat doradczy GitHub, GHSA-97r6-3rgm-v39r, został opublikowany o 18:32 UTC 18 sierpnia, pół godziny po CVE, a w podsumowaniu jego istotność określono jako średnią, mimo że wektor CVSS 3.1 w tym samym rekordzie daje wynik 9,0. Baza danych podatności UE ENISA odwzorowuje wpis jako EUVD-2026-61099 i przechowuje wynik bazowy 6,4 wyłącznie w wersji 4.0. Rekord archiwum, na którym opiera się ten artykuł, ocenia incydent jako wysoki — co nie jest żadnym z dwóch opublikowanych wyników — i jest to ocena archiwum, a nie jego własny pomiar.

CVE opublikowane w sierpniu, dotyczące ujawnienia z marca

Identyfikator CVE zarezerwowano 17 sierpnia 2026 r. i opublikowano o 18:02 UTC 18 sierpnia, co odpowiada dacie widocznej w rekordzie. Kontener CNA zawiera także drugą datę, która nie pojawia się na stronach agregatora: datePublic, 5 marca 2026 — pięć i pół miesiąca przed powstaniem identyfikatora i tego samego dnia, w którym Noma opublikowała ContextCrush. Jedyną techniczną referencją w komunikacie doradczym jest ta marcowa publikacja, którą VulnCheck oznacza zarówno jako opis techniczny, jak i exploit.

Kalendarium ujawnienia przez Nomę wyjaśnia tę lukę. Dokument podaje, że błąd zgłoszono Upstash 18 lutego 2026 r. wraz z pełnym raportem i proof of concept, odnotowuje, że Upstash zaakceptował ustalenia i rozpoczął naprawę 19 lutego, stwierdza, że poprawka została „wdrożona na produkcję z sanityzacją reguł i zabezpieczeniami” 23 lutego, a publiczne ujawnienie i ostateczną weryfikację przez Nomę datuje na 5 marca. Według relacji Nomy lutowy błąd został rozwiązany w ciągu kilku dni.

Daty w rejestrze npm układają się z tą chronologią w taki sposób, że zakres objętych wersji wygląda dziwnie. @upstash/context7-mcp 2.1.2 został opublikowany 23 lutego 2026 r. o 10:06 UTC, w dniu, w którym według Nomy poprawka trafiła do produkcji; w jego changelogu czytamy: „Remove unnecessary warning and update tool descriptions”. 2.1.3 pojawił się 4 marca 2026 r., dzień przed publikacją tekstu Nomy, z uwagami o odrzucaniu żądań GET na punktach końcowych MCP i dodaniu pola źródła do wyników wyszukiwania. Żadna z not wydania nie wspomina o sanitizacji, mechanizmach zabezpieczających ani o wstrzyknięciu. Zakres objętych wersji według CNA kończy się na 2.1.2, przez co 2.1.3 jest pierwszą wersją poza nim.

Trzy interpretacje pasują do tych dat, a ani VulnCheck, ani Noma nie podają, która jest poprawna. Pierwsza – przedstawiona przez Digital Applied w artykule z 18 sierpnia i powtórzona przez AI Security Wire 22 sierpnia – mówi, że poprawka uległa regresji: build zawierający lutową łatkę mieści się w sierpniowym zakresie wersji podatnych. Druga – że zakres jest po prostu zakotwiczony w buildzie przetestowanym przez badacza i że prawdziwą granicą jest 2.1.3, wydana dzień przed ujawnieniem – to wniosek, który kilku agregatorów wyciąga mechanicznie, w tym Feedly, wymieniający „aktualizację do wersji 2.1.3 lub późniejszej” jako środek łagodzący. Trzecia – że lutową poprawkę zastosowano tam, gdzie reguły są serwowane, a nie w pakiecie klienta; w tym przypadku zakres wersji npm w ogóle nie opisuje poprawki. Cicha poprawka bezpieczeństwa jest na tyle częsta, że brak pasującego wpisu w changelogu niczego nie rozstrzyga w żadną stronę.

Co jest ustalone, a co nie

• Potwierdzone w rekordzie źródłowym. Identyfikator CVE, jego publikacja 18 sierpnia, VulnCheck jako CNA, klasyfikacja CWE-1427 za niewłaściwą neutralizację danych wejściowych używanych do promptowania LLM, uznanie dla Eli Ainhorna z Noma Security oraz zakres objętych problemem wersji Context7 do 2.1.2 włącznie.

• Ustalone przez badania Noma. Ścieżka wstrzyknięcia przez Custom AI Instructions, trzystopniowy proof of concept, obserwacja, że serwer udostępnia wyłącznie resolve-library-id i query-docs, oraz stwierdzenie, że nie zaobserwowano dowodów na wykorzystanie błędu z lutego w rzeczywistych warunkach.

• Ustanowione przez rejestr. Data publikacji 2.1.2 to 23 lutego 2026 r., data publikacji 2.1.3 to 4 marca 2026 r., a linia pakietu od tego czasu przekroczyła 4.0 i osiągnęła 4.4.4 w dniu 19 października 2026 r.

• Nie ustalono: czy obecne kompilacje są narażone. Żadne źródło nie podaje, że linia 4.x jest narażona, ani nie podaje, że jest bezpieczna. Wpis CVE, komunikat VulnCheck i komunikat GitHub nie wskazują żadnej wersji poprawionej, a lista zakresów wersji narażonych w komunikacie GitHub jest pusta.

• Nie ustalono: żadnej ofiary ani wykorzystania w rzeczywistych warunkach.Archiwum odnotowuje rzeczywiste szkody jako fałszywe. Uzupełnienie wpisu przez CISA 19 sierpnia oceniło Eksploatację jako „brak”, Automatyzowalność jako „nie”, a Wpływ techniczny jako „całkowity”; luka nie znajduje się w katalogu KEV; kopia lustrzana ENISA odnotowuje EPSS na poziomie 0,49 proc. Badanie Noma to demonstracja, a nie raport o incydencie.

• Nie ustalono: sama interpretacja jako regresji. Opiera się ona na zbieżności dat między harmonogramem poprawki a publikacją w npm, a żadne źródło pierwotne nie twierdzi, że ta sama ścieżka kodu zawiodła dwukrotnie.

Potwierdzenie: powtórzenie i milczenie tam, gdzie ma to znaczenie

Dokumenty zgodne z rekordem są w dużej mierze z niego wyprowadzone. Komunikat doradczy VulnCheck powtarza tekst CVE i dodaje klasyfikację słabości oraz wskazanie badacza. Komunikat doradczy GitHub jest aliasem tego samego zgłoszenia, opublikowanym tego samego wieczoru, bez zakresów wersji i bez niezależnej weryfikacji. Wpis ENISA jest lustrzaną kopią. Digital Applied, jedno z dwóch źródeł cytowanych przez archiwum, opublikowało swoją analizę 18 sierpnia i zaktualizowało ją 22 sierpnia o świeże dane pobrane z rejestru; AI Security Wire opublikowało drugi tekst 22 sierpnia. Oba powtarzają komunikat doradczy i propagują wniosek o regresji, a żaden nie twierdzi, że zweryfikował go niezależnie.

Nie znaleźliśmy żadnych doniesień redakcyjnych na temat CVE z 29 października 2026 r. — żadnego materiału BleepingComputer, The Register ani SecurityWeek — a wyniki stanowiły strony agregatorów CVE, a nie materiały dziennikarskie. Ten brak ma znaczenie dla sposobu odczytania zapisu: archiwum ocenia go na A, uznając go za dobrze udokumentowany zgodnymi źródłami pierwotnymi, a te źródła pierwotne rzeczywiście się zgadzają — ale zgodność zachodzi tu między rekordem CNA a badaniami, które ten cytuje, a nie między dwoma niezależnymi pomiarami. Kilka stron agregatorów dodaje twierdzenia, których ich źródła nie potwierdzają; wpis Feedly na przykład stwierdza, że poprawka jest dostępna, i podaje numer 2.1.3, czego nie robi żaden komunikat doradczy, natomiast strona VulDB zwróciła weryfikację botów zamiast treści i nie można było jej w ogóle odczytać.

Co się zmieniło, a co nie

W przypadku lutowego błędu Upstash zadziałał w ciągu kilku dni: zgłoszenie przyjęto 19 lutego, a poprawkę wprowadzono 23 lutego — według relacji Nomy. W przypadku sierpniowego rekordu jedynym oświadczeniem dostawcy, do którego odwołuje się CVE, jest post Upstash na LinkedIn, oznaczony tam jako komunikat doradczy dostawcy, którego treści nie mogliśmy odczytać bez sesji. Żaden komunikat bezpieczeństwa GitHub dotyczący tego repozytorium nie zawiera wersji poprawionej, a wpis NVD ma status Odroczony, nie ma konfiguracji CPE, a jego ostatnia modyfikacja przypadła na 22 października 2026 r., dlatego własna analiza NVD nie znajduje się w rekordzie.

Sam pakiet był nadal wydawany. W okresie od 20 kwietnia 2025 r. do 23 października 2026 r. repozytorium upstash/context7 opublikowało 163 wydania, a żadna z ich notatek nie wspomina o tym CVE ani nie opisuje sanityzowania niestandardowych instrukcji, które przenoszą wstrzyknięcie. To zapis tego, co opiekunowie projektu zdecydowali się zapisać, a nie dowód, że nic nie zostało naprawione.

To, co ten wpis zostawia operatorowi, to zarządzanie ekspozycją, a nie gotowa ścieżka łatania. Zalecenia Noma koncentrują się na przeglądzie integracji MCP i inspekcji tego, co w czasie działania przechodzi między agentem a serwerem; sugerowane działania OpenCVE to aktualizacja, wyłączenie lub ograniczenie funkcji Custom AI Instructions oraz dodanie walidacji danych wejściowych po stronie serwera. Operacyjny wymiar tego wszystkiego sprowadza się do trzech posunięć: przypięcia wersji serwera MCP zamiast pływania na wersji latest, trzymania produkcyjnych poświadczeń z dala od jawnych plików środowiskowych, które agent może odczytać, oraz traktowania odpowiedzi narzędzi jako niezaufanych danych wejściowych, a nie dokumentacji, której agent może się trzymać.

Dziesięć tygodni po publikacji publiczny rejestr wciąż kończy się tam, gdzie zakończył się 18 sierpnia: identyfikator, dwie oceny oddalone o dwa przedziały, zakres objętych wersji, którego górna granica to kompilacja wydana w lutym, i brak wskazanego rozwiązania. Ktokolwiek dokonuje wstępnej oceny CVE-2026-75130, musi zdecydować w oparciu o to, do czego docierają ich agenci, ponieważ rejestr nie mówi im, którą wersję zainstalować.