Анонимный исследователь выложил 0-day exploitarium с рабочими, по его словам, эксплойтами для 15 продуктов и open source-проектов, и как минимум две уязвимости уже пошли в атаку. Для русскоязычной IT-аудитории это не очередная страшилка про «нулевые дни», а вполне прикладной сигнал: self-hosted Git, SSH-библиотеки и привычный стек инфраструктуры снова оказались в зоне, где между публикацией PoC и реальной компрометацией проходит слишком мало времени.
Об этом сообщает The Register. По данным издания, аноним под ником bikini опубликовал в GitHub-репозитории exploitarium код и описания для zero-day-уязвимостей без предварительного уведомления вендоров и мейнтейнеров. Репозиторий уже удален, но главный неприятный факт в другом: часть материалов успела разойтись, а минимум две уязвимости из этой подборки уже рассматриваются как реально опасные и замечены в эксплуатации.
Первая из них — CVE-2026-55200, критическая pre-auth RCE в libssh2, популярной клиентской C-библиотеке для реализации протокола SSH2. Суть проблемы в обработке специально сформированных SSH-пакетов с чрезмерно большим значением packet_length: это позволяет повредить память в heap и довести дело до удаленного выполнения кода. Патч уже влит в основную ветку разработки libssh2, но отдельный релиз с исправлением на момент публикации The Register еще готовился. Для команд, которые тянут libssh2 транзитивно через инструменты автоматизации, backup-системы, CI/CD-утилиты и прочий инфраструктурный софт, это та самая неприятная зона риска, где «мы напрямую библиотеку не ставили» ничего не меняет.
Вторая история еще ближе к бизнес-рискам: CVE-2026-20896, критический обход аутентификации в self-hosted Gitea Docker deployments. По описанию, неаутентифицированный удаленный атакующий может выдавать себя за любого пользователя и полностью захватить Git-сервер. Исправление уже выпущено в Gitea 1.26.3, так что здесь окно для реакции хотя бы формально есть. Но в реальности именно self-hosted Git-платформы часто живут в режиме «обновим после спринта», а потом внезапно выясняется, что через один сервер кода можно зайти в сборки, секреты, контейнерный реестр и дальше по цепочке. Для DevOps и ИБ это выглядит не как баг отдельного продукта, а как потенциальная точка входа в значительную часть внутренней разработки.
Что именно выложили и почему это неприятнее обычного PoC
Судя по пересказу The Register, bikini не концентрировался на одном вендоре. В списке фигурируют libssh2, Splunk, RustDesk, 7-Zip, VLC, AnyDesk, OpenVPN, c-ares, Gitea и Floci, а всего речь идет о 15 продуктах и проектах. При этом сам исследователь утверждал, что ни один из эксплойтов из репозитория не был предварительно зарепорчен. Издание отдельно оговаривает важную вещь: эти заявления и работоспособность всего кода независимо не верифицированы. Это существенная поправка, потому что на подобных сливах обычно всегда много шума, half-baked PoC и спорных находок. Но для защитников инфраструктуры проблема в том, что даже один-два действительно рабочих эксплойта уже меняют картину: атакующим не нужно тратить время на ресерч, достаточно быстро пройтись по доступным инстансам и проверить, кто не успел обновиться.
Дополнительный контекст делает историю еще менее уютной. The Register сравнивает bikini с другим охотником за багами — Nightmare Eclipse, который в последние месяцы публиковал эксплойты для Microsoft в обход привычной модели responsible disclosure. Разница в том, что там был конфликт вокруг одного вендора, а здесь — скорее беспорядочная раздача уязвимостей по широкому набору продуктов. Для рынка это плохой сценарий: у ИБ-команд нет возможности сосредоточиться на одном поставщике или одном классе систем. Приходится быстро проверять разные слои стека — от библиотек и сетевых компонентов до средств удаленного доступа и платформ разработки.
Отдельная линия — роль ИИ в такой охоте за багами. Несколько исследователей, включая аналитика Federal Signal Ethan Andrews, предположили, что bikini мог использовать продвинутые модели ИИ, в частности GPT-5.5 Codex, для автоматизации фаззинга и поиска уязвимостей. Подчеркнем: это предположение, а не установленный факт. Но сама логика тренда давно читается без особых гаданий. Если раньше bottleneck был в том, чтобы найти интересное состояние программы и руками добраться до воспроизводимого крэша, то теперь ИИ все заметнее удешевляет рутинную часть перебора, triage и первичной систематизации результатов. Для blue team из этого следует простой вывод: скорость генерации уязвимостей растет не только у крупных ресерч-команд, но и у одиночек с достаточным упрямством и доступом к хорошим моделям.
Что делать разработчикам, DevOps и ИБ прямо сейчас
Andrews после публикации слива собрал 44 правила детектирования на KQL, покрывающих весь репозиторий exploitarium, и отдельно отметил, что наиболее технически значимые находки — та самая heap-write в libssh2 и обход аутентификации в Gitea Docker — независимо подтверждены как high-risk, причем с признаками активной эксплуатации. Это важный маркер: даже если часть остальных публикаций сообщество сочтет шумом от AI-fuzzing, обороняться все равно придется по-взрослому. Для команд разработки и эксплуатации минимальный набор действий выглядит банально, но банальность тут не делает задачу менее срочной: проверить, где именно в инфраструктуре используется libssh2; поднять инвентаризацию self-hosted Gitea; убедиться, что Docker-развертывания обновлены до 1.26.3; посмотреть на сетевые логи и аномалии аутентификации; сверить собственные правила детектирования с тем, что уже собрали исследователи. Самый дорогой сценарий здесь не взлом одной ноды, а тихое продвижение от Git-сервера или SSH-компонента к цепочке поставки кода.
История с 0-day exploitarium неприятна не только самим сливом, но и тем, как быстро меняется экономика атаки. Репозиторий удалили, однако такие материалы редко исчезают по-настоящему: копии, архивы, пересобранные PoC и просто чужие заметки начинают жить отдельно от оригинала. Если хотя бы две уязвимости из этой подборки уже используются, дальше вопрос не в том, повторят ли эту схему снова, а в том, насколько часто ИБ-командам придется работать в режиме «чужой PoC уже в паблике, релиз с патчем еще не везде доехал». Первоисточник с деталями и артефактами описан у .