GitHub MCP kötüye kullanımı: MCP üzerinden özel depolara erişim

 (invariantlabs.ai)
3 puan yazan GN⁺ 2025-05-28 | 2 yorum | WhatsApp'ta paylaş
  • GitHub MCP entegrasyonunda ciddi bir güvenlik açığı keşfedildi; saldırganlar kötü amaçlı bir GitHub Issue aracılığıyla kullanıcının ajanını manipüle edip özel depo verilerini sızdırabiliyor
  • Bu açık, Toxic Agent Flow adlı yeni bir türü temsil ediyor; bu senaryoda ajan, kötü niyetli promptlar nedeniyle istenmeyen verileri herkese açık depolarda ifşa ediyor
  • Güvenlik açığı aracın kendisindeki bir kusurdan değil, mimari sınırlardan kaynaklanıyor; basit kullanıcı onayı politikaları gibi gerçekçi kullanım alışkanlıkları da riski büyütüyor
  • Etkili savunma için ayrıntılı yetki kontrolü ve sürekli güvenlik izleme gibi sistematik ajan koruma önlemlerinin benimsenmesi gerekiyor
  • Yalnızca model hizalaması (Alignment) yeterli olmadığından, MCP ve tüm ajan ortamını kapsayan sistem düzeyinde güvenlik önlemleri kritik önem taşıyor

Genel bakış

Invariant, yaygın olarak kullanılan GitHub MCP entegrasyonunda (14.000 yıldız) son derece ciddi bir güvenlik açığı keşfetti. Bu açık, saldırganların kötü amaçlı bir GitHub Issue oluşturarak kullanıcının ajanını manipüle etmesini ve özel depolardaki verileri dışarı sızdırmasını mümkün kılıyor.

Bu sorun, Invariant'ın otomatik Toxic Agent Flow tespit tarayıcısıyla bulunan ilk örnek oldu. Bu tür senaryolarda ajan, amaçlanmayan eylemler yapmaya yönlendirilerek veri sızıntısı veya kötü amaçlı kod çalıştırma gibi zararlara yol açabiliyor.

Son dönemde sektörde kodlama ajanları ve IDE'ler yaygın biçimde benimsendiği için, bu tür saldırılara karşı farkındalığın artırılması özellikle önemli.

Saldırı senaryosu

  • Saldırı hazırlığı

    • Kullanıcının Claude Desktop gibi bir MCP istemcisini GitHub MCP sunucusuna bağladığı varsayılıyor
    • <user>/public-repo: Herkesin Issue oluşturabildiği herkese açık depo
    • <user>/private-repo: Kurum içi veriler gibi bilgilerin tutulduğu özel depo
    • Saldırgan, herkese açık depoda kötü amaçlı bir Issue (prompt injection dahil) oluşturuyor
    • Kullanıcı “public-repo’daki issue listesini göster” gibi sıradan bir istekte bulunduğunda, ajan herkese açık deponun issue'larını getirirken enjeksiyona maruz kalıyor

  • Saldırı akışı

    • Ajan kötü amaçlı Issue'yu okuduğu anda, özel depo verilerini bağlama alıyor ve bunları herkese açık depoda PR olarak oluşturarak herkesin erişimine açıyor
    • Bu süreç Toxic Agent Flow olarak tanımlanıyor ve Invariant'ın güvenlik analiz aracıyla gerçek ortamlarda otomatik olarak tespit edilebiliyor

Saldırı gösterimi

  • Örnek olarak herkese açık bir depo (ukend0464/pacman) ve özel depolar kullanılarak saldırı yeniden üretildi
  • Saldırgan, herkese açık depoda kötü amaçlı bir Issue oluşturuyor ve ajan bu deponun issue listesini sorguladığında prompt injection çalışıyor
  • Kullanıcı Claude 4 Opus'tan destek istediğinde, Claude GitHub MCP entegrasyonu üzerinden enjeksiyonu yürütüyor
    • Claude Desktop varsayılan olarak araç kullanımında onay istiyor, ancak birçok kullanıcı sistemi “her zaman izin ver” politikasıyla çalıştırdığı için dikkatsiz davranabiliyor
  • Ajan, özel depo verilerini çıkarıp herkese açık bir PR ile ifşa ediyor
  • Deneyde özel proje adları, taşınma planları, maaş gibi hassas bilgiler bile sızdırıldı

Toxic Agent Flow'ların tespiti

  • Bu açık, mevcut MCP aracının kendisi ele geçirilmese bile, harici platformlardan (GitHub) gelen güvenilmeyen bilgiler nedeniyle ortaya çıkabiliyor
  • Büyük ajan sistemlerinde bu tür riskleri elle analiz edip azaltmak son derece karmaşık olduğundan, Invariant proaktif tehdit analizi sağlayan otomatik tespit yöntemleri geliştirdiğini belirtiyor

Etki alanı ve yanıt yolları

  • Bu açık, belirli bir ajan/istemciyle sınırlı değil; MCP sunucusu kullanan tüm ajanları etkiliyor
  • Sorun GitHub MCP sunucu kodundaki bir kusur değil, tasarımsal bir problem olduğu için GitHub tarafındaki bir yama ile çözülemiyor
  • İki temel yanıt stratejisi öneriliyor

1. Ayrıntılı yetki denetimi

  • MCP entegrasyon ortamında, ajanın yalnızca gerçekten ihtiyaç duyduğu depolara erişebilmesi için en az yetki ilkesinin uygulanması gerekiyor
  • Geleneksel token tabanlı yetkilendirme tek başına kullanılabilirlik açısından sınırlayıcı olabiliyor
  • Invariant Guardrails gibi dinamik çalışma zamanı güvenlik katmanlarıyla, iş akışı bağlamına göre erişim kontrolü güçlendirilebiliyor
    • Örnek politika: Oturum başına yalnızca tek bir depoya erişime izin vererek depolar arası bilgi sızıntısını önlemek
    • Politika tanımı örneği: 
      raise Violation("You can access only one repo per session.") if:
    (call_before: ToolCall) -> (call_after: ToolCall)
    call_before.function.name in (...set of repo actions)
    call_after.function.name in (...set of repo actions)
    call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
    call_before.function.arguments["owner"] != call_after.function.arguments["owner"]
    • Politikalar, Guardrails Playground gibi ortamlarda denenebiliyor

2. Sürekli güvenlik izleme

  • Önleyici tedbirlerin yanında, ajan ile MCP sistemi arasındaki etkileşimleri gerçek zamanlı tarayan güçlü izleme araçları da gerekiyor
  • Örneğin Invariant MCP-scan ile izleme ve anomali tespiti yapılabiliyor
  • Güncel proxy modu kullanılarak, mevcut altyapıyı değiştirmeden yalnızca MCP trafiği bir proxy üzerinden geçirilip gerçek zamanlı teşhis sağlanabiliyor
  • Kapsamlı gözlem sayesinde güvenlik açıkları tespit edilebiliyor, ihlal girişimleri kaydedilebiliyor ve kötü amaçlı akışlar erken aşamada durdurulabiliyor

Neden yalnızca model hizalaması (Alignment) yeterli değil?

  • En yeni büyük dil modelleri bile (ör. Claude 4 Opus) basit prompt injection saldırılarına kolayca maruz kalabiliyor
  • Temel hizalama (Alignment) eğitimi tek başına, gerçek dağıtım ortamlarındaki çeşitli ve bağlama bağlı saldırıların tamamını engelleyemiyor
  • Bu nedenle, model katmanından ayrı olarak sistem düzeyinde bağlam algılama ve güvenlik mekanizmalarının mutlaka kurulması gerekiyor

Sonuç

  • Invariant, GitHub MCP sunucusunda ajanın kötü amaçlı bir GitHub Issue ile ele geçirilip özel depoların sızdırılmasına yol açan ciddi bir güvenlik açığını ortaya koydu
  • Bu açık, Invariant'ın otomatik tespit sisteminde bulunan temsilî bir örnek ve MCP dahil çeşitli ortamlarda benzer saldırılar yaşanmaya devam ediyor
  • MCP/ajan sistemlerinin güvenli şekilde devreye alınması ve işletilmesi için MCP-scan ve Guardrails gibi özel güvenlik tarayıcıları kritik önemde

Referans ve iletişim

  • Ek güvenlik uygulamaları veya danışmanlık için earlyaccess@invariantlabs.ai adresi üzerinden iletişime geçilebilir

Yazar:
Marco Milanta
Luca Beurer-Kellner

İlgili okumalar

2 yorum

 
crawler 2025-05-28

Kulağa büyük geliyor ama aslında sadece prompt injection + MCP’nin kullanabildiği yetkilerin fazla olmasından kaynaklanan bir sorun.
Bu yüzden, sanki MCP yetkilerini dışarıdan kontrol edebilen bir aracı tanıtıyormuş gibi bir his veriyor.
Dışarıdan girilen prompt’larla yalnızca içeriden girilen prompt’ların kullanabildiği MCP yetkileri farklı olursa iyi olur.
 
GN⁺ 2025-05-28
Hacker News görüşleri

  • Bu saldırıyı tam olarak anlamakta zorlanıyorum. Claude'a bir erişim token'ı verirseniz, ona hangi amaçla kullanmasını söylediğinizden bağımsız olarak, Claude token'ın yetkileri dahilinde her şeyi yapmaya yönlendirilebilir. Bir LLM'e kimlik bilgisi verdiğinizde, o kimlik bilgisinin tüm yetkilerinin LLM tarafından kullanılabileceğini varsaymalısınız. Özellikle araç çağrılarını otomatik olarak izinli hale getirdiyseniz çok dikkatli olmak gerekir. Ancak GitHub'da yetkileri ayrıntılı biçimde kısıtlanabilen erişim token'ları var; bu yüzden yalnızca belirli depolara erişim verecek şekilde sınırlandırırsanız, LLM'in kötüye kullanılabileceği alan da sınırlanır. Bu saldırı yalnızca LLM'in tüm hesap üzerinde erişime sahip olduğu durumda mümkün ve böylesine tehlikeli kimlik bilgilerini Claude'a vermek başlı başına sorun

    • Buradaki önemli nokta, çoğu prompt injection saldırısında olduğu gibi, LLM'e saldırganın kontrol ettiği veri, hassas bilgi ve veri sızdırma yeteneği gibi en az üç unsurdan ikisine aynı anda erişim verilen bir ortam sunulmasıdır. Ajan tasarımının temel ilkesi, aynı anda en fazla ikisine izin vermek olmalı; güvenlik sorunlarını engellemek için sistemler bu kuralla tasarlanmalıdır. Örneğin güvenilmeyen birinin açtığı bir issue'yu gördüğünüz anda LLM'in bağlamı zaten saldırganın ürettiği veriyle kirlenmiş olur. Sonrasında hassas bilgilere erişecekse, internet bağlantısı gibi yetenekler kapatılmalıdır. Bu modeli izlerseniz, depo bazlı token'lar olmadan da güvenli kalabilirsiniz. Ne yazık ki MCP bunu garanti edecek araçlar sunmuyor

    • Sorun, token yetkilerinin fazla geniş tanımlanması; ama aynı zamanda geliştiriciler de her depo için ayrı bir token açık tutmak istemiyor. Bu yüzden token'lara geniş yetkiler verip LLM'e koşulsuz güveniyorlar. Bu dikkatli yaklaşım yerinde olsa da, pratikte ekosistemdeki birçok oyuncu bunu uygulamıyor. Bu raporun önemli olmasının nedeni de, LLM'in yalnızca yetki ve güvenilmeyen veriyle bile tamamen ele geçirilebileceğini öğretmesi. Çözüm, token'ın kullanım kapsamını dinamik olarak sınırlamak. Biz bu yöntemi bu listede araştırıyoruz

    • Bu, Railway gibi servislerde yaşanabilecek bir sorun. Railway bazen tek bir proje dağıtımı için bile tüm GitHub depolarına erişim istiyor, oysa Netlify yalnızca istediğiniz depolara yetki vermenize saygı duyuyor. GitHub, erişim kapsamına saygı göstermeyen uygulamaların onaylanmasını baştan engellemeli

    • Her yeni teknoloji çıktığında sürekli aynı şey oluyor. Sanki temel güvenlik ilkeleri yeni bağlamlarda göz ardı edilebilirmiş gibi davranılıyor. Oysa hangi "parlak" yeni teknolojiyi kullanırsanız kullanın, temel güvenlik ilkeleri asla ihmal edilmemeli. Kripto dünyasında da geçmişteki dolandırıcılıkların ve finansal suçların aynen tekrarlanmasının nedeni, teknoloji farklı diye eski derslerin görmezden gelinmesiydi

    • Eğer chatbot kullanıcıyla etkileşime giriyorsa, chatbot'un izin verilen sınırlar içinde her şeyi yapacağını varsaymalısınız. Chatbot, API'nin üstüne eklenmiş bir kolaylık katmanından ibaret; kendi başına bir güvenlik mekanizması değil

  • MCP ve ajan güvenliğiyle ilgileniyorsanız, bu konuda hazırladığımız çeşitli materyaller var. Tüm saldırı senaryosu için Claude yürütme izi (bağlantı), MCP bağlantıları için güvenlik tarayıcısı (bağlantı), MCP araç zehirleme saldırıları (blog), WhatsApp MCP exploit örneği (blog), ajanlar için güvenlik katmanı Guardrails (blog), yapay zeka ajanlarının güvenlik ve faydasını birlikte değerlendiren AgentDojo (blog) incelenebilir

  • Buna gerçekten "exploit" demek doğru mu emin değilim. Ajanınıza özel depolara erişebilen bir token verirseniz, elbette erişebilir. MCP sadece bir API sunucusu. API üzerinden açmak istemediğiniz şeylere zaten yetki vermemelisiniz

    • Birçok kişi gibi ben de yazıyı okumadan önce yorumlara baktım. Gerçek makaleye göre, GitHub'a kötü niyetli bir issue açılıyor ve bu issue içinde LLM'i veri sızdırmaya yönlendiren bir prompt bulunuyor. Depo sahibi ajanı tetiklediğinde, ajan bu kötü amaçlı prompt doğrultusunda davranıyor

    • Bu, insan hatasını ya da aşırı güveni suistimal eden gerçek bir exploit. Sorun, insanların abartılı pazarlamaya kanıp özel ve hassas tam erişimli GitHub token'larını rahatça LLM'lere vermesi

    • Konu önemli olduğu için biraz sivri konuşacağım: herkesin yapay zeka araç çalıştırmanın risklerini doğru anlaması gerekiyor. Ajanlar bugün mevcut dikkatlerine, yani bağlamlarına göre araç çalıştırıyor ve bu dikkat, araç çıktıları ya da prompt'lar tarafından kolayca etkilenebiliyor. Ama yorumlarda sadece "token verdin, olan bu" türü yüzeysel iddialar tekrarlanıyor. Sorun düzgün açıklandıktan sonra bile "kullanıcı izin verdiği için oldu" diyerek konuyu saptırmaları üzücü. Bu, confused deputy problemine dair klasik bir yanlış yaklaşım. Ayrıca "kullanıcı sorumluluğu" deniyor ama pratikte asıl sorun, MCP'nin erişim sonrası denetim veya günlükleme sağlamaması. Ben kayıt (logging) tutulabildiğini görmeden rahat edemem. Güvenlik araştırmasını küçümseyip "zaten sağduyu" diye geçiştiriyorlar ama güvenlik üzerine konuşmak her zaman değerlidir. Bir zafiyet zayıf diye konuşmaya değmez olmaz. Hatta bunu SQL injection ile aynı sınıfta görmek mümkün. Sistemin dolaylı olarak kirletilmesi, yani herkese açık bir issue üzerinden kötü amaçlı içerik taşınması fikrini anlamamak da tehlikeli. Son olarak, savunmacı refleksle davranmak yerine yeni görüşlere açık olmak gerekirdi; bu konuda o açıklığı görememek üzücü

  • Güvenlik açısından bakıldığında, LLM güvenilmeyen bir kaynaktan gelen metni gördüğünde, o kaynağın LLM'in ürettiği çıktıyı istediği şekilde yönlendirebileceğini varsaymak gerekir. Sonuç araç çağrılarına dönüşüyorsa, artık güvenilmeyen kaynak da bu araçları fiilen kullanabiliyor demektir. Konuyu araştırırken invariant labs'ın Guardrails dokümantasyonunun biraz pazarlama tarafı da olduğunu düşündüm. Güvenlik açısından bakınca, böyle bir guardrail ürününe ihtiyaç duyulacak kadar yapının karmaşık olması ürkütücü. Yapay zeka şirketleri en baştan güvenlik merkezli tasarlasaydı, belki bu tür ürünlere gerek kalmazdı

    • Girdi ayrımı düzgün yapılırsa bu aslında kolay bir sorun. Prompt içinde <github_pr_comment> gibi etiketlerle işaretlenir ve bunun yalnızca salt okunur veri olduğu, asla komut olarak yorumlanmaması gerektiği açıkça belirtilir. Bu saldırı aslında yapısal olarak biraz karmaşık. Eskiden chatbot prompt injection meseleleri çıktığında oluşan hisse benziyor. Şimdi MCP de aynı şekilde gündeme geliyor

    • Metnin bazı kısımlarını arındırılmamış, yani kirli veri olarak işaretleyip LLM'in bu bölümlerdeki komut anlamını yok sayacak şekilde eğitilmesi mümkün mü diye merak ediyorum

    • Aslında yapay zeka şirketleri güvenlik tasarımını düşünüyor. Ama bu "exploit" yalnızca güvenlik devre dışı bırakıldığında mümkün olan bir senaryo ve bu da kalın uyarılarla sunuluyor. Örneğin Claude Desktop varsayılan olarak her araç çağrısında açık onay ister. Ancak birçok kullanıcı bunu "her zaman izin ver" olarak ayarlayıp tek tek eylemleri izlemiyor

    • Bu tür yazılım zafiyeti örüntüleri geleneksel sistemlerde de tekrar tekrar görüldü; yeni teknolojilerde de hep ortaya çıkmaları hem komik hem sinir bozucu. "Kullanıcı girdisini al, yeterince korunmayan bir ortamda komut gibi yorumla ve çalıştır" deseni sürekli geri geliyor. SQL injection, XSS, PHP include açıkları... hepsinde gördüğümüz hikâye şimdi LLM'lerde yeniden yaşanıyor

  • MCP'nin başlı başına devrimsel ya da hack'lenmeye özel olarak yatkın olduğunu düşünmüyorum; gerçi MCP hakkında başka görüşlerim de var. Bana biraz prompt injection tekniğinin pazarlama ambalajına sarılmış hali gibi geliyor. Ajan sistemleri tasarlarken hep şu ilkeyi kullanırım: "Ajanın erişebildiği her şeye, o ajana erişebilen herkes de erişebilir." Erişim kontrolünü LLM'e emanet etmem; ajanın yaptığı işin güvenlik sorumluluğu her zaman isteği yapan özneye aittir. Bu yazıda baştan sona asıl odaklanmamız gereken şey, ajana gerçekte hangi kaynakların açıldığıdır. E-posta verilerine erişim verirseniz ve prompt injection içeren bir e-posta LLM'i güvenlik token'larını çalıp aktarmaya yönlendirirse, asıl ciddi risk budur

    • Buna MCP etiketi eklenmesi bana 10 yıl önceki "bunu blockchain'e koyduk" modasını hatırlatıyor. "LLM onay ve eylem öznesi olduğundan en az yetki ilkesini sıkı uygulamak gerekir" sözü tecrübeliler için çok bariz; ama belki de yeni bir neslin bu temelleri yeniden öğrenmesi gerekiyor

  • Gerçek saldırı örneği ve ajanın tepkisi burada görülebilir. Ajanın saldırıyı eksiksiz başarıyla gerçekleştirmiş olması biraz ironik derecede komik

  • Ben de bir hafta önce Google's Jules kodlama ajanını denedim ve GitHub OAuth yetki isteği, hesaptaki tüm depolar ve izinler için tam kapsamlı erişim talep ediyordu. Bu tasarım kısmen geliştirici kolaylığından, kısmen de GitHub OAuth akışının kendisinden kaynaklanıyor. Aslında depo bazında sınırlı yetki verme ve sonradan ek yetki isteme daha kolay olmalıydı. Ama pratikte tek çözüm, yalnızca belirli depolara izin vermek için ayrı bir GitHub hesabı oluşturmak gibi görünüyor (örnek hesap). Bu oldukça zahmetli. GitHub'ın resmi belgeleri de böyle ayrı bir makine kullanıcısı oluşturmayı öneriyor, ama varsayılan depo kapsamı belirleme çok daha kolay olmalı. Daha iyi bir yöntem bilen varsa gerçekten duymak isterim

  • Bu yazının iddiası bana fazla abartılı geliyor. Basit bir issue ile veri sızdırıldığı anlatılıyor ama gerçekte bunun olması için kullanıcının bir dizi güvenlik açısından riskli adımı bizzat atması gerekiyor. Yani MCP sunucusunu kurması, hem public hem private repo'lara erişebilen kimlik bilgileri vermesi, LLM'in bu sunucuya erişmesine ve depo issue'larını okumasına izin vermesi, ardından kötü amaçlı issue'yu gerçekten okuması ve sonucu dışarı açacak şekilde yapılandırması gerekiyor. Sonuç kötü, evet; ama bu, klasik anlamda "başkasının uzaktan istismar ettiği bir güvenlik açığı" gibi görünmüyor. Kullanıcı kendi elleriyle güvenilmeyen veriyi okutmuş ve sonucu da güvenilmeyen bir yere göndermiş oluyor. Yine de GitHub MCP'nin de bir miktar sorumluluğu var. Public/private depolar arasında çapraz işleme engel koymaması sorunlu

    • Özünde, sadece "issue'ları özetle" gibi basit bir komutla bile, kötü amaçlı issue'nun içindeki komutların uygulanabileceği gerçeği gözden kaçmamalı

    • MCP'nin pazarlama boyutu da önemli. Protokolün kendisi güvenilen ortamlar veya kullanıcılarla sınırlandırılmalı. MCP sunucularında kapsam belirleme ya da kimlik doğrulama için standart bir yöntem olmaması sorun. Bana göre mesele GitHub MCP'den çok, sektörün genel kullanım ve uygulama biçimlerinde. Nitekim özel MCP sunucuları kullanırken, yapay zeka dışı ek bilgiler de gönderip güvenlik kapıları koyuyoruz; örneğin kimlik bilgisi, JWT vb.

    • Günümüzdeki yapay zeka furyası nedeniyle, birçok kişinin bu tür tehlikeli yapılandırma ve akışları düşünmeden uyguladığı da bir gerçek. "Bunu kullanmamalılardı" demek kolay ama işte bu yüzden guardrail'lere ihtiyaç var. İnsanlar sık sık riskli kararlar veriyor

    • Public/private depoları karıştırmayın deniyor ama pratikte bunlar birbirinden tamamen ayrı araç çağrıları. MCP sunucusu açısından bu etkileşimi tespit etmenin bir yolu yok

  • Tartışmanın şu anda ilgili HN başlığında sürdüğünü fark ettim

    • Orada da zaten söylenmiş ama güvenlik riski çok açık. Sisteme özel verilere erişim izni verip dış kullanıcıların da keyfi metin girmesine olanak tanırsanız, sonuçta dış kullanıcıya özel verileri dolaylı yoldan açmış olursunuz. Standart güvenlik uygulamaları izlenirse kolayca önlenebilecek bir sorun

    • Yorumlar şu anda buraya taşınmış durumda

  • MCP sadece bir protokol. A2A gibi benzer yaklaşımlar veya daha ilkel yöntemler de var. LLM'e GitHub API belgelerini okutabilir ve bir token ile API'yi kullanmasını söyleyebilirsiniz. Henüz tüm LLM'ler bu seviyede değil ama yakında olacaktır. Araç kayıt mekanizmasını kusursuz biçimde güvenli yapmak pratikte neredeyse imkânsız. Veri sızıntısının nihai sorumluluğu sonuçta LLM'de kalıyor. Geliştiriciler LLM'den verimlilik kazanımı beklediği için ya güvenliğin garanti altına alınması gerekecek ya da her dizüstü bilgisayara bir güvenlik duvarı eklemek zorunda kalacağız. Asıl can sıkıcı olan, gelecekte güvenlik duvarlarını bile suistimal eden "kötü davranan LLM'i yakalayan LLM" savaşlarına kadar gidebilecek olmamız