Разработчик OCaml-библиотеки cohttp выпустил сегодня версию 6.3.0 с исправлением уязвимости path traversal. Сам патч получился несложным, и в обычной ситуации процедура была бы стандартной: приватно исправить, уведомить пострадавших пользователей, затем опубликовать публичное сообщение об уязвимости. Но на этот раз в логах живого веб-сервера появились зонды с точным паттерном бага — буквально через несколько минут после того, как PR с исправлением был открыт.
Хуже того, выяснилось, что построить эксплойт можно с помощью собственных ИИ-агентов, зная лишь приблизительно, о чём идёт речь — а значит, эксплуатация была возможна задолго до выхода публичного патча. Если одного слуха об уязвимости достаточно, чтобы злоумышленники получили всю необходимую информацию для поиска новых эксплойтов, подход к реагированию на security-инциденты в open source придётся менять.
1 Слуха об уязвимости достаточно для новых агентных систем эксплуатации
Конкретно этот отчёт пришёл приватно в Slack-канал через Jane Street на прошлой неделе — сам он был найден с помощью Claude Fable. Это существенно сжимает все временные рамки...
1.1 Хронология современного security-отчёта
Перед детальным изучением патча собственный экземпляр Claude был направлен на уязвимый код — с задачей выяснить, что ещё может скрываться там (проверка проблем нормализации путей). Fable в итоге категорически отказался из-за блокировки безопасности, поскольку доступа к Glasswing нет, зато DeepSeek V4 Pro справился и самостоятельно нашёл несколько смежных проблем. Агент тривиально создал эксплойт для проверки локального живого сервера меньше чем за минуту.
После обсуждения возможных решений с автором отчёта, PR cohttp#1145 был тихо открыт публично, чтобы привлечь к нему больше внимания. Обычно это занимает несколько дней, а релиз в течение недели-двух — разумный срок. Но уже примерно через десять минут (!) сайт фиксировал зонды с percent-encoded последовательностями обхода пути — то есть автоматизированные наблюдатели уже отслеживают публичные репозитории.
Если создание собственного локального эксплойта заняло всего минуту, то десять минут на самом деле выглядят довольно долгим сроком для старта автоматизированного окна атаки! Целеустремлённый злоумышленник, отслеживающий репозитории пакетов, вполне может начать эксплуатацию за секунды.
1.2 Security-эмбарго больше не работают
Традиционный security-процесс предполагает эмбарго на баг, исходя из того, что секретность деталей защищает пользователей. Однако сегодня агенту достаточно общего направления поиска — дальше он проведёт собственное исследование. Fang et al. обнаружили: получив описание CVE, их агент на базе GPT-4 эксплуатировал 87% уязвимостей из тестового набора из 15 позиций, а без описания — лишь 7%.
Два года спустя среднее время до эксплуатации составляет минус семь дней. Другими словами, эксплуатация теперь опережает выход патча! Тот же показатель в 2018–19 годах составлял около 63 дней, а нулевую отметку пересёк в 2024-м. Похожих случаев сегодня легко найти множество: CVE marimo CVE-2026-39987 прошёл путь от публикации до первой попытки эксплуатации за 9 часов, причём публичного proof-of-concept вообще не существовало. Langflow CVE-2026-33017 потребовал 20 часов. Похоже, рубикон автоматизированной генерации эксплойтов уже пройден...
2 Обернулась ли «баг-экономика» против мейнтейнеров open source?
Похоже, процессы обеспечения безопасности нуждаются в некоторой инверсии: одного человека, ищущего определённый класс проблем (это может быть вопрос в рассылке, странный коммит в заброшенной ветке или утечка контекста), достаточно, чтобы насторожить чужого агента и позволить ему получить код эксплойта. Это дикость.
В майской статье 2026 года был предложен термин «bugonomics» («баг-экономика») — и утверждается, что узким местом стала «пропускная способность устранения проблем защитниками». LLM с готовностью генерируют эксплойты, но способность защищаться от них не обязательно растёт, поскольку темпы проверки, приоритизации и релизов у мейнтейнеров остаются неизменными. К сожалению, это совпадает с картиной, наблюдаемой изнутри мейнтейнерского кресла open source:
Вопрос не в том, побеждают ли передовые модели, открытые модели или анализ программ. Вопрос в том, как их оркестрировать так, чтобы дефицитные ресурсы проверки, приоритизации и выпуска релизов направлялись на устойчивые исправления, а не на механический поиск и составление отчётов. Ключевая возможность для защитников — устранение технического долга: семантически обоснованные, проверенные инструментами, поддерживаемые моделями рабочие процессы, которые помогают мейнтейнерам находить, проверять, приоритизировать и исправлять уязвимости безопасности до того, как они станут завтрашними эксплуатируемыми уязвимостями. — Demystifying the Mythos or Disrupting Bugonomics?, Pesoli et al, 2026
Почему же возможности мейнтейнеров остаются неизменными? Очевидная причина — отсутствие доступа к передовым агентам вроде Mythos, но есть и другая: разработка security-патча, не вызывающего регрессий, фундаментально требует больше работы.
3 Что вообще можно с этим сделать?
Адаптироваться нужно довольно быстро. Текущий процесс ручной проверки вряд ли должен исчезнуть, но с момента выхода Fable наблюдается неустойчивый всплеск активности. Только начинается понимание того, какая доля входящего потока сгенерирована машинами — но очевидно, что доля эта немаленькая.
Крупные инженерные компании (например, Google) встраивают микрообновления прямо в софт, чтобы исправления в первую очередь доходили до пользователей, а не ждали фиксации в репозитории кода Chrome. У Docker или OCaml такой роскоши нет — конечные точки использования софта не контролируются. За исключением Docker Desktop, downstream-дистрибутивы вполне закономерно переупаковывают open source по собственным срокам и правилам.
Для небольших проектов вроде OCaml даже доступ к передовым моделям — уже проблема. У западных коммерческих моделей есть защитные механизмы, блокирующие их использование в подобных задачах. Project Glasswing расширился до 150 организаций в 15 странах, включая операторов критической инфраструктуры, облачных и финансовых провайдеров, Linux Foundation — но у мейнтейнеров-«одиночек» доступа по-прежнему нет. В апреле ещё оставались сомнения, вредно ли это, но сегодня уже очевидно: ситуация складывается довольно скверно.
3.1 Сверхсекретная приватная разработка патчей
Первый способ смягчения проблемы — разрабатывать исправления где-то по-настоящему приватно, вне досягаемости ИИ. GitHub-механизм временных приватных форков номинально это обеспечивает, но на практике работает не слишком хорошо.
Во-первых, GitHub ограничивает доступ так, что «для защиты информации об уязвимостях интеграции, включая CI, не могут обращаться к временным приватным форкам», что сразу отрезает мейнтейнера от результатов CI. Во-вторых, в форк может смержиться только один PR — а проблемы часто затрагивают сразу несколько репозиториев. К тому же ревьюеров приходится подключать по одному через администратора, а в open source ревьюеры зачастую заходят «мимоходом», в зависимости от того, кто свободен (особенно в августе!).
Но в более широком смысле это латает не ту дыру. Секретность самого патча гораздо менее важна, чем гарантия, что описание проблемы попадёт именно к нужным людям без утечки к злоумышленникам.
Внутри open source нет надёжной инфраструктуры для обсуждений: она разбросана по разным end-to-end зашифрованным каналам (используется Matrix), а также по общей инфраструктуре вроде Discord или Slack, которая крайне «дырявая». Нужен некий web-of-trust, чтобы отличать «своих» от «чужих» в контексте конкретного проекта.
3.2 Никаких эмбарго — только непрерывные релизы
Другой вариант — быстро исправлять проблемы публично, непрерывно поставлять релизы и улучшать процесс выпуска через лучшую автоматизацию.
Крупные проекты вроде Chrome показывают, что это возможно: еженедельные security-обновления, два релиза в неделю (!), а также динамическое патчинг, заменяющий фоновые процессы обновлёнными бинарниками без перезапуска. Технология не совсем новая — интеграция живого патчинга ksplice для Linux с Xen изучалась ещё 15+ лет назад. Ядро Linux тоже старается выпускать исправления как можно быстрее, откладывая максимум на семь дней, в исключительных случаях — на четырнадцать.
Главное препятствие здесь — упаковка софта. У Chrome относительно простая задача: поставлять один бинарный артефакт, тогда как open source часто представляет собой набор библиотек, которые затем встраиваются в самые разные downstream-продукты. Чтобы это заработало, потребуется:
- значительно лучшее кросс-экосистемное управление пакетами для отслеживания того, куда в итоге встраиваются разрозненные библиотеки. Райан Гибб расскажет об этом на ICFP на следующей неделе!
- лучшие инструменты сканирования для помощи в триаже; Эндрю Несбитт последние несколько месяцев занимается именно этим в проекте Scrutineer. Томас Газаньер обсуждал возможность опробовать это на коде OCaml — при условии получения доступа к достаточно передовой модели без блокировок безопасности.
- более надёжная инфраструктура контроля качества без ложных срабатываний, работающая на всех поддерживаемых платформах. Если запустить CI на Linux относительно легко, то на OpenBSD, FreeBSD, macOS и на некоторых архитектурах вроде RISC-V ситуация совсем другая.
3.3 Проактивная защита на уровне протокола
Возникали и более радикальные идеи о том, как динамически внедрять защиту конечных точек, использующих эти библиотеки. Если принять как данность, что апстрим-патчи всегда будут отставать от эксплойта, потребуется что-то более быстрое, чтобы вырваться вперёд.
Например, у сегодняшнего бага cohttp есть простая митигация: просто нормализовать percent-encoded разделители пути в URL запроса. Это правило можно было реализовать сразу, как только пришёл отчёт, и развернуть его, пока полноценное исправление проходило ревью, тестирование и упаковку. Виртуальный патчинг сегодня — обычная практика в облачной инфраструктуре: Cloudflare развернула управляемые правила для закрытия Log4shell ещё в 2021 году.
Но у open source нет механизма распространения подобных правил вне коммерческого CDN. Именно это пытается закрыть идея antibotty-сети из статьи об интернет-экологии — через большее разнообразие ПО в масштабах глобального интернета. Как обеспечить локальные, быстро распространяющиеся защитные механизмы, которые узнают об уязвимости и реагируют на своей инфраструктуре в течение секунд?
4 Направления для дальнейших исследований
В краткосрочной перспективе потребуется какая-то комбинация всех трёх вариантов: облегчённый web-of-trust для контрибьюторов open source (наподобие того, каким когда-то был Advogato), а также больший фокус на упаковке open source и механизмах непрерывной поставки и триажа, которые не перегружают ценных человеческих контрибьюторов.
Также опубликованы пара новых идей для магистерских исследований (MPhil) для тех, кто поступает в Кембридж в следующем месяце и ищет тему проекта.
- «Antibotty-полигон для защиты сетевых сервисов» размещает MirageOS-шлюз перед домашней сетью и исследует, можно ли сделать набор правил митигации достаточно надёжным для автоматического развёртывания. Возможна интересная игра в формате capture-the-flag: одинаковый «слух» о баге даётся атакующему и защищающемуся агентам, и смотрится, кто доберётся до цели первым.
- «Компиляция спецификаций Lean в автоматы принуждения OxCaml» определяет, что библиотеке разрешено делать на уровне файловой системы, парсера и сети, используя монады Дейкстры. Такая спецификация Lean компилируется в автомат OxCaml, который принуждает к соблюдению правил во время выполнения. Это современная вариация statecall-автоматов, разработанных ещё во время диссертации.
И если кто-то из команды Project Glasswing это читает — команде OCaml сейчас бы очень пригодился доступ :-)
Исправление cohttp — результат совместной работы. Sapphire Livingstone нашла и сообщила о проблеме, направляла разработку патча и участвовала в его создании; Michael Dales, Török Edwin и Patrick Ferris проверили патч; Hannes Mehnert координировал публикацию advisory; а Thomas Gazagnaire размышлял над более широкой проблемой триажа. Спасибо всем! «Баг-экономика» может быть против нас, но этот перевал ещё можно взять.