Поискайте от водещ модел с изкуствен интелект да отстрани реална уязвимост и той ще ви предостави нещо, което изглежда като решение. То се чете точно като корекция за сигурност, която би написал самият поддръжник на проекта. Когато има наличен тест, той често преминава успешно. Приблизително в един от всеки четири случая това действително е правилно решение.

Изследователи от 1Password оцениха 6080 корекции за сигурност за шест наскоро разкрити CVE уязвимости и се оказа, че неуспехите рядко са от очевидния вид: път за експлоатация, скрит зад проверка, докато уязвимостта все още стои зад него; грешка, коригирана в една функция, но оставена непроменена в нейния идентичен близнак; или грешка в паметта, която е затворена, но същевременно е отворена нова грешка в същата спомагателна функция.

Това, което следва, показва къде се концентрират тези неуспехи, защо погрешните съвети за коригиране нанасят повече вреда, отколкото липсата на всякакви съвети, и какво струва да се различи работещата корекция от тази, която просто изглежда убедително.

Уеб сървърът Freenginx позволява на администраторите на сайтове да пишат малки Perl програми, които се изпълняват при постъпване на заявка. Пропуск в тази функционалност – грешка в паметта от типа „use-after-free“ – позволява на посетител да предизвика срив на сървъра. Trail of Bits изпрати на поддръжниците готов код за отстраняване на уязвимостта чрез инициативата „Patch the Planet“, която управляват съвместно с OpenAI и която предоставя на разработчиците готов код вместо поредния доклад за грешка. Поддръжниците го отхвърлиха и написаха свой собствен. Отхвърлената версия коригира две от трите места, където съществува уязвимостта, докато версията на поддръжниците поправя и трите. Двете версии обаче добавят и нов начин за срив на сървъра, за чието достигане е необходим само обикновен клиент, който започва заявка и след това затихва.

Off-by-1 Labs, новата изследователска група за сигурност в 1Password, откри този втори срив и го докладва на поддръжниците на freenginx на 29 юни, а корекцията беше пусната на 2. юли. След това същата група приложи автоматизиран инструмент за генериране на кръпки към първоначалната уязвимост и накара ChatGPT 5.5 да напише 270 опита за коригирането ѝ. Техният проверяващ орган прецени, че 114 от тези опити са затворили първоначалната дупка, но откри нов проблем във всеки един от тези 114. В нито един от 270-те опита не беше получен изцяло чист код.

Тази кампания беше казус, прикачен към по-голямото проучване, при което ChatGPT 5.5 и Claude Opus 4.8 бяха тествани срещу разкрити тази пролет CVE уязвимости, като бяха изключени всички опити, при които моделът е търсил реалната официална корекция. Около половината от останалите генерирани корекции оставиха поне един възможен път за експлоатация отворен. Почти един на всеки двадесет опита въведе нова уязвимост, понякога в допълнение към неуспеха да се затвори първоначалната. Повечето от останалите пропуснати опити затвориха първоначалния бъг, но промениха поведението на софтуера по пътя, отхвърляйки входни данни, които програмата преди е приемала, или пренаписвайки изцяло синтактичния анализатор.

Ако трябва да запомните едно нещо от това проучване, то е липсата на видими признаци за неуспех. Нищо в корекцията, която оставя бъга отворен, не сигнализира, че нещо не е наред.

Моделите коригират примера, а не самата уязвимост

Дайте на модела конкретен пример, демонстриращ един злонамерен вход, и той ще коригира пътя на кода за този конкретен вход. Човек разглежда същия пример като единичен случай на по-общ проблем. Моделите не го правят. Повече от една трета от корекциите, оценени като успешни, бяха допълнително отбелязани като „нестабилни“ – което означава, че блокират демонстрирания експлойт с тясна проверка, докато оставят уязвимия код непокътнат, достъпен отново в момента, в който някой намери друг начин да го достигне.

Грешката в Chromium, CVE-2026-8512, показва този провал отблизо. Chrome следи папките на macOS за промени, а операционната система изпраща обратно повикване към Chrome, когато нещо се премести. Официалната корекция насочва това обратно повикване през малък междинен обект и изисква две отделни части от кода да задържат права върху този обект, така че той да не може да бъде изхвърлен, докато обратното повикване все още се изпълнява. И двата модела рутинно организираха първото задържане и пропускаха второто. Уязвимостта не изчезна, тя просто се премести.

Конфигурацията, която се върти в цикъл, докато тестовете спрат да се провалят, се оказа най-големият виновник тук. Нейният тест никога не проверява случая, който второто задържане защитава, така че непълната корекция преминава успешно и AI агентът спира дотам.

Погрешният съвет е по-лош от липсата на такъв

Насоките за коригиране се оказаха по-важни от избора на модел или архитектурата на тестовата среда. Подканите, съдържащи правилна посока за коригиране, са затворили бъга в около две трети от случаите. Подканите с правдоподобна, но грешна посока – от вида, който AI бот за преглед на код или уверен, но грешащ специалист по сигурността би предоставил – сринаха успеваемостта до около един на всеки шест случая. Тези данни включват всяка корекция, която е затворила първоначалната дупка, включително и тези, които са нарушили поведението на програмата или са отворили нова уязвимост – което е по-нисък критерий от споменатото по-горе отношение едно към четири.

Лошите насоки струват много повече, отколкото добрите насоки помагат. Ако не можете да гарантирате за корекцията, която предлагате на един AI агент, по-добре подминете бъга и запазете мълчание. В опитите с уверено подадени грешни насоки, собствените повиквания на инструменти на агентите понякога връщаха информация, която противоречи на подканата, но моделите въпреки това следваха инструкциите в подканата.

По-богатият правилен контекст помогна и итеративната тестова среда победи единичния офлайн опит. Нито едно от двете обаче не промени ситуацията толкова драстично, колкото коректността на насоките.

Един и същ модел постигна коренно различни резултати при различен код: Claude чисто коригира отдалеченото изпълнение на код в Exim.