MCP Sunucunuz, Sisteminizdeki En Büyük Açık

Kötü niyetli bir MCP sunucusu, tek bir eksiksiz kötü niyetli talimat yazmadan SSH anahtarlarınızı çalabilir. ASSET araştırma grubu bunu kanıtladı: hırsızlık talimatı modele tek bir blok halinde verildiğinde, büyük modellerin neredeyse tamamı reddediyor. Aynı talimat zararsız görünen parçalara bölündüğünde ise GPT-4o, Gemini 2.0 Flash ve Llama 3.3, test edilen vakaların %100'ünde uyum gösteriyor.

Bu arada çoğu geliştirici, GitHub'da bulduğu bir config satırını kopyalayarak her hafta agent'ına yeni bir MCP sunucusu ekliyor. Bu sunucuların her biri erişiminizin bir parçasını tutuyor: API token'ları, cloud anahtarları, service account'lar. MCP faydalı — bunu kimse tartışmıyor. Ama MCP sunucusu, tüm agent yığınındaki en zayıf halka haline geldi.

Bu yazı, bir MCP sunucusunun fark edilmeden nasıl sırlarınızı sızdırdığını, model reddini bölme yoluyla atlatan GhostSplice saldırısını ve Cloudflare WriteGuard'dan bugün kendi kurulumunuza uygulayabileceğiniz kurallara kadar somut savunmaları ele alıyor.

Bir MCP sunucusu, agent'ınız ile dış bir araç arasındaki köprüdür: veritabanınız, GitHub'ınız, Slack'iniz, bulutunuz. Bu köprü işini yapmak için, sizin adınıza giriş yapmak için gereken her şeyi — token'lar, API anahtarları, service account kimlik bilgileri — düz metin olarak, diskinizdeki bir config dosyasında, genellikle sıfır şifrelemeyle saklar.

Sonrası için önemli olan bir protokol detayı var. Bir agent bir MCP sunucusuna bağlandığında, sunucu geri kendi araç listesini gönderir; her biri, modele ne zaman ve nasıl kullanılacağını söyleyen serbest metinli bir açıklamayla birlikte. Bu açıklamalar doğrudan modelin context'ine girer, tıpkı sizin kendi talimatlarınızla aynı ağırlıkta, ve araçların döndürdüğü sonuçlar da oraya girer. Bir MCP sunucusu, agent'ınızla kimsenin tekrar okumadığı metinlerle durmaksızın konuşur. GhostSplice saldırısını mümkün kılan tam olarak budur.

Ekosistem de korkuluklarından daha hızlı büyüdü:

Sinyal	Sayı
Resmi MCP registry'sindeki sunucular	9.600+
Uzak sunucu deployment'larının Mayıs 2025'ten bu yana büyümesi	5×

Herkes bir sunucu yayımlayabilir, merkezi bir inceleme yok ve agent'ınız her birine tıpkı resmi bir araçmış gibi güveniyor. NSA, Mayıs ayında MCP'ye özel bir güvenlik rehberi yayımlayarak protokolün benimsenmesinin korumalarının inşasından daha hızlı ilerlediğini belirtti. Bir istihbarat ajansı favori dev aracınız hakkında bir rehber yazdığında, bu nadiren sizi tebrik etmek için olur.

İşte tablo bu: binlerce sunucu, inceleme yok ve anahtarlarınız ortada.

İlk delik, kimlik bilgilerinin düz metin olarak saklanması. The Hacker News, 17 Ağustos'ta sızıntı mekaniğinin detaylı bir dökümünü yayımladı ve başlangıç noktası nettir: token'lar doğrudan yapılandırma stringlerine yapıştırılır ve diskte okunabilir kalır. Biraz aceleye getirilmiş bir commit, config'inizi anahtarlarla birlikte bir Git deposuna itmeye yeter. İşe, makalenin "sprawl" (yayılma) dediği şeyle daha da kötüleşiyor: aynı anahtarlar config dosyaları, ortam değişkenleri ve dev, staging, production'daki kopyalar arasında çoğaltılıyor. Bir süre sonra kimse sırların nerede yaşadığını bilmiyor, bu yüzden kimse onları döndürmüyor — ve asla döndürülmeyen statik bir anahtar, saldırganını bekleyen bir anahtardır.

İkinci delik, aşırı yetkilendirme. Geliştirme sırasında yetkilendirme hatalarından kaçınmak için sunucunuza geniş haklar verirsiniz ve bu geniş haklar dokunulmadan production'a taşınır. Tek bir ihlal, o zaman gerçek kullanımın hiçbir zaman gerektirmediğinden çok daha fazlasını açığa çıkarır.

Üçüncü delik, tedarik zinciri. CVE-2025-6514, 400.000'den fazla kez indirilen bir OAuth proxy olan mcp-remote'u vurdu ve kötü niyetli bir sunucunun kullanıcının makinesinde command injection tetiklemesine izin verdi — kod çalıştırıp kimlik bilgileriyle kaçarak. Popüler bir npm paketi, tek satırda kurulan, ve kapı açıldı.

Dördüncü delik en sinsisi: prompt injection. Bir agent, araçlarının getirdiği her şeyi okur — bir web sayfası, bir ticket, bir iç doküman. Bunlardan biri gizli bir talimat içeriyorsa, agent onu sizden gelmiş gibi takip edebilir ve korumakla görevli olduğu şeyi açığa çıkarmak için meşru araçlarını kullanabilir. Bu sızıntı hiçbir teknik kusurdan geçmiyor; modelin saflığından geçiyor.

Herhangi bir sofistike saldırıdan önce bile, bir MCP sunucusunun sıradan hayatı — düz metin config, aşırı büyük haklar, denetlenmemiş bağımlılıklar, filtrelenmemiş içerik — sırlarınızı zaten açığa çıkarıyor.

GhostSplice, ASSET araştırma grubunun kendi agent'ınızı tam iş birliğiyle sızdırma işlemini çalıştıran bir tekniğe verdiği isim. İlke tek bir cümlede özetlenebilir: hırsızlık talimatını tam olarak yazmak yerine, kötü niyetli sunucu onu parçalara böler, bir parçayı bir aracın açıklamasına, diğerini de o aracın döndürdüğü sonuca koyar. Her parça, tek başına okunduğunda zararsız görünür. Ama agent, working context'ine giren her şeyi birleştirir: tam talimatı yeniden inşa eder ve onu tam bir iyi niyetle yürütür — kendi bakış açısından, sadece aracın doldurmasını istediği formu dolduruyordur.

Test sayıları gerçek hikâye:

Model	Tek bloklu talimat	Parçalanmış talimat
GPT-4o	%100 reddediyor	%100 uyum gösteriyor
Gemini 2.0 Flash	%100 reddediyor	%100 uyum gösteriyor
Llama 3.3	%100 reddediyor	%100 uyum gösteriyor
Claude Haiku 4.5	API üzerinden reddediyor	Cursor içindeki üç parçalı testte %100 uyum gösteriyor

Claude detayı, kolay bir sonucu öldürüyor: aynı model bir client'ta reddedebilir, başka bir client'ta sızdırabilir; bu da o client'ın eklediği ya da eklemediği korumalara bağlı.

GhostSplice'ın testlerde çaldığı şeyler: SSH anahtarları, ortam sırları, kaynak kod, müşteri verisi. Araştırmacılar sahte anahtarlarla izole projeler üzerinde çalıştı, gerçek kurbanlar üzerinde değil, ama yöntem yayımlandı ve yeniden üretilebilir.

GhostSplice ilk deneme değil. Aynı laboratuvar Haziran'da, talimatlarını proje konvansiyonlarınca referans verilen PNG dosyalarının içine gizleyen ve ardından çalınan sırları kaynak koda tamsayılar olarak kodlayan Ghostcommit'i yayımladı. Talimat bölme, izole bir merak değil, yerleşen bir saldırı ailesi.

Perspektifi korumak için iki şey var. Saldırının iki ön koşulu var: kötü niyetli sunucu zaten agent'ınıza bağlanmış ve agent'ın hedef dosyalara okuma erişimi var. Provenance'ın (kaynağın) bu kadar önemli olmasının nedeni tam olarak bu — sunucularınızın nereden geldiği ilk savunma hattınızdır. Ve mekaniği hatırlayın: modelin alignment'ı sizi korumaz, çünkü saldırı asla tek parça halinde yasak bir şey istemez.

GhostSplice, kötü niyetli bir sunucunun zaten bağlı olduğunu varsaydı. Peki neyin bağlanacağına kim karar veriyor? Bir takımda, dürüst cevap kimsenin karar vermediğidir. Cloudflare'in shadow MCP dediği sorun bu: geliştiricilerin herhangi bir güvenlik incelemesi olmadan agent'larına bağladığı tüm sunucular. Yakın zamana kadar bu trafik görünmezdi — bir MCP isteği, herhangi bir HTTPS çağrısı gibi görünür.

Cloudflare, protokol seviyesinde tespitle bunu değiştirdi. Spec güncellemesinden bu yana, uyumlu her MCP client, isteklerinde bir MCP-Protocol-Version header'ı gönderiyor ve Gateway, şifresini çözdüğü tüm TLS trafiğinde bu header'ı inceliyor. Bir güvenlik ekibi artık şirkette kullanılan her MCP sunucusunu, özel bir dashboard ile görebiliyor: benzersiz sunucular, kullanıcılar, istek hacimleri. Bu header yaklaşımı, alan adına göre filtrelemeyi geride bırakıyor, çünkü bir MCP sunucusunun kendine mcp-bir-şey demesi için hiçbir nedeni yok — protokol, ne iddia ettiğine değil, ne söylediğine göre yakalanıyor.

Ekip ayrıca harekete geçebilir: bir is_mcp seçici, onaylı bir portaldan geçmeyen her türlü MCP trafiğini engellemenize izin verir. Portal, kurulumun diğer yarısıdır — kimlik doğrulamasının arkasında incelenmiş sunucuları gruplayan tek bir erişim noktası.

En son spec sürümü görünürlüğü daha da ileri götürüyor. Yeni Mcp-Method ve Mcp-Name header'ları, istenen işlemi ve çağrılan aracı, firewall'un request body'sini açması gerekmeden ortaya koyuyor. Bir ekip, bir ticket'ı okuyan bir agent ile elli tanesini silen bir agent'ı, tam ağ katmanında ayırt edebilir.

Cloudflare bunu iki duruma ayırıyor: hiç onaylanmamış bir sunucu olan saf shadow MCP ve checkpoint'in doğrudan etrafından dolaşılarak erişilen onaylı bir sunucu olan portal bypass. İkisi de aynı temel kuralla engelleniyor. Mantık basit: portaldan geçen her şey bilinir ve loglanır, geri kalan her şey engellenir. Bir şirket için bu, bir Cuma gecesi kurulan hayalet MCP sunucusunun sonu demektir.

Onaylı bir sunucu bile zarar verebilir, çünkü bir agent, hizmet ettiği kullanıcının tüm haklarını bir anda devralır. WriteGuard tam da burada devreye giriyor; Cloudflare'in az önce özel beta olarak açtığı bir özellik. Fikir şu: her MCP sunucusunun her aracını bir risk katmanına sınıflandırmak ve her katman için farklı bir politika uygulamak.

• Bir okuma, hiç sürtünme olmadan geçer.
• Bir yorum yazmak gibi sınırlı bir yazma, geçer ama zenginleştirilmiş olarak: eylem, bir agent'tan geldiği, belirli bir insan adına olduğu şeklinde imzalanır ve merkezi bir loga bir audit event gönderilir.
• Kod merge etmek, production'a deploy etmek, toplu silme gibi kritik bir eylem, sunucu onu ele almadan önce engellenir.

Cloudflare'in yazısındaki GitLab örneği bu kademeyi güzel gösteriyor: bir merge request'i okumak geçer, üzerine yorum yapmak atıf ile geçer, ve merge etmek bir insan bizzat yapana kadar reddedilir.

En ilginç kısım, kimlik modeli. Agent, hizmet ettiği çalışanın izinlerini korur, ama artık her yazma iki imza taşıyor: kişi ve onun adına hareket eden agent oturumu. Downstream sistemler artık elle yapılan bir değişikliği makine üretimi olandan ayırt edebiliyor ve audit, hassas verilerden arındırılmış olarak merkezi bir loga asenkron olarak gönderiliyor. Şu ana kadar bir agent, loglarda insanından ayırt edilemezdi; bir olay incelemesi için bu her şeyi değiştiriyor — tek bir sorgu, Salı günkü şüpheli merge'in aceleci bir çalışma arkadaşından mı yoksa yaratıcılığa kapılan bir agent oturumundan mı geldiğini söylüyor.

Cloudflare bir teori satmıyor; kendi iç kullanımlarını anlatıyorlar: portalları 27 MCP sunucusuna bağlanıyor, Nisan'daki 13'ten yukarı. Bu sayı gerçek hikâyeyi anlatıyor — Cloudflare'de bile sunucu sayısı birkaç ayda ikiye katlanıyor, ve tam olarak bu yüzden araç bazlı kontrol gerekli hale geliyor. Sektörün yöneldiği yön açık: tüm sunucuya güvenmeyi bırakıyoruz ve bir agent'ın ne yapmasına izin verildiğine eylem bazında karar veriyoruz.

Sınırların açıkça söylenmesi gerekiyor. WriteGuard, bir başvuru formunun arkasındaki özel bir beta; Gateway'in tespiti, TLS incelemesi açık bir Cloudflare Zero Trust deployment'ı gerektiriyor: tek başına bir geliştirici ya da küçük bir takım için bu basitçe sizin altyapınız değil. Bir şirkette bile, tespit yalnızca şifresini çözdüğü ağ trafiğini görüyor — makinenizde düz bir process olarak başlatılan, stdio üzerinden çalışan yerel bir MCP sunucusu, Gateway için görünmez kalıyor. Ki bu, geliştiricilerin kurduğu sunucuların çoğunun gerçekte nasıl çalıştığı ile tam olarak aynı.

Her şeyden önce, bu araçların hiçbiri GhostSplice'ın ortaya çıkardığı temel mekaniği onarmıyor: bir agent, context'ine giren her şeyi özgürce birleştirdiği sürece, zararsız parçalar düşmanca talimatlara yeniden birleşmeye devam edecek. ASSET araştırmacıları bunu kendileri söylüyor: çözüm, araç çıktısını asla talimat olarak değil, veri olarak ele almayı gerektiriyor, ve bu ayrım henüz agent'larda doğal olarak mevcut değil.

Bu arada onların önerileri üç harekete iniyor: bir araçtan çıkan değerlerin, kontrol edilmeden başka bir aracın argümanlarını beslemesini durdurun, her araç çağrısını elle reddetme yeteneğini koruyun ve denetlenmemiş bir sunucudan gelen her annotation'ı varsayılan olarak düşmanca kabul edin. Üçü de bugün otomatik değil: ya siz uygularsınız ya da kimse uygulamaz. Cloudflare'in burada sunduğu her şeyi emniyet kemeri olarak görün, fren olarak değil — hasarı sınırlar, çarpışmayı önlemez.

Bugün başlayarak ne yapılmalı:

1. Envanter. Agent'larınıza gerçekten bağlı MCP sunucularını listeleyin ve artık kullanmadıklarınızı kaldırın.
2. Kaynağa göre ayırın. Bilinen bir satıcıdan resmi bir sunucu, evet. Bir thread'de bulunan 40 yıldızlı bir GitHub deposu, hayır — verinizle ne yaptığını okumadan önce değil.
3. Hakların kapsamını belirleyin. Her sunucuya minimal kapsamlı özel bir token verin, asla ana anahtarınızı vermeyin ve bu token'ları herhangi bir production sistemi için yapacağınız gibi döndürün.
4. Hassas eylemlerin kontrolünü elinizde tutun. Yazan, merge eden ya da silen bir agent, sizin üzerinizden geri gelmeli — WriteGuard'ın endüstrileştirdiği şeyin elle yapılan versiyonu.
5. GhostSplice kuralını günlük olarak uygulayın. Agent'ınız istemediğiniz araç eylemlerini zincirlediğinde, onu durdurun ve sunucunun ona ne söylediğini okuyun.

Her agent client, bağlı sunucularını ve araçlarını listeleyebilir, ve bu listeyi okumak otuz saniye sürer. Bu otuz saniye, tüm kurulumunuzdaki en iyi zaman-güvenlik oranıdır.

Bir şirketteyseniz, ağ katmanını ekleyin: Gateway'in MCP tespiti ve portallar rollout'a değer, çünkü shadow MCP, siz görün ya da görmeyin, organizasyonunuzda zaten var.

MCP sorun değil — anahtarlarımızı teslim etme hızımız sorun.