Najnowsze biuletyny bezpieczeństwa AWS wskazują na zmianę charakteru ryzyka związanego z narzędziami deweloperskimi. Opisane produkty nie są różnymi wersjami jednej platformy, a luki nie mają wspólnej przyczyny technicznej. Łączy je jednak wzorzec operacyjny: środowisko programistyczne lub analityczne wspierane przez AI może znajdować się pomiędzy poleceniem użytkownika a poświadczeniami, plikami, wewnętrznymi usługami sieciowymi albo interfejsami API chmury. Błąd w takiej warstwie może więc stać się zdarzeniem bezpieczeństwa o większym zasięgu niż typowa usterka edytora.

Stanowisko operacji bezpieczeństwa, na którym laptop monitoruje połączenia między agentem AI, narzędziami, poświadczeniami, plikami i infrastrukturą chmurową.

W ostatnich dniach AWS opublikował lub zaktualizował ważne ostrzeżenia dotyczące Loom for AWS, otwartoźródłowego security-agent-mcp-server, SageMaker Distribution w SageMaker Unified Studio oraz środowiska Kiro IDE. Ujawnione problemy obejmują obejście uwierzytelniania, ujawnienie tokenów, niebezpieczne żądania wychodzące, wstrzykiwanie argumentów, wykonywanie poleceń oraz agentowy zapis do globalnej konfiguracji. Biuletyny AWS wskazują różne wersje podatne na atak i różne ścieżki naprawy, dlatego ogólna instrukcja w rodzaju „zaktualizujcie narzędzia AWS” nie wystarczy.

Bezpośrednia reakcja jest prosta: trzeba ustalić, czy którykolwiek z podatnych komponentów jest zainstalowany lub wdrożony, przejść do wersji z poprawką, zrestartować usługi tam, gdzie AWS wskazuje, że poprawka zostanie dostarczona po ponownym uruchomieniu, oraz obrócić poświadczenia, jeśli biuletyn mówi o możliwości ich ujawnienia. Ważniejsza praca ma charakter strukturalny. Zespoły deweloperskie powinny traktować narzędzia agentowe jak uprzywilejowane komponenty oprogramowania i zapewnić zespołom bezpieczeństwa widoczność ich uprawnień, zasięgu sieciowego, zakresu lokalnego zapisu oraz śladu audytowego.

Co ujawnił AWS

Najnowszy biuletyn w tej grupie dotyczy CVE-2026-104019 w procesie uruchamiania SageMaker Spaces w SageMaker Unified Studio. AWS podaje, że skrypt startowy weryfikuje połączenia sieciowe dostępne w projekcie. W określonych warunkach niewystarczająca sanitacja szczegółów połączenia mogła umożliwić wykonanie kodu w Space należącym do innego członka projektu. W projektach korzystających z Trusted Identity Propagation osoba mająca rolę współtwórcy lub wyższą mogła potencjalnie uzyskać tymczasowe poświadczenia roli wykonawczej innego członka i wywoływać usługi zależne w jego imieniu.

AWS informuje, że poprawka została wdrożona globalnie i jest stosowana przy ponownym uruchomieniu obsługiwanych Spaces. Biuletyn wymienia naprawione wersje SageMaker Distribution, w tym 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 oraz 4.4.3. Kilka starszych linii minor nie ma poprawki, ponieważ nie są już wspierane. AWS zaleca ponowne uruchomienie Spaces działających na podatnych liniach minor, aby otrzymały poprawiony obraz. Nie podano obejścia. Oznacza to, że restart i sprawdzenie wersji są kontrolą operacyjną, a nie sugestią, którą można odłożyć do najbliższego okna serwisowego.

Biuletyn dotyczący Loom for AWS opisuje inny problem, szczególnie istotny dla zespołów eksperymentujących z orkiestracją agentów. AWS przedstawia Loom jako otwartoźródłową platformę AWS Labs do orkiestracji agentów AI. Trzy CVE dotyczą wersji wcześniejszych niż 1.7.0. Jeden z problemów z uwierzytelnianiem, występujący w wersjach wcześniejszych niż 1.6.1, mógł pozwolić nieuwierzytelnionemu klientowi sieciowemu uzyskać uprawnienia administratora do płaszczyzny sterowania agentami, gdy nie skonfigurowano dostawcy tożsamości. Według AWS takie uprawnienia mogły obejmować rejestrowanie serwerów narzędzi, odczyt zapisanych danych uwierzytelniających integracji oraz przepisywanie polityk ról IAM przypisanych do zarządzanych ról agentów.

Drugi problem, dotyczący wersji wcześniejszych niż 1.7.0, wiąże się z obsługą wykrywania OAuth2. AWS podaje, że uwierzytelniony użytkownik ze zakresem mcp:write lub a2a:write mógł skonfigurować adres URL wykrywania, który powodował wysyłanie sekretów klienta OAuth2 albo tokenu dostępowego innego użytkownika do punktu końcowego kontrolowanego przez stronę trzecią. Wcześniejsze wydanie 1.6.1 blokowało dostęp do adresów wewnętrznych, ale nie zamykało całkowicie ścieżki ujawniania tokenów. Trzeci problem dotyczył połączeń z serwerami narzędzi i zdalnymi agentami. Uwierzytelniony użytkownik mógł kierować żądania do dowolnych lokalizacji w sieci wewnętrznej, w tym do punktu końcowego kontenera wydającego poświadczenia.

Rozwiązaniem wskazanym przez AWS dla Loom jest wersja 1.7.0; odrębny problem z uwierzytelnianiem naprawiono również w 1.6.1. Biuletyn wyraźnie zaleca obrócenie sekretów klientów OAuth2, unieważnienie i ponowne wydanie tokenów dostępowych aktywnych w podatnym okresie oraz obrócenie poświadczeń sesji ról IAM, jeśli mogło dojść do dostępu do poświadczeń kontenera. To najbardziej czytelny przykład w całej grupie pokazujący, dlaczego sama poprawka może nie wystarczyć: jeżeli sekrety mogły przekroczyć granicę zaufania, naprawa obejmuje także odzyskanie kontroli nad tożsamością.

Problem security-agent-mcp-server ma węższy zakres produktowy, ale jest ważny, ponieważ dotyczy granicy między lokalnym asystentem AI a systemem plików hosta. AWS opisuje ten projekt jako otwartoźródłowy serwer MCP w repozytorium awslabs/mcp, którego asystenci używają do uruchamiania lokalnych skanów bezpieczeństwa, w tym skanów różnicowych. CVE-2026-97662 dotyczyło wersji od 0.1.1 do wcześniejszej niż 0.2.0. Specjalnie spreparowana wartość referencyjna przekazana do skanu różnicowego mogła zostać zinterpretowana jako opcja wiersza poleceń, a nie jako rewizja. AWS podaje, że skutkiem mogło być tworzenie, nadpisywanie lub obcinanie dowolnych plików poza zamierzonym obszarem roboczym, z pominięciem kontroli ograniczającej serwer do tego obszaru.

AWS wskazuje wersję 0.2.0 jako naprawioną i informuje, że poza aktualizacją nie ma obejścia. Do tego czasu zaleca uruchamianie skanów różnicowych wyłącznie względem zaufanych repozytoriów oraz używanie konta o minimalnych uprawnieniach w odizolowanym środowisku. Ta rada wykracza poza jeden pakiet. Lokalny agent, który może wywołać skaner, kompilator, menedżer pakietów lub pomocnicze narzędzie wdrożeniowe, jest lokalnym systemem automatyzacji. Błąd w obsłudze argumentów może zamienić starannie opisaną granicę obszaru roboczego w założenie, którego system operacyjny wcale nie egzekwuje.

Kiro IDE pokazuje kolejną odmianę tego samego problemu. Biuletyn AWS dotyczący CVE-2026-95985 informuje, że wersje Kiro wcześniejsze niż 1.0.242 mogły pozwolić zdalnemu nieuwierzytelnionemu sprawcy wykonywać dowolne polecenia i wstrzykiwać spreparowane instrukcje do kontekstu agenta, gdy użytkownik uruchamiał agenta w spreparowanym repozytorium oznaczonym jako niezaufany obszar roboczy. AWS podaje, że użytkownik musiał jedynie wysłać wiadomość, aby modyfikacje agenta zostały automatycznie wprowadzone do globalnych ścieżek konfiguracji ładowanych przez środowisko.

Naprawioną wersją Kiro jest 1.0.242. AWS informuje, że nie ma obejścia, i prosi użytkowników, którzy uruchamiali agenta w niezaufanym obszarze roboczym na wcześniejszej wersji, o sprawdzenie globalnego katalogu konfiguracji Kiro pod kątem wpisów, których sami nie utworzyli. Wskazane ścieżki to ~/.kiro w systemach macOS i Linux oraz %USERPROFILE%\.kiro w Windows. Ważny szczegół operacyjny jest taki, że repozytorium może być niezaufane, nawet jeśli osoba, która je otwiera, jest zaufana. Decyzja o zaufaniu dotyczy treści analizowanej przez agenta i narzędzi, które agent może wywoływać, a nie tylko tożsamości programisty siedzącego przy klawiaturze.

Wspólnym mianownikiem nie jest „AI jest niebezpieczne”

Łatwo byłoby sprowadzić te ostrzeżenia do ogólnego twierdzenia o niebezpieczeństwie oprogramowania AI. Taki wniosek nie pomaga jednak w reakcji. Użytecznym wspólnym mianownikiem jest koncentracja uprawnień. Każdy z opisanych produktów łączy zwykłe komponenty oprogramowania z możliwością przekraczania granicy: lokalnym zapisem plików, konektorem MCP lub A2A, klientem OAuth2, tymczasową rolą wykonawczą, skryptem startowym albo kontekstem agenta wpływającym na późniejsze działania.

Te granice są dobrze znane zespołom bezpieczeństwa. W przypadku narzędzi agentowych zmienia się liczba kroków, które mogą nastąpić po początkowym wejściu. Repozytorium może wpłynąć na kontekst agenta. Agent może wywołać narzędzie. Narzędzie może dotrzeć do wewnętrznego punktu końcowego albo uruchomić polecenie. Polecenie może odczytać lub zmienić pliki. Usługa chmurowa może następnie użyć tymczasowych poświadczeń do wykonania żądań API. Taki przebieg nie musi być łańcuchem wykorzystania luki w każdym wdrożeniu, ale architektura sprawia, że niewielki błąd w analizie danych lub autoryzacji może mieć konsekwencje poza pierwotną aplikacją.

Dlatego właściwą jednostką oceny nie jest sam pakiet ani samo IDE. Jest nią pakiet wraz z używaną tożsamością wykonawczą, zakresem lokalnego systemu plików, ruchem wychodzącym z sieci, podłączonymi narzędziami i uprawnieniami w chmurze. Zespół, który zaktualizuje Kiro, ale pozostawi każdemu agentowi deweloperskiemu poświadczenia administratora, usunie jedną znaną usterkę, lecz zachowa duży i niekontrolowany promień rażenia. Zespół, który załata Loom, ale nie obróci tokenów po możliwym ujawnieniu, zamknie ścieżkę w kodzie, lecz nie zamknie incydentu.

Wytyczne AWS dotyczące IAM zalecają tymczasowe poświadczenia dla obciążeń, uprawnienia zgodne z zasadą najmniejszych uprawnień, regularny przegląd nieużywanych uprawnień, warunki zawężające polityki oraz zabezpieczenia uprawnień pomiędzy kontami. AWS zaleca również wykorzystywanie aktywności z CloudTrail i IAM Access Analyzer do doskonalenia polityk. Są to ogólne kontrole, ale opisane biuletyny pokazują, gdzie je zastosować: przy tożsamościach i integracjach używanych przez narzędzia agentowe, a nie wyłącznie przy usługach produkcyjnych.

Kto powinien działać w pierwszej kolejności

Pierwszą grupą jest każdy zespół, który wdrożył Loom for AWS poza pętlą zwrotną pojedynczego programisty, szczególnie jeśli aplikacja stała się dostępna z sieci przed skonfigurowaniem dostawcy tożsamości. Drugą są zespoły, które przyznały szerokie zakresy integracji Loom, takie jak mcp:write lub a2a:write, większej liczbie osób niż niewielka grupa administratorów. Trzecią grupą są zespoły używające Loom z integracjami OAuth2, zdalnymi agentami albo serwerami narzędzi przechowującymi poświadczenia.

Następne w kolejce są zespoły danych i AI korzystające z SageMaker Unified Studio Spaces z Trusted Identity Propagation. Ryzyko zależy od konfiguracji projektu i linii dystrybucji, ale działania naprawcze są konkretne: zidentyfikować Spaces na podatnych wersjach, zrestartować je po udostępnieniu poprawionych obrazów oraz sprawdzić, czy starsze, niewspierane linie minor nie pozostają w użyciu. Restart powinien być śledzony jako zmiana z właścicielem i dowodem wykonania, a nie zakładany tylko dlatego, że platforma jest zarządzana.

Zespoły odpowiedzialne za platformę deweloperską i bezpieczeństwo aplikacji powinny sprawdzić obecność security-agent-mcp-server AWS w lokalnych manifestach narzędzi, integracjach edytorów, pomocniczych obrazach CI oraz współdzielonych kontenerach deweloperskich. Pakiet może być zainstalowany pod nazwą, która nie wynika wprost z inwentaryzacji usług AWS. Należy przeszukać repozytoria źródłowe i konfigurację uruchamiania stanowisk, w której deklarowane są serwery MCP, a następnie przypisać każdą instalację do wersji i konta wykonawczego.

Na końcu zespoły zarządzające punktami końcowymi powinny zweryfikować wersje Kiro na stacjach programistów i zarządzanych pulpitach wirtualnych. Jest to szczególnie ważne tam, gdzie programiści regularnie otwierają zewnętrzne repozytoria, zgłoszenia lub wygenerowany kod. Przegląd stacji powinien obejmować globalny katalog konfiguracji Kiro, jeśli podatna wersja była używana z niezaufanym obszarem roboczym. Celem nie jest ręczne oglądanie każdego pliku bez kontekstu, lecz porównanie historii konfiguracji z zatwierdzonymi wzorcami zarządzania i zbadanie wpisów, które pojawiły się w podatnym okresie.

Praktyczna sekwencja reakcji

1. Zbuduj inwentaryzację możliwości

Zacznij od możliwości, nie od nazw dostawców. Wypisz każde narzędzie deweloperskie lub analityczne, które może robić co najmniej jedną z następujących rzeczy: zapisywać poza katalogiem projektu, wykonywać lokalne polecenia, wywoływać serwery MCP lub A2A, uzyskiwać dostęp do poświadczeń chmurowych, rozwiązywać adresy sieciowe, tworzyć lub modyfikować role IAM albo odczytywać sekrety integracji. Uwzględnij rozszerzenia IDE, lokalne demony, współdzielone kontenery, runnery CI, obrazy notebooków oraz wewnętrzne nakładki na projekty otwartoźródłowe.

Dla każdego elementu zapisz zainstalowaną wersję, źródło instalacji, właściciela, hosta lub kontener, tożsamość używaną do dostępu do zasobów chmurowych, osiągalne sieci oraz repozytoria lub projekty, które mogą dostarczać dane wejściowe. Inwentaryzacja nie musi pierwszego dnia być idealną bazą zasobów. Musi jednak umożliwiać odpowiedź na pytanie, czy dane ostrzeżenie AWS dotyczy rzeczywistej instalacji i jakie inne systemy były z niej osiągalne.

2. Łataj zgodnie z rzeczywistą granicą produktu

W przypadku Loom przejdź do wersji 1.7.0 i sprawdź forki oraz kod pochodny. AWS wyraźnie informuje, że pochodne rozwiązania muszą zawierać poprawki, więc repozytorium skopiowane ze źródła nie jest objęte naprawą tylko dlatego, że wydanie upstream jest aktualne. Dla serwera MCP zainstaluj wersję 0.2.0 i potwierdź, że współdzielone obrazy oraz skrypty uruchamiania stanowisk nie instalują już starszego zakresu. W przypadku Kiro przejdź do wersji 1.0.242 lub nowszej i przejrzyj globalną konfigurację, jeśli podatna wersja była używana z niezaufanym obszarem roboczym.

W SageMaker Unified Studio ustal linię minor dystrybucji i zrestartuj podatne Spaces, aby zastosować poprawkę wdrożoną globalnie. Lista wersji AWS ma znaczenie, ponieważ niektóre stare linie nie są już poprawiane, lecz niewspierane. Usługa zarządzana może ograniczyć część obowiązków związanych z łataniem, ale nie zwalnia z potwierdzenia, jaki runtime faktycznie działa ani czy Space został zrestartowany.

3. Odzyskaj materiały tożsamości, gdy ujawnienie jest prawdopodobne

Nie czekaj na dowód, że token został wykorzystany. Biuletyn AWS dotyczący Loom zaleca obrót sekretów klientów OAuth2 oraz unieważnienie i ponowne wydanie aktywnych tokenów dostępowych, jeśli podatny okres mógł ich dotyczyć. Jeżeli poświadczenia roli kontenera mogły zostać odczytane, obróć poświadczenia sesji i przejrzyj CloudTrail pod kątem niezamierzonego użycia. Dokładna kolejność powinna wynikać z procesu reagowania na incydenty w organizacji i możliwości dostawcy tożsamości.

Zasada polega na rozdzieleniu naprawy kodu od naprawy poświadczeń. Poprawiony plik binarny zapobiega ponownemu wykorzystaniu znanej ścieżki. Nie unieważnia jednak sekretu, który mógł zostać wcześniej skopiowany. To samo dotyczy plików konfiguracyjnych, tokenów programistów, poświadczeń CI i tymczasowych sesji ról.

4. Przejrzyj aktywność w chmurze z okresu narażenia

CloudTrail rejestruje wywołania interfejsów API AWS wraz z informacjami takimi jak tożsamość wywołująca, czas, źródłowy adres IP, parametry żądania i elementy odpowiedzi. Wykorzystaj te dane, aby ustalić, czy podatna rola lub integracja wykonywała nietypowe działania w czasie, gdy podatny komponent był dostępny. Zwróć uwagę na przyjmowanie ról, zmiany polityk IAM, tworzenie nowych kluczy dostępowych, modyfikacje polityk zaufania, dostęp do sekretów, nieoczekiwane odczyty danych oraz aktywność z nieznanych sieci.

Celem nie jest znalezienie jednej magicznej nazwy zdarzenia. Zbuduj oś czasu obejmującą podatny komponent, jego tożsamość i podłączone usługi. Ujawnienie tokenu może pojawić się jako dostęp z nieoczekiwanego adresu. Przepisanie polityki roli może wyglądać jak zmiana w IAM, po której nastąpił dostęp nowego podmiotu. Przejęty Space do pracy z danymi może generować aktywność z użyciem prawidłowej tymczasowej roli, dlatego czas, źródło i oczekiwana aktywność projektu trzeba analizować razem.

5. Ogranicz uprawnienia przed powrotem do normalnej pracy

Okno przeznaczone na łatanie jest dobrym momentem na usunięcie uprawnień przyznanych do eksperymentów, których nigdy później nie ograniczono. Zacznij od rozdzielenia odkrywania tylko do odczytu, skanowania kodu, wdrażania, dostępu do sekretów i administracji IAM na różne role. W miarę możliwości używaj tymczasowych poświadczeń i krótkich sesji. Najpotężniejsze działania umieść za akceptacją albo w oddzielnej roli operatora, zamiast udostępniać je każdej tożsamości połączonej z agentem.

AWS zaleca najmniejsze uprawnienia i zabezpieczenia uprawnień. W praktyce oznacza to, że agent powinien mieć wyłącznie te działania API, które są potrzebne do zadania, i tylko wobec zasobów wymaganych przez to zadanie. Skaner kodu nie potrzebuje automatycznie uprawnień do zmiany polityk IAM. Serwer narzędzi odczytujący kod źródłowy nie musi mieć dostępu do sekretów produkcyjnych. Współtwórca notebooka nie powinien dziedziczyć tożsamości innego członka projektu tylko dlatego, że włączono funkcję propagacji zaufanej tożsamości.

W tym miejscu znaczenie mają również kontrole sieciowe. Ogranicz ruch wychodzący z kontenerów agentów i usług deweloperskich do miejsc, których naprawdę potrzebują. Zablokuj dostęp do punktów końcowych wydających poświadczenia poza obsługiwanym mechanizmem. Trzymaj lokalne narzędzia w odizolowanych środowiskach, gdy przetwarzają niezaufane repozytoria. Izolacja sieci nie zastępuje łatania, ale może powstrzymać parser, konektor lub opakowanie polecenia przed zamianą lokalnego błędu w dostęp do szerszego środowiska.

Czego nie należy wywnioskować z tych biuletynów

Opisane ujawnienia nie dowodzą, że każde agentowe IDE lub każdy serwer MCP został przejęty. Pokazują jednak, że przegląd bezpieczeństwa musi obejmować zwykłe błędy oprogramowania w płaszczyźnie sterowania otaczającej agenta. Ryzyko nie zależy wyłącznie od tego, czy produkt reklamuje funkcje AI. Wtyczka bez AI, która ma możliwość wykonywania poleceń i dostęp do poświadczeń chmurowych, może być równie wrażliwa. Z drugiej strony agent bez poświadczeń, dostępu do sieci i z obszarem roboczym tylko do odczytu ma inny profil skutków niż agent mogący zmieniać role wdrożeniowe.

Biuletyny nie uzasadniają również zakazu korzystania z otwartoźródłowych narzędzi agentowych jako kategorii. Ostrzeżenia dotyczące Loom i security-agent-mcp-server pokazują, dlaczego zespoły potrzebują sposobu śledzenia forków, przypiętych wersji i lokalnych opakowań. Otwarty kod może ułatwiać widoczność i audyt poprawek, ale oznacza też, że skopiowane repozytorium, wewnętrzna poprawka lub obraz kontenera mogą nadal zawierać lukę po wydaniu naprawy przez upstream. Kontrolą jest dyscyplina wersji i pochodzenia, a nie uproszczona etykieta.

Wreszcie sam wynik podatności nie może określać pilności. Obejście uwierzytelniania w dostępnym z internetu planie sterowania, problem z wstrzykiwaniem argumentów na stacji programisty oraz wykonanie kodu w wieloużytkownikowym środowisku danych mogą mieć zupełnie różne prawdopodobieństwo i konsekwencje. Priorytet powinien uwzględniać ekspozycję, poświadczenia, zasięg sieciowy, objęte dane oraz dowody z logów.

Trwała lekcja dla zespołów platformowych

Agentowe programowanie staje się zbiorem małych płaszczyzn sterowania: IDE, lokalnego serwera narzędzi, warstwy orkiestracji, repozytorium, obszaru roboczego w chmurze i dostawcy tożsamości. Każdy komponent z osobna może wyglądać jak funkcja zwiększająca produktywność. Razem tworzą ścieżkę od niezaufanych danych wejściowych do uprzywilejowanego działania. Odpowiedzialność za bezpieczeństwo nie może kończyć się na zespole aplikacyjnym, który zainstalował narzędzie.

Bieżące ostrzeżenia AWS są użytecznym testem dojrzałości organizacji. Czy zespół potrafi wskazać, którzy programiści korzystają z Kiro, które repozytoria zawierają serwer MCP, które wdrożenia Loom są osiągalne, które SageMaker Spaces działają na podatnych dystrybucjach oraz jakie role mogą przyjmować te systemy? Czy potrafi obrócić sekret integracji bez przebudowy całej platformy? Czy potrafi odróżnić zwykłe wywołanie z użyciem tymczasowej roli od podejrzanego działania? Jeśli nie, brakującą kontrolą nie jest kolejny dokument o polityce AI. Jest nią proces zarządzania zasobami, tożsamością i audytem automatyzacji deweloperskiej.

Na razie rozsądna sekwencja jest krótka: zidentyfikować ekspozycję, zastosować poprawki dostawcy, zrestartować zarządzane Spaces tam, gdzie jest to wymagane, obrócić potencjalnie ujawnione materiały, przejrzeć CloudTrail i zawęzić uprawnienia przed ponownym włączeniem szerokiego dostępu. Biuletyny AWS dotyczą konkretnych produktów i wersji, ale ich przesłanie operacyjne sięga dalej. Gdy oprogramowanie potrafi interpretować repozytorium, wywoływać narzędzie i działać z użyciem tożsamości chmurowej, jego poprawka bezpieczeństwa powinna trafić zarówno do kolejki aktualizacji deweloperskich, jak i do kolejki reagowania na incydenty.

Źródła i zakres

Ten artykuł koncentruje się na biuletynach bezpieczeństwa AWS opublikowanych między 24 września a 2 października 2026 roku, ze szczególnym uwzględnieniem działań operacyjnych wskazanych przez AWS. Nie twierdzi, że w którymkolwiek z podatnych wdrożeń doszło do wykorzystania luki. Szczegóły techniczne umożliwiające wykorzystanie podatności zostały celowo pominięte; do dochodzenia zespoły powinny używać biuletynów dostawcy i własnych procedur reagowania na incydenty.

Podstawowe ujawnienia to Biuletyn AWS 2026-125 dotyczący CVE-2026-104019 w SageMaker Distribution, Biuletyn AWS 2026-124 dotyczący trzech CVE w Loom for AWS, Biuletyn AWS 2026-121 dotyczący CVE-2026-97662 w security-agent-mcp-server oraz Biuletyn AWS 2026-117 dotyczący CVE-2026-95985 w Kiro IDE. Zalecenia dotyczące uprawnień i audytu opierają się na dokumentach AWS: najlepsze praktyki bezpieczeństwa IAM, wytyczne dotyczące najmniejszych uprawnień oraz dokumentacja API CloudTrail.