CVE-2026-18953: Serwer Transform MCP firmy AWS nie miał granicy zapisu

Amazon opublikował 5 sierpnia 2026 r. komunikat bezpieczeństwa 2026-075-AWS dotyczący CVE-2026-18953 — podatność typu path traversal w get_resource, narzędziu z pakietu awslabs.aws-transform-mcp-server, serwerze Model Context Protocol o otwartym kodzie źródłowym, który działa na własnym komputerze dewelopera, dzięki czemu asystent AI może uruchamiać zadania AWS Transform i pobierać ich artefakty. Wersje od 0.1.0 do 0.1.4 nie ograniczały odpowiednio nazw ścieżek, a parametr savePath mógł zapisywać pliki poza zamierzonym katalogiem roboczym — co według komunikatu doradczego GitHub w repozytorium Amazon „może prowadzić do lokalnego wykonania kodu”. Amazon ocenił ją na 8,6 (poziom High). Poprawką jest wersja 0.1.5 i nie ma obejścia po stronie serwera ani obejścia wyłącznie konfiguracyjnego, ponieważ podatna ścieżka kodu występuje w konfiguracji domyślnej. Żadne publiczne źródło nie odnotowało, by ktokolwiek wykorzystał tę podatność. Pełny zapis, wraz z ocenami ważności i pewności, znajduje się w Orca AI Incident Archive obok incydentów dotyczących MCP i środowiska uruchomieniowego agentów zgłoszonych w tym samym miesiącu.

Serwer MCP, który zapisuje tam, gdzie pracuje programista.

Serwery Model Context Protocol to warstwa, która zapewnia asystentowi narzędzia możliwe do wywołania, a ten serwer jest celowo lokalny. W biuletynie Amazon opisuje go jako „serwer MCP o otwartym kodzie źródłowym, który działa lokalnie na komputerze dewelopera i pozwala asystentom opartym na AI współdziałać z AWS Transform w celu uruchamiania zadań transformacji kodu i pobierania ich artefaktów”. Jego opis pakietu w Python Package Index wskazuje, że udostępnia cykl życia Transform za pośrednictwem 19 narzędzi, zarządzając obszarami roboczymi transformacji, zadaniami, konektorami, zadaniami z udziałem człowieka, artefaktami i czatem, oraz obejmuje modernizację systemów mainframe, migrację VMware, modernizację .NET i niestandardowe transformacje kodu.

To właśnie umiejscowienie sprawia, że ta wada ma znaczenie. Serwer we własnej infrastrukturze dostawcy, który niewłaściwie obsługuje nazwę pliku, uszkadza pamięć masową dostawcy. Ten działał z uprawnieniami dewelopera, w katalogu domowym dewelopera, obok jego konfiguracji powłoki i kluczy SSH, a skutek opisywany przez Amazon to nie uszkodzone pobranie, lecz „lokalne wykonanie kodu”. Każda ocena powiązana z CVE zgadza się co do jednego punktu: wektor ataku jest lokalny, a nie sieciowy.

Narzędzie wymienione w komunikacie doradczym to to, które pobiera artefakt zadania na dysk. get_resource przyjmuje savePath wskazujący, gdzie plik ma trafić. Błąd polega na tym, że nic nie powstrzymywało tej ścieżki przed wskazaniem innego miejsca.

Jak bardzo źle i według czyjej arytmetyki?

Do tego CVE przypisane są trzy oceny i nie są one zgodne. Amazon, który nadał CVE jako organ numerujący, ocenia go na 8.6 High w CVSS v3.1 z wektorem CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — lokalny, niska złożoność, nie wymaga uprawnień, wymagana interakcja użytkownika, zmieniony zakres, wysoki wpływ na poufność, integralność i dostępność. Wpis NIST w National Vulnerability Database ma własną podstawową ocenę v3.1 wynoszącą 8.8 na innym wektorze, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: wymagane niskie uprawnienia, brak interakcji użytkownika. Obie mieszczą się w paśmie High. Spór dotyczy warunków wstępnych — czy aktor musi już mieć punkt zaczepienia i czy trzeba przekonać człowieka — a nie tego, jak poważne są skutki.

Ocena CVSS v4.0 Amazon dla tego samego CVE wynosi 6,3, Medium, według 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. Przeanalizuj metryki wpływu: nic w samym podatnym systemie, wszystko wysokie w systemie następczym. To kształt traversal, który wykracza poza własne granice narzędzia — szkody wyrządzane są temu, do czego narzędzie może dotrzeć, więc trafia to do kolumny podsystemu, a podatny system otrzymuje zero punktów.

Wzbogacenie CVE przez CISA, datowane na 6 sierpnia 2026 r., odnotowuje decyzję SSVC: Wykorzystanie: brak, Automatyzowalność: nie, Wpływ techniczny: całkowity. Rekord NVD został ostatnio zmodyfikowany 23 października 2026 r. i nadal zawiera zarówno 8.6, jak i 8.8 obok siebie. Żaden z dokumentów nie traktuje drugiego jako błędnego.

Co robił podatny kod i co zmieniła wersja 0.1.5

Opis mechanizmu autorstwa Amazon to jedno zdanie — i to ostrożnie sformułowane: narzędzie „nie ograniczało w wystarczający sposób nazw ścieżek”, co mogłoby pozwolić „podmiotowi zależnemu od kontekstu” na „zapisanie dowolnych plików poza zamierzonym katalogiem roboczym przez parametr savePath”. Komunikat doradczy nie definiuje tego podmiotu, nie mówi, co wyzwala zapis, ani nie opisuje, jak wygląda udana eksploatacja. Mówi jedynie, że wynik „może prowadzić do lokalnego wykonania kodu”.

Najbardziej szczegółowy publiczny opis tego mechanizmu nie pochodzi od Amazonu. To małe repozytorium proof-of-concept, ronamosa/CVE-2026-18953, opublikowane na GitHubie 8 sierpnia 2026 r. na licencji Apache-2.0 — dwa commity, brak gwiazdek i forków w chwili pisania — które zawiera dosłowne kopie podatnej i załatanej wersji file_validation.py i przepuszcza obie przez te same dane wejściowe.

Jego interpretacja wersji 0.1.4 jest następująca: validate_write_path() rozwiązywał savePath za pomocą realpath i expanduser, odrzucał krótką listę zabronionych lokalizacji (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd) oraz usuwał składniki katalogu z podanej nazwy pliku. Nigdy nie ograniczał rozwiązanej ścieżki do żadnego katalogu bazowego ani roboczego. Lista zablokowanych wrażliwych nazw plików — .bashrc, .zshrc, authorized_keys, id_rsa — była wymuszana podczas odczytów, ale nie podczas zapisów.

Repozytorium demonstruje trzy zapisy, na które to pozwala: ścieżkę bezwzględną, która w ogóle nie wymaga przechodzenia, względne wyjście ../../ oraz nazwę pliku kropkowego, którą ścieżka odczytu by odrzuciła. Wszystkie trzy trafiają do katalogu tymczasowego tworzonego przez skrypt, a jego przykładowe wyjście pokazuje dropped_by_absolute_path.sh, dropped_by_traversal.sh i .bashrc w fałszywym katalogu domowym; prawdziwy katalog domowy nigdy nie jest naruszany. Wersja 0.1.5 dodaje brakującą granicę: katalog bazowy pobierany z $AWS_TRANSFORM_MCP_WRITE_DIR lub katalog roboczy, w którym uruchomiono serwer, poniżej którego musi znajdować się każdy zapis po rozwiązaniu ścieżki, oraz lista zablokowanych nazw plików stosowana do ostatecznej ścieżki zapisu po rozwiązaniu. Poprawiony walidator zgłasza „Write path must be within the working directory” dla wszystkich trzech.

Żaden z tych szczegółów nie pojawia się w zaleceniu, a repozytorium nie twierdzi, że pochodzi stamtąd. Listę zablokowanych, sprawdzenie nazwy pliku tylko do odczytu i poprawkę katalogu bazowego należy traktować jako rekonstrukcję na podstawie kodu źródłowego, a nie jako drugie oficjalne ustalenie. To, co repozytorium jednak dodaje poza zaleceniem, to wyjaśnienie, kto może dostarczyć ścieżkę: ponieważ zadaniem serwera jest pobieranie treści zadań i czynności do kontekstu asystenta, podmiot wybierający savePath nie musi być osobą przy klawiaturze. Asystent sterowany przez niezaufane treści, które pobrał za pomocą tego samego narzędzia, może podjąć tę decyzję. To argument repozytorium wynikający z kodu i konstrukcji narzędzia, a nie twierdzenie Amazona; niezdefiniowany przez Amazon „podmiot zależny od kontekstu” jest z nim spójny i na tym poprzestaje.

Siedem tygodni między poprawką a komunikatem

Poprawka nie pojawiła się wraz z ogłoszeniem. Historia wydań Python Package Index — metadane pierwszej ręki pochodzące z rejestru, przez który pakiet jest publikowany — datuje 0.1.4 na 20 maja 2026 r., a 0.1.5 na 17 czerwca 2026 r., siedem tygodni przed publikacją biuletynu 2026-075 w dniu 5 sierpnia. W indeksie nie ma w ogóle pliku 0.1.0; najwcześniejszym opublikowanym artefaktem w objętym zakresie jest 0.1.1, przesłany 9 maja 2026 r. Programista instalujący z indeksu mógł zatem otrzymać podatną kompilację wyłącznie między 9 maja a 17 czerwca, a każdy, kto śledził wydania, miał już załataną wersję kodu w połowie czerwca.

Amazon nie podaje, kiedy dowiedział się o problemie, kiedy nadeszło zgłoszenie ani dlaczego opublikowano wydanie, które go zamknęło. Jedyną osobą wymienioną w zapisie jest Drew Raines, któremu podziękowano zarówno w biuletynie, jak i w poradniku bezpieczeństwa GitHub „za współpracę przy tym problemie w ramach skoordynowanego procesu ujawniania problemów”. GHSA-66mr-jr63-2jgw opublikowano w repozytorium awslabs/mcp Amazon na GitHubie 5 sierpnia 2026 r., tego samego dnia co biuletyn; rekord CVE zarezerwowano o 13:44 UTC i opublikowano o 19:33 UTC tego dnia.

Zatem data poprawki jest ustalona, a powód — nie. Wersja z łatką widniejąca w rejestrze siedem tygodni przed komunikatem doradczym jest spójna z cichą poprawką, po której nastąpiło skoordynowane ujawnienie — ale to jest wniosek wyciągnięty z dwóch znaczników czasu, a żaden z dokumentów tego nie stwierdza.

Co ustala dokumentacja, a czego nie ustala

Archiwum przyznaje temu wpisowi ocenę A — dobrze udokumentowany, źródła pierwotne są zgodne — i nie oznacza go jako spornego. Klasyfikuje go jako rekord badawczy, ustalenie dotyczące podatności, a nie incydent wdrożeniowy, bez odnotowanych szkód w świecie rzeczywistym. Ocena dotyczy jakości dokumentacji i wobec przeanalizowanych dowodów się utrzymuje: biuletyn, poradnik bezpieczeństwa GitHub i rekord CVE to trzy dokumenty opublikowane przez Amazon, które są zgodne co do produktu, wersji, poprawki i uznania.

• Potwierdzono. Amazon opublikował biuletyn 2026-075-AWS w dniu 5 sierpnia 2026 r., obejmujący CVE-2026-18953, podatność CWE-22 typu path traversal w obsłudze get_resourceprzez savePath w awslabs.aws-transform-mcp-server od 0.1.0 do 0.1.4, naprawioną w 0.1.5, bez obejścia po stronie serwera ani obejścia wyłącznie konfiguracyjnego, ponieważ podatna ścieżka znajduje się w konfiguracji domyślnej.

• Ustalono. Oceny i ich rozbieżność: 8,6 High od Amazon jako organu numerującego CVE, 8,8 High od NIST jako podstawowa ocena NVD, 6,3 Medium w CVSS v4.0 oraz decyzja SSVC CISA z 6 sierpnia, że nie zaobserwowano wykorzystania ani automatyzowalnej ścieżki ataku.

• Ustalono. Daty wydania w Python Package Index oraz uznanie dla Drew Raines za skoordynowane ujawnienie.

• Wywnioskowane z kodu źródłowego przez osobę trzecią. Lista odmowna, lista zablokowanych nazw plików tylko do odczytu, brakujący katalog bazowy oraz _ALLOWED_WRITE_BASE poprawka pochodzą z repozytorium proof-of-concept ronamosa, którego dołączone kopie dwóch wersji walidatora każdy może porównać.

• Wywnioskowane ze znaczników czasu i konstrukcji. Że 0.1.5 było celowym wydaniem z zakresu bezpieczeństwa i że asystent sterowany niezaufaną treścią mógłby dostarczyć wrogą ścieżkę. Amazon nie stwierdza ani jednego, ani drugiego.

• Nie ustalono. Jakiekolwiek wykorzystanie w warunkach rzeczywistych. Oznaczenie CISA „Exploitation: none” ma datę 6 sierpnia, dwa dni przed pojawieniem się publicznego proof-of-concept, więc odnosi się do tamtego momentu, a nie do niczego późniejszego. Nie opublikowano liczby dotkniętych użytkowników, powiadomienia dla klientów ani danych telemetrycznych.

• Nie ustalono.Niezależne relacje. Wydaje się, że żadne media głównego nurtu nie relacjonowały tego CVE. Publiczny zapis obejmuje trzy dokumenty Amazona, uzupełnienia tych dokumentów autorstwa NIST i CISA, strony trackerów, które powtarzają ten zapis, oraz jedno małe repozytorium proof-of-concept opisane powyżej.

Co się zmieniło i co sprawdzić

Środek zaradczy Amazon to podniesienie numeru wersji i nic więcej: zaktualizuj do wersji 0.1.5 lub nowszej oraz „upewnij się, że wszelki sforkowany lub pochodny kod został załatany tak, aby uwzględniał nowe poprawki”. To drugie zastrzeżenie ma szersze zastosowanie. Serwer jest open source, a fork, który wbudował walidator 0.1.4, dziedziczy wadę, ale nie dziedziczy komunikatu doradczego; komunikat prosi osoby utrzymujące kod pochodny o przeniesienie zmiany do niego, co oznacza, że wydanie upstream nie dociera do kopii utrzymywanej przez kogoś innego.

Repozytorium proof-of-concept sugeruje coś, czego komunikat doradczy nie chce powiedzieć. Operatorzy, którzy nie mogą od razu przeprowadzić aktualizacji, powinni — według niego — uruchamiać serwer z katalogiem roboczym ustawionym na dedykowany pusty katalog i traktować każdy plik, do którego serwer może zapisywać, jako skompromitowany. Stanowisko Amazon jest bardziej rygorystyczne: nie ma żadnego obejścia po stronie serwera ani takiego, które opierałoby się wyłącznie na konfiguracji. Według samego repozytorium ta sugestia jest również wątpliwa, ponieważ podatny kod nigdy nie ograniczał zapisów do katalogu roboczego. Tam, gdzie oba stanowiska się różnią, obowiązuje wyłącznie instrukcja aktualizacji od dostawcy.

Przydatne w tym rekordzie nie jest jego wynik. Przydatny jest jego kształt: lokalny serwer MCP, pobieranie artefaktu z miejscem docelowym podanym przez wywołującego oraz brak granicy między tymi dwoma elementami. Kontrola, która ma znaczenie, to nie data biuletynu, tylko przypięta wersja — 0.1.5 lub nowsza — oraz ta sama zmiana przeniesiona do każdego forka, który skopiował walidator.