Yapay zekâ ajanlarını masaüstünde güvenli biçimde çalıştırmak için kullanılan “harness” katmanı, model ile yerel araçlar arasında onay kapıları, oturum yönetimi ve uzaktan yordam çağrısı (RPC) köprüleri kurar. Açık kaynak OpenHuman da hem masaüstü ajan ortamı hem de Rust tabanlı bir kütüphane sunan bu tür bir proje. ABD Ulusal Güvenlik Açığı Veritabanı’nda (NVD) CVE-2026-54145 koduyla izlenen açık, CVSS ölçeğinde 8.8 puanla yüksek seviyede derecelendirildi ve 0.57.5 öncesi sürümleri etkiliyor.
Özetle sorun şu: Gate onay oturumlarında JSON-RPC bearer token, oturum anahtarı gibi kullanılıyor; aynı token ise onay kayıtlarında, olay loglarında, hata ayıklama çıktılarında ve RPC yanıtlarında görünebiliyor. Token’ı ele geçiren biri, çekirdek RPC arayüzüne yetkili erişim kazanabiliyor. Yani “insan onayı” için kurulan kapı, yanlış yerde tutulan anahtar yüzünden bypass edilebilir hale geliyor.
OpenHuman ve Gate onay oturumu nedir?
OpenHuman, ajanın dosya okuma, komut çalıştırma veya dış araç çağırma gibi riskli işlemlerinden önce kullanıcıdan onay almasını sağlayan bir kontrol düzlemi sunuyor. “Gate” adı verilen bu onay katmanı, ajanın her istediğini sessizce yapmasını engellemeyi amaçlıyor. Onay akışı ise çoğu zaman yerel bir RPC kanalı üzerinden yürüyor; istemci bir bearer token ile kimliğini kanıtlıyor.
Bearer token, “bu isteği yapan taraf yetkili” anlamına gelen bir taşıyıcı anahtardır. Token’ı bilen taraf, ek parola sormadan RPC arayüzüne istek atabilir. Bu yüzden token’ın yalnızca bellek içinde ve güvenli kanallarda kalması, loglara ve kalıcı kayıtlara yazılmaması temel bir kuraldır. Denetim izi tutulurken bile anahtarın kendisi değil, işlemin özeti kayda geçmelidir.
Sızıntı nerede oluşuyor?
CVE-2026-54145’e göre Gate onay oturumlarında kullanılan JSON-RPC bearer token, oturumu tanımlayan anahtar olarak da işleniyor. Bu tasarım, token’ın onay kaydı gibi denetim izlerinde tutulmasını kolaylaştırıyor. NVD ve OpenHuman güvenlik duyurularına göre token şu yerlerde görünür hale gelebiliyor:
- Onay kayıtları (hangi işlemin ne zaman onaylandığına dair kalıcı kayıtlar),
- Olay logları,
- Hata ayıklama (debug) çıktıları,
- RPC yanıtları.
Bir güvenlik veya destek ekibinin log dosyasını paylaşması, hata ayıklama çıktısını bir issue’ya yapıştırması ya da onay geçmişinin yedeklenmesi, farkında olmadan geçerli bir oturum anahtarını da dışarı taşıyabilir. Token bir kez sızdığında saldırgan çekirdek RPC arayüzüne yetkili istekler gönderebilir; yani onay kapısının arkasındaki kontrol düzlemine oturmuş gibi davranabilir. Bu erişim, ajanın yerel araçlarına giden komut yolunu da açabilir.
Stable ve launch-specific token’lar
Duyurularda iki token ömrü ayrımı yapılıyor. Stable token’lar, kullanıcı bunları çevirene (yenileyene) kadar geçerli kalıyor. Launch-specific token’lar ise ilgili çekirdek instance aktif olduğu sürece yaşıyor. Pratikte bu, sızıntının etkisinin “bir kerelik oturum” ile sınırlı kalmayabileceği anlamına geliyor. Özellikle stable token ele geçtiyse, uygulama yeniden başlatılsa bile token çevrilmeden erişim sürebilir. Launch-specific token’lar daha kısa ömürlü görünse de, uzun süre açık kalan bir çekirdek süreci boyunca risk devam eder.
Düzeltme: 0.57.5 ve token çevirme
OpenHuman açığı 0.57.5 sürümünde gideriyor. Ancak yalnızca yükseltmek yetmeyebilir. Güvenlik duyurularının vurguladığı gibi, sızıntıya uğramış olabilecek token’ların çevrilmesi (revoke / rotate) gerekiyor. Aksi halde eski loglarda veya paylaşılan debug çıktılarında kalan token, yamalı sürümde bile bir süre geçerli kalabilir. Güncelleme ile anahtar yönetimi birlikte düşünülmeli.
Ekipler için önerilen adımlar:
- OpenHuman sürümünü kontrol edin; 0.57.5 öncesindeyseniz hemen yükseltin.
- Güncellemeden sonra tüm stable token’ları çevirin; aktif launch-specific oturumları sonlandırıp yeniden başlatın.
- Onay kayıtları, olay logları ve debug çıktılarının token içerip içermediğini tarayın; gerekirse eski logları kısıtlı erişimli depoya alın veya silin.
- Log paylaşım politikasını gözden geçirin: Hata ayıklama çıktısını herkese açık issue’lara yapıştırmadan önce gizlilik süzgecinden geçirin.
- RPC arayüzünü yalnızca yerel veya güvenilir ağa açık tutun; internete doğrudan maruz bırakmayın.
Ajan güvenliğinde “onay kaydı” paradoksu
Onay kapıları, ajanların denetlenebilir olması için var. Ancak denetim izine oturum anahtarını yazmak, denetimi bir saldırı yüzeyine çevirir. CVE-2026-54145, kimlik bilgisinin “işlevsel anahtar” ile “denetim kaydı” rollerinin birbirine karıştırılmaması gerektiğini somutlaştırıyor. Token kanıtlamalı, kayıt ise yalnızca işlemin özetini tutmalı. CVSS 8.8 puanı da bu karışıklığın pratik etkisinin yüksek olduğunu gösteriyor: Ağ üzerinden veya paylaşılan kayıtlardan gelen bir sızıntı, yerel kontrol düzlemini ele geçirmeye yetebilir.
Kendi ajan altyapısını kuran ekipler için ders geniş: Loglama ne kadar ayrıntılıysa, sızıntı yüzeyi de o kadar büyür. Özellikle JSON-RPC, gRPC veya benzeri yerel kontrol kanallarında bearer token’ların yanıt gövdesine, hata mesajlarına ve onay geçmişine yazılmadığından emin olunmalı. OpenHuman kullanıcıları için yol haritası net: 0.57.5’e geçin, token’ları çevirin, eski kayıtlarda kalan sırları temizleyin. Aksi halde “güvenli onay” katmanı, anahtarı kendi defterine yazmış bir kapı gibi davranır.
Pratik etki: onay kapısı bypass’ı
CVSS 8.8 puanının arkasındaki senaryo, çoğu zaman “uzaktan herkese açık bir admin paneli” değil; token’ın göründüğü bir log, debug çıktısı veya onay kaydının yanlış ellere geçmesi. Kurumsal ortamlarda loglar SIEM’e, destek sistemlerine veya üçüncü taraf araçlara akar. Token bu akışa bir kez girdiyse, çekirdek RPC arayüzüne yetkili erişim artık fiziksel makineye oturmayı gerektirmeyebilir. Bu yüzden OpenHuman duyurusu yalnızca “sürüme yükseltin” demekle kalmıyor; token çevirmeyi de şart koşuyor. Yamayı uygulayıp eski anahtarları yerinde bırakmak, kapıyı yenileyip eski anahtarı cebinde unutmaya benzer.
Kaynak: ABD Ulusal Güvenlik Açığı Veritabanı (NVD), OpenHuman güvenlik duyuruları
