Loom for AWS przyznawał każdemu nieuwierzytelnionemu żądaniu uprawnienia superadministratora — CVE-2026-103956

2 października 2026 r. AWS opublikował Biuletyn Bezpieczeństwa 2026-124-AWS, ujawniając CVE-2026-103956 w Loom for AWS, otwartoźródłowej platformie AWS Labs do budowania, wdrażania i zarządzania agentami AI w środowisku Amazon Bedrock AgentCore Runtime. We wdrożeniu, w którym nie skonfigurowano żadnego dostawcy tożsamości, zależność uwierzytelniająca backendu przypisywała każde przychodzące żądanie do stałej tożsamości superadministratora — w tym żądania nieposiadające w ogóle nagłówka Authorization. Zdalny klient zdolny dotrzeć do backendu mógł rejestrować serwery narzędzi, odczytywać przechowywane poświadczenia integracji i przepisywać polityki ról IAM przypisane do zarządzanych ról agentów: pełna kontrola administracyjna nad płaszczyzną sterowania agentami przy zerowym uwierzytelnieniu. NVD ocenia tę lukę na 10,0 — krytyczną — zarówno w CVSS 3.1, jak i CVSS 4.0. Za odkrycie uznanie przypisuje się Kennethowi Coxowi, który działał w ramach skoordynowanego ujawniania. Biuletyn opisuje, co luka umożliwiałaby; nie opisuje, co ktokolwiek z nią zrobił.

Co faktycznie robiła zależność uwierzytelniania

Usterka znajdowała się w zależności uwierzytelniania backendu. Zgodnie z biuletynem GitHub GHSA-vgmj-998f-r8mp ścieżka kodu w zależności uwierzytelniania backendu — get_current_user funkcja w backendzie Loom — zwracała zakodowaną na stałe tożsamość administratora, konto superadministratora w g-admins-super grupie, za każdym razem, gdy nie istniała żadna pula użytkowników Amazon Cognito ani żaden aktywny zewnętrzny dostawca tożsamości. Nie sprawdzała, czy wywołujący przedstawił token. Nie przechodziła do ścieżki odrzucenia. Mimo to zwracała tożsamość administratora.

Biuletyn AWS opisuje tę konsekwencję w ten sam sposób: luka pozwalała dowolnemu klientowi sieciowemu uzyskać pełne uprawnienia administracyjne nad płaszczyzną sterowania agenta. CVE-2026-103956 jest przypisane do CWE-306 (brak uwierzytelniania w przypadku funkcji krytycznej) oraz CWE-1188 (niezabezpieczona domyślna inicjalizacja zasobu). Wektor CVSS 3.1 w NVD to AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — osiągalna sieciowo, niska złożoność, brak uprawnień, brak interakcji użytkownika, zmieniony zakres, pełny wpływ na poufność, integralność i dostępność.

Istotne ujęcie — i ta część, która wyjaśnia, dlaczego ocena CVSS 10.0 trafiła na mały projekt open source — polega na tym, że wdrożenie bez IdP nie jest egzotyczne. Świeżo zainstalowana instancja Loom, w której nie podłączono jeszcze Cognito, znajduje się dokładnie w takim stanie, podobnie jak wdrożenie, w którym konfiguracji dostawcy tożsamości nigdy nie ustawiono albo przestała się ona rozwiązywać. Biuletyn traktuje to jako częstą sytuację, a nie błąd konfiguracji, do którego operator musiał doprowadzić.

Do czego mógłby dotrzeć nieuwierzytelniony klient

• Rejestracje agentów i serwery narzędzi: klient mógłby rejestrować lub zmieniać serwery narzędzi, które agent może wywoływać, co w architekturze wywoływania narzędzi stanowi różnicę między agentem, który czyta zgłoszenie, a agentem, który coś uruchamia.

• Przechowywane poświadczenia integracji: platforma przechowuje poświadczenia do systemów zewnętrznych, z którymi łączą się jej agenci i serwery narzędzi, a biuletyn stwierdza, że można je było odczytać.

• Polityki ról IAM dla zarządzanych ról agentów: biuletyn opisuje przepisanie polityk ról IAM przypisanych do ról, którymi Loom zarządza dla swoich agentów, co jest krokiem, który przekształca kontrolę nad warstwą orkiestracji w kontrolę nad tym, co agenci mogą robić wewnątrz konta AWS.

• Wszystko inne, czym zarządza platforma: agenci, pamięci, konfiguracja autoryzatora i zabezpieczeń, ustawienia — oraz wywoływanie dowolnego agenta uruchamianego przez wdrożenie.

Te cztery pozycje to własna lista tego komunikatu, pokazująca, do czego sięga pełny dostęp administracyjny, a nie rekonstrukcja. Nie twierdzi się, że w ramach jakiejkolwiek eksploatacji wykorzystano którąkolwiek z nich.

Ustanowione i nieustanowione

Ustalono. Podatność istniała i jest udokumentowana w uzgodnionych źródłach pierwotnych: Biuletynie bezpieczeństwa AWS 2026-124-AWS z 2 października 2026 r., poradniku GitHub GHSA-vgmj-998f-r8mp opublikowanym tego samego dnia oraz w rekordzie NVD CVE-2026-103956. Wersje, których dotyczy problem (przed 1.6.1), wyniki CVSS, przypisania CWE, wersja poprawki i autorstwo są w nich spójne. Wpis archiwalny dotyczący tego incydentu ma ocenę pewności A, nie jest kwestionowany, a wartość real_harm wynosi false.

Pola samego rekordu umieszczają ujawnienie na 2 października 2026 r., z dokładnością do dnia, i opisują publiczne zgłoszenie proof-of-concept jako niezweryfikowane; ani biuletyn, ani komunikat doradczy nie zawierają dowodów na atak. Publiczny rekord NVD dla CVE-2026-103956 wskazuje, że katalog znanych wykorzystywanych podatności CISA jest pusty w przypadku tego CVE, a rekord archiwalny ma real_harm ustawione na false. A więc: luka, którą mógłby wykorzystać nieuwierzytelniony klient sieciowy, bez dowodów w źródłach, że ktokolwiek to zrobił.

Warto to również rozdzielić. Ocena CVSS 10.0 mierzy to, co podatność mogłaby umożliwić, a nie to, co faktycznie zrobiła. Ocena 10.0 bez wykorzystania i bez odnotowanych szkód to przypadek, w którym niewiele brakowało, a archiwum klasyfikuje go właśnie w ten sposób.

Poprawka i dwumiesięczna luka, zanim została nazwana

AWS naprawiło ten problem w Loom 1.6.1, wydanym 4 sierpnia 2026 r. Ta data ma znaczenie: wydanie ukazało się około dwa miesiące przed biuletynem, a numer CVE istniał już publicznie. Notatki do wydania wersji 1.6.1 opisują tę zmianę bez podania numeru CVE — obejście uwierzytelniania wymaga teraz jawnego opt-in oraz klienta loopback, a w przeciwnym razie następuje bezpieczne odrzucenie z kodem 401 — więc waga tej luki i jej oznaczenie były widoczne tylko dla użytkowników Loom śledzących trackery, a nie dla kogoś, kto czytałby wyłącznie notatki do wydania. To samo wydanie dodało wzmocnienie ochrony przed SSRF przy pobieraniu danych na potrzeby wykrywania OAuth.

W przypadku wdrożeń, które zostały już ujawnione, wytyczne AWS dotyczące okresu przed aktualizacją mówią, aby przed udostępnieniem backendu poza interfejsem loopback w pełni skonfigurować pulę użytkowników Amazon Cognito lub aktywnego zewnętrznego dostawcę tożsamości, a także potwierdzić, że LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV nie jest ustawiona poza lokalnym środowiskiem programistycznym, oraz aby w międzyczasie ograniczyć dostęp sieciowy lub dostęp grup zabezpieczeń do backendu. Biuletyn wyraźnie stwierdza, że ograniczenie sieciowe zmniejsza prawdopodobieństwo niezamierzonego dostępu, ale nie zamyka problemu bez aktualizacji, a forki i kod pochodny również wymagają załatania.

Ten sam biuletyn, inne wady

W podsumowaniu rekordu zauważono, że 2026-124-AWS nie dotyczy tylko tego CVE. Tego samego dnia ujawniono jeszcze dwa problemy Loom, które naprawiono w Loom 1.7.0: CVE-2026-103957, SSRF w obsłudze wykrywania OAuth2, który mógł wysłać sekrety klienta OAuth2 lub token dostępu innego użytkownika do punktu końcowego kontrolowanego przez atakującego (CVSS 3.1 6.2, CVSS 4.0 8.2), oraz CVE-2026-103958, SSRF w obsłudze połączeń serwera narzędzi i zdalnego agenta, który mógł dotrzeć do dowolnych adresów wewnętrznych, w tym do punktu końcowego kontenera wydającego poświadczenia, i odczytać odpowiedzi (CVSS 3.1 7.6, CVSS 4.0 8.3). Oba wymagały uwierzytelnionego użytkownika z zakresem mcp:write lub a2a:write. Biuletyn obejmuje również CVE-2026-104019, wstrzyknięcie polecenia systemu operacyjnego w skrypcie walidacji uruchamiania Studio Space używanym przez Amazon SageMaker Unified Studio, ocenione jako krytyczne 9.0 w CVSS 3.1, które według AWS zostało naprawione po stronie serwera globalną zmianą sanitizującą zastosowaną przy następnym ponownym uruchomieniu Space.

Po aktualizacji AWS prosi operatorów o rotację sekretów klienta OAuth2 dla integracji MCP i A2A, unieważnienie i ponowne wydanie tokenów, które były aktywne w okresie objętym problemem, a także — jeśli uzyskano dostęp do poświadczeń roli kontenera — rotację poświadczeń sesji roli IAM i przegląd CloudTrail.

Dlaczego ten rekord znajduje się w archiwum

CVE-2026-103956 został zgłoszony jako podatność, a nie incydent: wykryta, niekoniecznie wykorzystana, INFRA i CRED, GLOBAL, wysoka waga, wysoka pewność. Jego wartość w zbiorze rekordów polega na tym, że stanowi przypadek brzegowy dla całej kategorii płaszczyzn kontrolnych agentów. Zadaniem Loom jest przechowywanie tożsamości, rejestracji serwerów narzędzi wraz z ich poświadczeniami integracyjnymi oraz polityk IAM, które decydują, do czego agenci mogą mieć dostęp — warstwy, która łączy platformę agentów z kontem w chmurze, w którym ona funkcjonuje. Brak kontroli w tej warstwie nie degraduje agenta; przenosi całe środowisko. Pokrewny rekord w archiwum — ujawnienie AgentCorruption z 8 października 2026 r. dotyczące Amazon Bedrock AgentCore — opisuje dotarcie do tej samej warstwy inną drogą: łańcuchem SSRF wychodzącym z jednego publicznie dostępnego agenta.

Archiwum wymienia każdy udokumentowany incydent dotyczący agenta, jaki zawiera — każdy z własnymi źródłami, poziomem dotkliwości, oceną pewności i flagą sporności — obok tego. Ten artykuł dotyczy pojedynczego rekordu w tym zbiorze, a właśnie w tym rekordzie znajduje się pełna klasyfikacja pole po polu.

To jeden rekord — zbadany i opisany przez innych, a tutaj przytoczony z podaniem ich jako źródła. Własna warstwa Loom — tożsamości, rejestracje serwerów narzędzi oraz polityki IAM, które decydują, czego agenci mogą dotykać — to warstwa, do której sięgają także pokrewne wpisy w archiwum incydentów AI, a każdy z tych rekordów ma własne źródła, wagę, stopień pewności i znacznik sporu.