Анонимный исследователь под ником Bikini опубликовал на GitHub репозиторий Exploitarium с описаниями и PoC-эксплоитами к десяткам уязвимостей нулевого дня. Сейчас в коллекции 31 каталог, а у 12 находок уже есть идентификаторы CVE.

Что произошло

По данным из самого репозитория, Bikini выкладывает материалы по уязвимостям в популярных проектах и не предупреждает разработчиков заранее. Исследователь обещает продолжать публикации и, судя по его словам, планирует добавлять примерно по одному новому PoC в день.

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

Как это сделано

Bikini говорит, что для поиска багов использовал фаззинг с помощью GPT-5.3 и строгий автоматизированный воркфлоу. Сами эксплоиты, по его словам, он писал вручную, хотя для части работ привлекал ИИ, а README-файлы и вовсе сгенерировал автоматически и потом проверил.

На практике это важная деталь: крупные модели не заменяют инфраструктуру, тестовые стенды и ручную проверку. Исследователь прямо утверждает, что ключевую роль сыграли именно процесс и среда, а не дорогая модель сама по себе.

Отдельный вопрос — качество самих материалов. СМИ уже отмечают, что не все записи в Exploitarium выглядят как собственные 0-day-находки Bikini. В таких списках легко смешиваются свежие баги, старые исследования и PoC, появившиеся уже после публикации исправлений.

Для понимания того, как быстро уязвимость из лаборатории превращается в реальную проблему, полезно посмотреть и на разбор активных атак на корпоративные продукты, и на материал о том, как группы-вымогатели используют легальные инструменты. В обоих случаях уязвимость сама по себе — только часть картины.

Кого затронуло и чем это грозит

В списке Exploitarium уже фигурируют 7-Zip, AnyDesk, curl, Docker, Firefox, FFmpeg, Ghidra, Gitea, Gogs, ImageMagick, libssh2, MyBB, Nmap, OpenVPN, PHP, QEMU, RustDesk и VLC. Для администраторов это не просто перечень громких имен, а набор продуктов, которые встречаются в рабочих средах, сборках и CI/CD-процессах.

Один из самых показательных примеров — CVE-2026-55200 в libssh2. Речь идет об ошибке в обработке packet_length: вредоносный SSH-сервер может передать слишком большое значение, вызвать целочисленное переполнение и добиться записи за пределы массива в хипе. В худшем случае это открывает путь к исполнению произвольного кода на стороне клиента.

Есть и другой опасный кейс — CVE-2026-58053 в Gitea act_runner с Docker-бэкендом. Если у атакующего есть возможность запускать CI/CD-воркфлоу, он может подсунуть опасные параметры контейнеру, обойти настройку privileged: false, выйти из контейнера и получить root-доступ к хосту.

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

Что делать сейчас

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

Стоит обновить систему мониторинга, пересмотреть правила доступа к CI/CD и проверить, не запускаются ли процессы с избыточными правами. Если в компании уже есть практика реагирования на новые CVE, сейчас самое время прогнать ее еще раз на живом списке сервисов.

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

Краткий чек-лист

  • Проверьте, есть ли в вашей среде 7-Zip, curl, Docker, Gitea, libssh2, QEMU и другие упомянутые продукты.
  • Сверьте версии с последними бюллетенями производителей и списками CVE.
  • Ограничьте права на запуск CI/CD-воркфлоу и проверьте настройки контейнеров.
  • Посмотрите журналы на признаки странных SSH-сессий, падений и нештатных прав доступа.
  • Обновите процессы реагирования на свежие уязвимости и назначьте ответственных.
  • Для рабочих подключений из внешних сетей используйте инструмент для приватной сетевой сессии как один из шагов защиты переписки и метаданных от пассивной слежки.
  • Проведите внутренний аудит зависимостей и сборочных окружений, если у вас есть собственные сервисы на этих компонентах.
Поделиться: