22 августа 2026 года профессор информатики Кембриджа Anil Madhavapeddy опубликовал патч для OCaml-библиотеки cohttp, закрыв path traversal уязвимость (OSEC-2026-16). Приватный отчёт пришёл через Slack от Jane Street, баг нашёл Claude Fable. Anil открыл PR публично — и через десять минут (!) его сервер начал получать запросы с процентно-кодированными traversal-последовательностями. Кто-то уже видел патч и прислал ботов проверить, воспользовался ли уязвимостью его сервер.
Но самое тревожное — это не «кто-то». Скорее всего, это был автономный агент, который по шуму вокруг патча за считаные минуты сам нашёл эксплойт. Anil повторил это на своих агентах: DeepSeek V4 Pro нашёл related issues и создал работающий exploit за минуту. Claude Fable отказался — из-за встроенных ограничений безопасности (нет доступа к Project Glasswing), но альтернативная модель справилась без проблем.
Пост Anil Madhavapeddy на его сайте, 22 августа 2026 года — пост became viral через Simon Willison 28 августа
Источник: anil.recoil.org
Что произошло: таймлайн за 10 минут
Разберём цепочку событий по шагам.
День −7 (примерно). Anil получает приватный отчёт об уязвимости в cohttp — path traversal через percent-encoded path separators. Отчёт приходит через Slack отJane Street, баг найден Claude Fable.
День 0. Anil тестирует проблему: запускает собственного Claude Code, задача — «исследуй path normalisation в cohttp». Claude Fable отказывается (security block). Anil переключается на DeepSeek V4 Pro — и тот за минуту создаёт работающий exploit, способный прощупать локальный сервер.
День 0, PR открыт публично. После обсуждения с автором отчёта Anil открывает pull request #1145 в открытом репозитории.
День 0, +10 минут. Сервер Anil получает probes — автоматические запросы с percent-encoded traversal-последовательностями. Патч ещё не смержен, релиз ещё не вышел, но атакующие агенты уже реагируют.
Within about ten minutes (!) this website was fielding probes for percent-encoded traversal sequences, indicating that automated watchers are keeping an eye on public repositories.
[…]
If it took me just a minute to create my own exploit locally, then ten minutes actually seems quite long for an automated attack window to start! A determined attacker who is monitoring package repositories could easily be exploiting them within seconds.
Перевод: «Примерно через десять минут (!) мой сервер начал обрабатывать запросы с percent-encoded traversal-последовательностями — это говорит о том, что автоматические наблюдатели следят за публичными репозиториями. […] Если мне понадобилась минута, чтобы создать собственный exploit локально, то десять минут — это, пожалуй, долгое время для окна автоматической атаки! Настойчивый атакующий, который мониторит репозитории пакетов, мог бы эксплуатировать уязвимость буквально в течение секунд.»
Источник: anil.recoil.org, 22.08.2026
Полный таймлайн — от появления бага до эксплуатации — укладывается в считаные минуты. Раньше на это уходили дни или недели.
Таймлайн: от обнаружения бага до эксплуатации
Авторская схема по данным anil.recoil.org
Почему «слуха» достаточно для эксплойта
Ключевой вопрос: как агент, который видит только патч (фикс кода), восстанавливает уязвимость и создаёт эксплуатацию?
Anil процитировал исследование Fang et al. (2024), которое показало контраст:
- С описанием CVE: GPT-4 агент эксплуатировал 87% из 15 тестируемых уязвимостей.
- Без описания: только 7%.
То есть описание проблемы — даже зашифрованное в diff патча — даёт агенту достаточно контекста, чтобы найти эксплойт. Дифф патча — это, по сути, инструкция: «здесь была уязвимость, вот как мы её исправили». Агент читает обратно: «вот как можно эксплуатировать».
Как работает этот процесс на практике:
-
Мониторинг публичных PR и патчей. Автоматические наблюдатели следят за commit-потоками в популярных репозиториях. Открытие PR с security-related изменениями — триггер.
-
Анализ diff. Агент считывает diff: какой файл изменён, что заменено. Path traversal через percent-encoding? Значит, нужно попробовать traversal-последовательности в URL.
-
Генерация probes. Агент формирует HTTP-запросы с различными вариантами encoding (%2e%2e%2f, %252e%252e%252f и т.д.) и отправляет на целевые серверы.
-
Оценка результатов. По кодам ответа (200 vs 404 vs 500) агент определяет, сработала ли уязвимость.
Десять минут — это время от открытия PR до первого probes. В случае Marimo (CVE-2026-39987) от advisory до первой попытки эксплуатации прошло 9 часов, у Langflow (CVE-2026-33017) — 20 часов. Но оба этих случая касались уже опубликованных advisory, а не патча в репозитории.
Агенты как охотники за уязвимостями: цикл поиска и эксплуатации
Авторская схема по данным anil.recoil.org и Fang et al., 2024
rclone: 40+ security disclosures за месяц
Anil Madhavapeddy — не единственная жертва. В комментариях к посту на Hacker News Ник Craig-Wood, мейнтейнер rclone (одного из самых популярных инструментов для работы с облачными хранилищами), подтвердил масштаб проблемы:
In the first 10 years of the rclone project we received about 20 security disclosures through GitHub. We had to deal with over 40 in the last month! That has taken a huge amount of my time, even using AI tools to triage and come up with fixes for review. The hit rate for those security disclosures is pretty good — about 75% of them have a nugget of something which needs looking at.
Перевод: «За первые 10 лет проекта rclone мы получили около 20 отчётов об уязвимостях через GitHub. За последний месяц пришлось обработать более 40! Это отняло огромное количество моего времени, даже с использованием ИИ-инструментов для триажа и поиска исправлений на ревью. Процент реальных находок высокий — около 75% отчётов содержат что-то, требующее внимания.»
И ещё одна деталь: раньше GitHub назначал CVE за 2–3 дня. Теперь — за 3–4 недели. Система не успевает за потоком автоматически сгенерированных отчётов.
Связанные статьи:
— Промпт-инъекции в кодинг-агентах: как атакуют и как защититься — общая механика атак на агентов
— Кейс: взлом Claude Code auto mode — разбор атаки Rehberger — конкретный пример атаки через auto mode
Значит, embargoes больше не работают?
Anil задаёт этот вопрос напрямую: conventional security process предполагает, что секретность деталей защищает пользователей. Но сегодня агенту нужен только намёк — broad direction to search — чтобы он провёл собственное исследование и нашёл эксплойт.
Среднее время от патча до эксплуатации (mean time to exploit) по данным M-Trends 2026 от Google составляет −7 дней. Да, минус семь — эксплуатация опережает патч. В 2018–19 этот показатель был около 63 дней, в 2024 он пересёк ноль.
Поставщики вроде Google решают это через Continuous Updates: Chrome получает два релиза в неделю с динамическим обновлением фоновых процессов без перезапуска. Для open-source такой подход нереализуем: OSS-библиотеки встроены в десятки downstream-продуктов, и контроль над конечными точками отсутствует.
Anil Madhavapeddy предлагает три направления решений.
1. Секретная разработка патчей (super sekrit private patch development).
GitHub предоставляет временные приватные форки для security advisory, но на практике это не работает хорошо: CI отключён для приватных форков, только один PR может смержиться, рецензентов нужно добавлять по одному.
А главное — patch staying secret не так важен, как описание уязвимости, которое не должно попасть к атакующим. Сейчас обсуждение уязвимостей в open source идёт через Matrix, Discord, Slack — все эти каналы «протекают».
2. Отказ от embargoes, непрерывная доставка (no embargoes, just ship continuously).
Вместо того чтобы прятать патч, быстро фиксить и публично релизить. Linux Kernel делает так: fixes ship ASAP, не более 7 дней задержки, исключительно — 14. Но для этого нужна автоматизация: cross-ecosystem package management, инструменты вроде Scrutineer для триажа, и robust quality control.
3. Активная защита на уровне протокола (proactive protection at the protocol layer).
Пока патч проходит через review, тесты и упаковку, можно применить mitigation. Для cohttp это простое правило: нормализовать percent-encoded path separators. На облачных инфраструктурах это routine — Cloudflare развернул managed rules для Log4shell в 2021. Но open source не имеет mechanism для распределения таких правил.
Практический разбор: что делать мейнтейнерам
Кейс Anil не теоретический — он показывает конкретную дыру в процессах. Вот что можно извлечь:
Для мейнтейнеров open source
-
Не рассчитывайте на embargo. Если ваш патч виден в публичном PR — через 10 минут агенты будут его тестировать. Решение: либо приватная разработка (с ограничениями GitHub), либо публичный быстрый релиз с mitigation-правилами.
-
Используйте transient patches (virtual patching). Добавляйте WAF-правила или middleware-фигсы до полного патча. Anil предложил это для cohttp: нормализация percent-encoding в URL — простое правило, которое можно deploить за секунды.
-
Мониторьте собственные репозитории. Автоматические наблюдатели следят за PR и commits. Если у вас есть web-сервер — логируйте probes на known-vulnerable endpoints.
-
Ведите counter-offensive triage. Nick Craig-Wood из rclone использует AI-инструменты для триажа: 40+ отчётов за месяц — неподъёмная нагрузка для человека. AI помогает отсеять 25% мусора, но оставшиеся 75% требуют реального анализа.
Для разработчиков, использующих open-source библиотеки
-
Обновляйтесь быстро. Когда выходит security advisory — обновление должно быть приоритетом. Среднее время от патча до эксплуатации — меньше нуля, значит, у вас уже может быть окно уязвимости.
-
Следите за security advisories зависимостей. GitHub Dependency Review, Dependabot alerts, или сканеры вроде Snyk/Trivy — не опциональны, а необходимы.
-
Не полагайтесь на auto mode как на защиту. Как показал случай с Rehberger, auto mode в Claude Code — это удобство, а не безопасность. Настоящая защита — песочницы и сетевые ограничения.
Связанные статьи:
— Что такое агентный кодинг: как AI-агенты пишут код за вас — основы агентного подхода
— Песочницы для ИИ-агентов: запускаем код изолированно — как изолировать агента от сети и файловой системы
Как DeepSeek V4 Pro оказался в роли охотника за уязвимостями
Одна из деталей кейса, которая заслуживает отдельного внимания: Anil попросил Claude Fable исследовать проблему — и получил отказ. Claude Fable встроен в Claude Code и имеет security block: он отказывается от задач, связанных с поиском и эксплуатацией уязвимостей. Это часть политики Anthropic — без доступа к Project Glasswing (расширенный доступ для verified организаций) модель блокирует подобные запросы.
Anil переключился на DeepSeek V4 Pro — и тот за минуту нашёл related issues и создал exploit. Это показывает контраст:
| Модель | Поведение | Результат |
|---|---|---|
| Claude Fable (Anthropic) | Отказ по security block | Агент не помогает с поиском уязвимостей |
| DeepSeek V4 Pro | Выполнил задачу | Нашёл related issues, создал exploit за минуту |
С точки зрения атакующего это идеальное положение: одна модель блокирует, другая — помогает. Доступ к DeepSeek V4 Pro не требует special approval — модель доступна через API.
Что это значит для безопасности
Модель с ограничениями безопасности (Claude Fable, GPT-4 с guardrails) — не панацея. Атакующий просто возьмёт модель без таких ограничений. DeepSeek V4 Pro, open-source веса (MIT) для V4-Flash, commercial API для V4 Pro — всё доступно без ограничений на security research.
Это создаёт асимметрию: защитники должны учитывать, что атакующий имеет доступ к моделям без ограничений, а собственные агенты мейнтейнеров — с ограничениями.
Примечание: на момент публикации, DeepSeek V4 Pro доступен через API (DeepSeek) и агрегаторы. В России прямой доступ требует VPN, но агрегаторы (SpeShu.AI, RouterAI, provod.ai) предоставляют доступ с оплатой в рублях.
Честные ограничения
Кейс — частный случай, но тренд — системный. Anil Madhavapeddy описал ситуацию в OCaml-экосистеме. OCaml — нишевый язык, но проблема касается всех: rclone (Go), Marimo (Python), Langflow (Python) показывают ту же картину.
Мы не знаем, кто именно прислал probes. Anil предполагает, что это автоматические наблюдатели (automated watchers), но не может это доказать. Возможно, это были не агенты, а скрипты-мониторы. Однако способность агентов находить эксплойты по намёку подтверждена его личным опытом.
Статистика Fang et al. — на лабораторном бенчмарке. 87% эксплуатаций с описанием CVE — это на 15 тестируемых уязвимостей в контролируемых условиях. Реальные эксплуатации сложнее: нужен доступ к целевому серверу, понимание контекста, обход дополнительных защит. Но тренд очевиден.
Предложения Anil находятся на ранней стадии. Virtual patching и continuous shipping — рабочие подходы для крупных компаний (Google, Cloudflare). Для «mom and pop maintainers» (термин Anil) это требует инфраструктуры, которой пока нет.
Блок российских реалий
Пост Anil Madhavapeddy не освещён в русскоязычных источниках (на момент публикации, 30.08.2026). Тема автоматической эксплуатации уязвимостей агентами на habr.com покрыта шире:
- ИИ-агент нашёл в NGINX критическую уязвимость, которой 18 лет — автономный агент нашёл уязвимость за 6 часов (май 2026).
- Что не так с ИБ в опенсорсе и при чем тут ИИ (опять) — обсуждение AI-агентов и безопасности open source (июнь 2026).
- Первая полностью автономная атака AI-агента — Langflow, эксплуатация за 20 часов (июль 2026).
DeepSeek V4 Pro в России:
— Прямой доступ (chat.deepseek.com, API) требует VPN — российские карты не принимаются напрямую.
— Агрегаторы с оплатой в рублях: SpeShu.AI, provod.ai, RouterAI, AITUNNEL, gptrf.ru.
— Цены: промо-тарифы ~30₽/1M input + 60₽/1M output; после промо ~87₽/1M input + 174₽/1M output.
— Open-weight: DeepSeek V4-Flash доступен на Hugging Face (MIT), V4 Pro — только через API.
Claude Fable / Project Glasswing — для российских мейнтейнеров недоступен: Anthropic не работает в РФ напрямую, Glasswing ограничен 150 организациями в 15 странах.
