Luka w AWS Kiro umożliwiała zdalne wykonanie kodu przez złośliwą stronę WWW

Wprowadzenie do problemu / definicja

W środowiskach programistycznych wyposażonych w agentów AI granica między pomocą a automatycznym wykonywaniem działań systemowych staje się coraz cieńsza. Ujawniona podatność w AWS Kiro pokazała, że odpowiednio przygotowana strona internetowa mogła przekazać agentowi ukryte instrukcje, prowadząc do modyfikacji lokalnej konfiguracji i uruchomienia nieautoryzowanego kodu na komputerze dewelopera.

Problem miał charakter prompt injection. Oznacza to, że model analizujący treść zewnętrznego zasobu interpretował niewidoczne lub ukryte polecenia jako instrukcje operacyjne, mimo że użytkownik oczekiwał jedynie pobrania lub streszczenia strony.

W skrócie

• Podatność pozwalała złośliwej stronie WWW wpłynąć na zachowanie agenta AI w AWS Kiro.
• Atak prowadził do modyfikacji pliku konfiguracyjnego mcp.json i uruchomienia wskazanego procesu lokalnie.
• Skutkiem mogło być zdalne wykonanie kodu w kontekście konta użytkownika.
• Mechanizm zatwierdzania zmian nie zawsze stanowił skuteczną blokadę techniczną.
• Incydent podkreśla ryzyko łączenia dostępu do internetu, zapisu plików i automatycznego przeładowywania konfiguracji w narzędziach agentowych.

Kontekst / historia

Sprawa wpisuje się w szerszy trend zagrożeń związanych z agentami AI zintegrowanymi z IDE oraz narzędziami developerskimi. W odróżnieniu od klasycznych asystentów podpowiadających kod, takie rozwiązania potrafią analizować dokumentację, pobierać zasoby sieciowe, modyfikować pliki projektu, a nawet inicjować procesy lokalne. To znacząco zwiększa powierzchnię ataku.

W przypadku AWS Kiro problem nie ograniczał się do błędnej interpretacji treści. Kluczowe było połączenie kilku funkcji: dostępu do zasobów internetowych, możliwości zapisu lokalnych plików konfiguracyjnych oraz automatycznego przeładowywania zmian. Taki zestaw tworzy warunki, w których prompt injection może przejść z poziomu manipulacji odpowiedzią modelu do rzeczywistej kompromitacji stacji roboczej.

Według dostępnych informacji podatność dotyczyła co najmniej wybranych wersji dla macOS i Ubuntu, a poprawka została potwierdzona w gałęzi 0.11.130. To kolejny sygnał ostrzegawczy dla organizacji wdrażających agentów AI w procesach wytwórczych bez pełnej izolacji środowiska wykonawczego.

Analiza techniczna

Rdzeniem problemu był plik ~/.kiro/settings/mcp.json, odpowiedzialny za konfigurację serwerów Model Context Protocol. To z niego środowisko odczytywało, jakie komponenty zewnętrzne należy załadować i jakimi poleceniami je uruchomić. Jeśli plik został zmieniony, Kiro przeładowywał konfigurację i wykonywał wskazane procesy z uprawnieniami aktualnego użytkownika.

W praktyce atak rozpoczynał się od sytuacji pozornie nieszkodliwej. Deweloper prosił agenta o odwiedzenie strony, pobranie dokumentacji lub przygotowanie podsumowania. Złośliwa witryna zawierała jednak ukryte instrukcje osadzone w kodzie HTML, na przykład w praktycznie niewidocznej treści. Dla człowieka strona wyglądała normalnie, ale agent traktował ukryty blok jako polecenie do wykonania.

Łańcuch ataku można opisać w kilku etapach:

• użytkownik zleca agentowi analizę strony WWW,
• agent odczytuje ukryte instrukcje osadzone w treści,
• następuje zapis złośliwego wpisu do pliku mcp.json,
• aplikacja przeładowuje konfigurację,
• zdefiniowany przez napastnika serwer MCP zostaje uruchomiony lokalnie,
• dochodzi do wykonania kodu na stacji roboczej ofiary.

Szczególnie istotny był fakt, że mechanizm zgód użytkownika nie zawsze działał jak realna zapora bezpieczeństwa. Jeśli zmiana konfiguracji mogła zostać przeładowana niezależnie od skutecznego zatwierdzenia, to interfejs ostrzegawczy pełnił rolę informacyjną, a nie ochronną. Z perspektywy bezpieczeństwa oznacza to błąd architektoniczny, a nie wyłącznie problem z interakcją użytkownika.

Badacze zwracali również uwagę, że exploit nie musiał działać w sposób całkowicie deterministyczny. Nawet jeśli model nie wykonywał złośliwych instrukcji za każdym razem, skuteczność osiągana w niewielkiej liczbie prób była wystarczająca, aby uznać zagrożenie za praktyczne i wysokiego ryzyka.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności było zdalne wykonanie kodu w kontekście zalogowanego użytkownika. W przypadku stacji roboczej dewelopera oznacza to bardzo szeroki zakres możliwych nadużyć, zwłaszcza jeśli urządzenie ma dostęp do repozytoriów, sekretów, narzędzi CI/CD lub środowisk chmurowych.

• kradzież tokenów, kluczy API i poświadczeń chmurowych,
• dostęp do kodu źródłowego oraz danych projektowych,
• modyfikację repozytoriów i pipeline’ów automatyzacji,
• instalację mechanizmów trwałości na urządzeniu,
• wykorzystanie komputera programisty do ruchu lateralnego w sieci wewnętrznej.

Ryzyko rośnie szczególnie tam, gdzie agenci AI działają na uprzywilejowanych stacjach roboczych, mają dostęp do sekretów lub są wykorzystywani w środowiskach połączonych z produkcją. Incydent pokazuje, że prompt injection nie jest już wyłącznie problemem jakości odpowiedzi modelu, ale może stać się pełnoprawnym wektorem przejęcia endpointu.

Rekomendacje

Organizacje korzystające z agentów AI powinny traktować je jak komponenty zdolne do wykonywania operacji wysokiego ryzyka. W praktyce oznacza to konieczność wdrożenia kontroli technicznych wykraczających poza same komunikaty ostrzegawcze i deklaratywne zgody.

• niezwłoczna aktualizacja AWS Kiro do wersji zawierających poprawki,
• blokowanie zapisu do wrażliwych plików konfiguracyjnych bez twardych mechanizmów kontroli,
• izolowanie środowiska pracy agentów od systemu hosta, najlepiej przez sandboxing lub kontenery,
• ograniczenie lokalnych uprawnień oraz dostępu do sekretów przechowywanych na stacji roboczej,
• monitorowanie zmian w plikach wykonawczych i konfiguracyjnych, takich jak mcp.json czy artefakty środowisk IDE,
• wdrożenie narzędzi EDR/XDR do wykrywania nietypowych procesów uruchamianych przez IDE i narzędzia AI,
• filtrowanie oraz klasyfikacja treści pobieranych z internetu przez agentów,
• weryfikacja, czy proces zatwierdzania zmian stanowi rzeczywistą blokadę techniczną.

Z punktu widzenia producentów oprogramowania kluczowy wniosek jest prosty: operacje dotyczące plików sterujących wykonaniem kodu muszą być chronione na poziomie platformy, a nie pozostawione decyzjom modelu lub miękkim regułom interfejsu.

Podsumowanie

Podatność w AWS Kiro pokazuje, jak szybko zagrożenia związane z agentami AI przechodzą z obszaru teorii do realnych scenariuszy ataku. W tym przypadku zwykła analiza strony WWW mogła doprowadzić do zmiany konfiguracji i uruchomienia złośliwego kodu bez skutecznej interwencji użytkownika.

Najważniejsza lekcja ma charakter architektoniczny. Narzędzia agentowe nie mogą opierać bezpieczeństwa wyłącznie na zaufaniu do modelu, promptach ochronnych czy ostrzeżeniach w interfejsie. Kontrola nad plikami wrażliwymi, uruchamianiem procesów i przeładowywaniem konfiguracji musi być wymuszana technicznie oraz odporna na prompt injection.

Źródła

1. AWS Kiro Flaw Let a Poisoned Web Page Rewrite Its Config and Run Code — https://thehackernews.com/2026/07/aws-kiro-flaw-let-poisoned-web-page.html
2. Intezer Research Proof of Concept for Kiro MCP Prompt Injection — https://research.intezer.com/kiro-prompt-injection-vulnerability-mcp/
3. AWS Kiro Security Advisory for CVE-2026-10591 — https://aws.amazon.com/security/security-bulletins/AWS-2026-018/
4. Kiro Documentation: Protected Paths — https://kiro.dev/docs/security/protected-paths/
5. Kiro Documentation: Capability-Based Permissions — https://kiro.dev/docs/security/capability-permissions/