OpenCode kimlik bilgisi sızıntısı barındırılan Console hizmetini etkiledi, CLI'yı değil

Gerçekte ne ihlal edildi

2026-10-17 tarihinde dolaşıma giren haberler olayı, OpenCode'un hacklendiği ve kullanıcı kimlik bilgilerinin sızdırıldığı şeklinde aktardı. Önceden agentjournal.dev'de yayımlanan, dev.to'daki bir yazıya göre ifşa edilen sistem, çoğu insanın günlük olarak kullandığı komut satırı kodlama ajanı değildi. İfşa edilen sistem, ekiplerin sağlayıcı hesaplarını bağlayarak üyelerin bunları paylaşabildiği ve bu sağlayıcı kimlik bilgilerini kendi tarafında saklayan isteğe bağlı bir barındırma hizmeti olan OpenCode Console'du. Buna karşılık yerel ajan, anahtarları kullanıcının makinesindeki bir dosyada tutar ve istekleri yapılandırmanın belirttiği uç noktaya gönderir.

Satıcı ne dedi

Yazı, OpenCode ekibinden alınan ve "kullanımdan kaldırma sürecinde olan eski bir sisteme yetkisiz erişim" olduğunu kabul eden bir açıklamaya yer veriyor. Açıklamada, bir çalışma alanına kaydedilmiş OpenAI veya Anthropic anahtarları gibi üçüncü taraf sağlayıcı anahtarlarının ifşa olmuş olabileceği belirtiliyor ve etkilenen kullanıcılardan bu anahtarları sağlayıcı tarafında iptal edip yenilerini almaları, bunları kullanan her şeyi güncellemeleri ve son kullanım kayıtlarını incelemeleri isteniyor.

Aynı yazı, olayı sağlayıcı tarafından anlatan bir OpenAI müşterisinin aldığı e-postayı da aktarıyor: bir saldırganın müşteri API anahtarlarını barındıran bir sisteme eriştiği, etkilenen anahtarlardan birinin bu kuruma ait olduğu ve söz konusu anahtarın zaten devre dışı bırakılmış olduğu bildiriliyor.

Yazıda ayrıca tartışma başlığının 975 puana ulaştığı ve 37 üst düzey yorum alduğu, tartışmaların çoğunun ihmalin kendisinden çok hangi ürünün ihlal edildiği konusunda olduğu belirtiliyor.

Ortak isim neden kafa karışıklığına yol açtı

Yazı, hizmetin dokümantasyonuna atıfta bulunarak Console'un tasarımının saklama (custody) üzerine kurulu olduğunu açıklıyor: kullanıcılar halihazırda ödedikleri sağlayıcı hesaplarını bağlar, hizmet her kimlik bilgisini saklar ve sağlayıcıları kendi gateway'i üzerinden sunar, modeller bir çalışma alanında paylaşılır. Anahtarı elinde tutmak, paylaşımın çalışmasını sağlayan şeydir.

Yerel ajan ise tam tersini yapar. Sağlayıcı kimlik bilgilerini yerel bir dosyada tutar ve istekleri her sağlayıcı için yapılandırılmış base URL'ye yönlendirir; bu, satıcının barındırılan gateway'i, yerel bir proxy veya üçüncü taraf bir API olabilir. Duyuruda eksik olan tek ayırt edici özellik budur ve bu, kafa karışıklığının büyük kısmını çözer.

Bir kullanıcı ifşayı nasıl doğruladı

Hiçbir zaman Console'a sağlayıcı bağlamamış günlük bir CLI kullanıcısı olan yazar, güvende olduğunu varsaymak yerine dört denetim yaptı. Her sağlayıcının base URL'sini okumak, üç girişin de barındırılan hizmete değil yerel bir gateway olan 127.0.0.1:8787'yi gösterdiğini ortaya koydu. Auth dosyasını listelemek, dosya modu 600 olan üç sağlayıcı girişi gösterdi. Projeler, yetenekler (skills), dotfiles ve shell geçmişi genelinde 38.734 dosyayı tam anahtar dizgileri için taramak sıfır kopya buldu. Yapılandırma deposunun izlenen 49 dosyasının kontrolü, auth dosyasının bunlar arasında olmadığını doğruladı.

Yazıya göre belirleyici denetim uç nokta denetimidir. Loopback yönlendirmesi, anahtarın barındırılan bir çalışma alanında saklanmadığına değil, kullanıcının çalıştırdığı koda sunulduğuna işaret eder. Satıcının gateway URL'sini gösteren bir yapılandırma, bir de connect akışından geçmiş olmak, kullanıcıyı etkilenen kategoriye yerleştirir ve bu anahtarlar iptal edilmelidir.

Denetimler neyi kanıtlamaz

Yerel mod otomatik olarak güvenli değildir. Yazı, üç anahtarın da kullanıcı olarak çalışan her şey tarafından okunabilir düz metin JSON olarak durduğuna dikkat çekiyor; dosya modu 600, makinedeki diğer hesapları durdurur ama aynı kullanıcı altında çalışan ele geçirilmiş bir paketi durdurmaz. Tarama ayrıca, 2026-10-20'deki bir rotasyondan kalma, bir sağlayıcıya ait eski bir değer içeren ikinci bir auth dosyası ortaya çıkardı; yazar bunun ölü olduğunu doğrulayıp silmeyi planlıyordu. Yapılandırma dizini kendisi herkese açık bir depodur ve özel kalması gereken dosyaları ifşa etmek tek dikkatsiz commit uzağınızdır.

Barındırılan anahtar kullanıcıları için önerilen adımlar

Yazı beş adımla kapanıyor. Gerçekte hangi ürünü kullandığınızı, hatıranıza güvenmek yerine yapılandırmayı kontrol ederek belirleyin. Bir sağlayıcıyı barındırılan bir hizmete bağladıysanız, anahtarı yalnızca hizmet içinde devre dışı bırakmak yerine sağlayıcının panelinden iptal edin. Son iki haftanın sağlayıcı kullanım grafiklerini okuyun, çünkü anomaliler herhangi bir bildirim gelmeden önce genellikle faturalandırmada görünür. Anahtarların ikinci kopyalarını depolarda, yedeklerde, shell geçmişinde, CI secrets'larda ve başıboş environment dosyalarında arayın. Ajanın anahtara hiç el koymadığı tasarımları tercih edin, örneğin kimlik bilgilerini ağ katmanında enjekte eden yerel bir proxy gibi.

Neden önemli

Bir ürün ailesini adlandıran bir ihlal bildirimi, kullanıcıya hangi bileşenin vurulduğunu söylemez ve hem yerel hem barındırılan biçimlerde sunulan araçlar bu belirsliği maliyetli hale getirir, çünkü iki durum için doğru remediation tamamen farklıdır. Olay ayrıca kimlik bilgisi paylaşım hizmetlerinin yapısal ödünleşimini gözler önüne seriyor: kolaylıkları tam da anahtarları sunucu tarafında saklamalarından geliyor ve bu, riski tek bir yerde yoğunlaştırıyor. Kodlama ajanı çalıştıran herkes için kalıcı ders mimaridir: kimlik bilgilerini ajanların erişemeyeceği bir yere koyun, çünkü anahtar ajanın erişebildiği bir hizmette dururken ajanı izole etmek pek bir koruma sağlamaz.