Gemini Live API'de Kritik Token Güvenlik Açığı

Haziran 2026'nın sonlarında, güvenlik araştırmacısı Alvin Ferdiansyah, Google'ın Gemini Live API geçici token (ephemeral token) sisteminde kritik bir yapılandırma hatası olarak tanımladığı bir durumu detaylandıran kapsamlı bir yazı yayınladı. Bu açık, kısa ömürlü bir WebSocket token'ını ele geçiren bir saldırganın, tarayıcı tabanlı bir AI ses oturumunu tamamen ele geçirmesine, yani modeli, sistem komutunu (system prompt) ve hatta oturumun çalıştırabileceği araçları kontrol etmesine olanak tanıyor ^A.

Güvenlik açığının özü, token oluşturma (minting) sırasında eksik olan bir güvenlik alanından kaynaklanıyor. İşte bilinenler, henüz doğrulanmamış olanlar ve geliştiricilerin şu anda dağıtımlarını nasıl koruyabilecekleri.

Gemini Live API Geçici Token Sistemi Nasıl Çalışır?

Gemini Live API, tarayıcıdan sunucuya WebSocket bağlantıları için geçici token'lar kullanır. Bunlar, hızlıca süresi dolan ve belirli kullanımlarla kısıtlanabilen kısa ömürlü kimlik doğrulama token'larıdır ^A. Bu token'lar bir arka uç sunucusu tarafından oluşturulur ve istemciye verilir. İstemci, bu token'ı kullanarak, asıl API anahtarını açığa çıkarmadan doğrudan Gemini API'sine bağlanır.

Google dokümantasyonu, geçici token'ların güvenliğin önemli olduğu istemciden sunucuya uygulamalar için tasarlandığını, çünkü token'ın kısa ömrünün olası bir sızıntıda hasarı sınırladığını belirtir ^A. Bu kısıtlı bağlantılar için kullanılan uç nokta (endpoint) BidiGenerateContentConstrained olup, geçici token'ı access_token sorgu parametresi olarak kabul eder ^DS.

Eksik live_connect_constraints Alanı

Ferdiansyah'ın yazısına göre, token oluşturma için kullanılan referans uygulama live_connect_constraints alanını içermiyordu ^A. Bu alanın, token'ı belirli bir modele, sistem talimatına ve araç setine bağlayan bir bidi_generate_content_setup nesnesi içermesi gerekiyordu.

live_connect_constraints boş bırakıldığında veya hiç eklenmediğinde, herhangi bir kısıtlama uygulanmaz. Geçici token'ı ele geçiren bir saldırgan, daha sonra istediği modeli, sistem komutunu ve araçları belirten istemci tarafından kontrol edilen bir kurulum çerçevesi (setup frame) gönderebilir. Token'da bağlayıcı değerler olmadığı için sunucu, saldırganın yapılandırmasını kabul eder.

Önemli Uyarı: Sağlanan kaynaklar, live_connect_constraints için Google'ın resmi dokümantasyonunu, bir CVE'yi veya bu davranışı doğrulayan bir Google güvenlik bültenini içermemektedir. Bu iddia, Ferdiansyah'ın Medium yazısına dayanmaktadır ve doğrulanmamış ancak olası olarak değerlendirilmelidir ^A.

Etkisi: Saldırgan Kısıtlamasız Bir Token ile Ne Yapabilir?

Eğer güvenlik açığı gerçekse, sonuçları Gemini Live API'sini tarayıcı bağlamında kullanan herhangi bir uygulama için ciddi olabilir:

• Araçlar Yoluyla Korumalı Alan Kod Çalıştırma (Sandboxed Code Execution via Tools): Gemini Live API örnekleri, özel araçlar eklemek için istemci tarafı desteği içerir ^D. Kötü niyetli bir araç tanımı enjekte edebilen bir saldırgan, potansiyel olarak uygulamanın korumalı alanı içinde kod çalıştırabilir.
• İşlem Gücü İstismarı (Compute Abuse): Ele geçirilen bir oturum, mağdur uygulamanın kotasını ve faturalandırma tahsisatını tüketir. Geçici token'lar tek kullanımlık bağlantılar için tasarlandığından, bir saldırgan arka uçtaki token oluşturma uç noktasından tekrar tekrar yeni token talep ederek maliyetleri artırabilir ^G.
• Komut Değiştirme (Prompt Tampering): Kurulum çerçevesini kontrol etmek, sistem talimatını kontrol etmek anlamına gelir. Saldırgan, oturumu hassas bilgileri çıkarmak, zararlı içerik üretmek veya güvenilir bir aracı taklit etmek için kullanabilir ^D.
• Tekrarlanan Oturum İstismarı (Repeated Session Abuse): Canlı API oturumlarının yaklaşık 10 dakikalık bir bağlantı sınırı vardır ^DD. Saldırganın yeniden bağlanması gerekir, ancak aynı kısıtlamasız token akışını kullanarak oturumu defalarca tekrar ele geçirebilir.

Google AI forumundaki geliştiriciler, geçici token'ların sistem talimatlarını yok saydığına ve kısıtlı uç noktalarla beklendiği gibi çalışmadığına dair sorunlar bildirmiş, bu da ekosistemin henüz olgunlaşma aşamasında olduğunu göstermektedir ^DD.

Tek Alanlık Çözüm

Ferdiansyah tarafından açıklanan düzeltme oldukça basittir: Token oluşturma sırasında live_connect_constraints.bidi_generate_content_setup alanını üç değerle doldurun:

1. model — Kullanılacak tam Gemini modeli (ör. models/gemini-2.5-flash-native-audio-latest).
2. system_instruction — Amaçlanan sistem komutu, text içeren parts şeklinde yapılandırılır.
3. tools — İstemci tarafından araç enjeksiyonunu önlemek için boş bir dizi [] veya yalnızca açıkça izin verilen araçlar.

İşte Ferdiansyah'ın yazısından örnek bir Python kodu ^A:

token = gemini_client.auth_tokens.create({
    "uses": 1,
    "expire_time": now + timedelta(seconds=60),
    "new_session_expire_time": now + timedelta(seconds=60),
    "live_connect_constraints": {
        "bidi_generate_content_setup": {
            "model": "models/gemini-2.5-flash-native-audio-latest",
            "system_instruction": {
                "parts": [{"text": "Sen bir müşteri destek asistanısın..."}]
            },
            "tools": []
        }
    }
})

Not: live_connect_constraints, kaynaklarda sağlanan resmi Google API referansında belgelenmediğinden, bu örnek Ferdiansyah'ın kendi açıklamasına dayanmaktadır ve üretimde kullanılmadan önce gerçek API'ye karşı test edilmelidir ^A.

Hala Doğrulanmamış Olanlar

Aşağıdaki önemli noktalar sunulan kaynaklar tarafından doğrulanmamıştır:

• Hiçbir resmi Google dokümantasyonu live_connect_constraints'in varlığını veya şemasını doğrulamamaktadır.
• Hiçbir CVE veya güvenlik bülteni yayınlanmamıştır.
• Güvenlik açığının bağımsız bir tekrar üretimi kaynaklarda yer almamaktadır.
• BidiGenerateContentConstrained uç noktasının, kısıtlamasız bir token aldığında tam olarak nasıl davrandığı, sağlanan resmi referanslarda belgelenmemiştir ^DS.

Geliştiriciler Şimdi Ne Yapmalı?

Google resmi bir bülten yayınlayana kadar, en güvenli yaklaşım güvenlik açığını olası kabul etmek ve düzeltmeyi proaktif olarak uygulamaktır:

1. Geçici token oluşturma kodunuzu denetleyin: Arka uç sisteminizin live_connect_constraints veya eşdeğer alanı doldurup doldurmadığını kontrol edin.
2. Ham API anahtarlarını asla açığa çıkarmayın: Tarayıcıya yönelik bağlantılar için her zaman geçici token'lar kullanın ^S.
3. Sıkı token süre sonu belirleyin: Google, token hırsızlığı penceresini sınırlamak için newSessionExpireTime değerinin yaklaşık 60 saniye olarak ayarlanmasını önerir ^G.
4. Kurulum çerçevelerini sunucu tarafında doğrulayın: İstemciler kendi yapılandırmalarını gönderse bile, arka uç sisteminiz amaçlanan modeli, komutu ve araçları zorunlu kılmalıdır.
5. Kötüye kullanımı izleyin: Özellikle aynı token'dan tekrarlanan bağlantılar veya beklenmeyen araç çağrıları gibi olağandışı oturum modellerini izleyin.

Gemini Live API, gerçek zamanlı ses ve video deneyimleri oluşturmak için güçlü bir araçtır. Token oluşturma sürecindeki tek bir eksik alan bu yeteneği zayıflatmamalıdır; ancak geliştiriciler uygulamalarının eksiksiz olduğundan emin olmalıdır.

Bu makale, resmi Google dokümantasyonu, topluluk forumu tartışmaları ve orijinal araştırmacının yazısı dahil olmak üzere 27 kaynağa dayanarak doğrulanmıştır. Araştırmacının temel iddiaları, yayın anında resmi kaynaklardan bağımsız olarak doğrulanamamıştır.