Источник: Zero Day Initiative Blog — https://www.thezdi.com/blog/2026/5/16/pwn2own-berlin-2026-day-three-results-and-master-of-pwn
Pwn2Own Berlin 2026 закончился сильным сигналом для команд безопасности: за три дня участники показали 47 уникальных 0-day и получили $1,298,250 призовых. Это не означает, что уже появились 47 срочных патчей. Это означает, что у вендоров, защитников и исследователей появился свежий набор подтвержденных путей эксплуатации, который теперь пройдет через раскрытие, исправления и бюллетени безопасности.
DEVCORE получила титул Master of Pwn с 50.5 балла и $505,000. STARLabs SG заняла второе место с 25 баллами и $242,500. Out Of Bounds стала третьей с 12.75 балла и $95,750. Но таблица лидеров важна меньше, чем разброс успешных атак: сразу несколько команд смогли довести реальные корпоративные цели от теории до показанной эксплуатации.
О чем на самом деле говорит Pwn2Own#
Пост Zero Day Initiative о третьем дне закрывает событие и фиксирует итоговый масштаб: 47 уникальных 0-day за три дня. Именно это число командам безопасности стоит поставить на первое место.
Результаты Pwn2Own находятся в неудобной, но важной фазе жизненного цикла уязвимости. Эксплойт уже показали по правилам конкурса. При этом у публики не обязательно есть полные технические детали. CVE может еще не быть. Патч может еще не выйти. Бюллетень безопасности от вендора может появиться позже, а финальная оценка серьезности может отличаться от того, что защитники предположили по итогам конкурса.
Поэтому это ранний сигнал о будущих бюллетенях, а не готовая инструкция по исправлению.
В третий день был как минимум один результат с пометкой «SUCCESS / COLLISION»: Sina Kheirkhah из Summoning Team использовал две ошибки для эксплуатации Red Hat Linux, но одна из них уже была известна. Награда все равно засчиталась, но в уменьшенном размере: $7,000 и 1.5 балла Master of Pwn. Это важная деталь: результаты Pwn2Own нельзя читать как чистый список полностью новых и одинаково готовых к эксплуатации уязвимостей. В некоторых цепочках есть уже известные компоненты. Некоторые находки пересекаются с прежними отчетами. Какие-то исправления могут уже готовиться.
В исходном материале также упомянута успешная попытка исследователей из Viettel Cyber, но доступный фрагмент источника обрывается до полных данных о цели и результате. Значит, повторять нужно только то, что есть в источнике. Если точного продукта, класса ошибки или цепочки эксплуатации в доступном фрагменте нет, не стоит заполнять пробелы по памяти или догадкам.
Почему это важно для команд безопасности#
Pwn2Own — не просто таблица результатов. Это стресс-тест предположений о корпоративном ПО, типовых развертываниях и разрыве между «достаточно защищено» и «эксплуатируется на практике».
Практическая работа начинается еще до появления CVE. Правильный шаг — заранее подготовить маршрут обработки: следить за бюллетенями вендоров, сопоставить затронутые продукты с внутренними владельцами и решить, какие системы потребуют ускоренного обновления, если выйдет подтвержденный бюллетень.
Особенно это важно для организаций, где работают открытые наружу или высокодоверенные системы из тех же семейств продуктов, которые были целями на конкурсе. Конкурсный эксплойт не означает, что уже идет массовая эксплуатация. Но он доказывает, что сильные исследователи нашли рабочий путь в контролируемых условиях. Когда появятся патчи и технические детали, окно между раскрытием и массовыми попытками эксплуатации может быстро сузиться.
Есть и риск для приватности. Корпоративные системы часто находятся рядом с учетными записями, рабочими процессами разработчиков, административными интерфейсами, внутренними документами и управлением конечными устройствами. Даже если ошибка не описана как проблема приватности, компрометация соседней системы может раскрыть логи, токены, файлы или открыть путь для бокового перемещения по сети. Контекст актива — часть риска, а не деталь на потом.
Для команд, отвечающих за безопасность open source, упоминание Red Hat Linux напоминает: видимость исходного кода не равна операционной безопасности. Open source дает возможность ревью, пересборки и downstream-проверок. Но он не отменяет отслеживание бюллетеней, дисциплину патчей и понятное владение системой, если уязвимость затрагивает развернутые сервисы. Доступ к исходникам помогает только тогда, когда кто-то следит за правильными сигналами и может действовать.
По теме в блоге GigaTap: OpenSSF’s April signal: make security artifacts operational, 100% package test coverage is the point, not the slogan и Open Source Security Needs More Than Code.
Что проверить перед действиями#
Не превращайте заголовок Pwn2Own в паническое обновление всего подряд. Превратите его в точный список наблюдения.
Начните с инвентаризации. Проверьте, используются ли в вашей среде продукты или платформы, названные в официальных постах ZDI и последующих бюллетенях вендоров. Назначьте владельца для каждого совпадения. Если у продукта внутри нет владельца, это первая операционная ошибка.
Затем проверьте статус бюллетеня:
- Вендор уже опубликовал бюллетень безопасности?
- Назначен CVE или проблема еще в состоянии pre-CVE?
- Есть патч, мера снижения риска или конфигурационный обходной путь?
- В бюллетене описаны удаленная эксплуатация, локальное повышение привилегий, выход из песочницы, требования к authentication или user interaction?
- Затронутый компонент доступен из интернета, только администраторам, только изнутри или изолирован?
- Есть логи или правила обнаружения, которые покажут подозрительную активность против этого компонента?
Возможность эксплуатации — не поле «да/нет». Успешный конкурсный эксплойт доказывает, что путь работает в контролируемой среде. Реальный риск зависит от предварительных условий, доступности поверхности атаки, надежности эксплойта, опубликованных деталей и скорости, с которой атакующие смогут воспроизвести цепочку.
Для патчей в первую очередь выбирайте системы, где сходятся три условия: подтвержденная затронутая версия, достижимая поверхность атаки и высокая бизнес-ценность или связь с учетными записями. Лабораторная система с низкой доступностью для атакующего не должна получать тот же приоритет, что внешний сервис, связанный с административными учетными данными.
Чего не стоит утверждать#
Финальное число Pwn2Own сильное: 47 уникальных 0-day. Но его нельзя раздувать до заявлений, которых нет в источнике.
Не утверждайте, что все 47 уже активно эксплуатируются в реальных атаках. В предоставленном источнике этого нет. Не утверждайте, что у каждой проблемы уже есть CVE, патч или публичный эксплойт. Не считайте, что каждая показанная цепочка ровно соответствует одной уязвимости. Пометка collision по Red Hat Linux показывает, почему такой ярлык ломается.
Также не воспринимайте призовые как прямую оценку серьезности. Награды зависят от правил конкурса, категорий целей, качества эксплойта и системы баллов. Они могут намекать на техническую ценность, но не заменяют CVSS, анализ вендора, доступность системы в вашей среде и компенсирующие меры защиты.
Более полезное прочтение выглядит так: Pwn2Own Berlin 2026 дал большой пакет подтвержденных исследований уязвимостей против корпоративных целей. Теперь ZDI и вендоры станут основными источниками деталей раскрытия. Командам безопасности стоит превратить событие в очередь бюллетеней для отслеживания, а не в патч-спринт на слухах.
Победители забрали таблицу. Защитникам нужна очередь.