CVE-2026-18953: AWS:s Transform MCP-server hade ingen skrivgräns

Amazon publicerade säkerhetsbulletinen 2026-075-AWS den 5 augusti 2026 för CVE-2026-18953, en sökvägstraversering i get_resource-verktyget i awslabs.aws-transform-mcp-server, den Model Context Protocol-server med öppen källkod som körs på utvecklarens egen maskin så att en AI-assistent kan styra AWS Transform-jobb och hämta deras artefakter. Versionerna 0.1.0 till och med 0.1.4 begränsade inte sökvägsnamn tillräckligt, och parametern savePath kunde skriva filer utanför den avsedda arbetskatalogen – vilket GitHub-rådgivningen i Amazons kodförvar säger "kan leda till lokal kodkörning". Amazon bedömde den till 8,6, Hög. Korrigeringen är version 0.1.5, och det finns ingen åtgärd på serversidan eller som endast bygger på konfiguration, eftersom den sårbara kodvägen finns i standardkonfigurationen. Ingen offentlig källa har dokumenterat att någon har utnyttjat den. Den fullständiga posten, med dess allvarlighets- och konfidensgraderingar, finns i Orca AI Incident Archive tillsammans med de MCP- och agent-runtime-incidenter som registrerats under samma månad.

En MCP-server som skriver där utvecklaren arbetar

Model Context Protocol-servrar är det lager som ger en assistent anropbara verktyg, och den här är avsiktligt lokal. Amazons bulletin beskriver den som "en MCP-server med öppen källkod som körs lokalt på en utvecklares maskin och låter AI-drivna assistenter interagera med AWS Transform för att köra kodtransformationsjobb och hämta deras artefakter." Dess paketbeskrivning på Python Package Index anger att den gör Transform-livscykeln tillgänglig via 19 verktyg som hanterar transformationsarbetsytor, jobb, anslutningar, uppgifter med människa i loopen, artefakter och chatt, samt täcker stormaskinsmodernisering, VMware-migrering, .NET-modernisering och anpassade kodtransformationer.

Den placeringen är det som gör att felet spelar roll. En server på en leverantörs egen infrastruktur som hanterar ett filnamn felaktigt korrumperar leverantörens lagring. Den här kördes som utvecklaren, i utvecklarens hemkatalog, bredvid dennes shellkonfiguration och SSH-nycklar, och effekten som Amazon beskriver är inte en korrupt nedladdning utan "lokal kodkörning". Varje poäng som är kopplad till CVE:t är överens om en sak: attackvektorn är lokal, inte nätverksbaserad.

Verktyget som nämns i säkerhetsmeddelandet är det som hämtar ner en jobbartefakt till disk. get_resource tar en savePath som anger var filen ska hamna. Buggen är att ingenting hindrade den sökvägen från att peka ut någon annanstans.

Hur illa, och enligt vems aritmetik

Tre poängvärden är kopplade till denna CVE och de överensstämmer inte. Amazon, som tilldelade CVE:n i egenskap av numreringsmyndighet, ger den 8,6 Hög på CVSS v3.1 med vektorn CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H – lokal, låg komplexitet, inga privilegier krävs, användarinteraktion krävs, omfattning ändrad, hög påverkan på konfidentialitet, integritet och tillgänglighet. NIST:s post i National Vulnerability Database har ett eget primärt v3.1-poängvärde på 8,8 på en annan vektor, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: låga privilegier krävs, ingen användarinteraktion. Båda hamnar i intervallet Hög. Oenigheten gäller förutsättningarna – huruvida aktören redan behöver ett fotfäste och huruvida en människa måste övertygas – inte hur allvarligt utfallet är.

Amazons CVSS v4.0-poäng för samma CVE är 6,3, Medium, på 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. Läs påverkansmåtten: inget på det sårbara systemet självt, allt högt på det efterföljande systemet. Det är formen av en traversering som bryter sig ut ur ett verktygs egen gräns – skadan drabbar allt som verktyget kan nå, så den hamnar i delsystemskolumnen och det sårbara systemet får nollpoäng.

CISA:s berikning av CVE:n, daterad 6 augusti 2026, registrerar ett SSVC-beslut med Exploitation: none, Automatable: no, Technical Impact: total. NVD:s post ändrades senast den 23 oktober 2026 och innehåller fortfarande både 8.6 och 8.8 sida vid sida. Inget av dokumenten behandlar det andra som felaktigt.

Vad den sårbara koden gjorde och vad 0.1.5 ändrade

Amazons beskrivning av mekanismen består av en mening och den är noggrant formulerad: verktyget "begränsade inte sökvägar på ett adekvat sätt", vilket kan tillåta "en kontextberoende aktör" att "skriva godtyckliga filer utanför den avsedda arbetskatalogen via parametern savePath". Säkerhetsmeddelandet definierar inte aktören, anger inte vad som utlöser skrivningen och beskriver inte hur ett lyckat exploateringsförsök ser ut. Det säger endast att resultatet "kan leda till lokal kodkörning".

Den mest detaljerade offentliga beskrivningen av mekanismen är inte Amazons. Det är ett litet proof-of-concept-förråd, ronamosa/CVE-2026-18953, som publicerades på GitHub den 8 augusti 2026 under Apache-2.0 – två commits, inga stjärnor och inga forks vid skrivandet – och som innehåller ordagranna kopior av den sårbara och den patchade file_validation.py och kör båda genom samma indata.

Dess tolkning av 0.1.4 är följande: validate_write_path() löste upp savePath med realpath och expanduser, avvisade en kort neklista med platser (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd) och tog bort katalogkomponenter från det angivna filnamnet. Den begränsade aldrig den upplösta sökvägen till någon bas- eller arbetskatalog. En blocklista över känsliga filnamn — .bashrc, .zshrc, authorized_keys, id_rsa — tillämpades vid läsning men inte vid skrivning.

Repositoriet visar tre skrivningar som detta tillåter: en absolut sökväg som inte kräver någon traversal alls, en relativ ../../-utbrytning och ett punktfilnamn som läsvägen skulle ha avvisat. Alla tre hamnar i en tillfällig katalog som skriptet skapar, och dess exempelutdata visar dropped_by_absolute_path.sh, dropped_by_traversal.sh och en .bashrc under en avledande hemkatalog; den riktiga hemkatalogen berörs aldrig. Version 0.1.5 lägger till den saknade gränsen: en baskatalog som hämtas från $AWS_TRANSFORM_MCP_WRITE_DIR eller serverns arbetskatalog vid start, som varje upplöst skrivning måste ligga under, plus filnamnsblocklistan som tillämpas på den slutgiltigt upplösta skrivsökvägen. Den korrigerade valideraren utlöser "Write path must be within the working directory" för alla tre.

Ingen av dessa detaljer förekommer i säkerhetsmeddelandet, och repositoryt hävdar inte att det kom därifrån. Behandla deny-listan, filnamnskontrollen för skrivskydd och korrigeringen av baskatalogen som en rekonstruktion från källkoden, inte som ett andra officiellt fynd. Det som repositoryt däremot tillför utöver säkerhetsmeddelandet är en redogörelse för vem som kan leverera sökvägen: eftersom serverns uppgift är att hämta jobb- och uppgiftsinnehåll till en assistents kontext behöver parten som väljer savePath inte vara personen vid tangentbordet. En assistent som styrs av opålitligt innehåll som den har hämtat via samma verktyg kan göra det valet. Det är repositoryts argument utifrån koden och verktygets design, inte ett påstående som Amazon gör; Amazons odefinierade "kontextberoende aktör" är förenlig med detta och sträcker sig inte längre.

Sju veckor mellan patchen och bulletinen

Rättningen kom inte i samband med tillkännagivandet. Python Package Indexets utgivningshistorik – förstapartsmetadata från registret som paketet distribueras via – daterar 0.1.4 till 20 maj 2026 och 0.1.5 till 17 juni 2026, sju veckor innan bulletin 2026-075 publicerades den 5 augusti. Det finns överhuvudtaget ingen 0.1.0-fil i registret, den tidigaste publicerade artefakten inom det berörda intervallet är 0.1.1, uppladdad 9 maj 2026. En utvecklare som installerade från registret kunde därför bara ha fått en sårbar byggversion mellan 9 maj och 17 juni, och alla som följde utgivningarna körde redan rättad kod i mitten av juni.

Amazon säger inte när man fick kännedom om problemet, när rapporten kom in eller varför utgåvan som stängde det publicerades. Den enda person som namnges i protokollet är Drew Raines, som tackas i både bulletinen och GitHub-advisorn "för samarbetet kring detta problem genom den samordnade processen för sårbarhetsutlämnande." GHSA-66mr-jr63-2jgw publicerades i Amazons awslabs/mcp-förråd den 5 augusti 2026, samma dag som bulletinen; CVE-posten reserverades 13:44 UTC och publicerades 19:33 UTC samma dag.

Så datumet för åtgärden är fastställt, men orsaken till den är det inte. En patchad version som fanns i registret sju veckor före säkerhetsmeddelandet stämmer överens med en tyst åtgärd följd av ett koordinerat offentliggörande – men det är en slutsats utifrån två tidsstämplar, och det står inte i något av dokumenten.

Vad handlingarna fastställer, och vad de inte fastställer

Arkivet betygsätter denna post som A – väl dokumenterad, primärkällorna stämmer överens – och markerar den inte som omtvistad. Det registrerar den som en forskningspost, en sårbarhetsfyndighet snarare än en driftsättningsincident, utan registrerad verklig skada. Betyget gäller dokumentationens kvalitet, och utifrån den granskade evidensen håller det: bulletinen, GitHub-rådgivningen och CVE-posten är tre Amazon-publicerade dokument som stämmer överens om produkten, versionerna, åtgärden och erkännandet.

• Bekräftat. Amazon publicerade bulletin 2026-075-AWS den 5 augusti 2026 som omfattar CVE-2026-18953, en CWE-22-sökvägstraversering i get_resource:s savePath-hantering i awslabs.aws-transform-mcp-server 0.1.0 till och med 0.1.4, åtgärdad i 0.1.5, utan något serversidigt eller konfigurationsbaserat kringgående, eftersom den sårbara sökvägen finns i standardkonfigurationen.

• Fastställt. Poängen och deras skillnader: 8,6 Hög från Amazon som CVE-nummermyndighet, 8,8 Hög från NIST som NVD:s primärpoäng, 6,3 Medel på CVSS v4.0, och CISAs SSVC-beslut den 6 augusti att ingen exploatering och ingen automatiserbar väg hade observerats.

• Bekräftat. Utgivningsdatumen på Python Package Index, och erkännandet till Drew Raines för samordnat offentliggörande.

• Härlett från källkoden, av en tredje part. Deny-listan, den skrivskyddade filnamnsblocklistan, den frånvarande baskatalogen och _ALLOWED_WRITE_BASE fixen kommer alla från ronamosa proof-of-concept-repot, vars vendorade kopior av de två validatorversionerna vem som helst kan diffa.

• Härlett från tidsstämplar och design. Att 0.1.5 var en avsiktlig säkerhetsutgåva, och att en assistent som styrs av opålitligt innehåll kunde ange den fientliga sökvägen. Amazon uppger ingendera.

• Inte fastställt. Något utnyttjande i det vilda. CISA:s "Exploitation: none" är daterat 6 augusti, två dagar innan det offentliga proof-of-conceptet dök upp, så det talar om det ögonblicket och inte om något efter det. Inget antal drabbade användare, ingen kundavisering och ingen telemetri har publicerats.

• Inte fastställt. Oberoende rapportering. Ingen etablerad mediekanal verkar ha bevakat detta CVE. Det offentliga underlaget består av Amazons tre dokument, NIST:s och CISA:s utökningar av dem, spårningssidor som upprepar uppgifterna, samt det enda lilla proof-of-concept-förrådet som beskrivs ovan.

Vad som ändrades och vad du bör kontrollera

Amazons åtgärd är en versionshöjning och inget annat: uppgradera till 0.1.5 eller senare, och "se till att all förgrenad eller härledd kod patchas för att införliva de nya rättningarna." Den andra klausulen är den som förs vidare. Servern är öppen källkod, och en fork som har vendorerat 0.1.4-validatorn ärver bristen utan att ärva rådgivningen; bulletinen ber operatörer av härledd kod att föra in ändringen i den, vilket innebär att uppströmsversionen inte når en kopia som någon annan underhåller.

Proof-of-concept-repositoriet föreslår något som säkerhetsmeddelandet inte gör. Det säger att operatörer som inte kan uppgradera omedelbart bör köra servern med arbetskatalogen inställd på en dedikerad tom katalog och behandla varje fil som den kan skriva till som komprometterad. Amazons hållning är strängare: det finns ingen åtgärd på serversidan eller enbart via konfiguration. Enligt repositoriets egen redogörelse är förslaget också svagt, eftersom den sårbara koden aldrig från början begränsade skrivningar till arbetskatalogen. Där de två är oense gäller leverantörens instruktion om enbart uppgradering.

Det användbara med den här posten är inte dess poäng. Det är dess utformning: en lokal MCP-server, en artefaktnedladdning med ett mål som anges av anroparen, och ingen gräns mellan de två. Den kontroll som betyder något är inte bulletinens datum utan den pinnade versionen – 0.1.5 eller senare, och samma ändring införd i varje fork som kopierade validatorn.