Николас Карлини, исследователь из Anthropic, рассказал на конференции [un]prompted 2026, что с помощью Claude Code обнаружил несколько удаленно эксплуатируемых уязвимостей в ядре Linux. Одна из них — переполнение heap в NFS-драйвере — оставалась незамеченной с 2003 года. "Я никогда не находил ничего подобного в жизни. Это очень, очень сложная задача. А с языковыми моделями у меня их целая пачка", — заявил Карлини.
Метод поиска оказался неожиданно простым: скрипт перебирает все файлы исходного кода ядра и отправляет каждый в Claude Code с промптом "Ты участвуешь в CTF-соревновании. Найди уязвимость". Никакой сложной оркестрации — обычный цикл for, который заставляет модель сфокусироваться на каждом файле по очереди.
Найденный баг в NFS-драйвере — классическое переполнение буфера. Когда сервер отказывает второму клиенту в блокировке файла, он формирует ответ с идентификатором владельца, который может занимать до 1024 байт. Проблема в том, что буфер ответа — всего 112 байт. Итого 1056 байт пишутся в 112-байтный буфер, что позволяет атакующему перезаписывать память ядра контролируемыми данными. Буфер был задан еще в коммите 2003 года — настолько давно, что прямой ссылки нет: баг старше самого Git.
Особенно показателен прогресс моделей. По словам Карлини, Claude Opus 4.1, вышедший восемь месяцев назад, и Sonnet 4.5 находили лишь малую часть тех уязвимостей, которые обнаруживает свежий Opus 4.6. Автор разбора Майкл Линч нашел в git-логе ядра пять патчей от Карлини, а еще несколько сотен крашей ждут ручной проверки — именно валидация людьми стала узким местом. "У меня столько багов, что я не успеваю их репортить. Я не буду отправлять мейнтейнерам непроверенный шлак", — объяснил Карлини.
Линч предупреждает: стоит ожидать волну обнаруженных уязвимостей в ближайшие месяцы — и со стороны исследователей, и со стороны атакующих. Если модели продолжат прогрессировать такими темпами, ручной аудит безопасности рискует остаться далеко позади.
P.S. Поддержать меня можно подпиской на канал "сбежавшая нейросеть", где я рассказываю про ИИ с творческой стороны.
