# От слуха о баге до эксплойта — 10 минут: как ИИ-агенты ломают старые правила disclosure
Каноническая страница: https://plainews.ru/posts/ai-agenty-najdut-eksploit-za-minuty
Опубликовано: 2026-08-29T11:01:05.236Z

ИИ-агенты сканируют публичные репозитории и находят эксплойты за минуты после намёка на баг. Как мейнтейнерам пересобрать процесс disclosure в 2026 году.
Раньше между первым обсуждением уязвимости и её эксплуатацией проходили дни, иногда недели. Сейчас счёт идёт на минуты — автоматические ИИ-агенты мониторят публичные репозитории и достраивают эксплойт по одному намёку на баг. Если вы поддерживаете опенсорс-проект, старые процессы embargo (период, когда об уязвимости знают только разработчики, до публикации патча) больше не работают, и это нужно учитывать уже сейчас.

## Что произошло у мейнтейнеров OCaml и rclone

Анил Мадхавапедди, профессор Кембриджа и один из core-мейнтейнеров компилятора OCaml, описал случай, который раньше выглядел бы фантастикой. Обычно между обсуждением проблемы безопасности и релизом с патчем проходило несколько дней, релиз в течение недели-двух считался нормальной скоростью реакции. В этот раз всё изменилось: примерно через десять минут после публикации обсуждения сайт проекта начал получать пробы с percent-encoded traversal последовательностями (закодированные символы, которые используют для обхода проверок пути к файлам) — верный признак того, что автоматические системы уже следят за публичными репозиториями и реагируют на любое движение.

Анил проверил гипотезу на собственных агентах. Он смог воспроизвести атаку, используя ИИ-инструменты — сначала попытался с Claude Fable, но тот отказался выполнять задачу, тогда он переключился на DeepSeek V4 Pro и получил рабочий эксплойт. То есть современные агенты настолько хорошо умеют находить уязвимости, что для них достаточно малейшего намёка на новый баг — остальное они достраивают сами.

Ник Крейг-Вуд, мейнтейнер rclone, подтвердил проблему в комментариях на Hacker News цифрами. За первые десять лет существования проекта rclone получил около 20 сообщений об уязвимостях через GitHub. За последний месяц — больше 40. При этом качество сигналов неплохое: примерно 75% присланных отчётов содержат реальную проблему, которую стоит рассмотреть. Но обработка этого потока съедает огромное количество времени мейнтейнера, даже с использованием ИИ-инструментов для triage (первичной сортировки и оценки серьёзности) и подготовки исправлений.

## Почему это ломает привычный процесс

Раньше вся система disclosure строилась на предположении, что между сообщением об уязвимости и её массовой эксплуатацией есть буфер в несколько дней. За это время мейнтейнер успевал подготовить патч, скоординироваться с дистрибьюторами и получить идентификатор CVE (Common Vulnerabilities and Exposures — стандартный номер для отслеживания уязвимости). Этот буфер и был основой embargo-практик.

Сейчас буфер схлопнулся до минут. Ник Крейг-Вуд отмечает побочный эффект: раньше GitHub присваивал CVE за 2-3 дня, сейчас на это уходит 3-4 недели — сама инфраструктура disclosure не успевает за скоростью атак. В итоге приходится выпускать релизы с пометкой CVE-PENDING в changelog, что неудобно и для пользователей, и для систем автоматического сканирования зависимостей, которые ищут именно CVE-номера.

Анил формулирует вывод жёстко: если проблема может превратиться в эксплойт за десять минут, старые процессы embargo несовместимы с реальностью, и сообществу нужно придумывать новые правила безопасности.

## Что делать мейнтейнеру уже сейчас

Готовых стандартов пока нет, но из описанных кейсов можно собрать практический чек-лист для тех, кто поддерживает открытые проекты.

**Не обсуждайте детали бага публично до готовности патча.** Даже упоминание того, что «в модуле X есть проблема с валидацией пути», для ИИ-агента может быть достаточной подсказкой, чтобы за минуты найти конкретную уязвимость и попробовать её эксплуатировать.

**Используйте приватные каналы disclosure.** GitHub Security Advisories и аналогичные механизмы позволяют обсуждать проблему в закрытом режиме, прежде чем она попадёт в публичные issue или pull request.

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

**Внедряйте ИИ-triage входящих отчётов.** Ник Крейг-Вуд использует ИИ-инструменты для первичной сортировки и подготовки черновиков исправлений — это единственный способ не утонуть в потоке из 40+ отчётов в месяц вместо 20 за десять лет.

**Заранее продумайте, как жить с CVE-PENDING.** Если официальный номер CVE может задержаться на 3-4 недели, публикуйте релизы и changelog с пометкой о том, что идентификатор в процессе присвоения, и объясняйте пользователям, что это не значит отсутствие проблемы.

**Мониторьте свой репозиторий на подозрительный трафик.** Резкий всплеск проб с закодированными traversal-последовательностями или похожими паттернами сразу после публикации обсуждения — сигнал, что автоматические сканеры уже включились в работу.

## Где это ломается

Приватные каналы disclosure сами по себе не панацея — если в обсуждении участвует достаточно широкий круг людей (мейнтейнеры, ревьюеры, тестировщики), утечка информации всё равно возможна, а автоматические агенты не спят и мониторят даже закрытые форки и зеркала репозиториев, если к ним есть доступ у большего числа участников.

Ускорение цикла патч-релиз тоже упирается в ресурсы: не у каждого проекта есть штат, способный реагировать за часы, а не за дни, особенно если поддержка держится на одном-двух волонтёрах, как это часто бывает в опенсорсе.

Использование ИИ для triage экономит время, но переносит ответственность на модель — если агент неправильно оценит серьёзность репорта или предложит неполный патч, это может создать ложное чувство защищённости.

## Что попробовать дальше

Начните с малого: настройте GitHub Security Advisories для приватного обсуждения уязвимостей, если этого ещё нет. Проверьте, сколько времени у вас уходит от получения отчёта до релиза с патчем — если счёт идёт на недели, это первое узкое место, которое стоит сократить. И присмотритесь к тому, как ИИ-инструменты справляются не только с атакой, но и с обороной — triage входящих репортов и генерация черновиков исправлений с их помощью может окупить время, потраченное на настройку.

## FAQ

### Что такое embargo-период в контексте уязвимостей?

Это время между тем, как о проблеме безопасности узнают разработчики, и публикацией информации о ней вместе с патчем. Раньше это давало несколько дней или недель на подготовку исправления без риска массовой эксплуатации.

### Почему ИИ-агенты находят эксплойты так быстро?

Современные модели умеют не только писать код, но и анализировать репозитории, искать паттерны уязвимостей и достраивать рабочий эксплойт по минимальным подсказкам — например, по формулировке в обсуждении на GitHub.

### Что такое CVE-PENDING и почему это проблема?

CVE — стандартный идентификатор уязвимости. Если GitHub не успевает присвоить номер вовремя, мейнтейнеры выпускают релиз с пометкой CVE-PENDING в changelog, что усложняет автоматическое отслеживание патчей системами анализа зависимостей.

### Как небольшому проекту защититься при ограниченных ресурсах?

Использовать приватные каналы disclosure по умолчанию, подключить ИИ-инструменты для первичной сортировки отчётов и заранее прописать процесс быстрого релиза хотя бы для критичных проблем.

### Значит ли это, что публиковать информацию об уязвимостях вообще опасно?

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

## Источники

- Simon Willison: Just a rumour of a bug is enough to find a security exploit these days