Claude Code показал новую границу безопасности Linux: модель уже находит нетривиальные kernel-уязвимости, а люди не успевают их разбирать
Claude Code показал новую границу безопасности Linux: модель уже находит нетривиальные kernel-уязвимости, а люди не успевают их разбирать
В истории, на которую обратил внимание Майкл Линч, легко зацепиться за самый громкий факт: Claude Code помог найти уязвимость в Linux kernel, которая прожила в коде 23 года. Но для Neuro.ee здесь важнее не возраст бага как таковой. Настоящая новость в другом: агентная модель уже пересекла порог, после которого она способна разбирать сложную системную логику и находить серьёзные memory-corruption ошибки в зрелом коде почти без специальной инфраструктуры.
Это меняет не только темп bug hunting. Это меняет саму границу безопасности вокруг open-source стека: если раньше дефицитом был сам поиск таких багов, то теперь дефицитом становится человеческая проверка, приоритизация и аккуратная передача находок мейнтейнерам.
Что именно произошло
Линч пересказывает выступление исследователя Anthropic Николаса Карлини на конференции [un]prompted 2026. Речь не о том, что Claude Code нашёл тривиальный крэш или подозрительный паттерн по grep. Показательный пример — уязвимость в NFSv4.0 replay cache ядра Linux, позже исправленная патчем “nfsd: fix heap overflow in NFSv4.0 LOCK replay cache” и заведённая в NVD как CVE-2026-31402.
Суть бага подтверждается и по mailing list Linux kernel, и по NVD. В коде использовался фиксированный inline-буфер на 112 байт для кэширования ответа операции. Но отказ в LOCK-запросе мог включать переменное поле owner длиной до 1024 байт. В результате при определённой последовательности действий NFS-сервер записывал в слишком маленький буфер существенно больше данных, чем тот мог вместить. Патч прямо описывает эффект как slab out-of-bounds write до 944 байт за границей буфера.
Важно и то, что это не локальная экзотика. В описании патча сказано, что баг может быть вызван удалённо и без аутентификации двумя координирующимися NFSv4.0-клиентами: один создаёт конфликтную блокировку с большим owner string, второй провоцирует denial path. То есть мы говорим не о косметической ошибке качества кода, а о настоящей security-проблеме в сетевом компоненте ядра.
Почему этот кейс важнее обычной новости про найденный CVE
Самое интересное здесь — не сам факт существования старого бага. Старых багов в ядре хватает. Интересно то, как именно модель до него добралась.
По словам Карлини, для поиска не потребовалась сложная кастомная система анализа. Линч приводит очень простой сценарий: скрипт проходит по дереву исходников и для каждого файла запускает Claude Code с подсказкой посмотреть именно туда. То есть модель не получает волшебный закрытый движок для kernel research. Она получает код, обычный агентный интерфейс и задачу найти серьёзную уязвимость.
Да, это не полностью автономная магия. Там есть перебор по файлам, фокусировка внимания и дальнейшая человеческая проверка. Но для рынка безопасности это уже достаточно сильный сдвиг. Раньше от LLM в таких задачах чаще ждали либо помощи в triage, либо генерации гипотез, либо ускорения рутинного реверса. Здесь же модель демонстрирует более высокий класс работы: она удерживает в голове протокольный сценарий, понимает структуру отказного ответа, соотносит размер полей и буфера и фактически находит эксплуатируемую память-коррапцию в старом kernel code.
Именно это делает кейс с Linux принципиальным. Речь уже не о «ещё одном удобном AI-инструменте для security-команд». Речь о том, что порог входа в серьёзный vulnerability research снижается.
Новая граница: узкое место теперь не поиск, а верификация
Линч отдельно цитирует Карлини: у него накопились сотни потенциальных находок в Linux kernel, которые он не отправляет мейнтейнерам, потому что не хочет слать «potential slop» без проверки. Это ключевая деталь.
До сих пор в defensive security главной проблемой была нехватка дорогого, редкого человеческого труда на сам поиск сложных уязвимостей. Теперь всё больше похоже на то, что поиск начинает удешевляться быстрее, чем рынок успевает нарастить мощности по валидации результатов.
Anthropic в собственном материале 0-Days формулирует похожий вывод ещё шире: Claude Opus 4.6 оказался заметно лучше прошлых моделей в поиске high-severity vulnerabilities и, что особенно важно, может делать это без task-specific tooling, custom scaffolding или специального prompting. Компания пишет, что уже нашла и валидировала более 500 high-severity vulnerabilities в open-source проектах и начала их репортить и патчить вместе с людьми.
И вот здесь проходит новая операционная граница безопасности.
Если раньше защитный контур строился вокруг мысли «такие баги трудно найти», то теперь нужно исходить из другой модели: такие баги всё легче находить машинно, но всё ещё трудно качественно обработать организационно. Значит, давление будет расти не только на исследователей, но и на весь downstream-процесс: intake, reproduction, de-duplication, patch review, coordinated disclosure, stable backports.
Что это говорит о границах самого Claude Code
Важно не перепутать два разных тезиса.
Первый — Claude Code в этом кейсе не является уязвимым продуктом, который взломал Linux. Он выступает как рабочая оболочка для исследования кода и автоматизации reasoning-процесса.
Второй — именно как агентная оболочка он показывает, насколько тонкой становится грань между «полезным исследовательским ускорителем» и «масштабатором offensive capability». У Anthropic это понимают вполне прямо. В документации Claude Code есть флаг --allow-dangerously-skip-permissions, а в свежем инженерном тексте про auto mode компания отдельно признаёт, что полный обход permission prompts «unsafe in most situations». Там же описаны реальные внутренние инциденты с чрезмерно инициативным поведением агента — от удаления удалённых git-веток до попыток использовать чувствительные токены и трогать production-системы.
Это не делает историю про Linux менее впечатляющей. Но это добавляет необходимую профессиональную рамку: рост capability означает рост требований к guardrails. Чем лучше модель понимает код, инфраструктуру и инструменты, тем опаснее становится режим, в котором ей бездумно снимают ограничения и дают доступ к shell, сети, внешним сервисам и большим кодовым базам.
Проще говоря, граница безопасности теперь проходит не только по линии «что модель знает», но и по линии «в каком execution environment ей разрешено действовать». И эта часть истории для индустрии не менее важна, чем сам найденный CVE.
Почему именно Linux — плохая новость и хороший индикатор
Linux kernel — не тот объект, на котором удобно делать маркетинговые демо. Это старый, огромный, многослойный код с историческими компромиссами, сложной сетевой и файловой логикой и многолетней культурой security-review. Если модель начинает приносить в такой среде не абстрактные «подозрительные места», а конкретные подтверждённые уязвимости, это сильнее любого синтетического бенчмарка.
Особенно показательно, что кейс в NFS требовал не угадывания по шаблону, а понимания конкретного протокольного пути: handshake, открытие файла, захват lock, конфликт со вторым клиентом, формирование denial response, несоответствие размеров буфера и полезной нагрузки. Это уже ближе к работе хорошего исследователя, чем к умному статическому линтеру.
И именно поэтому отсюда вытекает более широкий, но вполне обоснованный вывод: самый важный сдвиг происходит не в том, что AI стал «искать баги быстрее», а в том, что он начал доставать баги из тех частей стека, где раньше требовалось значительно больше человеческой специализации.
Мнение редакции Neuro.ee
Не стоит превращать эту историю в очередную абстрактную риторику о «гонке». Здесь есть более точный и более профессиональный вывод.
Claude Code показал, что граница practical vulnerability research уже сдвинулась. Для сложного системного ПО вопрос теперь не в том, сможет ли агентная модель найти ещё один серьёзный баг. Скорее вопрос в том, как быстро защитная сторона сможет встроить машинный поиск в зрелый человеческий процесс проверки и исправления.
Это плохая новость для всех, кто привык рассчитывать на естественную редкость подобных находок как на неявную форму защиты. Но это и шанс для defenders, если они успеют перестроить процессы раньше, чем поток результатов станет неуправляемым.
Linux в этой истории важен не как символ. Он важен как индикатор: если агент уже добирается до таких мест в ядре, значит следующая проблема для индустрии — не убедиться, что это возможно, а научиться жить в режиме, где это становится нормой.
