Model Context Protocol için kullanılan resmi MCP Python SDK’sındaki bir güvenlik açığı, kötü niyetli sunucuların OAuth ile girişte kullanılan kimlik bilgilerini ele geçirmesine kapı aralayabiliyor. Etkilenen sürümlerde saldırgan kontrolündeki bir token uç noktasına istemcinin client secret değeri, authorization code ve PKCE proof key bilgisi gönderilebiliyordu.
Açık, HTTP üzerinden MCP istemcisi olarak çalışan ve belirli OAuth sağlayıcılarını kullanan uygulamaları etkiliyor. Düzeltme 1.x hattında 1.30.0, 2.x hattında ise 2.2.0 sürümlerine eklendi.
MCP, yapay zekâ uygulamalarını dış araçlara ve veri kaynaklarına bağlamak için tasarlanmış açık bir standart. Python paketi de bu ekosistemde MCP sunucusu ve istemcisi geliştirmek için resmi SDK olarak kullanılıyor. Güvenlik incelemesini yapan ekip, açığın gerçek bir hizmete girişte kullanılan OAuth akışını saldırganın kontrol ettiği bir yönlendirmeye çevirebildiğini bildirdi.
İncelemeye göre saldırgan, ele geçirdiği kimlik bilgileriyle gerçek oturum açma servisinden geçerli bir access token talep edebiliyor. Test ortamında bu akışı doğrulayan güvenlik firması, alınan token’ın uygulamaya verilen izinleri taşıdığını aktardı. Client secret uzun ömürlü olduğu için değiştirilene kadar çalışmaya devam ediyor.
Açığın risk puanı, müdahale olmadan çalışan iki sağlayıcı için 7.5 olarak verildi. Oturum açma işlemi bir kişinin başlatmasını gerektiren etkileşimli sağlayıcıda ise puan 6.5’e düşüyor. 29 Eylül itibarıyla bu açık için bir CVE numarası atanmış değildi.
Sorun, MCP istemcisinin bir sunucuya bağlanırken önce o sunucunun hangi yetkilendirme sunucusunu kullandığını sormasıyla başlıyor. Etkilenen sürümlerde SDK, verilen cevabı her zaman doğrulamıyordu. Bu yüzden kötü niyetli bir MCP sunucusu, istemciyi saldırganın seçtiği bir giriş hizmetine yönlendirebiliyordu. Bunu ya doğrudan kendi sunucusunu işaret ederek ya da kullanıcının gerçek hizmetini gösteren giriş bilgileri verip kimlik bilgilerini başka bir hedefe aktararak yapabiliyordu.
İstemci daha sonra secret, authorization code ve PKCE proof key değerlerini gerçek servis yerine saldırgana gönderiyordu. PKCE proof key, çalınan authorization code’un yeniden kullanılmasını engellemek için tasarlanan tek kullanımlık bir değer. Bu anahtarın da ele geçirilmesi, korumanın devre dışı kalması anlamına geliyor.
Etkileşimli sağlayıcı kullanıldığında kullanıcıdan yine de giriş onayı isteniyor. İncelemeyi yapan ekip, onay ekranının gerçek giriş sayfası olduğunu ve ilk bakışta şüpheli bir şey görünmediğini belirtti. Buna karşılık makineden makineye çalışan iki sağlayıcıda hiçbir kullanıcı etkileşimi gerekmiyor.
Yapılan duyuruya göre açık, MCP istemcisi olarak HTTP üzerinden çalışan ve OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider ya da artık kullanılmayan 1.x RFC7523OAuthClientProvider sağlayıcılarından birini kullanan uygulamaları kapsıyor. Ayrıca bu uygulamanın, gerçek bir giriş servisine ait kimlik bilgilerini taşırken tam olarak kontrol etmediği bir MCP sunucusuna bağlanabilmesi gerekiyor. SDK ile geliştirilen MCP sunucuları, yerel stdio istemcileri ve kendi token’larını doğrudan ekleyen istemciler bu zafiyetten etkilenmiyor.
1.x hattında 1.9.1 ile 1.29.1 arasındaki sürümler, 2.x hattında ise 2.0.0 ile 2.1.1 arasındaki sürümler açık içeriyor. Düzeltme, 1.x için 1.30.0 ve 2.x için 2.2.0 sürümlerinde yer alıyor.
Güncelleme tek başına her durum için yeterli değil. ClientCredentialsOAuthProvider veya PrivateKeyJWTOAuthProvider kullananların, kimlik bilgilerinin ait olduğu giriş servisini belirtmek için ayrıca issuer= parametresini geçmesi gerekiyor. Aksi halde istemci, MCP sunucusunun işaret ettiği servise göre hareket etmeye devam ediyor.
1.30.0 sürümünde bu uyarı standart bir kullanım dışı bırakma bildirimi olarak geliyor. Python bu tür uyarıları varsayılan olarak gizlediği için gözden kaçabiliyor. Kullanımdan kaldırılan RFC7523OAuthClientProvider’da ise issuer= seçeneği bulunmuyor; bu nedenle geliştiricilerin diğer iki sağlayıcıdan birine geçmesi gerekiyor.
Güncellemeden sonra daha önce saklanmış OAuth client registration kayıtlarının bir kez temizlenmesi gerekiyor. Çünkü eski kayıtlar bir yetkilendirme servisine bağlı olmadan kalabiliyor ve bu durum yeni sürümde de devam edebiliyor. Bir istemci daha önce güvenilmeyen bir sunucuya bağlandıysa, client secret’ın döndürülmesi ve yetkilendirme servisinde token’ların iptal edilmesi isteniyor. Eski sürümler içinse güvenilmeyen MCP sunucularına bağlanmaktan başka bir geçici yol bulunmuyor.
Açığı kapatan issuer kontrolleri, 7 Eylül’de yayımlanan 1.30.0 ve 2.2.0 sürüm notlarında davranış değişikliği olarak yer almıştı. Güvenlik duyurusu 28 Eylül’de yayımlandı ve aynı gün teknik inceleme de paylaşıldı. Duyuruda sekiz araştırmacı kredilendirildi; bunların arasında bulguyu bildiren güvenlik firmasından bir araştırmacı da bulunuyor.
Şu ana kadar bu zafiyeti kullanan herhangi bir saldırı bildirimi yapılmadı. Duyuru metni de teknik inceleme de aktif istismar belirtisi aktarmıyor.