Мейнтейнер cohttp: слух об уязвимости уже даёт ИИ-агентам эксплойт

Мейнтейнер библиотеки cohttp (OCaml) выпустил патч версии 6.3.0, закрывающий уязвимость типа path traversal (обход каталогов через специально закодированные символы в пути). Патч был несложным, и по обычной процедуре сначала чинят проблему приватно, уведомляют пострадавших и только потом публикуют советник. Но в этот раз всё пошло иначе: буквально через несколько минут после того, как автор открыл публичный pull request с исправлением (cohttp#1145), в логах его боевого веб-сервера появились запросы с точно тем же паттерном атаки, сканирование на закодированные символы обхода каталогов началось примерно через десять минут после публикации.

Ещё до публикации автор сам направил своего ИИ-агента на проверку затронутого кода на предмет похожих проблем с нормализацией путей. Модель Claude Fable отказалась выполнять запрос из-за встроенной защиты безопасности, у автора нет доступа к программе Glasswing. Зато DeepSeek V4 Pro запрос выполнила и самостоятельно нашла ещё несколько похожих проблем. Тот же агент за неполную минуту собрал рабочий эксплойт против локального тестового сервера.

Автор ссылается на исследование Фанга с соавторами: агент на основе GPT-4, получив описание CVE, успешно эксплуатировал 87% уязвимостей из тестового набора на 15 позиций, а без описания, только 7%. По его данным, среднее время от публикации патча до появления эксплойта за два года ушло в отрицательную зону и составляет -7 дней, то есть эксплуатация теперь в среднем опережает патч. Для сравнения: в 2018-2019 годах этот показатель составлял около 63 дней, а к нулю он подошёл в 2024 году. Автор приводит и свежие примеры: у уязвимости CVE-2026-39987 в проекте marimo от публикации советника до первой попытки эксплуатации прошло 9 часов, при том что публичного proof-of-concept вообще не существовало; у CVE-2026-33017 в Langflow, 20 часов.

Опираясь на это, автор говорит о концепции «bugonomics» из статьи Пезоли с соавторами (май 2026): узкое место сместилось на сторону защитников, способность языковых моделей генерировать эксплойты растёт, а скорость валидации, приоритизации и выпуска исправлений мейнтейнерами остаётся прежней. Дополнительная проблема, неравный доступ к передовым моделям: программа Glasswing даёт защищённый доступ к таким моделям 150 организациям в 15 странах (включая операторов критической инфраструктуры, облачные и финансовые компании, Linux Foundation), но небольшие проекты вроде OCaml в неё не попадают и вынуждены использовать модели без нужных ограничений безопасности либо обходиться без ИИ-инструментов вовсе.

Автор разбирает три направления защиты. Первое, разработка патчей в максимально закрытой среде: временные приватные форки на GitHub решают задачу плохо, потому что отрезают CI-интеграции, допускают слияние только одного pull request и требуют вручную добавлять каждого ревьюера; к тому же, по его мнению, куда важнее не прятать сам патч, а не допустить утечки описания проблемы, а для этого у OSS-сообщества нет надёжной инфраструктуры доверенного общения (используются end-to-end зашифрованные каналы вроде Matrix, но также утечкоопасные Discord и Slack). Второе направление, отказ от эмбарго в пользу непрерывной поставки исправлений, по образцу Chrome (два релиза безопасности в неделю, динамическая подмена процессов без перезапуска) или ядра Linux (не более 7, в исключительных случаях 14 дней отсрочки); для OSS-библиотек это упирается в фрагментированную упаковку и распространение, нужны более совершенные инструменты отслеживания зависимостей между экосистемами (эту тему на конференции ICFP на следующей неделе разберёт Райан Гибб) и сканеры для триажа вроде Scrutineer, который несколько месяцев разрабатывает Эндрю Несбитт. Третье направление, проактивная защита на уровне протокола: быстрые правила-митигации, которые можно развернуть на затронутых серверах ещё до выхода полноценного патча (для самой уязвимости в cohttp такое правило, просто нормализовать закодированные разделители пути в URL). Автор напоминает, что виртуальный патчинг такого рода уже рутинно применяется в коммерческой облачной инфраструктуре, например, Cloudflare в 2021 году так закрыла Log4Shell управляемыми правилами, но у открытого ПО нет собственного механизма распространения подобных правил вне коммерческих CDN.

В конце автор благодарит соавторов исправления в cohttp: Сапфир Ливингстон нашла и сообщила об уязвимости, направляла работу над патчем и участвовала в его разработке; Майкл Дейлс, Тёрёк Эдвин и Патрик Феррис проверяли патч; Ханнес Менерт координировал публикацию советника; Тома Газаньер продолжает разбираться с более широкой проблемой триажа уязвимостей в проекте.

Ключевые факты

Патч cohttp 6.3.0 закрыл уязвимость path traversal; через ~10 минут после публикации pull request на сервере автора уже фиксировались зондирующие запросы с тем же паттерном атаки
Собственный ИИ-агент автора собрал рабочий эксплойт против тестового сервера меньше чем за минуту; DeepSeek V4 Pro выполнила запрос на поиск похожих уязвимостей, а Claude Fable отказала из-за защиты безопасности (нет доступа к программе Glasswing)
По данным Фанга с соавторами, GPT-4-агент с описанием CVE эксплуатирует 87% уязвимостей тестового набора против 7% без описания; среднее время до эксплойта упало с ~63 дней (2018-2019) до -7 дней сейчас, то есть эксплуатация в среднем опережает патч
Свежие примеры разрыва между советником и атакой: 9 часов у marimo (CVE-2026-39987, без публичного PoC) и 20 часов у Langflow (CVE-2026-33017)
Программа Glasswing даёт защищённый доступ к передовым моделям 150 организациям в 15 странах, но небольшие проекты вроде OCaml в неё не входят, автор предлагает три направления защиты: закрытая разработка патчей и доверенные каналы связи, непрерывная поставка исправлений по образцу Chrome и Linux, и виртуальный патчинг на уровне протокола

Почему это важно

Материал фиксирует практический слом традиционной модели раскрытия уязвимостей. Раньше секретность деталей бага давала мейнтейнерам окно на приватную разработку и выпуск патча. Автор показывает на своём примере, что этого окна больше нет: через десять минут после публикации фикса сервер уже сканировали на ту же уязвимость, а собственный ИИ-агент собрал рабочий эксплойт меньше чем за минуту, имея лишь общее направление поиска. Цифры из внешнего исследования (87% против 7% эксплуатируемости с описанием CVE и без него) и динамика среднего времени до эксплойта (с ~63 дней в 2018-2019 до -7 дней сейчас) показывают, что это не единичный случай, а системный сдвиг: эксплуатация в среднем опережает патч.

Кому это важно

В первую очередь, мейнтейнерам open source проектов, особенно небольших, где нет ресурсов крупных компаний. Автор прямо противопоставляет свою ситуацию инструментам вроде Chrome, который может выкатывать исправления безопасности дважды в неделю и подменять процессы без перезапуска, потому что контролирует весь путь от кода до конечного пользователя. У OCaml и подобных библиотек такого контроля нет: код расходится по множеству зависимых проектов с собственными циклами упаковки. Дополнительно это важно для тех, кто использует программы контролируемого доступа к передовым ИИ вроде Glasswing (150 организаций, 15 стран) и для тех, кто в них не попадает, по словам автора, именно вторые остаются наиболее уязвимыми.

Как это применить

Автор предлагает три взаимодополняющих направления, а не единое решение. Первое, держать разработку патча в максимально закрытой среде и построить доверенные каналы связи между участниками, поскольку временные приватные форки GitHub неудобны (нет доступа CI, только один pull request на форк, ручное добавление ревьюеров), а популярные общие чаты вроде Discord и Slack протекают. Второе, отказаться от эмбарго и перейти на непрерывный выпуск исправлений по образцу Chrome (два релиза в неделю) или ядра Linux (отсрочка не больше 7, в исключительных случаях 14 дней), для чего нужны инструменты отслеживания того, где именно используется библиотека в чужих продуктах, и сканеры для триажа вроде разрабатываемого Scrutineer. Третье, проактивные быстрые правила-митигации на уровне протокола, разворачиваемые на затронутых серверах ещё до выхода полного патча, по аналогии с тем, как коммерческие CDN виртуально патчили Log4Shell в 2021 году.

Можно ли доверять

Это личный отчёт мейнтейнера cohttp о реальном инциденте с его собственным проектом, с конкретными деталями (номер версии, номер pull request, наблюдаемые логи). Часть аргументации опирается на внешние источники с точными цифрами, исследование Фанга с соавторами и статью о «bugonomics» Пезоли с соавторами (май 2026), которую автор прямо цитирует. При этом сам автор не утверждает и не доказывает, что зафиксированные им зондирующие запросы были сгенерированы именно ИИ-агентом, а не обычным автоматическим сканером, это его интерпретация происходящего, поданная как гипотеза, а не как подтверждённый факт.

Риски и подводные камни

Есть риск переоценить угрозу: сам автор не отделяет строго ИИ-генерируемые атаки от обычного автоматического сканирования репозиториев, которое существовало и раньше. Предлагаемые меры защиты тоже не бесплатны, непрерывная поставка исправлений и виртуальный патчинг требуют инфраструктуры, тестирования кросс-платформенной совместимости (от Linux до OpenBSD, FreeBSD, macOS и RISC-V) и рисков регрессий, которых у большинства open source проектов просто нет. Наконец, программы контролируемого доступа к передовым моделям вроде Glasswing, задуманные как защита от злоупотреблений, по признанию самого автора на практике усиливают неравенство: крупные организации получают инструмент для защиты, а небольшие мейнтейнеры остаются без него же, притом что именно они чаще всего под ударом.

«Вопрос не в том, кто победит, передовые модели, открытые модели или инструменты программного анализа. Вопрос в том, как их организовать так, чтобы дефицитные ресурсы валидации, приоритизации и выпуска исправлений шли на устранение системных проблем, а не на механический поиск уязвимостей и составление отчётов. Ключевая возможность для защитников, устранение технического долга: основанные на семантике, проверяемые инструментами, ассистируемые моделями процессы, которые помогают мейнтейнерам находить, проверять, приоритизировать и исправлять дефекты безопасности прежде, чем они станут завтрашними эксплуатируемыми уязвимостями.»

— Пезоли с соавторами, статья «Demystifying the Mythos or Disrupting Bugonomics?», 2026