Cursor sıfır günü: Neden geriye tek koruma aracı olarak tam açıklama kaldı

• Windows için Cursor, bir proje açıldığında çalışma alanı kökündeki git.exe dosyasını otomatik çalıştırıyor; bu nedenle kötü amaçlı bir ikili dosya içeren bir depoyu açmak bile kullanıcı etkileşimi olmadan rastgele kod yürütülmesine yol açabiliyor
• Git yolu arama kapsamına depo içi de dahil ediliyor; dosya uyarı veya onay olmadan çalıştırılmakla kalmıyor, proje açık olduğu sürece periyodik olarak yeniden çalıştırılıyor
• Mindgard, 15 Aralık 2025'te bildirim yaptı ve HackerOne üzerinden yeniden üretim ve iletimi tamamladı; ancak 6 aydan fazla süre ve 197'den fazla yeni sürüm geçmesine rağmen sorun en son test sürümünde hâlâ mevcuttu
• Yönetilen Windows ortamları AppLocker veya Windows App Control ile yol tabanlı reddetme kuralları uygulamalı; sıradan kullanıcılar ise yama gelene kadar güvenilmeyen depoları VM veya Windows Sandbox içinde açmalı
• Koordine açıklama sürecinin kullanıcı riskini azaltamayacağına karar veren Mindgard tüm ayrıntıları yayımladı; yapay zeka geliştirme araçları seçilirken tedarikçinin güvenlik yanıtı ve iletişim kapasitesi de güven ölçütü olarak ele alınmalı

---

Depoyu açmakla çalışan git.exe

• Cursor, proje yüklerken Git ikili dosyasını birden fazla konumda arıyor ve arama hedeflerine mevcut çalışma alanını da dahil ediyor
• Saldırgan depo köküne kötü amaçlı bir git.exe yerleştirirse Cursor bunu uyarı, onay penceresi veya ek tıklama olmadan otomatik olarak çalıştırıyor
• Saldırı, geliştiricinin ilgili projeyi açmasıyla başlıyor; prompt injection, model manipülasyonu, jailbreak, bellek bozulması veya karmaşık exploit zincirleri gerekmiyor
• Çalıştırılan kod, mevcut Cursor kullanıcısının yetki kapsamı içinde çalışıyor

Yeniden üretim süreci ve tekrarlı çalıştırma kayıtları

• Mindgard, güvenli bir kavram kanıtı için Windows Calculator uygulamasının adını git.exe olarak değiştirip depo köküne yerleştirdi
• Depo Cursor'da açıldığında Calculator çalıştı; proje açık bırakılınca ek olarak birden fazla pencere belirdi
  • Araştırmacı birden fazla pencereyi elle açmadı
  • Bu, tek seferlik bir başlangıç davranışı değil, normal kullanım sırasında çalışma alanındaki yürütülebilir dosyanın periyodik olarak yeniden çalıştırılmasının sonucuydu
• Gerçek bir saldırıda Calculator yerine saldırganın kontrol ettiği kod yerleştirilebilir
• Sysinternals Process Monitor kayıtlarında Cursor.exe'nin depo içindeki git.exe dosyasını çalıştırırken şu komutu ilettiği görülüyor

git rev-parse --show-toplevel

• Son doğrulama 30 Nisan 2026 tarihinde, Windows için Cursor 3.2.16 üzerinde yapıldı

Geniş kullanıcı tabanında kalan güvenlik açığı

• Cursor aşağıdaki ölçekte kullanılan yapay zeka destekli bir geliştirme ortamı
  • 7 milyondan fazla aktif kullanıcı
  • 1 milyondan fazla günlük kullanıcı
  • 1 milyondan fazla ücretli kullanıcı
  • 50 binden fazla kullanıcı şirket
• Bildirilen piyasa değeri 60 milyar dolar
• Mindgard güvenlik açığını 15 Aralık 2025'te keşfetti ve aynı gün bildirdi
• Girişteki ölçüte göre 6 aydan fazla süre ve 197'den fazla yeni sürüm geçmesine rağmen güvenlik açığı en son test sürümünde hâlâ mevcuttu
• Yanıt sürecini ele alan metinde, özellik eklemeleri ve duyurular sürerken 70'ten fazla sürüm yayımlanmasına rağmen sorunun devam ettiği kaydediliyor
• Basit ve yeniden üretmesi kolay bir rastgele kod yürütme açığı aylar boyunca giderilmediği için Cursor'u dağıtan hem bireyler hem de kuruluşlar etkilendi

Yama öncesi uygulanabilecek geçici önlemler

• Yönetilen Windows sistemlerinde, AppLocker veya Windows App Control ilkeleriyle geliştirme çalışma alanı dizinlerindeki ilgili yürütülebilir dosya adları engellenebilir
• Her ikili dosyanın hash'i değişebileceğinden, hash tabanlı engelleme listeleri yerine kapsamı depo/çalışma alanı köküyle sınırlayan yol tabanlı reddetme kuralları daha uygundur

%USERPROFILE%\source\repos\*\filename.exe

• Windows'ta, yalnızca belirli bir üst süreç tarafından çalıştırıldığında rastgele alt yürütülebilir dosyaları engelleyen genel bir yerleşik kural yok
  • Üst süreci tanıyan kontroller için EDR veya özelleştirilmiş uç nokta güvenlik ürünleri gerekir
• Sıradan kullanıcılar, IDE yamalanana kadar güvenilmeyen depoları yalnızca izole bir VM, Windows Sandbox veya atılabilir bir ortam içinde açmalı
• İkili dosya her değiştirildiğinde hash değişebileceğinden, bu güvenlik açığı için dosya hash'i engelleme listelerine güvenilmemeli

Bildirim sonrası durma noktasına gelen koordinasyon süreci

• İlk bildirim Cursor'ın security.txt dosyasında belirtilen güvenlik bildirim e-posta adresine gönderildi, ancak alındı onayı gelmedi
• Mindgard, takip e-postaları ve açık iletişim talebi yoluyla doğru güvenlik yetkilisini bulmaya çalıştı
• Cursor CISO'su, iç otomasyon arızası nedeniyle planlanan HackerOne sürecinin başlamadığını söyledi ve Mindgard'ı özel bug bounty programına elle davet etti
• HackerOne'a yeniden sunulan rapor başlangıçta Informative ve kapsam dışı olarak kapatıldı
  • Mindgard bu karara itiraz etti
  • HackerOne sorunu yeniden ürettikten sonra raporu yeniden açtı ve ayrıntıların Cursor'a iletildiğini doğruladı
• Sonrasında güncelleme talepleri, HackerOne üzerinden eskalasyonlar ve Cursor CISO'su ile yöneticilere doğrudan temaslara rağmen anlamlı bir yanıt gelmedi
• Mindgard, düzeltmenin başladığına, mühendislik ekibinin inceleme yaptığına veya etkilenen kullanıcılara riskin iletildiğine dair kanıt almadı

Bildirimden tam açıklamaya kadar takvim

• 15 Aralık 2025

  • Mindgard güvenlik açığını keşfetti
  • [e-mail] adresine bildirdi

• 18 Aralık 2025

  • Alındı onayı isteyen takip mesajı gönderdi

• 13 Ocak 2026

  • Cursor'da irtibat kişisi bulmak için LinkedIn gönderisi yayımladı
  • Yorumlarda bir kullanıcı Cursor CISO'sunu işaret etti

• 15 Ocak 2026

  • Cursor CISO'su, HackerOne özel bounty daveti otomasyonunun başarısız olduğunu bildirdi ve elle davet etti
  • Mindgard güvenlik açığını HackerOne üzerinden sundu

• 16 Ocak 2026

  • Rapor Informative ve kapsam dışı olarak kapatıldı
  • Mindgard karara itiraz etti
  • Yeniden üretim başarılı olduktan sonra rapor yeniden açıldı

• 20 Ocak 2026

  • HackerOne raporu Cursor'a ilettiğini doğruladı

• 16 Şubat 2026, 3 Mart 2026

  • Mindgard güncelleme istedi ancak yanıt alamadı

• 17 Mart 2026

  • Cursor CISO'sundan doğrudan güncelleme istedi

• 18 Mart 2026

  • HackerOne, Cursor ile iletişime geçtiğini bildirdi

• 1 Nisan 2026

  • Mindgard yeniden güncelleme istedi ancak yanıt alamadı
  • HackerOne da Cursor'dan güncelleme gelmediğini doğruladı

• 1 Haziran 2026

  • Mindgard, açıklama niyetini HackerOne'a bildirdi

• 3 Haziran 2026

  • HackerOne açıklama yönergeleri sağladı

• 14 Temmuz 2026

  • Güvenlik açığı ayrıntılarını içeren gönderiyi yayımladı

Koordine açıklamanın neden kullanıcı korumasına dönüşmediği

• Tipik koordine açıklama; bildirim, diyalog, ciddiyet tartışması, mühendislik incelemesi, düzeltme geliştirme, kullanıcı koruması ve açıklama sırasıyla ilerler
• Bu süreç, tüm katılımcılar risk azaltma hedefini paylaştığında işler
• Bu vakada 7 ay boyunca tedarikçinin anlamlı katılımı olmadığından risk azaltma aşamasına geçilemedi
• Büyük ölçekte ve hızla değişen platformlarda düzeltmeler zaman alabilir; ancak aylar boyunca iletişim, güncelleme veya görünür ilerleme olmadığında beklemeye devam etmek zorlaşır
• Araştırmacının önünde yalnızca iki seçenek kaldı
  • Sessiz kalıp kullanıcıların güvende oldukları gibi yanlış bir varsayımla çalışmaya devam etmesine izin vermek
  • Açıklama yaparak kuruluşların riski anlamasını ve nasıl yanıt vereceklerine karar vermesini sağlamak
• Mindgard, diğer tüm yollar başarısız olduğunda başvurulan tam açıklamayı seçti

Bug bounty ve yapay zeka güvenlik yanıt sisteminin bıraktığı sorular

• Çözümdeki gecikmenin nedeni olarak şu olasılıklar sorgulanıyor
  • Modern bug bounty programları aşırı yük altında mı
  • Mythos gibi yetenekleri artan modeller nedeniyle bildirim hacmini karşılamak zorlaştı mı
  • Cursor, SpaceX satın almasına odaklanırken kullanıcı güvenliğinin önceliğini düşürdü mü
  • Milyarlarca doların söz konusu olduğu bir durumda kullanıcı güvenliği gerçekten önemseniyor mu
• Yapay zeka ürünlerinin yaygınlaşmasıyla güvenlik bulgularının sayısı büyük ölçüde artıyor ve bunların önemli bir kısmı mevcut güvenlik açığı sınıflandırmalarına temiz biçimde uymuyor
• Yaklaşık 20 yıldır dayanılan sınıflandırma ve alım süreçleri, yapay zeka ortamında temel varsayımları sarsıldığı için hızla başarısız oluyor
• Açıklama hattı aşırı yük altındaysa sektör bunu şeffaf biçimde duyurmalı; böylece araştırmacılar, müşteriler ve kullanıcılar durumu değerlendirebilmeli
• Hızla büyüyen şirketler güvenlik başarısızlıklarını giderirken kullanıcıları satın alma deneylerinin nesnesi değil, değerli müşteriler olarak görmeli

Yapay zeka geliştirme araçlarına güvenmek için koşullar

• Yapay zeka şirketleri kodlara, depolara, terminale, gizli bilgilere ve iş akışlarına eşi görülmemiş genişlikte erişim talep ediyor; öneri ile yürütme arasındaki sınır da giderek bulanıklaşıyor
• Kullanıcılar üretim yazılımlarına kaynak kodunu, kimlik bilgilerini, tescilli fikri mülkiyeti ve giderek otonomlaşan işlevleri emanet ediyor
• Bir sistem yalnızca üretkenliği artırdığı için güvenilir kabul edilmemeli; güven, güvenlik bildirimlerine verilen yanıt, etkilenen kullanıcılarla iletişim ve düzeltme önceliğiyle kazanılmalı
• Güven sorumluluk gerektirir, sorumluluk da iletişim gerektirir; ancak kullanıcılar, araştırmacılar ve açıklama platformları aylarca temel durum güncellemeleri bile alamazsa bu sorumluluğu doğrulamak zorlaşır
• Mindgard, kuruluşlara maruziyet kapsamlarını değerlendirme, telafi edici kontroller uygulama ve güvenlik durumlarına karar verme fırsatı vermek için tüm ayrıntıları yayımladı
• Bilgileri saklamaya devam etmek kullanıcıları değil yalnızca sessizliği korur hâle geldiğinde, rahatsız edici olsa bile kullanıcı güvenliği öncelik olmalı

[GN⁺]

Hacker News görüşleri

• Güvenlik raporlarını alan tarafta, LLM’lerin ürettiği düşük kaliteli raporlar başa çıkılamayacak kadar yağıyor; bunlar çoğu zaman ürün tasarımını ya da güvenlik kapsamını anlamayan içerikler oluyor. Ara sıra çok iyi raporlar da geldiği için hepsini tek tek kontrol etmek gerekiyor, ancak LLM’in ürettiği uzun uzadıya “gerekçeler” göndermek çözüm değil; bu yazı da büyük ölçüde LLM ile yazılmış gibi görünüyor.
  Bu olayda da yazılımın keyfî kod veya ikili dosya çalıştırabildiği bir ortama kötü amaçlı bir ikili dosya konmuşsa, Cursor kullanıcı ortamının güvenliğini de üstleneceğini söylemediği sürece sorumluluk daha çok çalışma alanını yalıtıp koruması gereken tarafta gibi görünüyor.
  LLM ile CVE raporu hazırlarken onu kesin olarak yeniden üretme sürecinde kullanın; ana metni ise kendiniz kısa ve öz yazıp LLM’e özgü gereksiz sıfatları ve abartıları ayıklayın.

  • Yeni klonlanmış bir depoyu Cursor ile açtığınız için içindeki ikili dosyanın otomatik çalıştırılmaması gerekir.
  • PATH değişkeni tam da bu tür sorunları denetlemek için vardır. Anladığım doğruysa Cursor, kullanıcı onayı olmadan depoyu hemen PATH’e ekliyor.
  • Kolay bir çözüm yok; güvenliğe önem veriliyorsa değişen ortama uygun biçimde inceleme personeli artırılmalı. Üstüne bir katman daha LLM kontrolü eklemek sorunu çözmez.

• Sorunun kökü, Cursor’ın depo klonlamayı ve kod çalıştırmayı ayrı güvenlik sınırları olarak görmemesinde. Cursor varsayılan olarak Workspace Trust’ı devre dışı bırakıyor[0] ve .vscode/tasks.json içinde "runOn": "folderOpen" bulunan bir depoyu açmak bile zaten keyfî kod çalıştırıyor[1].
  [0] https://cursor.com/docs/agent/security#workspace-trust
  [1] https://www.oasis.security/blog/cursor-security-flaw

• Mindgard, açığı ilk olarak 15 Aralık 2025’te keşfedip aynı gün ve sonrasında birkaç kez bildirdiğini, ancak 6 ay ve 197’den fazla yeni sürüm geçmesine rağmen hâlâ en güncel Cursor’da bulunduğunu söylüyor.
  Başta bilgilendirici/kapsam dışı rapor olarak kapatılmış; itirazdan sonra HackerOne yeniden açıp yeniden üretmiş ve Cursor’a iletmiş. Buna rağmen sonraki güncelleme talepleri, ek sorular, HackerOne üzerinden üst seviyeye taşıma ve Cursor yönetimine gönderilen iletişimlerin tamamı yanıtsız kalmış; Cursor’ın neden böyle davrandığını anlamak zor.

  • CVE işleme sürecinin kendisi bozulmuş durumda. Ajan tabanlı yapay zekânın gelişmesiyle HackerOne ve şirketlerin açık ifşa programlarında hem düşük kaliteli raporlar hem de gerçekten üstün raporlar aynı anda patladı; aynı yapay zekâ ikisini de yazdığı için yalnızca yüzeye bakarak ayırt etmek neredeyse imkânsız.
    Sonuç olarak şirketler eskisi gibi yanıt vermiyor; hazirandaki siber güvenlik konferansında da sorumlu ifşanın öldüğü ya da ölmek üzere olduğu, bu yüzden kamuya açık biçimde duyurmanın daha iyi olduğu yönünde güçlü bir hava vardı. Microsoft ve Nightmare Eclipse olayı sıkça örnek gösterildi.
  • Kasıtlı bir arka kapı olma ihtimali de akla geliyor. NSA ya da FBI hedefe yönelik bir depoya git.exe koyup hedefin bunu klonlamasını sağlarsa yük çalıştırılabilir.
    Cursor VS Code tabanlı olduğuna göre aynı şeyin VS Code’da da olup olmadığını merak ediyorum.

• Bunun ciddi bir açık olduğuna tamamen katılmak zor. Gerçekten istismar edebilmek için saldırganın önce kullanıcının kod klasörüne git.exe adlı kötü amaçlı bir çalıştırılabilir dosya koyması gerekir; bu da .bashrc dosyasını değiştirip ls komutunun /tmp/mega-big-virus.sh çalıştırmasını sağlayan bir alias oluşturmayı açık olarak adlandırmaya benziyor.
  Bir saldırı yolu olduğu doğru, ancak böyle bir dosya zaten dosya sistemine girmişse önceden gerçekleşmiş bir ihlal var denebilir.

  • Bir GitHub deposunu klonlayıp varsayılan editör olan Cursor ile açmak bile enfeksiyona yol açabilir. Bu, CD takılınca autorun.exe çalışıp Windows’un enfekte olmasına benzer.
    Kullanıcının tüm depo dosyalarını ve git.exe gibi şüpheli ikili dosyaları yalıtılmış ortamda bizzat incelemesi gerektiği söylenebilir; ama pratikte bunu kullanıcı değil, otomatik çalıştırmayı engelleyen güvenlik politikası denetler ve Cursor da aynı şekilde bunu devre dışı bırakmalıdır.
  • .bashrc’ten farklı olarak kod klasörleri sık sık güvenilmeyen kaynaklardan alınır. Bir GitHub projesini incelemek için açtığınız gerekçesiyle keyfî kod çalıştırmaya da izin verilmemeli.
    Öte yandan büyük IDE’lerde bu sınır zaten uzun zaman önce çöktü; VS Code’un SSH ve devcontainer uzak özellikleri de tasarım gereği uzaktan kod çalıştırmaya izin veriyor.
  • Sayfanın ilk paragrafından itibaren Cursor’ın projeyi açtıktan sonra mevcut çalışma alanı dâhil çeşitli konumlarda Git ikili dosyasını aradığı ve depo köküne kötü amaçlı git.exe konursa kullanıcı girdisi ya da onayı olmadan çalıştırdığı iki cümleyle açıkça belirtiliyor. Ana davranışı saklayan bir yazı değil.
  • Bir depoyu klonlayıp IDE’de açmak bile depo sahibine uzaktan kod çalıştırma yetkisi vermek anlamına geliyor; bunun klasör açma eylemine zımnen dâhil bir sözleşme olduğunu söylemek zor.
  • 30 yıl önce de MP3 veya fotoğraf klasörlerine bulaşmış alternatif DLL koyup Winamp ya da Windows Fotoğraf Görüntüleyicisi’nin bunları yüklemesini sağlayan DLL arama sırası saldırıları vardı; bu olay onlara çok benziyor.

• Cursor’ın onay almadan keyfî yürütülebilir dosyalar çalıştırması tuhaf; araştırmacıların aylar boyunca düzgün bir yanıt alamaması da endişe verici.
  Ancak hesap makinesi çalıştırma örneği biraz yanıltıcı olabilir. Kötü amaçlı yürütülebilir dosyanın zaten sisteme indirilmiş olması gerekiyor; Cursor çalıştırmayı denerse anladığım kadarıyla ACL devreye girer ve imzasız yeni bir uygulamayı ilk kez çalıştırıp çalıştırmayacağınıza dair izin sorar. Gerçek istismar için ACL’nin tamamen devre dışı bırakılmış olması gerekebilir.

  • Onay penceresinde “git.exe çalıştırılsın mı?” yazarsa, Cursor’ın Git’e ihtiyaç duyduğunu ama izin ayarlarının bozulduğunu düşünüp olduğu gibi onaylama olasılığı yüksek.
  • Mevcut Git dalını gösteren bir PS1 kullanırken mevcut dizini PATH’e eklemişseniz aynı şey yaşanabilir. Öyleyse Bash için de yüksek riskli bir CVE göndermek gerekip gerekmediği soru işareti.

• Bu, yalnızca Cursor’a özgü bir hatadan ziyade, Windows’un PATH’e bakmadan önce geçerli çalışma dizininde çalıştırılabilir dosya arayan Windows’a özgü arama sırası ile ilgili görünüyor. Windows’taki birçok programın benzer saldırılara açık olma olasılığı yüksek.

  • Güvenliği önemseyen yazılımlar bu sorunu zaten düzeltti.
    https://go.dev/blog/path-security adresinde açıklandığı gibi Command ve LookPath, işletim sistemi geleneklerine uygun olarak mevcut PATH’te listelenen dizinlerde program arar; ancak günümüzde geçerli dizini dahil eden bu davranış çoğu zaman beklenmediktir ve güvenlik sorunlarına yol açar.
    https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
  • Bilinen sistem yollarında gerçek Git çalıştırılabilir dosyasını bulmak ya da kullanıcının yolu ayarlamasına izin vermekle kolayca hafifletilebilir; bildiğim kadarıyla VS Code da bunu bu şekilde ele alıyor.
  • Windows için yazılım geliştirirken mutlaka savunma alınması gereken, eski ve iyi bilinen bir güvenlik tuzağı.
  • Öyleyse sonuçta Cursor’un Windows sürümünde bir hata ve güvenlik açığı olduğu anlamına geliyor gibi.

• Şirketlerin güvenliği önceliklendirmemesi çok yaygın; üzücü ama bir ölçüde anlaşılabilir de. Bir güvenlik startup’ının beklemekten yorulup yaptığı harcamanın en azından bir kısmını tanıtım etkisiyle geri kazanmaya çalışarak bunu kamuya açıklaması da anlaşılır; kamuya açık güvenlik açığı ifşasının gerekli olduğu zamanlar da vardır.
  Ancak gerçekten çözümüne yardımcı olmak isteselerdi, HackerOne’da sıkıştırmak ve CISO’ya LinkedIn’den bir kez mesaj göndermekten daha fazlasını yapabilirlerdi gibi geliyor. Artık kimse gerçekten umursamıyor gibi görünmesi acı.

  • Çözüme gerçekten yardımcı olmak için ne yapılması gerektiği ve burada kastedilen batık maliyetin tam olarak ne olduğu belirsiz. Genel olarak fazla muğlak geliyor.

• Cursor’un neden çalıştırılabilir dosyaları otomatik olarak çalıştırdığını, hangi karar alma akışı içinde bu davranışın ortaya çıktığını merak ediyorum. Vim’de de %{expr} gibi açık özellikler yüzünden dosya yüklenirken beklenmedik kod çalıştırma sorunları olmuştu; ama Cursor’un neden özellikle git.exe aradığını ve bunun kime fayda sağlayan bir özellik olduğunu anlamak zor.
  Kolayca düzeltilebilecek gibi görünen yinelenen bir CVE’nin neden var olduğunu, Cursor’u hiç kullanmamış biri olarak bile merak ediyorum.

  • Yaygın akış şu: Cursor’dan mevcut bir depoyu özetleyip README yazması istenir; Cursor depoyu ve kodu okuduktan sonra geliştirme dalı ya da önceki etiketler gibi meta verileri de sunmak için Git komutları çalıştırır.
    Sorun, uzak bir depoyu değerlendirmesi istendiğinde depoyu klonladıktan sonra çalışma dizininde git ... çalıştırırsa, Windows’un o dizindeki git dosyasını çalıştırılacak hedef olarak kabul edebilmesinde. Güvenilmeyen bir depoya ya da ele geçirilmiş bir dala geçildiğinde de kod anında çalıştırılabilir.
    Genel çözüm, sistemde kurulu Git’in tam yolunu kullanmaktır; insan için yazması zahmetli olsa da Cursor için önemsiz bir iş.
  • Yerleşik ajanın, birden fazla dal ve worktree’de bağlamı okuyabilmek için kullanıcının gerçek Git’ini bulmaya çalıştığı anlaşılıyor. Daha güvenli yollar var; ancak bu tür küçük kestirmeler AI destekli iş akışlarında kolayca ters tepebilir ve AI kullanan hata sınıflandırmasında da alarmın kaçabileceği noktalardır.

• Geliştirme ajanlarına Git depolarını çekme ve gönderme yetkisi sıkça verildiğinden, bu devasa bir tedarik zinciri saldırı yolu haline geliyor. Çalışmakta olan Cursor ajanı en yeni dosyaları çektiğinde ve saldırgan projeye bir çalıştırılabilir dosya yerleştirmişse, bir anda yüz binlerce kişi varsayılan kullanıcı izinleriyle rastgele bir EXE çalıştırabilir.

• Rapor biraz AI tarafından yazılmış metin gibi okunuyor. Kötüye kullanmak için kötü amaçlı yükün klonlama ya da indirme gibi yollarla zaten PC’de bulunması gerektiğinden ciddiyetini anlıyorum; ama en başta böyle bir durumla karşılaşmamayı bekler insan.

  • Modern kodlama ajanları, belgeleri belirsiz olan API’ler hakkında soru aldıklarında depoyu klonlayıp kodu okuyabildiği için bu güvenlik açığı gerçekten istismar edilebilir.
  • Kötü amaçlı yük uzak depoda bulunabilir. Depoyu git clone ettikten sonra Cursor ile açmak ele geçirmenin tamamlanması için yeterlidir.
  • Açık kaynak geliştiricisiyseniz içinde git.exe bulunan bir pull request de alabilirsiniz.
  • Bir depoyu indirip kaynak koduna bakmanın kötü amaçlı yükü etkinleştirmekle aynı şey olduğu normalde düşünülmez; endişe verici olan da tam olarak bu. AI üslubu rahatsız edici olsa bile, yazım biçiminden ziyade güvenlik açığının içeriğini eleştirmek gerekir.
  • Yükün önceden PC’de olması gerektiğini kesin söylemek zor. Prompt injection ile download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;) gibi bir komut yönlendirilebiliyorsa, ajanın git.exe dosyasını indirip çalıştırma olasılığı var.