Claude Mythos от Anthropic находит уязвимости нулевого дня

В 2024 году исследователи из Университета Иллинойса выяснили, что GPT-4 при предоставлении описания уязвимости из базы Common Vulnerabilities and Exposures (CVE) способна автономно проэксплуатировать 87% тщательно отобранного набора данных, состоящего из 15 уязвимостей типа «один день» (one-day). Без описания этот показатель составлял всего 7%. Это обеспечивало для индустрии определенный «запас прочности», поскольку ИИ мог эксплуатировать уже известные уязвимости, но не умел их находить.

Однако 7 апреля компания Anthropic объявила, что модель Claude Mythos Preview свела этот запас на нет: она автономно обнаружила тысячи уязвимостей нулевого дня в основных операционных системах и браузерах. Кроме того, Mythos набрала 83,1% на бенчмарке воспроизведения уязвимостей CyberGym. В ходе одной из кампаний, нацеленной на OpenBSD и включавшей 1 000 тестовых прогонов, общие затраты на вычисления составили менее 20 000 долларов.

Временные интервалы эксплуатации сокращаются. Уязвимость CVE-2026-33017 в Langflow (с оценкой CVSS 9.8) была проэксплуатирована через 20 часов после раскрытия при отсутствии публичного концепта атаки (PoC). Уязвимость CVE-2026-39987 в Marimo (CVSS 9.3) «упала» всего через 9 часов и 41 минуту.

Защитная инфраструктура, на которую полагается большинство организаций, не была рассчитана на такие условия. Отчет Rapid7 о ландшафте угроз за 2026 год гласит, что медианное время от публикации CVE до внесения уязвимости в каталог известных эксплуатируемых уязвимостей CISA (KEV) составляет пять дней. Отчет Google M-Trends за 2026 год показал, что эксплуатация происходит еще до того, как успевает выйти патч. Когда было опубликовано предупреждение по Langflow, первый эксплойт появился через 20 часов. При публикации бюллетеня по Marimo на это ушло менее 10 часов.

Предположение о том, что ваше окно для установки патчей находится в безопасности, поскольку эксплуатация требует времени, больше не актуально. Вот базовые строительные блоки для защиты.

Замените приоритизацию исключительно по шкале CVSS трехуровневым фильтром

Большинство программ управления уязвимостями по-прежнему определяют приоритеты только на основе оценки CVSS. CVSS оценивает «теоретическую» серьезность уязвимости без учета того, эксплуатируется ли она «в дикой природе» или как быстро ее можно превратить в оружие. Уязвимость с CVSS 8.8 и историей активной эксплуатации (например, CVE-2026-34040 для Docker) получает более низкий приоритет, чем уязвимость с CVSS 9.8, которая, возможно, никогда не будет использована на практике.

Недавнее исследование, проверенное на 28 377 реальных уязвимостях, предлагает конкретную замену: дерево решений, состоящее из трех уровней, которое включает статус в каталоге CISA KEV, оценки системы прогнозирования эксплойтов (EPSS) и CVSS, образуя единый фильтр приоритизации.

Трехуровневый фильтр приоритизации уязвимостей

Подтвержденный результат: рост эффективности в 18 раз, охват эксплуатируемых уязвимостей на уровне 85,6%, сокращение срочного объема работ по исправлению примерно на 95%. Все три источника данных являются открытыми и бесплатными.

Описанная интеграция полностью поддается автоматизации. Можно написать скрипт, который будет отправлять запросы к API CISA KEV, API EPSS от FIRST.org и NVD, а затем запускать этот скрипт для сверки с вашим инвентарем активов по каждой опубликованной CVE. Человек в этом процессе должен оставаться в контуре управления в роли утверждающего лица, но не триггера.

Ликвидируйте разрыв в авторизации агентов

Быстрое создание эксплойтов меняет не только подход к приоритизации патчей, но и настройку средств контроля для всех агентских систем, которые теперь обладают привилегированными учетными данными. Ваши политики авторизации не проверялись на соответствие поведению агентов на базе ИИ, и теперь это поддающийся измерению риск. CVE-2026-34040 показала, что архитектура плагинов авторизации Docker незаметно обходит любой плагин, если тело запроса превышает 1 МБ. Популярные плагины авторизации (OPA, Casbin, Prisma Cloud) не знают об этом типе обхода, который происходит в мидлваре Docker до того, как запрос достигает плагина.

Когда компания Cyera продемонстрировала эту уязвимость, она показала, что инфраструктура отладки на базе ИИ-агента может вычислить путь обхода при выполнении легитимной задачи без каких-либо инструкций по эксплуатации уязвимостей.

Инженерный совет Интернета (IETF) работает над моделями авторизации для агентов. В документе draft-klrc-aiagent-auth-01, опубликованном в марте участниками из AWS, Zscaler, Ping Identity и OpenAI, предлагается использовать существующие спецификации SPIFFE (Secure Production Identity Framework for Everyone) и OAuth 2.0, чтобы ИИ-агенты могли получать динамически выделяемые и недолговечные учетные данные.

Кроме того, в черновике стандарта IETF Agent Identity Protocol (draft-prakash-aip-00) сообщается, что из примерно 2 000 исследованных серверов протокола контекста моделей (MCP) аутентификации не было ни у одного.

Однако до внедрения этих стандартов пройдут месяцы или даже годы. В текущих условиях команды безопасности должны заблаговременно внедрять тестовые сценарии на уровне агентов для всех границ авторизации — такие как слишком большие запросы, высокая частота отправки пакетов (burst frequency) и многоэтапная эскалация привилегированных запросов.

Составьте карту радиуса поражения учетных данных

Согласно исследованию CSA/Zenity, опубликованному 16 апреля, 53% организаций заявили, что уже сталкивались с ситуациями, когда ИИ-агенты выходили за рамки предназначенных им прав, а 47% столкнулись с инцидентами безопасности с участием агентов.

Когда такие инструменты для создания ИИ-систем, как Flowise (CVE-2025-59528, CVSS 10.0), Langflow или n8n, оказываются скомпрометированными, радиус поражения выходит далеко за рамки хоста. Эти инструменты содержат ключи API к передовым моделям, учетные данные баз данных, токены векторных хранилищ и токены OAuth к бизнес-системам. Компрометация хоста ИИ-конструктора — это не просто взлом отдельной системы. Это сбор учетных данных, открывающий аутентифицированный доступ ко всем подключенным сервисам.

Без карт зависимостей учетных данных для каждого хоста ИИ-инструментов реагирование на инциденты при компрометации агентов превращается в угадайку. Для каждого экземпляра задокументируйте все учетные данные, степень их доступа и соответствующий процесс ротации учетных данных. Также начните переводить статические ключи API в недолговечные токены везде, где это поддерживают нисходящие сервисы.

Пять шагов на текущий квартал

1. Разверните трехуровневый фильтр KEV-EPSS-CVSS

Замените приоритизацию исключительно по CVSS в соответствии с таблицей выше. Автоматизируйте сбор данных со всех трех API в рамках запланированного скрипта, выполняемого по вашей инвентаризации активов. Желаемый результат: рост эффективности в 18 раз, покрытие эксплуатируемых уязвимостей на уровне 85,6%, сокращение срочного объема работ по устранению на 95%.

2. Внедрите управление патчами на основе событий для сервисов нулевого уровня.

Определите, какие службы относятся к уровню критического воздействия: сервисы, напрямую доступные пользователям интернета, хосты ИИ-конструкторов и плоскость управления оркестрацией контейнеров. Запускайте установку патчей по событию в момент публикации CVE, не дожидаясь следующего окна технического обслуживания для этого уровня.

Цель: развернуть патч в тестовой среде (canary) в течение четырех часов после объявления CVE критической. Используйте каналы CISA KEV и EPSS для инициирования патчинга по событиям. В ситуациях, когда выполнение четырехчасовой цели невозможно из-за устаревших зависимостей, окон заморозки изменений или риска отката, немедленно примените компенсирующие меры: отключите доступ к уязвимому сервису из интернета, выполните ротацию учетных данных для уязвимого сервиса, отключите затронутую функциональность сервиса (если применимо) и назначьте ответственного за исключение для данной зоны риска до тех пор, пока патч не будет развернут.

Недопустимо допускать неограниченное пребывание в зоне риска в течение длительного времени в ожидании окна техобслуживания.

3. Протестируйте границы авторизации в масштабе агентов.

Создайте тестовые сценарии для каждого API, с которым ИИ-агенты могут взаимодействовать посредством политик AuthZ. В частности, включите тесты для запросов с размером тела более 1 МБ, 5 МБ и 10 МБ. Сюда входят тесты на частоту пакетов > 100 запросов в секунду и тесты на необычные комбинации параметров (привилегированные флаги, монтирование хоста, добавление возможностей). Кроме того, установите патч для Docker Engine версии 29.3.1 для устранения CVE-2026-34040.

4. Составьте карту радиуса поражения учетных данных для всех хостов ИИ-конструкторов.

Задокументируйте все учетные данные для каждого экземпляра Langflow, Flowise, n8n и пользовательских конвейеров ИИ. Классифицируйте каждую учетную запись по ее жизненному циклу (статический ключ против недолговечного токена). Определите, к чему имеют доступ эти учетные данные. Настройте оповещения об аномальных IP-адресах или идентификаторах при любом доступе по учетным данным.

5. Проведите сканирование для обнаружения теневого ИИ на этой неделе.

Согласно данным CSA, вероятность того, что ваши агенты вышли за рамки ожидаемых границ, превышает 50%. Проверьте свои инструменты SIEM (управления информацией и событиями безопасности) и сетевого мониторинга на предмет коммуникации со стандартными портами ИИ-конструкторов: Langflow (7860), Flowise (3000) и n8n (5678). Любые неавторизованные экземпляры представляют собой неконтролируемую поверхность атаки.

Итоги

ИИ-агенты развиваются, и стандартизирующие организации реагируют на это. IETF выпустила несколько черновиков, касающихся аутентификации и авторизации агентов. Коалиция за безопасный ИИ (COSAI) опубликовала свою таксономию безопасности протокола контекста моделей (MCP) и принципы безопасного проектирования (Secure-by-Design).

Тем не менее, эти стандарты движутся со скоростью бюрократических комитетов, в то время как окно для эксплуатации теперь измеряется часами. Организации, которые внедрят трехуровневый фильтр и патчинг по событиям в текущем квартале, смогут добиться заметного снижения рисков. Те же, кто будет выжидать, продолжат жить в режиме календарных циклов обновлений, борясь с противником, который действует менее чем за 20 часов. 

Ник Кейл (Nik Kale) — главный инженер, специалист по корпоративным платформам ИИ и безопасности

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций — это площадка, где технические эксперты делятся идеями и публикуют независимые, неангажированные аналитические материалы об искусственном интеллекте, инфраструктуре данных, кибербезопасности и других передовых технологиях, формирующих будущее корпоративного сектора.

Читайте далее материалы нашей программы гостевых публикаций — а также ознакомьтесь с нашими рекомендациями, если вы хотите предложить собственную статью!