CVE-2026-18953: AWS' Transform MCP Server had geen schrijfgrens

Amazon heeft op 5 augustus 2026 beveiligingsbulletin 2026-075-AWS gepubliceerd voor CVE-2026-18953, een path traversal in het get_resource-hulpmiddel van awslabs.aws-transform-mcp-server, de opensource-Model Context Protocol-server die op de eigen machine van een ontwikkelaar draait, zodat een AI-assistent AWS Transform-taken kan aansturen en hun artefacten kan ophalen. Versies 0.1.0 tot en met 0.1.4 beperkten padnamen onvoldoende, en de savePath-parameter kon bestanden schrijven buiten de bedoelde werkmap — wat de GitHub-advisory in de repository van Amazon stelt: "zou kunnen leiden tot lokale code-uitvoering." Amazon gaf het een score van 8,6, Hoog. De fix is versie 0.1.5, en er is geen workaround aan de serverzijde en ook geen workaround die alleen via configuratie werkt, omdat het kwetsbare codepad in de standaardconfiguratie aanwezig is. Geen publieke bron heeft vastgelegd dat iemand het heeft misbruikt. Het volledige record, met zijn ernst- en betrouwbaarheidsgraden, staat in het Orca AI Incident Archive samen met de MCP- en agent-runtime-incidenten die onder dezelfde maand zijn geregistreerd.

Een MCP-server die schrijft waar de ontwikkelaar werkt

Model Context Protocol-servers vormen de laag die een assistent aanroepbare tools geeft, en deze is bewust lokaal. Een bulletin van Amazon beschrijft het als ‘een opensource-MCP-server die lokaal op de machine van een ontwikkelaar draait en AI-aangedreven assistenten laat samenwerken met AWS Transform om code-transformatietaken uit te voeren en hun artefacten op te halen.’ In de pakketbeschrijving op de Python Package Index staat dat het de Transform-levenscyclus via 19 tools beschikbaar stelt, met beheer van transformatiewerkruimtes, taken, connectors, human-in-the-loop-taken, artefacten en chat, en dat het mainframe-modernisering, VMware-migratie, .NET-modernisering en aangepaste codetransformaties ondersteunt.

Die plaatsing is wat de fout belangrijk maakt. Een server op de eigen infrastructuur van een leverancier die een bestandsnaam verkeerd behandelt, beschadigt de opslag van de leverancier. Deze liep als de ontwikkelaar, in de thuismap van de ontwikkelaar, naast diens shellconfiguratie en SSH-sleutels, en de impact die Amazon beschrijft is niet een beschadigde download maar "lokale code-uitvoering". Elke score die aan de CVE is gekoppeld, is het op één punt eens: de aanvalsvector is lokaal, niet netwerk.

Het hulpmiddel dat in het advies wordt genoemd, is het hulpmiddel dat een job-artefact naar schijf haalt. get_resource verwacht een savePath die aangeeft waar het bestand moet landen. De bug is dat niets dat pad ervan weerhield om naar iets anders te verwijzen.

Hoe erg, en volgens wiens berekening?

Aan deze CVE zijn drie scores gekoppeld en ze komen niet overeen. Amazon, dat de CVE als nummeringsautoriteit heeft toegewezen, geeft het een score van 8,6 Hoog op CVSS v3.1 met de vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — lokaal, lage complexiteit, geen privileges vereist, gebruikersinteractie vereist, scope gewijzigd, hoge impact op vertrouwelijkheid, integriteit en beschikbaarheid. De vermelding van NIST in de National Vulnerability Database heeft een eigen primaire v3.1-score van 8,8 op een andere vector, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: lage privileges vereist, geen gebruikersinteractie. Beide vallen in de hoge band. Het meningsverschil gaat over de randvoorwaarden — of de actor al een eerste toegangspunt nodig heeft, en of er een mens moet worden overtuigd — niet over hoe ernstig de uitkomst is.

De CVSS v4.0-score van Amazon voor dezelfde CVE is 6,3, Medium, op 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. Lees de impactmetrieken: niets op het kwetsbare systeem zelf, alles hoog op het daaropvolgende systeem. Dat is de vorm van een traversal die de eigen grens van een tool doorbreekt — de schade wordt toegebracht aan alles wat de tool kan bereiken, dus het valt in de subsysteemkolom en het kwetsbare systeem scoort nul.

CISA's verrijking van de CVE, gedateerd 6 augustus 2026, registreert een SSVC-beslissing met Exploitatie: geen, Automatiseerbaar: nee, Technische impact: totaal. Het NVD-record is laatst gewijzigd op 23 oktober 2026 en bevat nog steeds zowel de 8.6 als de 8.8 naast elkaar. Geen van beide documenten beschouwt het andere als onjuist.

Wat de kwetsbare code deed, en wat 0.1.5 veranderde

Amazons beschrijving van het mechanisme bestaat uit één zin, en die is zorgvuldig geformuleerd: het hulpprogramma "beperkte de padnamen niet voldoende," waardoor "een contextafhankelijke actor" mogelijk "via de savePath-parameter willekeurige bestanden zou kunnen schrijven buiten de beoogde werkmap." Het advies definieert de actor niet, zegt niet wat de schrijfactie veroorzaakt, en beschrijft niet hoe een geslaagde exploit eruitziet. Er staat alleen dat het resultaat "zou kunnen leiden tot lokale code-uitvoering."

De meest gedetailleerde openbare uiteenzetting van het mechanisme is niet die van Amazon. Het is een kleine proof-of-concept-repository, ronamosa/CVE-2026-18953, op 8 augustus 2026 op GitHub gepubliceerd onder Apache-2.0 — twee commits, geen sterren en geen forks op het moment van schrijven — die letterlijke kopieën bevat van de kwetsbare en gepatchte file_validation.py en beide met dezelfde invoer aanstuurt.

De interpretatie van 0.1.4 is als volgt: validate_write_path() loste savePath op met realpath en expanduser, verwierp een korte deny-list van locaties (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd), en verwijderde directorycomponenten uit de opgegeven bestandsnaam. Het heeft het opgeloste pad nooit beperkt tot een basis- of werkdirectory. Een blocklist van gevoelige bestandsnamen — .bashrc, .zshrc, authorized_keys, id_rsa — werd afgedwongen bij leesbewerkingen, maar niet bij schrijfbewerkingen.

De repository demonstreert drie schrijfacties die dit toelaat: een absoluut pad waarvoor helemaal geen traversal nodig is, een relatieve ../../-ontsnapping, en een dotfile-naam die het leespad zou hebben geweigerd. Alle drie komen terecht in een tijdelijke map die het script aanmaakt, en de voorbeelduitvoer ervan toont dropped_by_absolute_path.sh, dropped_by_traversal.sh en een .bashrc onder een nep-thuismap; de echte thuismap wordt nooit aangeraakt. Versie 0.1.5 voegt de ontbrekende grens toe: een basismap afkomstig uit $AWS_TRANSFORM_MCP_WRITE_DIR of uit de opstartwerkmap van de server, waaronder elk opgelost schrijfpad moet vallen, plus de blokkeerlijst voor bestandsnamen die op het definitieve opgeloste schrijfpad wordt toegepast. De gerepareerde validator geeft bij alle drie de foutmelding "Schrijfpad moet binnen de werkmap liggen".

Geen van die details staat in het advies, en de repository claimt niet dat het daarvandaan komt. Behandel de deny-list, de read-only-bestandsnaamcontrole en de base-directory-fix als een reconstructie op basis van de broncode, niet als een tweede officiële bevinding. Wat de repository wel toevoegt ten opzichte van het advies, is een uiteenzetting van wie het pad kan leveren: omdat het de taak van de server is om job- en taakinhoud in de context van een assistent te halen, hoeft de partij die savePath kiest niet de persoon aan het toetsenbord te zijn. Een assistent die wordt bestuurd door niet-vertrouwde inhoud die hij via hetzelfde hulpmiddel heeft opgehaald, kan die keuze maken. Dat is het argument van de repository op basis van de code en het ontwerp van het hulpmiddel, niet een claim die Amazon maakt; de ongedefinieerde "contextafhankelijke actor" van Amazon is daarmee consistent en gaat niet verder.

Zeven weken tussen de patch en het bulletin

De oplossing kwam niet met de aankondiging. De releasegeschiedenis van de Python Package Index — first-party metadata van het register waarlangs het pakket wordt verspreid — dateert 0.1.4 op 20 mei 2026 en 0.1.5 op 17 juni 2026, zeven weken voordat bulletin 2026-075 op 5 augustus werd gepubliceerd. Er staat helemaal geen 0.1.0-bestand op de index; het vroegst gepubliceerde artefact binnen het getroffen bereik is 0.1.1, geüpload op 9 mei 2026. Een ontwikkelaar die vanaf de index installeerde, kon daarom tussen 9 mei en 17 juni alleen een kwetsbare build hebben ontvangen, en iedereen die releases bijhield, zat medio juni al op gepatchte code.

Amazon zegt niet wanneer het van het probleem op de hoogte kwam, wanneer het rapport binnenkwam, of waarom de release die het sloot, werd uitgegeven. De enige persoon die in het record wordt genoemd, is Drew Raines, die zowel in het bulletin als in de GitHub-advisory wordt bedankt "voor de samenwerking aan dit probleem via het gecoördineerde proces voor het openbaar maken van problemen." GHSA-66mr-jr63-2jgw werd op 5 augustus 2026 gepubliceerd in het awslabs/mcp-repository van Amazon, dezelfde dag als het bulletin; het CVE-record werd om 13:44 UTC gereserveerd en die dag om 19:33 UTC gepubliceerd.

Dus de datum van de fix staat vast, maar de reden ervoor niet. Een gepatchte versie die zeven weken voor het beveiligingsadvies in het register staat, past bij een stille fix gevolgd door een gecoördineerde openbaarmaking — maar dat is een gevolgtrekking uit twee tijdstempels, en geen van beide documenten vermeldt dat.

Wat het dossier vaststelt, en wat niet.

Het archief beoordeelt dit item met een A — goed gedocumenteerd, primaire bronnen stemmen overeen — en markeert het niet als betwist. Het registreert het als een onderzoeksrecord: een kwetsbaarheidsbevinding, geen uitrolincident, zonder vastgelegde schade in de praktijk. De beoordeling gaat over de kwaliteit van de documentatie, en op basis van het beoordeelde bewijs houdt die stand: het bulletin, de GitHub-advisory en het CVE-record zijn drie door Amazon gepubliceerde documenten die overeenstemmen over het product, de versies, de fix en de credits.

• Vastgesteld. Amazon heeft op 5 augustus 2026 bulletin 2026-075-AWS gepubliceerd over CVE-2026-18953, een CWE-22-padtraversal in de get_resource's savePath-verwerking in awslabs.aws-transform-mcp-server 0.1.0 tot en met 0.1.4, opgelost in 0.1.5, zonder serverside- of louter op configuratie gebaseerde workaround, omdat het kwetsbare pad in de standaardconfiguratie zit.

• Vastgesteld. De scores en hun onderlinge verschillen: 8,6 Hoog van Amazon als CVE-nummeringsautoriteit, 8,8 Hoog van NIST als primaire NVD-score, 6,3 Gemiddeld op CVSS v4.0, en het SSVC-besluit van CISA van 6 augustus dat geen exploitatie en geen automatiseerbaar pad waren waargenomen.

• Vastgesteld. De releasedatums op de Python Package Index, en de vermelding van Drew Raines voor gecoördineerde openbaarmaking.

• Afgeleid uit de broncode, door een derde partij. De deny-list, de blokkeringslijst voor alleen-lezen bestandsnamen, de afwezige basisdirectory en de _ALLOWED_WRITE_BASE-correctie komen allemaal uit het ronamosa proof-of-conceptrepository, waarvan iedereen de meegeleverde kopieën van de twee validatorversies kan diffen.

• Afgeleid uit tijdstempels en ontwerp. Dat 0.1.5 een bewuste beveiligingsrelease was, en dat een assistent die door onbetrouwbare inhoud werd gestuurd, het vijandige pad kon aanleveren. Amazon zegt geen van beide.

• Niet vastgesteld. Elk misbruik in het wild. CISA's "Exploitation: none" is gedateerd op 6 augustus, twee dagen voordat het publieke proof-of-concept verscheen, dus het zegt iets over dat moment en niet over iets daarna. Er zijn geen cijfers over getroffen gebruikers, klantnotificaties of telemetrie gepubliceerd.

• Niet vastgesteld.Onafhankelijke berichtgeving. Geen enkel mainstream medium lijkt over deze CVE te hebben bericht. Het openbare verslag bestaat uit de drie documenten van Amazon, de verrijkingen daarvan door NIST en CISA, trackerpagina's die het verslag herhalen, en het ene kleine proof-of-conceptrepository dat hierboven is beschreven.

Wat is er veranderd, en wat je moet controleren

De oplossing van Amazon is een versieverhoging en niets anders: upgrade naar 0.1.5 of hoger, en "zorg ervoor dat eventuele geforkte of afgeleide code wordt gepatcht om de nieuwe fixes op te nemen." De tweede clausule is het deel dat de ronde doet. De server is open source, en een fork die de 0.1.4-validator heeft ingebed, erft de fout zonder het beveiligingsadvies te erven; het bulletin vraagt beheerders van afgeleide code om de wijziging daar door te voeren, wat wil zeggen dat de upstream-release geen kopie bereikt die door iemand anders wordt onderhouden.

Het proof-of-conceptrepository suggereert iets wat het advies weigert te doen. Operators die niet onmiddellijk kunnen upgraden, zegt het, moeten de server laten draaien met de werkmap ingesteld op een speciale lege map en elk bestand waarnaar hij kan schrijven als gecompromitteerd behandelen. De positie van Amazon is strikter: er is helemaal geen workaround op de server of uitsluitend via configuratie. Volgens het repository zelf is die suggestie ook mager, aangezien de kwetsbare code schrijfbewerkingen sowieso nooit tot de werkmap beperkte. Waar de twee het oneens zijn, geldt de instructie van de leverancier om alleen te upgraden.

Het nuttige aan dit record is niet zijn score. Het is de vorm ervan: een lokale MCP-server, een artefactdownload met een door de aanroeper opgegeven bestemming, en geen grens tussen de twee. De controle die ertoe doet, is niet de datum van het bulletin maar de vastgezette versie — 0.1.5 of later, en dezelfde wijziging doorgevoerd in elke fork die de validator heeft gekopieerd.