Первый день Pwn2Own Berlin поставил AI-инструменты для разработчиков и локальные inference-стеки под такое же давление, какое давно применяют к браузерам и операционным системам. Для команд безопасности это полезный сигнал: теперь есть свежие доказательства того, где исследователи уже показывают эксплуатацию, даже если вендорские бюллетени и патчи еще не вышли.
Источник: Zero Day Initiative Blog — https://www.thezdi.com/blog/2026/5/13/pwn2own-berlin-2026-day-one-results
Что изменилось#
Zero Day Initiative сообщила о 22 заявках в первый день Pwn2Own Berlin 2026. Целями стали AI Databases, Coding Agents, Local Inferences, продукты NVIDIA, браузеры и операционные системы. По данным ZDI, после первого дня было выплачено $523,000 за 24 уникальных zero-day.
Самый сильный одиночный результат показал Orange Tsai из DEVCORE Research Team: он связал четыре логические ошибки и добился sandbox escape в Microsoft Edge. За это он получил $175,000 и 17.5 очка Master of Pwn. По данным ZDI, DEVCORE завершила день лидером в зачете Master of Pwn.
Направление AI и инструментов разработки оказалось насыщенным. Compass Security проэксплуатировала OpenAI Codex через одну ошибку CWE-150. Отдельная заявка Doyensec по OpenAI Codex была успешно показана на сцене, но ZDI уточнила, что ошибка уже была известна вендору. Anthropic Claude Code также успешно атаковали исследователи Viettel Cyber Security; эту ошибку ZDI тоже описала как ранее известную вендору.
Локальный inference и AI-инфраструктура тоже получили удары. LiteLLM проэксплуатировали цепочкой, куда входили SSRF и Code Injection. LM Studio взломали через цепочку из пяти ошибок, также включавшую SSRF и Code Injection. Chroma проэксплуатировали цепочкой из двух ошибок с CWE-190 и CWE-362.
Цели, связанные с NVIDIA, встречались в нескольких заявках. IBM X-Force Offensive Research проэксплуатировала NV Container Toolkit через одну ошибку. NVIDIA Megatron Bridge атаковали через слишком разрешающий allow list, проблему CWE-470, а позже — через path traversal в отдельной попытке.
Классические платформы никуда не исчезли. Для Microsoft Windows 11 показали несколько повышений привилегий, включая improper access control, heap-based buffer overflow и цепочку use-after-free. Red Hat Enterprise Linux for Workstations проэксплуатировали через race condition. Часть заявок не уложилась в отведенное время, несколько были отозваны.
Почему этот сигнал важен для безопасности#
Pwn2Own — не обычная лента security advisory. В день конкурса она не дает защитникам номера CVE, ссылки на патчи или детали эксплойтов. Ценность в другом: конкурс показывает, какие классы продуктов уже ломают сильные исследователи в условиях соревнования и какие поверхности атаки достаточно созрели, чтобы за них брались всерьез.
Итоги первого дня в этом году сложно игнорировать командам, которые используют AI-ассистентов разработки, локальные inference-инструменты, AI-базы данных или инфраструктуру рядом с NVIDIA. Во многих средах это уже не боковые эксперименты. Такие системы касаются исходного кода, секретов, файлов моделей, внутренних API, экосистем плагинов и рабочих станций разработчиков.
Это меняет операционный риск. Coding agent с широким доступом к репозиторию — не просто еще одна вкладка SaaS. Локальный inference-стек с мягкими сетевыми ограничениями — не просто инструмент продуктивности. Container toolkit или компонент AI-фреймворка может находиться рядом с системами сборки, GPU-нагрузками и привилегированными границами хоста.
Важны и цепочки эксплуатации. SSRF и Code Injection в продуктах вокруг AI — не экзотика. Это знакомые проблемы веб- и прикладной безопасности, которые теперь появляются в новых слоях оркестрации. Path traversal, ошибки контроля доступа, race conditions, небезопасная работа с типами или reflection — тоже не новые классы багов. Новизна в контексте: эти ошибки находят в системах, которые организации могли внедрить быстрее, чем успели укрепить.
Для безопасности open source урок не в том, что open source якобы слабее. Урок в другом: доступность исходного кода не заменяет операционные проверки. Командам все равно нужны инвентаризация активов, дисциплина патчей, проверка экспонирования, отслеживание зависимостей и ясная модель доверия для инструментов, которые исполняют код или работают с данными разработчиков.
Подробнее о том, как превращать артефакты безопасности в рабочие процессы, см. предыдущую заметку GigaTap: апрельский сигнал OpenSSF: сделать артефакты безопасности операционными.
Что проверить перед действиями#
Воспринимайте пост ZDI как раннее предупреждение, а не как полный план исправлений. Первая задача — понять собственное экспонирование.
Начните с инвентаризации. Проверьте, используются ли в вашей среде продукты, названные в результатах первого дня: Microsoft Edge, Microsoft Windows 11, Red Hat Enterprise Linux for Workstations, OpenAI Codex, Anthropic Claude Code, LiteLLM, LM Studio, Chroma, NV Container Toolkit, NVIDIA Megatron Bridge и Oracle Autonomous AI Database. В списке ZDI есть и попытки, которые не удались или были отозваны, поэтому не превращайте каждое упоминание цели в подтвержденную уязвимость.
Затем отделите факт использования от реального экспонирования. Инструмент, запущенный разработчиком локально на изолированной тестовой машине, несет один риск. Общий сервис, доступный из внутренних сетей, — другой. Coding agent с доступом только на чтение отличается от агента, который может писать код, запускать команды или получать учетные данные. GPU container stack на рабочей станции — не то же самое, что такой же стек в production CI или общей исследовательской инфраструктуре.
Для security operations полезны такие проверки:
- Определите, развернуты ли затронутые продукты, тестируются ли они или разрешены политикой.
- Проверьте, запускаются ли они с повышенными привилегиями или широким доступом к файловой системе.
- Пересмотрите сетевое экспонирование локальных inference-сервисов и AI-баз данных.
- Найдите пути, важные для SSRF: URL fetchers, connectors, plugins, model importers и proxy features.
- Проверьте, не раскрываются ли секреты через coding agents, build scripts, локальные конфигурационные файлы и environment variables.
- Отслеживайте бюллетени вендоров после того, как раскрытия Pwn2Own пройдут coordinated disclosure.
- Подготовьте окна патчей для продуктов с подтвержденными исправлениями от вендоров, но не делайте аварийные изменения только из-за того, что продукт был целью конкурса.
Для команд разработки самый практичный вопрос звучит просто: что этот инструмент может читать, записывать, исполнять и отправлять по сети? Если ответ размытый, модель риска тоже размыта.
Особенно это важно для локальных AI-инструментов. Многие команды считают локальный inference более безопасным, потому что данные не уходят облачному провайдеру моделей. Для приватности в одном направлении это может быть верно. Но это не снижает автоматически риск эксплуатации, компрометации хоста или lateral movement, если локальный сервис открыт в сеть или работает с избыточными правами.
Чего не стоит утверждать#
Пост ZDI не означает, что все названные продукты уже эксплуатируются in the wild. Он не дает публичный exploit code. Он не доказывает, что каждая проблема еще не исправлена. Некоторые успешные демонстрации использовали ошибки, уже известные вендору. Некоторые заявки не уложились в отведенное время. Некоторые были отозваны.
Также этих данных недостаточно, чтобы назначить серьезность внутри конкретной организации. Sandbox escape в браузере, повышение привилегий в операционной системе и code injection в AI-инструменте оркестрации дают разные последствия в зависимости от развертывания, поведения пользователей, границ привилегий и компенсирующих мер.
Правильная позиция — не паника и не отмахивание. Pwn2Own сжимает месяцы security research в публичную таблицу результатов. Эта таблица не заменяет план патчей, но дает сильную подсказку для приоритизации. Если категория продуктов снова и снова появляется на этой сцене, защитникам стоит исходить из того, что сильные исследователи смотрят туда, потому что поверхность атаки стоит времени.
Практический вывод#
Командам безопасности стоит использовать первый день Pwn2Own как триггер для операционных проверок вокруг AI-инструментов, developer agents, локальных inference-сервисов и инфраструктуры, связанной с NVIDIA. Подтвердите, что развернуто. Уберите лишние привилегии. Ограничьте сетевое экспонирование. Следите за каналами вендоров, где появятся CVE и патчи. Задокументируйте, какие инструменты имеют доступ к коду, учетным данным, моделям и внутренним сервисам.
Более широкий вывод стал четче: AI-инфраструктура теперь обычная инфраструктура. Ей нужны те же патчи, управление экспонированием и дисциплина security operations, что браузерам, операционным системам и container platforms. Результаты конкурса не закрывают вопрос. Они показывают, где начинать искать.