Googleov PageBreak našao je 500+ XSS propusta, uz provjeru svakog napada

Google je u objavi od 24. rujna 2026. naveo da je njegov interni agent PageBreak pronašao više od 500 ranjivosti tipa cross-site scripting (XSS) u vlastitim web-aplikacijama, uključujući osjetljive domene. Sumnju prije prijave timu za proizvod preuzima zaseban validator: u pokrenutoj aplikaciji pokušava izvesti stvarni napadački sadržaj. Google upravo toj razlici između pretpostavke i izvedenog napada pripisuje gotovo nultu stopu lažno pozitivnih prijava.

PageBreak je projekt Googleova tima za sigurnost proizvoda i služi za provjeru njegovih aplikacija, a objavljeni zbroj rezultat je internog rada. Nalaz koji ne prođe provjeru ne odlazi timu za proizvod kao potvrđena ranjivost. Generativni model traži mogući put do propusta, ali završni dokaz mora proizvesti odvojeni alat u pokrenutoj aplikaciji.

Kako hipoteza postaje prijava

Agent istražuje kod i površinu aplikacije te oblikuje hipotezu o mogućem napadu. Većina uporabe PageBreaka oslanja se na modele Gemini, no model može pogrešno protumačiti putanju zahtjeva ili previdjeti zaštitu koja blokira napad. Zato njegova uvjerljiva analiza još nije prijava: hipoteza se prosljeđuje validatoru prilagođenom vrsti propusta i načinu pristupa aplikaciji, primjerice HTTP-u ili gRPC-u.

Validatori su specijalizirani alati koje nije napisao AI agent. Pokušavaju proizvesti predviđeni učinak i utvrditi može li se on opaziti u pokrenutom sustavu. Ako provjera uspije, tim za proizvod dobiva nalaz s reproduciranim napadom i može procijeniti kontekst, rizik i popravak. Ljudska procjena pritom ostaje potrebna, ali više ne počinje samo od teksta koji je model napisao o sumnjivom kodu.

Nepotvrđena hipoteza ima drukčiju ulogu. Može poslužiti kao polazište za sljedeće pokretanje agenta, pokazati koja vrsta validatora nedostaje ili otkriti da sustav nema potreban pristup okolini. Takvi se kandidati zadržavaju u sigurnosnom procesu. Time se smanjuje broj neutemeljenih prijava poslanih timovima za proizvode, ali se otvara drugo pitanje: koliko stvarnih propusta ostaje bez potvrde jer ih sadašnji validator ne može reproducirati.

Što zasebni validator može dokazati

Kod XSS-a test ubacuje određeni JavaScript sadržaj, učitava zahvaćenu adresu kroz mehanizam za prikaz stranice i prati izvršava li se skripta u kontekstu web-stranice. To je presudan korak jer samo pojavljivanje opasnog niza u kodu ili odgovoru poslužitelja ne pokazuje da ga preglednik može izvršiti. Dokaz je opaženo izvršavanje pod uvjetima koji se mogu ponoviti; upravo ono razlikuje aktivan propust od uvjerljive, ali neuspjele hipoteze.

Za druge klase ranjivosti mijenja se ono što alat mora opaziti. Kod SQL injekcije prati može li umetnuti sadržaj promijeniti upit bazi podataka, što se može vidjeti u odgovoru ili vremenu odgovora. Kod prolaska kroz putanju datoteke pokušava pročitati pripremljenu datoteku; kod udaljenog izvršavanja koda traži učinak poput odgode, zapisane datoteke ili izlaznog mrežnog zahtjeva. Za krivotvorenje poslužiteljskog zahtjeva provjerava šalje li aplikacija očekivani zahtjev internoj usluzi.

Ta metoda traži mjerljiv učinak, ali je doseg svakog testa ograničen. Validator mora imati prikladnu vrstu testa, pristup potrebnoj površini aplikacije i siguran način opažanja posljedice. Složeniji slijed koraka može ostati izvan dosega postojećeg alata, čak i kada agent prepozna mogući problem. Stoga nizak udio pogrešnih prijava ne govori ništa izravno o udjelu stvarnih ranjivosti koje sustav nije uspio pronaći ili potvrditi.

Što otkrivaju primjeri i brojke

U iThomeovu izvješću opisana su tri primjera propusta visoke ozbiljnosti koje je PageBreak pronašao u aplikacijama koje su sigurnosni stručnjaci ranije pregledavali. Jedan se odnosi na admin.google.com: za uspješan XSS zahtjev je morao imati valjan potpis. Agent je zatim pronašao drugu pristupnu točku preko koje se takav potpis mogao pribaviti za zlonamjerni parametar. Primjer pokazuje zašto pronalazak sumnjivog mjesta u kodu nije dovoljan; važan je cijeli put kojim ulaz prolazi kroz zaštitu.

Prema prikazu crypto.newsa, do 4. rujna 2026. skener je u stotinama aplikacija izgrađenih na Googleovim web-okvirima s pojačanim sigurnosnim jamstvima pronašao dva XSS propusta, ograničena na interne aplikacije ili razvojne pristupne točke s nedostacima u zaštiti. To je posebna skupina unutar Googleova okruženja. Njezina se brojka ne može pretvoriti u postotak učinkovitosti okvira ili agenta bez podataka o opsegu i usporedivosti testiranja.

Širi prijavljeni zbroj također nema javnu razdiobu po aplikaciji, ozbiljnosti i broju pregledanih mjesta. Objavljena metodologija objašnjava kako se kandidati potvrđuju, ali ne pruža neovisno ponovljen test na istom skupu aplikacija ni usporedbu s drugim alatima pod jednakim uvjetima. Zato je prijavljena stopa lažnih uzbuna opis Googleova internog procesa, a ne javno potvrđena mjera koju bi se moglo preslikati na drugu organizaciju.

Zašto je Googleovo okruženje dio rezultata

PageBreak koristi više od modela. Googleovo zajedničko spremište koda dopušta praćenje putanje kroz različite usluge i njihove konfiguracije; sigurnosni signali iz stvarnog HTTP prometa pomažu povezati zahtjev s izvornim kodom. Postojeća infrastruktura skeniranja može se autentificirati u mnoge interne web-aplikacije. Ta kombinacija povećava broj dostupnih ciljeva i olakšava validatoru da na pokrenutom sustavu provjeri ono što agent predloži.

Takav pristup objašnjava zašto se rezultat ne može svesti na izbor modela Gemini. Organizacija bez usporedivog pristupa kodu, prometu, testnim okruženjima i internim aplikacijama imala bi drukčiju vidljivost i drukčije mogućnosti reprodukcije napada. I unutar Googlea se agent pokreće u ponovljenim pokušajima jer model ponekad krene neproduktivnim putem. Provjera izvedivosti smanjuje šum u prijavama, dok opseg pretrage i dalje ovisi o tome kamo agent i njegovi alati mogu doprijeti.

PageBreak već surađuje s inicijativama za automatsko predlaganje popravaka, među njima s CodeMenderom, a planirano je dublje povezivanje. Cilj je da timu za proizvod uz potvrđeni propust stigne i prijedlog ispravka koji treba pregledati. Objavljeni podaci zasad ne mjere koliko se takvih prijedloga prihvaća ni skraćuju li vrijeme do popravka; upravo će taj ishod pokazati koliki dio koristi od pouzdane prijave prelazi u stvarno uklanjanje ranjivosti.