Co się stało
6 sierpnia 2026 r. organizacja Cloud Security Alliance opublikowała notatkę badawczą opisującą CoreBreak, zestaw czterech CVE w frameworkach agentów AWS, Google i Vercel, w których warstwa wysyłania narzędzi wykonywała wywołanie narzędzia bez sprawdzania, czy model języka faktycznie je wygenerował. Wszystkie cztery mają poprawki dostawcy.
Inicjatywa AI Safety Initiative stowarzyszenia Cloud Security Alliance opublikowała 6 sierpnia 2026 r. notatkę badawczą opisującą wzorzec luk w zabezpieczeniach między platformami, który badacze nazwali CoreBreak. Zgodnie z notatką badacze bezpieczeństwa Hedi Ingber i Aviyam Ivgi, współzałożyciele firmy ochroniarskiej Stealth, przedstawili na konferencji Black Hat USA 2026 ustalenia pokazujące, że warstwy wykonawcze narzędzi Amazon Bedrock AgentCore, zestaw Agent Development Kit (ADK) Google dla Python oraz pakiety uprzęży dystrybuowane z pakietem AI SDK Vercel każdy z nich mógłby zostać nakłoniony do uruchomienia narzędzia bez wystąpienia uzasadnionej zmiany modelu. Jak argumentuje notatka, ponieważ nigdy nie odwoływano się do modelu językowego, nie podjęto decyzji o interwencji w przypadku poręczy zbudowanych wokół modelu.
Tego rodzaju struktury agentów mają wspólną strukturę. Warstwa aranżacji łączy żądanie użytkownika, monit systemowy, historię konwersacji i katalog dostępnych narzędzi, wysyła je do modelu językowego i czeka, aż model zwróci ustrukturyzowaną instrukcję zawierającą nazwę narzędzia i jego argumentów. Następnie zestaw SDK wywołuje odpowiednią funkcję, skrypt lub wywołanie interfejsu API i przekazuje wynik z powrotem do konwersacji. CoreBreak koncentruje się na ostatnim kroku: zgodnie z notatką logika wysyłania w każdym z trzech produktów traktowała dane, które jedynie przypominały wywołanie narzędzia wygenerowanego przez model, jako wiarygodne, bez sprawdzania, skąd pochodzą.
W notatce wymieniono cztery identyfikatory CVE z różnymi ścieżkami wykorzystania, powołując się na biuletyny dostawców i wpisy w krajowej bazie danych o lukach w zabezpieczeniach. AWS przypisał CVE-2026-18830 (CVSS v4.0 8.6, wersja wysoka) do wady wiązki Bedrock AgentCore, w której uwierzytelniony zdalny obiekt wywołujący może umieścić blok treści umożliwiający użycie narzędzia bezpośrednio w końcowym komunikacie żądania API InvokeHarness. Google przypisał CVE-2026-18236 (9.3, krytyczny) do luki ADK, w wyniku której osoba atakująca, która może wprowadzić zdarzenia do historii sesji, może sfałszować potwierdzenie zatwierdzenia przez człowieka, ponieważ procesor potwierdzeń nie sprawdził, czy docelowe narzędzie należy do agenta wykonującego, czy faktycznie wymaga potwierdzenia lub czy jego nazwa i argumenty odpowiadają pierwotnie zarejestrowanemu wywołaniu. @ai-sdk/harness-codex i @ai-sdk/harness-opencode Vercel otrzymały CVE-2026-64650 i CVE-2026-64651 (6.3, średni każdy), gdzie złośliwy kod działający już w piaskownicy Linuksa mógł spełnić kryteria kontroli ścieżki procesu, które ufałyby każdemu procesowi, którego linia poleceń zawierała ścieżkę do zatwierdzonego skryptu pomocniczego.
Dostępne są poprawki, ale obciążenie różni się w zależności od modelu wdrożenia. W notatce podano, że poprawka AWS do w pełni zarządzanego interfejsu API Bedrock AgentCore InvokeHarness została wdrożona automatycznie przed 31 lipca 2026 r. i nie wymagała żadnych działań ze strony klienta, chociaż nadal zaleca potwierdzenie zasięgu dla danego regionu i konfiguracji. Poprawka Google została dostarczona w zestawie ADK dla Python w wersji 2.5.0 16 lipca 2026 r., a poprawki Vercel zostały dostarczone w wiązce-codex 1.0.29 i wiązce-opencode 1.0.28 10 lipca 2026 r. — aktualizacje pakietów, które operatorzy hostujący samodzielnie muszą zastosować samodzielnie. Notatka przedstawia CoreBreak w odróżnieniu od natychmiastowego wstrzyknięcia: natychmiastowe wstrzyknięcie próbuje manipulować oceną modelu, podczas gdy CoreBreak omija kwestię, czy model w ogóle dokonał oceny.
Szczegóły źródła: labs.cloudsecurityalliance.org ↗
Dlaczego to ma znaczenie
Filtry treści, podpowiedzi systemowe, szkolenie w zakresie odmowy i bramki zatwierdzające przez człowieka zakładają, że model jest stroną decydującą o uruchomieniu narzędzia. Jeśli warstwa wysyłkowa zaakceptuje cokolwiek w kształcie wywołania narzędzia modelu, te elementy sterujące zostaną raczej ominięte niż pokonane, a dzienniki zwykle sprawdzane przez zespoły monitorujące nigdy nie zostaną utworzone.
Większość kontroli korporacyjnych dotyczących agentycznej sztucznej inteligencji znajduje się na modelu lub wokół niego. Monity systemowe ograniczają wrażliwe działania, filtry treści oceniają dane wejściowe i wyjściowe, szkolenie w zakresie odmowy jest uwzględniane w wagach modeli, a kroki potwierdzenia przez człowieka otwierają narzędzia wysokiego ryzyka. Każda z tych kontroli zakłada, że model jest stroną decydującą o uruchomieniu narzędzia. Jeśli warstwa dyspozytorska wykona dowolny ładunek o prawidłowym kształcie, inwestycje te zapewniają niewielką ochronę zapobiegawczą — nie dlatego, że zostały źle zaprojektowane, ale dlatego, że ataki przebiegają wokół miejsca, w którym działają. Jest to problem innej klasy niż poręcz, o której można dyskutować.
Specyficzne możliwości tych warstw wysyłki decydują o wadze wyników. W notatce napisano, że wady Vercel mogą dotrzeć do narzędzi udostępnianych przez hosta, w tym do wyszukiwania tajnych informacji, operacji wdrażania i wywołań API w chmurze. Wada Google jest jeszcze bardziej wyraźna: umożliwiała dotarcie sfałszowanych potwierdzeń do narzędzi celowo umieszczanych poza aprobatą człowieka, co jest rezerwą organizacji kontrolujących dla działań uznawanych za zbyt istotne, aby je zautomatyzować. Obejście, które w szczególności neutralizuje etap „człowiek w pętli”, podważa łagodzenie, które wiele zespołów przytacza, uzasadniając szerszą autonomię agentów.
Historia łatki ilustruje także asymetrię, która będzie się powtarzać w miarę rozprzestrzeniania się narzędzi agentowych. Klienci w pełni zarządzanej usługi AWS zostali naprawieni bez podejmowania jakichkolwiek działań. Zespoły korzystające z pakietu ADK Google lub pakietów wiązki przewodów Vercel we własnych środowiskach muszą zapoznać się z poradą, zaktualizować zależności i ponownie wdrożyć — a aktualizacje zależności w stosach produkcyjnych rutynowo opóźniają się o tygodnie lub miesiące. Ta sama luka w projekcie ma zatem bardzo różne praktyczne okna ekspozycji w zależności od tego, czy organizacja wykorzystuje infrastrukturę agenta jako usługę, czy też dostarcza ją do własnej bazy kodu.
Istnieje również luka w wykrywaniu. W notatce zauważono, że monitorowanie bezpieczeństwa systemów agentowych zasadniczo skupiało się na danych wejściowych i wyjściowych modelu — rejestrowaniu monitów, oznaczaniu podejrzanych uzupełnień i sprawdzaniu, jakie narzędzia wybrał model. Gdy narzędzie jest wykonywane bez uruchomionego modelu, nie istnieją żadne z tych artefaktów, które można zarejestrować. Kilka ważnych rzeczy pozostaje nieznanych: notatka nie podaje żadnych dowodów wykorzystania w środowisku naturalnym, nie podaje szacunkowej liczby wdrożeń, na które miało to wpływ, i nie opisuje kodu sprawdzającego koncepcję. CSA szczerze przyznaje, że dwa ujawnienia od czterech dostawców nie potwierdzają prawidłowości występującej w całej branży oraz że zaobserwowany gradient dotkliwości to jeden punkt danych, a nie reguła punktacji.
Mechanizm interaktywny: jak to faktycznie działa
Poznaj interaktywnie technologię leżącą u podstaw tego rozwoju.
crm_get_transaction(id='4092').What most distinguishes an AI agent from a basic chatbot?
Co obejrzeć dalej
Niezależnie od tego, czy operatorzy samodzielnie hostowani faktycznie stosują aktualizacje pakietów Google i Vercel, czy podobne luki w pochodzeniu pojawiają się w innych strukturach agentów, czy zgłaszane są jakiekolwiek przypadki wykorzystania w środowisku naturalnym i czy dostawcy przechodzą na podpisane, powiązane z sesją tokeny autoryzacyjne w celu wykonania narzędzia.
Najbardziej konkretną kwestią krótkoterminową jest wykorzystanie łatek. Zarządzaną poprawkę AWS opisano jako już wdrożoną, ale pakiet ADK 2.5.0 i dwie wersje wiązki przewodów Vercel pomagają jedynie operatorom, którzy je instalują. Uważaj na sygnały z dalszego łańcucha — współczynniki przyjęcia rejestru pakietów, forki od dostawców, które nigdy nie pobierają aktualizacji, oraz wewnętrzne obrazy platform, które przypinają starsze wersje. W notatce zaleca się również sprawdzenie retrospektywne: przejrzenie dzienników pod kątem wywołań narzędzi, których nie można powiązać z odpowiednim, dobrze sformułowanym zakończeniem modelu w zapisie sesji. To, czy organizacje mają telemetrię warstwy dyspozytorskiej do przeprowadzenia tego sprawdzenia, samo w sobie nie jest rozwiązane.
Drugie pytanie dotyczy zakresu. CoreBreak obejmuje trzy produkty, ale opisany wzorzec – zaufanie kształtowi ładunku lub wierszowi poleceń procesu jako dowód autoryzacji modelu – nie jest dla nich specyficzny. Dowolna platforma o tej samej strukturze od SDK do modelu do narzędzia może wykazywać porównywalną lukę. Zwróć uwagę na dalsze porady od innych opiekunów platformy agentów oraz na to, czy badacze opublikują pełniejsze szczegóły techniczne po prezentacji Black Hat. Dodatkowe potwierdzone przypadki wzmocniłyby argument CSA, że jest to wzorzec strukturalny, a nie trzy przypadkowe błędy.
Po trzecie, obserwuj reakcję architektoniczną. Zaleceniem CSA jest wymaganie kryptograficznego dowodu, że wywołanie narzędzia pochodzi z rzeczywistego ukończenia modelu — podpisanego, powiązanego z sesją, jednorazowego tokena — zamiast wnioskować o autoryzacji na podstawie struktury komunikatu lub tożsamości procesu. To, czy główni dostawcy przyjmą ten model i czy stanie się on czymś, o co kupujący będą mogli poprosić i zweryfikować podczas zamówienia, zadecyduje, czy ujawnienie to powoduje zmianę projektów, czy jedynie produkcję łatek. Logika przetwarzania potwierdzeń, która sprawdza własność narzędzia, wymagania dotyczące potwierdzeń i integralność argumentów w stosunku do oryginalnie nagranego wywołania, jest węższą wersją tej samej poprawki.
Na koniec przyjrzyj się ścieżkom zarządzania i analizy zagrożeń. CSA wskazuje na platformę modelowania zagrożeń MAESTRO i AI Controls Matrix v1.1 jako miejsca, w których oceny kontroli wykonania i zarządzania uprawnieniami powinny teraz wyraźnie obejmować wysyłkę narzędzi, i łączy CoreBreak z wcześniejszymi badaniami GuardFall nad obwodnicami poręczy na poziomie powłoki. Warto również monitorować: czy wpisy NVD lub wyniki CVSS są weryfikowane, czy dostawcy publikują szczegóły po incydencie poza początkowymi biuletynami i czy pojawiają się jakiekolwiek potwierdzone przypadki wykorzystania. Żadne z czterech CVE nie prowadzi obecnie publicznego raportu na temat znęcania się w naturze w materiale przytoczonym przez CSA, a brak takich raportów nie jest równoznaczny z brakiem aktywności.