Що сталося
6 серпня 2026 року Cloud Security Alliance опублікував дослідницьку записку, в якій описується CoreBreak, набір із чотирьох CVE у фреймворках агентів AWS, Google і Vercel, у яких рівень диспетчеризації інструментів виконує виклик інструменту, не перевіряючи, чи його справді створила мовна модель. Усі чотири мають виправлення постачальника.
Ініціатива безпеки штучного інтелекту Cloud Security Alliance опублікувала 6 серпня 2026 року дослідницьку записку, в якій описується кросплатформна модель уразливості, яку дослідники назвали CoreBreak. Згідно з приміткою, дослідники безпеки Хеді Інгбер і Авіям Івгі, співзасновники охоронної фірми Stealth, представили результати на Black Hat USA 2026, які показують, що рівні виконання інструментів Amazon Bedrock AgentCore, Google's Agent Development Kit (ADK) для Python і пакети джгутів, що розповсюджуються з Кожен SDK для штучного інтелекту Vercel може бути змушений запускати інструмент без будь-якого законного повороту моделі. Оскільки мовна модель ніколи не використовувалася, стверджується в примітці, огорожі, побудовані навколо моделі, не мали рішення про втручання.
Структури агентів такого типу мають спільну структуру. Рівень оркестровки збирає запит користувача, системну підказку, історію розмов і каталог доступних інструментів, надсилає їх до мовної моделі та чекає, поки модель поверне структуровану інструкцію з назвою інструменту та його аргументів. Потім SDK надсилає відповідну функцію, сценарій або виклик API і повертає результат назад у діалог. CoreBreak націлений на останній крок: згідно з приміткою, логіка відправлення в кожному з трьох продуктів розглядала дані, які просто нагадували виклик інструменту, створений моделлю, як авторитетні, не перевіряючи, звідки вони надійшли.
У примітці наведено чотири ідентифікатори CVE з різними шляхами використання, цитуючи бюлетені постачальників і записи національної бази даних уразливостей. AWS призначив CVE-2026-18830 (CVSS v4.0 8.6, High) дефекту збруї Bedrock AgentCore, де автентифікований віддалений абонент міг розмістити блок вмісту використання інструменту безпосередньо в останньому повідомленні запиту API InvokeHarness. Google присвоїв CVE-2026-18236 (9.3, критичний) дефекту ADK, у якому зловмисник, здатний впровадити події в історію сеансу, міг підробити підтвердження схвалення людиною, оскільки процесор підтвердження не перевірив, чи цільовий інструмент належить виконавцю, що він справді потребує підтвердження або чи його ім’я та аргументи збігаються з оригінальним записаним викликом. @ai-sdk/harness-codex і @ai-sdk/harness-opencode від Vercel отримали CVE-2026-64650 і CVE-2026-64651 (6.3, середній кожен), де зловмисний код, який уже працює всередині пісочниці Linux, міг задовольнити перевірку шляху процесу, яка довіряла будь-якому процесу, командний рядок якого містив шлях до затвердженого допоміжний скрипт.
Виправлення доступні, але навантаження залежить від моделі розгортання. У примітці сказано, що виправлення AWS для повністю керованого Bedrock AgentCore InvokeHarness API було розгорнуто автоматично до 31 липня 2026 року та не потребувало жодних дій від клієнта, хоча воно все ще рекомендує підтвердити покриття для певного регіону та конфігурації. Виправлення Google було надіслано в ADK для Python версії 2.5.0 16 липня 2026 р., а виправлення Vercel надіслано в harness-codex 1.0.29 і harness-opencode 1.0.28 10 липня 2026 р. — оновлення пакетів, які повинні виконувати оператори, що розміщуються самостійно застосовувати себе. У примітці CoreBreak відрізняється від швидкого впровадження: миттєве впровадження намагається маніпулювати судженням моделі, тоді як CoreBreak обходить питання про те, чи застосовувала модель взагалі рішення.
Деталі джерела: labs.cloudsecurityalliance.org ↗
Чому це важливо
Фільтри вмісту, системні підказки, навчання відмові та шлюзи схвалення людиною – все це припускає, що модель є стороною, яка вирішує, чи запускається інструмент. Якщо рівень диспетчеризації приймає щось у формі виклику інструменту моделі, ці елементи керування обходяться, а не втрачаються — і групи моніторингу журналів, які зазвичай перевіряють, ніколи не створюються.
Більшість корпоративних елементів керування для агентського штучного інтелекту розташовано на моделі або навколо неї. Системні підказки обмежують конфіденційні дії, фільтри вмісту оцінюють вхідні та вихідні дані, навчання відмовам записується в модельні ваги, а кроки підтвердження людиною виключають інструменти з високим ризиком. Кожен із цих елементів керування передбачає, що модель є стороною, яка вирішує, чи запускається інструмент. Якщо рівень диспетчеризації буде виконувати будь-яке корисне навантаження, яке має правильну форму, ці інвестиції забезпечують слабкий профілактичний захист — не тому, що вони були погано розроблені, а тому, що маршрути атаки обходять місце, де вони працюють. Це відмінний клас проблем від огорожі, про яку можна сперечатися.
Конкретні можливості, що стоять за цими рівнями відправлення, ось що надає ваги знахідці. У примітці сказано, що недоліки Vercel можуть поширюватися на інструменти, які виявляють на хості, включаючи секретні пошуки, операції розгортання та виклики хмарного API. Помилка Google є ще більш гострою: вона дозволила підробленим підтвердженням отримати доступ до інструментів, навмисно розміщених за схваленням людини, що є резервом контрольних організацій для дій, які вважаються надто значними для автоматизації. Обхід, який спеціально нейтралізує крок людини в циклі, підриває пом’якшення, на яке посилаються багато команд, виправдовуючи ширшу автономію агента.
Історія виправлення також ілюструє асиметрію, яка повторюватиметься в міру поширення засобів агента. Клієнти повністю керованої служби AWS були виправлені без жодних дій. Команди, які використовують пакети засобів розробки Google або Vercel у власному середовищі, повинні звернути увагу на пораду, оновити залежність і повторно розгорнути — а оновлення залежностей у виробничих стеках зазвичай затримуються на тижні або місяці. Таким чином, одна і та ж базова прогалина в дизайні має дуже різне практичне вікно експозиції залежно від того, використовує організація інфраструктуру агента як послугу чи постачальників її у власну кодову базу.
Також є прогалина у виявленні. У примітці зазначається, що моніторинг безпеки для агентських систем, як правило, зосереджений на вхідних і вихідних даних моделі — реєстрація підказок, позначення підозрілих завершень, перегляд інструментів, які обрала модель. Коли інструмент виконується без запущеної моделі, жоден із цих артефактів не існує для реєстрації. Кілька важливих речей залишаються невідомими: у примітці не повідомляється про докази використання в дикій природі, не дається оцінка кількості розгортань, які постраждали, і не описується код для підтвердження концепції. CSA відверто каже, що два розкриття інформації чотирма постачальниками не підтверджують загальногалузеву закономірність і що спостережуваний градієнт серйозності є одним пунктом даних, а не правилом оцінки.
Інтерактивний механізм: як він насправді працює
Дослідіть технологію, що лежить в основі цієї розробки, в інтерактивному режимі.
crm_get_transaction(id='4092').What most distinguishes an AI agent from a basic chatbot?
Що дивитися далі
Чи дійсно оператори, які розміщені на власному хості, застосовують оновлення пакетів Google і Vercel, чи виникають подібні прогалини походження в інших фреймворках агентів, чи повідомляється про будь-яку експлуатацію в дикій природі та чи переходять постачальники на підписані маркери авторизації, прив’язані до сеансу, для виконання інструменту.
Найбільш конкретне найближче питання – це застосування патча. Кероване виправлення AWS описано як уже розгорнуте, але ADK 2.5.0 і два випуски джгута Vercel допомагають лише операторам, які їх встановлюють. Слідкуйте за вихідними сигналами — темпами впровадження реєстру пакетів, розгалуженнями постачальників, які ніколи не витягують оновлення, і внутрішніми образами платформи, які закріплюють старіші версії. У примітці також рекомендовано ретроспективну перевірку: перегляд журналів для викликів інструментів, які не можна прив’язати до відповідного, добре сформованого завершення моделі в записі сеансу. Чи мають організації телеметрію диспетчерського рівня для виконання такої перевірки, само по собі не вирішено.
Друге питання – обсяг. CoreBreak охоплює три продукти, але описаний шаблон — довіряти формі корисного навантаження чи командному рядку процесу як доказ авторизації моделі — не є специфічним для них. Будь-який фреймворк з однаковою структурою SDK-модель-інструмент може містити порівнянний пробіл. Слідкуйте за подальшими порадами від інших супроводжувачів фреймворку агентів і за тим, чи опублікують дослідники повніші технічні деталі після презентації Black Hat. Додаткові підтверджені випадки посилять аргумент CSA про те, що це структурна модель, а не три випадкові помилки.
По-третє, спостерігайте за архітектурною реакцією. Рекомендація CSA полягає в тому, щоб вимагати криптографічного підтвердження того, що виклик інструменту походить від реального завершення моделі — підписаного, прив’язаного до сеансу, одноразового токена — замість того, щоб виводити авторизацію зі структури повідомлення чи ідентифікації процесу. Від того, чи приймуть цю модель основні постачальники, і чи стане вона чимось, що покупці можуть запитати та перевірити під час закупівлі, визначатиме, чи це розкриття змінить дизайн чи створить лише виправлення. Логіка обробки підтвердження, яка перевіряє право власності на інструмент, вимогу підтвердження та цілісність аргументів щодо вихідного записаного виклику, є вужчою версією того самого виправлення.
Нарешті, подивіться треки управління та аналізу загроз. CSA вказує на свою структуру моделювання загроз MAESTRO та матрицю AI Controls v1.1 як на місця, де оцінки контролю виконання та управління привілеями тепер повинні явно охоплювати відправку інструментів, і пов’язує CoreBreak зі своїм попереднім дослідженням GuardFall щодо обходу огорожі на рівні оболонки. Також варто відстежувати: чи переглядаються записи NVD або оцінки CVSS, чи публікують постачальники подробиці після інциденту поза початковими бюлетенями та чи з’являється підтверджене використання. Наразі жоден із чотирьох CVE не містить публічного звіту про жорстоке поводження в природі в матеріалах, на які посилається CSA, і відсутність таких звітів не означає відсутність діяльності.