Изкуственият интелект променя начина, по който се извършват изследванията на уязвимости, но по-голямата част от дискусията все още е теоретична: какво би могъл да направи даден модел в бъдеще, а не какво действително може да открие днес.

Искахме да отговорим на един по-практичен въпрос: като използваме моделите, които вече са ни достъпни в момента, докъде може да ни доведе изкуственият интелект при откриването на реални, експлоатируеми уязвимости в софтуер в реална експлоатация?

Тази статия описва подробно как екипът на Intruder използва големи езикови модели (LLM) за откриване на нови уязвимости, като прилага рамки за сканиране на код съвместно с настоящите модели, предхождащи поколението Mythos.

Преминаваме през отдалечена, многоетапна SQL инжекция от тип zero-day, която открихме в WordPress плъгин с над 300 000 потребители — напълно автоматизирана от откриването до експлоатацията, без намеса на човек.

Основният проблем: защо насочването на AI към цяла кодова база не работи

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

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

За по-сложни грешки, които изискват свързване на няколко стъпки в рамките на верига, вие разчитате на рамката да поддържа правилния контекст в паметта или да го извлича интелигентно, когато е необходимо. Според нашия опит това води до лоши резултати, а не до реални и интересни грешки.

Традиционните рамки за сканиране на код вече решават това. Използваме техника, която наричаме програмен отрязък (program slice), подобна на това, когато IDE или LSP инструмент използва функции като „намиране на имплементация“ или графа на извикванията, за да намери всички функции, извикани от текущата функция. Това са зрели, добре тествани инструменти и те напълно избягват проблема с разредения контекст.

Пентест при всяка важна версия. Сигурност, която е в крак с инженерната дейност.

Агентите за AI пентестване на Intruder предоставят дълбочината на ръчен ангажимент при поискване: без време за подготовка, без разговори за определяне на обхвата, на част от цената.

Тествайте с всяка нова версия, затворете прозореца си на уязвимост и получете готов за одит доклад в рамките на часове.

Нашият конвейер: от кодова база до работещ експлойт

Изградихме конвейер, който взема кодова база, прекарва я през ядро за сканиране на код (използваме Joern), генерира отрязъци от код, свързани с всяка констатация, и използва LLM за триаж (класифициране) и експлоатиране на проблема. Дизайнът беше вдъхновен от работата на nooperator върху Slice, въпреки че използваме Joern вместо CodeQL и проектирахме алгоритъма за отрязване по съвсем различен начин, за да се справим с конкретните класове уязвимости, които търсим.

Насочихме го към топ 200 на WordPress плъгините — код, който вече е подробно проучен от изследователи на програми за лов на бъгове (bug bounty), така че откриването на нещо реално там би означавало, че процесът може да се конкурира с квалифицирани хора.

  • Първо, Joern работи срещу кодовата база с правила, предназначени да маркират най-общо „интересни“ модели.
  • За всеки WordPress hook Joern генерира отрязък: функцията, която hook-ът извиква, всеки метод, който тази функция извиква, и т.н. надолу по веригата.
  • Всеки отрязък отива към лек модел за триаж (Sonnet в нашите тестове), за да филтрира очевидно неинтересните неща.
  • Това, което остане, отива към по-тежък модел (Opus), за да оцени експлоатируемостта с пълния контекст в паметта.
  • Всичко, което е оценено като експлоатируемо, се изпраща на финален агент за експлоатация, който се опитва да напише експлойт и да го тества в Docker контейнер.

Първата уязвимост: blind SQL инжекция в популярен WordPress плъгин

Първият бъг, предоставен от конвейера, беше CVE-2026-3985 — уязвимост от тип SQL инжекция в плъгина Creative Mail. Тя ни направи впечатление поради няколко причини:

  • Има високо въздействие, давайки на атакуващия достъп за четене до базата данни (включително администраторски хешове и тайни токени!).
  • Изисква множество свързани заявки за експлоатиране, което я прави по-малко откриваема от традиционните инструменти.