PageBreak откри над 500 XSS уязвимости, но не вярва на догадки

На 24 септември 2026 г. Google в техническия си разбор на PageBreak съобщи, че вътрешният агент е открил над 500 XSS уязвимости в собствени уеб приложения, включително в чувствителни домейни. Разработен от екипа Product Security, той изпраща кандидатите за уязвимости към отделни валидатори, които изпробват експлойта срещу работещо приложение, преди находката да стигне до продуктовия екип.

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

Пътят от хипотеза до изпълним експлойт

PageBreak използва езиков модел, за да търси възможни пътища за атака, но окончателната проверка се извършва от специализирани валидатори, които не са написани от агента. При предполагаема XSS уязвимост валидаторът подава конкретен JavaScript код, зарежда адреса през среда за визуализиране или съществуваща сканираща инфраструктура и следи контекста на изпълнение. Самото наличие на подозрителен параметър или опасна операция в кода не е равнозначно на изпълнен скрипт в приложението.

Същият принцип се прилага по различен начин според вида на пробива. При SQL инжекцията тестът търси промяна в резултата или времето за изпълнение на заявката; при обхождане на пътища проверява дали приложението може да прочете файл извън предвидения обхват. За дистанционно изпълнение на код валидаторът търси измерим ефект, например създаден файл, забавяне или изходяща заявка. Това са различни доказателства за различни класове уязвимости, затова един общ отговор на езиков модел не може да ги замести.

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

Защо случаят в admin.google.com е показателен

XSS находка в admin.google.com показва защо проверката трябва да обхване целия път на атака. В репортажа на iThome е описан случай, при който уязвимата заявка изисква валиден подпис. PageBreak е открил друга крайна точка, която подписва параметри със злонамерено съдържание; така е станало възможно да се състави адрес, задействащ XSS въпреки проверката на подписа.

Тук доказателството не се състои само в открит вход за скрипт. То трябва да включва начина, по който параметрите получават валиден подпис, заявката достига до уязвимата крайна точка и съдържанието се изпълнява. Ако се провери само последната стъпка с неподписана заявка, тестът ще бъде отхвърлен и уязвимият път може да остане незабелязан. Случаят илюстрира защо агентът трябва да свързва поведението на няколко части на приложението, а валидаторът да изпълни предложената последователност.

Мащабът на находките и защитените рамки

В репортажа на crypto.news е посочено, че към 4 септември 2026 г. PageBreak е открил само две XSS уязвимости сред стотици приложения върху високонадеждните уеб рамки на Google. И двете са били във вътрешни приложения или крайни точки за отстраняване на грешки с пропуски в защитата. Този резултат описва конкретна група приложения, докато общият брой находки обхваща собствените уеб приложения на компанията в по-широк смисъл.

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

Мащабът на PageBreak зависи и от условия, характерни за Google. Агентът може да проследява пътища през общото хранилище за код, да използва сигнали от реален уеб трафик за връзка между адрес и изходен код и да стъпва върху скенери с достъп до приложения, които изискват удостоверяване. Това обяснява как изследва по-сложни вериги, но означава, че самият избор на езиков модел не описва цялата система, дала резултатите.

Какво трябва да съдържа доказаната находка

Подходът на PageBreak дава на екипите по приложна сигурност ориентир за оценка на AI скенер: хипотезата, изпълнимият тест и наблюдаваният ефект трябва да са ясно отделени. За XSS докладът има смисъл, когато показва конкретния вход, нужните условия за достъп, начина на зареждане на страницата и доказателството, че подаденият скрипт е тръгнал. За многостъпков случай като този с подписването е нужна и възпроизводимата последователност, която преодолява привидната преграда.

Същата строгост важи и за отрицателния резултат. Валидаторът може да не покрива определен клас атака, да не разполага с необходимия достъп или да не следва правилния път през приложението. Затова „непотвърдено“ описва статуса на конкретния тест, а не доказва отсъствие на уязвимост. Полезният скенер запазва тези кандидати за последващо изследване, без да ги смесва с възпроизводимите сигнали за поправка.

За разработчика последствието е пряко: когато получи потвърден сигнал, може да започне от условията и наблюдавания ефект, а не от предположението на модела. Следващият труден въпрос пред PageBreak е дали валидаторите ще обхванат повече сложни сценарии, без да превърнат отново непроверените хипотези в задачи за продуктовите екипи.