---
title: "Google PageBreak, exploit ile doğrulayarak 500'den fazla XSS buldu"
description: "Google PageBreak, Gemini ile açık arıyor ve bulguyu yalnızca validator gerçek exploit ile doğrularsa raporluyor. Yaklaşımın sınırları ve dersleri."
image: "https://sezer.in/wp-content/uploads/2026/11/generatedHeaderImage-1791008728252.jpg"
url: "https://sezer.in/haberler/google-pagebreak-xss-ai-agent/"
date: "2026-11-02T16:15:55+03:00"
updated: "2026-11-02T16:15:55+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/google-pagebreak-xss-ai-agent/"
---

# Google PageBreak, exploit ile doğrulayarak 500'den fazla XSS buldu

Google PageBreak, ocakta tam operasyona geçtiğinden beri Google'ın web uygulamalarında 500'den fazla XSS (Cross-Site Scripting) güvenlik açığı buldu. Gemini modelleriyle çalışan agent, bir bulguyu ancak deterministik validator'lar exploit'i çalışan uygulamada yeniden ürettiğinde raporluyor. 500'ü aşan bulgu için bağımsız bir doğrulama yayımlanmadı.

## Cross-Site Scripting nedir, ne işe yarar?

Cross-Site Scripting (XSS), saldırganın bir web uygulamasına zararlı JavaScript yerleştirip bunu başka kullanıcıların tarayıcısında çalıştırabildiği güvenlik açığı sınıfıdır. Oturum çalma, kullanıcı adına işlem yapma ve sayfa içeriğini değiştirme için kullanılır. Kaynağı genellikle kullanıcı girdisinin doğru kodlanmadan sayfaya basılmasıdır. Content Security Policy ve çıktı kodlama başlıca korunma yöntemleridir.

## Google PageBreak modeli karar vermekten neden uzak tutuyor?

LLM ile açık arayan araçların ortak derdi false positive'ler (yanlış pozitif). Model ikna edici bir rapor yazıyor, açık gerçek çıkmıyor, ekip saatlerce doğrulama yapıyor.

Google PageBreak bu sorunu modeli daha akıllı yaparak çözmüyor. Modeli karar noktasının dışına çıkarıyor. Model hipotez üretiyor. Kararı, güvenlik mühendislerinin yazdığı ve agent döngüsünün dışında çalışan sıradan kod veriyor.

Kanıt kriterleri somut: XSS için JavaScript gerçekten çalışmalı. Path traversal (yol geçişi) için herkesin okuyabildiği bir konuma yazılmalı. RCE (Remote Code Execution) için dışarıya bir DNS sorgusu gitmeli.

## Validator mantığını kendi pipeline'ınıza taşımak

Bu yaklaşımın taşınabilir parçası Gemini değil, validator katmanı. Ekibinizde LLM tabanlı bir tarayıcı ya da kod inceleme agent'ı çalışıyorsa önce raporlama kapısını yeniden tanımlayın:

- Her açık sınıfı için kanıt kriteri yazın. XSS'te payload tarayıcıda çalıştı mı, RCE'de DNS sorgusu sizin kontrol ettiğiniz bir sunucuya düştü mü?
- Validator kodunu modelin erişemeyeceği yerde tutun. Model kendi kanıtını üretebiliyorsa kapının anlamı kalmaz.
- Doğrulanamayan bulguları silmeyin, ama geliştirici ekiplere de göndermeyin. Google bunları sonraki taramaları beslemek ve eksik validator'ları görmek için saklıyor.

Asıl iş yükü burada. Her yeni açık sınıfı, birinin yazıp bakımını yapacağı yeni bir kod demek.

## False negative bedeli

Bentkowski bunu kendisi söylüyor: validator'lar her açık türünü ve karmaşık senaryoları kapsamıyor. Yani false negative (yanlış negatif) riski var. Raporlanan bulgu güvenilir, raporlanmayan alan ise belirsiz.

Tek bir payload ile kanıtlanması zor olan sınıflar, örneğin çok adımlı yetkilendirme mantığı hataları, bu modelde kolayca gözden kaçabilir. Bu yüzden bu tür bir aracı pentest ve manuel kod incelemesinin yerine koymak yanlış olur. Onları tamamlayan bir katman olarak konumlandırın.

## Google'ın altyapı avantajı

Google PageBreak, üç şeye yaslanıyor: monorepo ile uçtan uca kod görünürlüğü, canlı HTTP trafiğini kaynak koda bağlayan sinyaller ve web uygulamalarına authentication ile girebilen tarama altyapısı. Dağınık repository'leri ve ayrı ortamları olan bir şirkette agent bu bağlamı aynı netlikte göremez.

Küçük başlamak mantıklı. Tek bir repository, ona bağlı bir staging ortamı ve test hesabıyla authenticated tarama yeterli bir ilk adım.

Sayıya da temkinli bakın. 500'ü aşan bulgu Google'ın kendi beyanı, bağımsız doğrulaması yok. Google, CodeMender entegrasyonuyla geliştirici ekiplerin işini AI'nın ürettiği düzeltmeyi onaylamaya indirmeyi hedefliyor. Aynı deterministik kapıyı düzeltmelere de koyun: yamadan sonra aynı exploit validator'da başarısız olmalı.