CVE-2026-75130: il server MCP per la documentazione di Context7 ottiene un punteggio di 9.0 e il record non indica alcuna versione corretta

Il 18 agosto 2026 VulnCheck ha pubblicato CVE-2026-75130 nei confronti di Context7, il server di documentazione delle librerie che Upstash gestisce per il Model Context Protocol e che gli agenti di codifica interrogano per documentazione specifica per versione. La vulnerabilità risiede nella funzionalità che Upstash chiama Custom AI Instructions: un proprietario di libreria allega indicazioni a una voce di documentazione, Context7 inserisce tali indicazioni nella finestra di contesto di ogni agente che consulta la libreria, e nulla lungo quel percorso le sanitizza. Noma Security, il cui ricercatore senior di vulnerabilità AI Eli Ainhorn è accreditato come scopritore, ha dimostrato che una voce avvelenata può indurre un agente connesso a leggere .env file nella root del progetto, inviare il loro contenuto a un repository GitHub controllato dall'attaccante come issue, ed eliminare cartelle locali con il pretesto della “pulizia” — tutto da una normale richiesta di documentazione. Nessuna vittima è registrata. Il resto degli incidenti documentati relativi agli agenti, ciascuno con la propria gravità, grado di confidenza e flag di contestazione, si trova in l'archivio degli incidenti AI, dove le voci adiacenti a questo record possono essere lette accanto ad esso.

Il server di Context7 è piccolo, e questa è la parte che vale la pena capire per prima. L'articolo di Noma fa notare che espone due strumenti, resolve-library-id e query-docs, e che non può eseguire codice, scrivere file o accedere alla rete da solo. Ogni impatto documentato viene attuato dall'agente all'altro capo, che ha davvero accesso al filesystem, alla shell e alla rete sulla macchina dello sviluppatore. Il registro npm mostra quanto è ampia la base installata: @upstash/context7-mcp è stato scaricato 4.064.176 volte nei trenta giorni dal 22 luglio al 20 agosto 2026, la finestra attorno alla pubblicazione.

Il meccanismo: una libreria avvelenata, ogni agente che la interroga

La dimostrazione di Noma, descritta nel suo resoconto ContextCrush del 5 marzo 2026, si è svolta in tre fasi eseguite dall'agente anziché dal server. Ha registrato una libreria nel registro di Context7 con regole avvelenate allegate. Le istruzioni contenute in tali regole indicavano all'agente di cercare e leggere tutti i file con estensione .env nella radice del progetto; altre istruzioni gli indicavano di pubblicare il contenuto come issue in un repository GitHub controllato dall'attaccante; un ultimo insieme di istruzioni gli diceva di eliminare cartelle e file locali per “pulizia”. La richiesta che porta tutto questo nel contesto è una richiesta ordinaria — chiedere a un assistente alla programmazione aiuto con una libreria.

Il motivo per cui si tratta di un problema della catena di fornitura anziché di una normale prompt injection è dove risiede il payload. L’attaccante non raggiunge mai la macchina della vittima e non deve mai inserire del testo in un documento che l’utente apre. Le istruzioni avvelenate si trovano nel registro stesso di Context7, sono ospitate e servite dall’infrastruttura stessa di Context7 e arrivano attraverso lo stesso canale affidabile della documentazione legittima, indistinguibili da essa. Noma osserva che il punteggio di fiducia di Context7, che valuta le librerie in base alla cronologia GitHub alle loro spalle, non difende da questo, perché un account di lunga durata può essere acquistato, dirottato o creato. Il riassunto aziendale stesso del punto strutturale è diretto: “La superficie di attacco non è ciò che il server MCP può fare. È in ciò che può far fare all’agente AI.”

Due punteggi per un bug

L'avviso riporta CVSS 3.1 9.0 (critico) e CVSS 4.0 6.4 (medio). Entrambi i vettori sono stati forniti da VulnCheck in qualità di CNA assegnante, e NVD li riporta entrambi invariati, attribuendo ciascuno a VulnCheck. La divergenza non è un errore; è il modo in cui i due framework conteggiano lo stesso danno rispetto a macchine diverse. CVSS 3.1 contrassegna lo Scope come Changed — l'injection valica il confine dal server alla macchina dello sviluppatore e oltre — e quindi registra a pieno peso l'intero impatto elevato su riservatezza, integrità e disponibilità delle capacità dell'agente. CVSS 4.0 sostituisce lo Scope con metriche separate per il sistema vulnerabile e per quello successivo: non registra alcun impatto su riservatezza, integrità o disponibilità per Context7 stesso (VC:N/VI:N/VA:N) e registra un impatto elevato sui sistemi a valle (SC:H/SI:H/SA:H), che la sua formula pondera meno. Il server è il corriere, non la vittima.

La discrepanza si propaga nei database. L'avviso di GitHub, GHSA-97r6-3rgm-v39r, è stato pubblicato alle 18:32 UTC del 18 agosto, mezz'ora dopo la CVE, e la severità riepilogativa indica media anche se il vettore CVSS 3.1 nello stesso record assegna 9.0. L'EU Vulnerability Database di ENISA replica la voce come EUVD-2026-61099 e memorizza un punteggio base di 6.4 solo con la versione 4.0. Il record d'archivio cui fa riferimento questo articolo assegna all'incidente la valutazione alta — che non è nessuno dei due punteggi pubblicati — ed è la valutazione dell'archivio, non una misurazione propria.

Un CVE pubblicato in agosto per una divulgazione di marzo.

L'identificatore CVE è stato riservato il 17 agosto 2026 e pubblicato alle 18:02 UTC del 18 agosto, data che il record riporta. Il container CNA riporta anche una seconda data che non compare nelle pagine dell'aggregatore: datePublic, 5 marzo 2026 — cinque mesi e mezzo prima che l'identificatore esistesse, e lo stesso giorno in cui Noma ha pubblicato ContextCrush. L'unico riferimento tecnico dell'avviso è quel writeup di marzo, che VulnCheck contrassegna sia come descrizione tecnica sia come exploit.

La cronologia della divulgazione di Noma spiega la lacuna. Riporta la vulnerabilità a Upstash il 18 febbraio 2026 con un report completo e una proof of concept, documenta che Upstash ha accettato le conclusioni e avviato la remediation il 19 febbraio, afferma che una correzione è stata «distribuita in produzione con la sanitizzazione delle regole e guardrail» il 23 febbraio, e fissa al 5 marzo la divulgazione pubblica e la verifica finale da parte di Noma. Secondo il resoconto di Noma, il bug di febbraio è stato risolto in pochi giorni.

Le date del registro npm coincidono con quella cronologia in un modo che fa apparire anomalo l'intervallo interessato. @upstash/context7-mcp 2.1.2 è stato pubblicato il 23 febbraio 2026 alle 10:06 UTC, il giorno in cui Noma afferma che la correzione è arrivata in produzione; la riga del suo changelog recita “Rimuovi l'avviso non necessario e aggiorna le descrizioni degli strumenti.” 2.1.3 ha fatto seguito il 4 marzo 2026, il giorno prima dell'articolo di Noma, con note sul rifiuto delle richieste GET sugli endpoint MCP e sull'aggiunta di un campo source ai risultati di ricerca. Nessuna delle note di rilascio menziona la sanitizzazione, i guardrail o l'iniezione. L'intervallo interessato del CNA termina a 2.1.2, il che rende 2.1.3 la prima versione al di fuori di esso.

Tre letture si conciliano con quelle date, e né VulnCheck né Noma dichiara quale sia quella corretta. La prima, sostenuta da Digital Applied nel suo articolo del 18 agosto e ripresa da AI Security Wire il 22 agosto, è che la correzione abbia subito una regressione: la build che conteneva la patch di febbraio rientra nell'intervallo interessato di agosto. La seconda è che l'intervallo sia semplicemente ancorato alla build testata dal ricercatore, e che 2.1.3, distribuita il giorno prima della divulgazione, sia il vero limite — un'inferenza che diversi aggregatori traggono meccanicamente, tra cui Feedly, che indica «aggiornare alla versione 2.1.3 o successiva» come mitigazione. La terza è che la correzione di febbraio sia stata applicata dove vengono servite le regole anziché nel pacchetto client, nel qual caso un intervallo di versioni npm non descrive affatto la correzione. Una correzione di sicurezza silenziosa è abbastanza comune che l'assenza di una voce corrispondente nel changelog non chiarisca nulla in un senso o nell'altro.

Che cosa è stabilito e che cosa non lo è

• Stabilito dal record primario. L'identificatore CVE, la sua pubblicazione del 18 agosto, VulnCheck come CNA, la classificazione CWE-1427 per neutralizzazione impropria dell'input utilizzato per il prompting LLM, l'attribuzione a Eli Ainhorn di Noma Security e un intervallo interessato di Context7 fino alla versione 2.1.2.

• Stabilito dalla ricerca di Noma. Il percorso di iniezione tramite Custom AI Instructions, la proof of concept in tre fasi, l'osservazione che il server espone solo resolve-library-id e query-docs, e l'affermazione che non è stata osservata alcuna evidenza di sfruttamento in the wild per il bug di febbraio.

• Stabilito dal registro. La data di pubblicazione della 2.1.2 del 23 febbraio 2026, la data di pubblicazione della 2.1.3 del 4 marzo 2026 e una linea di pacchetto che da allora ha superato la 4.0 fino ad arrivare alla 4.4.4 il 19 ottobre 2026.

• Non stabilito: se le build attuali siano interessate. Nessuna fonte afferma che la linea 4.x sia vulnerabile, e nessuna fonte afferma che sia esente. Il record CVE, l'avviso VulnCheck e l'avviso GitHub non indicano alcuna versione corretta, e l'elenco degli intervalli di versioni vulnerabili dell'avviso GitHub è vuoto.

• Non accertato: nessuna vittima o uso in-the-wild. L'archivio registra come falsi i danni reali. L'arricchimento del record da parte di CISA del 19 agosto ha valutato Sfruttamento come “none”, Automatizzabile come “no” e Impatto tecnico come “total”; la falla non è nel catalogo KEV; il mirror di ENISA registra un EPSS dello 0,49 per cento. La ricerca di Noma è una dimostrazione, non un rapporto di incidente.

• Non accertato: la stessa lettura della regressione. Si basa su una coincidenza di date tra una cronologia di correzione e una pubblicazione npm, e nessuna fonte primaria afferma che lo stesso percorso di codice abbia fallito due volte.

Corroborazione: riformulazione, e silenzio dove conta

I documenti che concordano con il record sono in gran parte derivati da esso. L'avviso di VulnCheck ripete il testo della CVE e aggiunge la classificazione della debolezza e l'attribuzione al ricercatore. L'avviso di GitHub è un alias della stessa segnalazione, pubblicato la stessa sera, senza intervalli di versione e senza revisione indipendente. La voce di ENISA è una copia speculare. Digital Applied, una delle due fonti citate dall'archivio, ha pubblicato la sua analisi il 18 agosto e l'ha aggiornata il 22 agosto con nuove estrazioni dai registri; AI Security Wire ha pubblicato un secondo articolo il 22 agosto. Entrambi ripetono l'avviso e rilanciano l'inferenza sulla regressione, e nessuno dei due dichiara di averla verificata in modo indipendente.

Non abbiamo trovato alcuna copertura redazionale della CVE il 29 ottobre 2026 — nessun articolo di BleepingComputer, The Register o SecurityWeek — e i risultati erano pagine di aggregatori di CVE anziché servizi giornalistici. Tale assenza è rilevante per la lettura della scheda: l'archivio la classifica come A, ben documentata con fonti primarie concordanti, e le fonti primarie in effetti concordano, ma qui la concordanza è tra un record CNA e la ricerca che esso cita, non tra due misurazioni indipendenti. Diverse pagine di aggregatori aggiungono affermazioni che le loro fonti non suffragano; la voce di Feedly, per esempio, dichiara che è disponibile una patch e indica la 2.1.3, cosa che nessun advisory afferma, mentre la pagina di VulDB ha restituito un controllo anti-bot invece del contenuto e non è stata leggibile affatto.

Cosa è cambiato e cosa no

Per il bug di febbraio, Upstash è intervenuta in pochi giorni: accettato il 19 febbraio, risolto il 23 febbraio, secondo il resoconto di Noma. Per il record di agosto, l'unica dichiarazione del fornitore a cui il CVE fa riferimento è un post LinkedIn di Upstash, lì contrassegnato come avviso del fornitore, il cui contenuto non abbiamo potuto leggere senza una sessione. Nessun avviso di sicurezza GitHub relativo al repository riporta una versione corretta, e la voce NVD è allo stato Differito senza configurazioni CPE e con ultima modifica il 22 ottobre 2026, quindi l'analisi di NVD stessa non è nel record.

Il pacchetto stesso ha continuato a essere distribuito. Tra il 20 aprile 2025 e il 23 ottobre 2026 il repository upstash/context7 ha pubblicato 163 release, e nessuna delle loro note menziona questa CVE o descrive la sanitizzazione delle istruzioni personalizzate che veicolano l'iniezione. Questo è un resoconto di ciò che i manutentori hanno scelto di mettere per iscritto, non la prova che nulla sia stato risolto.

Quello che il record lascia a un operatore è la gestione dell'esposizione, non una linea di patch. Le raccomandazioni di Noma si concentrano sulla revisione delle integrazioni MCP e sull'ispezione di ciò che passa tra agente e server in fase di runtime; le azioni suggerite da OpenCVE sono aggiornare, disabilitare o limitare la funzionalità Custom AI Instructions e aggiungere la validazione degli input al server. La versione operativa di tutto ciò corrisponde agli stessi tre passaggi: fissare la versione del server MCP invece di fluttuare su latest, tenere le credenziali di produzione fuori dai file di ambiente in testo in chiaro che l'agente può leggere e trattare le risposte degli strumenti come input non attendibile anziché come documentazione che l'agente potrebbe seguire.

Dieci settimane dopo la pubblicazione, il registro pubblico termina ancora dove terminava il 18 agosto: un identificatore, due punteggi separati da due bande, un intervallo interessato il cui limite superiore è una build rilasciata a febbraio, e nessuna correzione nominata. Chiunque effettui il triage di CVE-2026-75130 deve decidere in base a ciò che i propri agenti possono raggiungere, perché il registro non indica loro quale versione installare.