500 zero-day уязвимостей Claude Opus 4.6: что показывают три патча

5 февраля 2026 года Frontier Red Team компании Anthropic опубликовала исследование, в котором сообщается, что Claude Opus 4.6, выпущенный в тот же день, обнаружил и подтвердил более 500 уязвимостей высокой степени опасности в программном обеспечении с открытым исходным кодом — без инструментов для конкретных задач, специально созданной обвязки или специализированных промптов. Три находки описаны подробно: отсутствие проверки границ стека в Ghostscript, непроверенная серия strcat вызовов в OpenSC и переполнение буфера в GIF-кодере CGIF, которое зависит от того, как ведёт себя LZW-сжатие при заполнении его словаря. Anthropic сообщает, что все три ошибки уже исправлены их сопровождающими, и, по её данным, ошибки были найдены, подтверждены и о них сообщено. Как отмечается в публикации, многие из проектов поддерживаются небольшими командами или добровольцами без выделенного персонала по безопасности, поэтому нагрузка по сообщению об ошибках и выпуску патчей легла на них. Собственная запись архива об этой находке, которой присвоен информационный уровень серьёзности и не зафиксирован реальный ущерб, находится в Orca AI Incident Archive рядом с другими записями о политике и раскрытии информации за февраль 2026 года.

Что на самом деле опубликовал Anthropic

Публикация озаглавлена «Оценка и смягчение растущего риска 0-day-уязвимостей, обнаруживаемых LLM» и приписывается Frontier Red Team: Nicholas Carlini, Keane Lucas и Evyatar Ben Asher как равноправным участникам, а также Newton Cheng, Hasnain Lakhani, David Forsythe и Kyla Guru. На странице указана дата публикации 5 февраля 2026 года и примечание о редактировании от 6 февраля 2026 года, фиксирующее, что список авторов был обновлён. В архиве публикация указана по адресу red.anthropic.com, который теперь перенаправляет на anthropic.com/research/zero-days.

Метод важнее, чем цифра в заголовке. Anthropic утверждает, что поместила модель в виртуальную машину с доступом к последним версиям проектов с открытым исходным кодом и предоставила ей стандартные утилиты и инструменты, которыми пользовался бы исследователь безопасности-человек, — отладчики и фаззеры, — но без инструкций по их использованию и, по словам из публикации, «без специальной обвязки, которая дала бы ей специализированные знания о том, как лучше находить уязвимости». Проверялось поведение модели «из коробки».

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

Три бага и последовавшие за ними патчи

У трёх разобранных примеров общая схема: автоматизированный инструмент уже дал сбой, а модель нашла ошибку, рассуждая о чём-то ином, а не о мутации входных данных.

• Ghostscript, интерпретатор PostScript и PDF. Фаззинг, а затем ручной анализ ничего не выявили. Затем модель прочитала историю Git проекта, нашла коммит, описанный в посте как добавляющий «проверку границ стека для значений MM blend» к charstring-строкам Type 1, пришла к выводу, что код до этого коммита был уязвим, и принялась искать другие места вызова, не получившие такой же обработки. Она нашла одно в gdevpsfx.c — в посте указана строка 292 — и создала файл, который вызывает крах программы. Репозиторий это подтверждает: коммит 87486fb801 авторства Криса Лидделла от 5 сентября 2025 года озаглавлен «Type 1 charstrings: add stack bounds checking for MM blend values». Более позднее исправление Кена Шарпа, коммит 4e392a82 от 26 января 2026 года, добавляет проверки границ непосредственно перед этим вызовом в конвертере шрифтов; оно зарегистрировано по Bug 709080, отчёт о котором озаглавлен «Ghostscript Incomplete fix for Type 1 MM blend stack bounds check». Коммит от 13 февраля 2026 года расширил проверки границ в том же конвертере. Ни в одном из сообщений коммитов не указано, кто сообщил об ошибке.

• OpenSC, утилита командной строки для данных смарт-карт. Здесь модель искала вызовы рискованных функций и обнаружила последовательные strcat операции записи в 4096-байтовый буфер filename, после вычисления размера, в ходе которого вычиталась длина входной строки, но затем добавлялись дополнительные строки без повторной проверки. В заметке отмечается, что существующие фаззеры редко достигали этого пути из-за задействованных предварительных условий. Коммит OpenSC 33ab343a5c от 19 января 2026 года добавил проверку, что добавляемая строка имеет длину ровно 64 байта, а пул-реквест #3554, объединённый 25 января 2026 года, заменил оставшиеся strcat вызовы по всему проекту на strlcat; его автор назвал эту функцию «магнитом для любых инструментов статического анализа и CVE».

• CGIF — кодировщик GIF. Библиотека предполагала, что сжатые данные всегда будут меньше несжатого ввода, что почти всегда верно. Модель рассуждала, что LZW строит словарь фиксированного размера, и что когда словарь заполняется, clear-коды, вставляемые в поток, могут сделать «сжатый» вывод длиннее ввода, — поэтому буфер, рассчитанный на N+2 кода, мог принять больше N+1. В посте говорится, что даже 100-процентное покрытие строк и ветвей может не выявить это, поскольку для этого нужна определённая последовательность операций. Пул-реквест #84 этого проекта, слитый 19 января 2026 года и выпущенный в тот же день как v0.5.1, исправляет именно это: «Clear-коды сброса отсутствовали в расчёте верхней границы размера данных LZW».

Эти исправления были внесены ещё до публикации исследования — CGIF и OpenSC 19 января 2026 года, OpenSC снова 25 января, Ghostscript 26 января — и Anthropic заявила в публикации, что «начала сообщать о них и видит, как применяются наши первоначальные патчи» ещё до того, как информация стала публичной. Репозитории фиксируют изменения кода; они не фиксируют, кто подавал отчёты, поэтому связь между находками модели и этими конкретными коммитами опирается на рассказ Anthropic и на то, насколько описанные дефекты совпадают с диффами.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

Часть об управлении: проверки, блокировки и 90 дней

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

В посте также утверждается, что теперь проблемой является сам календарь раскрытия. «Стандартные для отрасли 90-дневные окна могут не устоять перед скоростью и объемом ошибок, обнаруживаемых LLM», — говорится в нем, и выражается предупреждение, что модели «могут вскоре превзойти скорость и масштаб даже опытных исследователей-людей». Это вендор утверждает, что норму, по которой его будут оценивать, необходимо заменить, и это та часть записи, которая имеет самое далеко идущее влияние.

Что изменилось после этого

20 февраля 2026 года Anthropic открыла Claude Code Security в качестве ограниченного исследовательского предпросмотра для клиентов Enterprise и Team, предоставив бесплатный ускоренный доступ мейнтейнерам open-source — эта возможность была продукт��зирована через пятнадцать дней после исследования. VentureBeat сообщил о запуске и заявил, что запрашивал у Anthropic долю ложноположительных срабатываний до и после самопроверки, число раскрытых уязвимостей с выпущенными патчами по сравнению с теми, что всё ещё находятся на триаже, а также меры защиты, позволяющие отличить использование злоумышленником от использования защитником; издание сообщило, что ведущий исследователь проекта был недоступен, а компания отказалась раскрывать конкретные механизмы обнаружения атакующих.

Патчи тоже продолжали двигаться, и не всегда в одном направлении. Исправление CGIF для описанного Anthropic выделения памяти вошло в v0.5.1 19 января 2026 года; 21 февраля 2026 года pull request #103 исправил переполнение 32-битного целого числа, внесённое тем же самым расчётом выделения памяти, и на следующий день было выпущено как v0.5.2 для GIF-файлов максимального размера 65 535 на 65 535 пикселей. Как выясняется, исправление расчёта границ само по себе является небольшим источником ошибок границ.

Правильное чтение числа

Собственная формулировка Anthropic — «более 500 уязвимостей высокой степени опасности». Axios, которому компания в первую очередь сообщила информацию, в день публикации описал их как «более 500 ранее неизвестных уязвимостей нулевого дня», каждая из которых была подтверждена членом команды Anthropic или сторонним специалистом по безопасности. Оба описания указывают на один и тот же набор, но только одно является формулировкой поставщика, и ни одно не сопровождается списком, сопоставлением с CVE или распределением по уровням опасности. Подсчёт принадлежит Anthropic, оценки опасности принадлежат Anthropic, и три проекта, разобранные в публикации, — единственное, что общественность может проверить.

Последовавший независимый анализ в основном воспринял это число буквально и спорил о том, что оно означает. Митч Эшли из Futurum Group написал 24 февраля 2026 года, что результат «важнее тем, что показывает метод, чем самим количеством», и что реальное ограничение находится ниже по потоку: «Более быстрое выявление большего числа уязвимостей не уменьшает поверхность атаки. Оно создаёт более длинную очередь перед процессом ниже по потоку, который не может поглотить такой объём». Это критика процесса раскрытия, а не самого вывода, и она приходит к тому же тезису, который Anthropic подняла в связи с 90-дневными окнами.

Что не устанавливают материалы дела

Архив оценивает эту запись как уровень уверенности A, серьёзность — info, при этом реального ущерба не зафиксировано и флаг спора отсутствует. Эта оценка касается того, насколько хорошо задокументировано событие, а не того, насколько хорошо проверено лежащее в его основе утверждение, и эту разницу стоит сохранять. Никто за пределами Anthropic не проверял эти 500. Уровень ложноположительных срабатываний не опубликован. Патчи для трёх названных проектов реальны и поддаются датировке, и это самое сильное доступное подтверждение — но они подтверждают три примера, а не общее количество.

Что же тогда остаётся? Хорошо задокументированное объявление с проверяемой сердцевиной и непроверяемым остатком: вендор, сообщающий о возможности, три upstream-диффа, которые соответствуют его описанию ошибок, и заявленное намерение пресекать злоупотребление этой возможностью на уровне модели. Архив относит это к политике — и это правильная полка. Спор о заявленной возможности решит тот, кто опубликует четвёртый патч.