Google, Agent Development Kit (ADK) Python deposundaki üç iş akışını kaldırdı. Araştırmacılar, herkese açık bir GitHub issue’sunun ayrıcalıklı bir kod düzeltme ajanını tetikleyebildiğini ve bunun güvenilir bot kimliği üzerinden yetki zinciri kurduğunu gösterdi. Saldırı yolu, kod çalıştırmadan kimlik bilgisi sızdırmaya uzanan bir akış oluşturdu.
Bulgu, dağıtılan ADK Python paketindeki bir kusuru değil, depo otomasyonunu hedef aldı. Pillar Security’nin raporuna göre sorun, GitHub iş akışlarının güvenilmeyen içerikle nasıl ilişki kurduğunda ortaya çıktı. Araştırmacılar, saldırının doğrudan üründe değil, repo tarafındaki otomasyon mantığında şekillendiğini belirtti.
Güvenilir bot kimliği yetki köprüsüne dönüştü
Saldırı zinciri, herkese açık issue-analyze.yml iş akışıyla başladı. Bu iş akışı bir issue açıldığında otomatik olarak çalışıyor, ADK_GCP_SA_KEY ile kimlik doğruluyor, Google’ın Antigravity coding agent aracına ADK_TRIAGE_AGENT ve GOOGLE_API_KEY veriyor ve üretilen analizi adk-bot hesabıyla yoruma dönüştürüyordu.
Pillar Security, kamuya açık issue içeriğinin prompt injection ile yönlendirilebildiğini gösterdi. Araştırmacılar, saldırganın yorumun /adk-issue-fix komutunu adk-bot gibi gönderebildiğini aktardı. Sistem bu hesabı bir işbirlikçi olarak tanıdığı için yorum, ayrıcalıklı iş akışının owner, member ya da collaborator kapısından geçti. Böylece güvenilir bot kimliği, yetkilendirme köprüsüne dönüştü.
İkinci aşama issue-fix.yml iş akışında yürüdü. Bu akış /adk-issue-fix yorumlarını dinliyor ve yalnızca owner, member ya da collaborator tarafından tetiklendiğinde çalışıyordu. Kontrol mekanizması, komutun arkasında dışarıdan manipüle edilmiş güvenilir bir hesap bulunup bulunmadığını değil, yorumu kimin gönderdiğini denetliyordu. Bu ayrım, saldırganın yönlendirdiği bot yorumunu meşru görmesine yol açtı.
Yetkili iş, issues, repository contents ve pull requests için write access tanımlıyordu. Pillar, bu izinlerin GitHub’ın ürettiği GITHUB_TOKEN için geçerli olduğunu, ancak iş akışının gerçekte kullandığı ADK_TRIAGE_AGENT kişisel erişim jetonunun kapsamının kamuya açık olmadığını söyledi. İş akışı depoyu bu PAT ile checkout ediyor, Google Cloud’a bağlanıyor ve ajanı hem PAT hem de API anahtarı ortam değişkenleriyle çalıştırıyordu.
Araştırmacılar, otomasyonun kod yazma, adk-bot fork’u oluşturma, branch gönderme ve pull request açma amacıyla tasarlandığını anlattı. 4 Haziran tarihli bot tarafından üretilmiş bir pull request, bu otomasyonun depoda gerçekten çalıştığını gösteren kanıtlar arasında yer aldı.
İş akışının bir başka ayrıntısı da yorum tabanlı tetiklemenin doğrudan hesap statüsüne bakmasıydı. Kullanıcı adı ya da hesabın arkasındaki içerik manipülasyonu değil, yalnızca posted command sahipliği kontrol ediliyordu. Bu yapı, dışarıdan yönlendirilmiş bir bot yorumunun yetkili akış içinde normal bir talep gibi işlenmesine imkan verdi.
CI üzerinde kod çalıştırma ve kimlik bilgisi sızıntısı
Gösterimde saldırganın continuous integration (CI) runner üzerinde keyfi kod çalıştırabildiği ve botun personal access token’ını dışarı sızdırabildiği ortaya kondu. Ayrıcalıklı iş akışında ayrıca bir Google API anahtarı ile Google Cloud hizmet hesabı kimlik bilgisi de bulunuyordu. Araştırmacılar, proof-of-concept saldırılarının sahada aktif istismarı ya da ADK’nin dağıtılmış sürümünün ele geçirildiğini göstermediğini de not etti.
Runner tarafında shell metakarakterleri reddediliyor, ilk token’ı gh ya da git olmayan komutlara izin verilmiyordu. Buna karşın betik CapabilitiesConfig() özelliğini etkinleştiriyordu. Google’ın Antigravity SDK dokümantasyonuna göre bu ayar, yazma işlemleri dahil tüm araçları açıyor. Araştırmacılar, ajanı bir payload yazmaya yönlendirip, izinli bir Git komutunu özel bir hook yolu üzerinden bu payload’ı çalıştıracak biçimde kullanabildi.
Git dokümantasyonu, hook’ların çalıştırılabilir programlar olduğunu ve core.hooksPath ayarının bu dizini başka bir konuma yönlendirebildiğini doğruluyor. Böylece komut listesi daraltılmış olsa da, dosya yazma ile Git’in hook mekanizması kod çalıştırma için bir yol bırakmaya devam etti.
Public kayıtlara göre PAT’nin tam yetkileri açıklanmadı. Google, Pillar’a hizmet hesabının ayrı bir GitHub yönetim projesinde Vertex AI erişimine sahip olduğunu iletti; daha geniş yetkiler paylaşılmadı. Raporda runner üzerinde yürütme ve kimlik bilgisi ifşası anlatılırken, bu kimliklerin depo ya da bulut tarafında ne kadar ileri gidebildiği kamuya açık belgelerle doğrulanmadı.
Araştırma ayrıca daha önce ayrıcalıklı Gemini iş akışları üzerinden sahte bir inceleme izi oluşturabilecek başka bir zinciri de tarif etti. Buna rağmen pull request’in birleşmesi için yine de bir bakımcının müdahalesi gerekiyordu. Bu ayrıntı, otomasyonun tek başına nihai onay yerine geçmediğini gösteren bir başka unsur olarak rapora girdi.
Google, kaldırma commit’inde iş akışlarının güvenilmeyen issue ve pull request içeriklerini geniş depo kimlik bilgileriyle işlediğini yazdı. Şirket, issue-analyze.yml, issue-fix.yml ve pr-analyze.yml dosyalarını, meta verisinde 9 Haziran 2026 yazar tarihi taşıyan bir yama içinde sildi. Pillar, 2 Temmuz tarihinde bu iş akışlarının depoda olmadığını doğruladığını, Google’ın da 21 Temmuz’da sorunun düzeltildiğini teyit ettiğini söyledi.
Hacker News, bot token’ının kapsamı, hizmet hesabı izinleri ve istismar kanıtı hakkında Google’a; proof-of-concept ortamı ve kimlik bilgisi erişimi hakkında ise Pillar Security’ye ulaştı. Her iki kurumdan da yanıt bekleniyordu. 4 Ağustos 2026 tarihinde yapılan kontrol, ana dalın workflow dizininde bu üç dosya adının artık yer almadığını gösterdi.