CVE-2026-18953: il server MCP Transform di AWS non aveva alcun confine di scrittura

Amazon ha pubblicato il bollettino di sicurezza 2026-075-AWS il 5 agosto 2026 per CVE-2026-18953, un path traversal nel get_resourcestrumento di awslabs.aws-transform-mcp-server, il server Model Context Protocol open source che viene eseguito sulla macchina dello stesso sviluppatore affinché un assistente AI possa pilotare i job di AWS Transform e recuperarne gli artefatti. Le versioni da 0.1.0 a 0.1.4 non limitavano adeguatamente i nomi dei percorsi, e savePath è il parametro che poteva scrivere file al di fuori della directory di lavoro prevista — cosa che l'avviso GitHub nel repository di Amazon afferma che "potrebbe portare all'esecuzione locale di codice". Amazon lo ha valutato 8,6, Alto. La correzione è la versione 0.1.5, e non esiste alcun workaround lato server o basato solo sulla configurazione, perché il percorso di codice vulnerabile è presente nella configurazione predefinita. Nessuna fonte pubblica ha registrato che qualcuno lo abbia sfruttato. Il record completo, con i suoi livelli di gravità e affidabilità, si trova nel Orca AI Incident Archive insieme agli incidenti MCP e agent-runtime registrati nello stesso mese.

Un server MCP che scrive dove lavora lo sviluppatore

I server Model Context Protocol sono il livello che fornisce a un assistente strumenti richiamabili, e questo è volutamente locale. Il bollettino di Amazon lo descrive come «un server MCP open source che viene eseguito localmente sulla macchina di uno sviluppatore e consente agli assistenti basati sull'IA di interagire con AWS Transform per eseguire job di trasformazione del codice e recuperarne gli artefatti». La descrizione del suo pacchetto sul Python Package Index afferma che espone il ciclo di vita di Transform attraverso 19 strumenti, gestendo spazi di lavoro di trasformazione, job, connettori, attività human-in-the-loop, artefatti e chat, e copre la modernizzazione dei mainframe, la migrazione VMware, la modernizzazione .NET e trasformazioni di codice personalizzate.

Quel posizionamento è ciò che rende rilevante la falla. Un server sull'infrastruttura dello stesso fornitore che gestisce male un nome file corrompe lo storage del fornitore. Questo veniva eseguito come lo sviluppatore, nella home directory dello sviluppatore, accanto alla sua configurazione della shell e alle chiavi SSH, e l'impatto che Amazon descrive non è un download corrotto ma "esecuzione locale di codice". Ogni punteggio associato alla CVE concorda su un punto: il vettore d'attacco è locale, non di rete.

Lo strumento indicato nell'avviso è quello che porta un artefatto di job su disco. get_resource accetta un savePath che indica dove deve finire il file. Il bug è che nulla impediva a quel percorso di puntare altrove.

Quanto è grave, e secondo i calcoli di chi

A questo CVE sono associate tre valutazioni che non coincidono. Amazon, che ha assegnato il CVE in qualità di autorità di numerazione, lo valuta 8.6 High su CVSS v3.1 con il vettore CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — locale, bassa complessità, nessun privilegio richiesto, interazione utente richiesta, ambito modificato, impatto elevato su riservatezza, integrità e disponibilità. La voce di NIST nel National Vulnerability Database riporta il proprio punteggio primario v3.1 di 8.8 su un vettore diverso, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: bassi privilegi richiesti, nessuna interazione utente. Entrambi rientrano nella fascia High. Il disaccordo riguarda i prerequisiti — se l'attore necessiti già di un punto d'appoggio e se una persona debba essere persuasa — non quanto sia grave l'esito.

Il punteggio CVSS v4.0 di Amazon per la stessa CVE è 6,3, Medio, su CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H. Leggi le metriche di impatto: nulla sul sistema vulnerabile stesso, tutto alto sul sistema successivo. È la forma di un traversal che esce dai confini dello strumento stesso — il danno viene arrecato a qualunque cosa lo strumento riesca a raggiungere, quindi finisce nella colonna del sottosistema e il sistema vulnerabile ottiene un punteggio pari a zero.

L'arricchimento della CVE da parte di CISA, datato 6 agosto 2026, registra una decisione SSVC di Sfruttamento: nessuno, Automatizzabile: no, Impatto tecnico: totale. Il record di NVD è stato modificato l'ultima volta il 23 ottobre 2026 e riporta ancora affiancati sia l'8.6 sia l'8.8. Nessuno dei due documenti considera l'altro errato.

Cosa faceva il codice vulnerabile e cosa è cambiato nella 0.1.5

La descrizione che Amazon dà del meccanismo è una sola frase ed è prudente: lo strumento "non ha limitato adeguatamente i nomi dei percorsi", il che potrebbe consentire a "un attore dipendente dal contesto" di "scrivere file arbitrari al di fuori della directory di lavoro prevista tramite il parametro savePath". L'avviso non definisce l'attore, non dice cosa innesca la scrittura e non descrive come si presenta un exploit riuscito. Afferma soltanto che il risultato "potrebbe portare all'esecuzione locale di codice".

Il resoconto pubblico più dettagliato del meccanismo non è quello di Amazon. È un piccolo repository proof-of-concept, ronamosa/CVE-2026-18953, pubblicato su GitHub l'8 agosto 2026 con licenza Apache-2.0 — due commit, nessuna star e nessun fork al momento della stesura — che include copie verbatim di file_validation.py nelle versioni vulnerabile e corretta e le esegue entrambe con gli stessi input.

La sua lettura di 0.1.4 è questa: validate_write_path() risolveva savePath con realpath e expanduser, rifiutava una breve deny-list di percorsi (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd) e rimuoveva i componenti di directory dal nome file fornito. Non limitava mai il percorso risolto a una base o a una directory di lavoro. Una blocklist di nomi file sensibili — .bashrc, .zshrc, authorized_keys, id_rsa — era applicata in lettura ma non in scrittura.

Il repository dimostra tre scritture consentite da questo meccanismo: un percorso assoluto che non richiede alcun attraversamento, una fuga relativa con ../../ e un nome di dotfile che il percorso di lettura avrebbe rifiutato. Tutte e tre finiscono in una directory temporanea creata dallo script, e il suo output di esempio mostra dropped_by_absolute_path.sh, dropped_by_traversal.sh e un .bashrc sotto una directory home civetta; la directory home reale non viene mai toccata. La versione 0.1.5 aggiunge il confine mancante: una directory di base ricavata da $AWS_TRANSFORM_MCP_WRITE_DIR o dalla directory di lavoro di avvio del server, sotto la quale deve ricadere ogni scrittura risolta, più la blocklist dei nomi file applicata al percorso di scrittura risolto finale. Il validatore corretto genera "Write path must be within the working directory" per tutte e tre.

Nessuno di questi dettagli compare nell'avviso, e il repository non afferma che provenga da lì. Considera la lista di esclusione, il controllo del nome file in sola lettura e la correzione della directory di base come una ricostruzione dal codice sorgente, non come una seconda constatazione ufficiale. Ciò che il repository aggiunge rispetto all'avviso è una descrizione di chi può fornire il percorso: poiché il compito del server è inserire i contenuti di job e task nel contesto di un assistente, la parte che sceglie savePath non deve necessariamente essere la persona alla tastiera. Un assistente guidato da contenuti non attendibili che ha recuperato attraverso lo stesso strumento può fare la scelta. Questa è l'argomentazione del repository basata sul codice e sulla progettazione dello strumento, non un'affermazione fatta da Amazon; l'"attore dipendente dal contesto" non definito di Amazon è coerente con essa e si ferma lì.

Sette settimane tra la patch e il bollettino

La correzione non è arrivata con l'annuncio. La cronologia delle release del Python Package Index — metadati di prima parte provenienti dal registry attraverso cui il pacchetto viene distribuito — colloca la 0.1.4 al 20 maggio 2026 e la 0.1.5 al 17 giugno 2026, sette settimane prima che il bollettino 2026-075 fosse pubblicato il 5 agosto. Sull'indice non esiste affatto alcun file 0.1.0; il primo artefatto pubblicato all'interno dell'intervallo interessato è la 0.1.1, caricata il 9 maggio 2026. Un developer che installava dall'indice poteva quindi ricevere soltanto una build vulnerabile tra il 9 maggio e il 17 giugno, e chiunque seguisse le release era già su codice corretto a metà giugno.

Amazon non dice quando sia venuta a conoscenza del problema, quando sia arrivata la segnalazione, né perché sia stata pubblicata la versione che lo ha chiuso. L'unica persona nominata nel documento è Drew Raines, ringraziato sia nel bollettino sia nell'avviso GitHub «per aver collaborato su questo problema attraverso il processo coordinato di divulgazione dei problemi». GHSA-66mr-jr63-2jgw è stato pubblicato nel repository awslabs/mcp di Amazon il 5 agosto 2026, lo stesso giorno del bollettino; il record CVE è stato riservato alle 13:44 UTC e pubblicato alle 19:33 UTC di quel giorno.

Dunque la data della correzione è stabilita, mentre la ragione non lo è. Una versione con patch disponibile nel registry sette settimane prima dell'avviso è coerente con una correzione silenziosa seguita da una divulgazione coordinata, ma questa è un'inferenza basata su due timestamp, e nessuno dei due documenti lo afferma.

Cosa stabilisce il verbale, e cosa non stabilisce

L'archivio assegna a questa voce il grado A — ben documentata, le fonti primarie concordano — e non la contrassegna come contestata. La archivia come record di ricerca, un riscontro di vulnerabilità anziché un incidente di distribuzione, senza danni concreti registrati. Il grado riguarda la qualità della documentazione e, sulla base delle prove esaminate, regge: il bollettino, l'avviso GitHub e il record CVE sono tre documenti pubblicati da Amazon che concordano su prodotto, versioni, correzione e attribuzione.

• Confermato. Amazon ha pubblicato il bollettino 2026-075-AWS il 5 agosto 2026 riguardante CVE-2026-18953, un path traversal CWE-22 nella gestione del get_resourcedi savePath in awslabs.aws-transform-mcp-server dalla 0.1.0 alla 0.1.4, risolto nella 0.1.5, senza alcuna soluzione alternativa lato server o basata esclusivamente sulla configurazione, poiché il percorso vulnerabile si trova nella configurazione predefinita.

• Stabilito. I punteggi e la loro divergenza: 8.6 High da Amazon in qualità di autorità di numerazione CVE, 8.8 High da NIST come punteggio primario NVD, 6.3 Medium su CVSS v4.0 e la decisione SSVC del 6 agosto di CISA secondo cui non erano stati osservati né sfruttamento né un percorso automatizzabile.

• Stabilito. Le date di rilascio sul Python Package Index e il ringraziamento a Drew Raines per la divulgazione coordinata.

• Inferito dal codice sorgente, da una terza parte. La deny-list, la blocklist dei nomi file in sola lettura, la directory di base assente e la correzione _ALLOWED_WRITE_BASE provengono tutte dal repository proof-of-concept ronamosa, le cui copie vendorizzate delle due versioni del validatore chiunque può confrontare con diff.

• Dedotto dai timestamp e dal design. Che la 0.1.5 sia stata una release di sicurezza deliberata e che un assistente guidato da contenuti non attendibili potesse fornire il percorso ostile. Amazon non afferma né l'una né l'altra cosa.

• Non stabilito. Qualsiasi sfruttamento in the wild. Il "Exploitation: none" della CISA è datato 6 agosto, due giorni prima della comparsa del proof-of-concept pubblico, quindi si riferisce a quel momento e non a nulla di successivo. Non sono stati pubblicati il numero di utenti interessati, notifiche ai clienti o telemetria.

• Non stabilito. Resoconto indipendente. Nessun media mainstream sembra aver trattato questa CVE. La documentazione pubblica è composta dai tre documenti di Amazon, dagli arricchimenti degli stessi da parte di NIST e CISA, dalle pagine dei tracker che riportano il medesimo contenuto e dal piccolo repository proof-of-concept descritto sopra.

Cosa è cambiato e cosa verificare

Il rimedio di Amazon è un incremento di versione e nient'altro: aggiornare alla 0.1.5 o a una versione successiva e «assicurarsi che qualsiasi codice forkato o derivato venga corretto con patch per incorporare le nuove correzioni». La seconda clausola è quella che viaggia. Il server è open source, e un fork che ha vendorizzato il validatore 0.1.4 eredita la vulnerabilità senza ereditare l'avviso; il bollettino chiede agli operatori del codice derivato di recepire la modifica, il che equivale a dire che il rilascio upstream non raggiunge una copia mantenuta da qualcun altro.

Il repository proof-of-concept suggerisce qualcosa che l'advisory si rifiuta di fare. Secondo quanto afferma, gli operatori che non possono aggiornare immediatamente dovrebbero eseguire il server con la directory di lavoro impostata su una directory vuota dedicata e considerare compromesso qualsiasi file su cui esso possa scrivere. La posizione di Amazon è più rigorosa: non esiste alcun workaround lato server o solo di configurazione. Per stessa ammissione del repository, anche quel suggerimento è debole, poiché il codice vulnerabile non ha mai confinato le scritture alla directory di lavoro fin dall'inizio. Laddove i due discordano, resta valida l'istruzione del fornitore di procedere solo all'aggiornamento.

La cosa utile di questo record non è il suo punteggio. È la sua forma: un server MCP locale, un download di artifact con una destinazione fornita dal chiamante, e nessun confine tra i due. Il controllo che conta non è la data del bollettino ma la versione bloccata — 0.1.5 o successiva, e la stessa modifica portata in qualsiasi fork che abbia copiato il validatore.