Zero-day Cursor: Mengapa Pengungkapan Penuh Menjadi Satu-satunya Perlindungan yang Tersisa

• Cursor untuk Windows secara otomatis menjalankan git.exe di root workspace saat membuka proyek, sehingga hanya dengan membuka repositori yang berisi biner berbahaya, kode arbitrer dapat dieksekusi tanpa interaksi pengguna
• Cakupan pencarian path Git mencakup bagian dalam repositori, dan bukan hanya menjalankan file tanpa peringatan atau persetujuan, tetapi juga menjalankannya ulang secara berkala selama proyek terbuka
• Mindgard melaporkannya pada 15 Desember 2025 dan telah menyelesaikan reproduksi serta penyampaian melalui HackerOne, tetapi setelah lebih dari 6 bulan dan lebih dari 197 versi baru, masalah ini masih ada di versi uji terbaru
• Lingkungan Windows terkelola sebaiknya menerapkan aturan penolakan berbasis path melalui AppLocker atau Windows App Control, sementara pengguna umum harus membuka repositori yang tidak tepercaya di VM atau Windows Sandbox sampai patch tersedia
• Karena menilai proses pengungkapan terkoordinasi tidak dapat mengurangi risiko pengguna, Mindgard memublikasikan detail lengkapnya; saat memilih alat pengembangan AI, kemampuan vendor dalam merespons dan berkomunikasi soal keamanan juga harus dijadikan tolok ukur kepercayaan

---

git.exe yang berjalan hanya dengan membuka repositori

• Saat memuat proyek, Cursor mencari biner Git di beberapa lokasi, dan target pencariannya juga mencakup workspace saat ini
• Jika penyerang menempatkan git.exe berbahaya di root repositori, Cursor akan menjalankannya secara otomatis tanpa peringatan, dialog persetujuan, atau klik tambahan
• Serangan dimulai hanya dengan developer membuka proyek tersebut; tidak diperlukan prompt injection, manipulasi model, jailbreak, kerusakan memori, atau rantai eksploit yang rumit
• Kode yang dieksekusi berjalan dalam cakupan hak akses pengguna Cursor saat ini

Proses reproduksi dan catatan eksekusi berulang

• Untuk proof-of-concept yang aman, Mindgard mengganti nama Windows Calculator menjadi git.exe dan menempatkannya di root repositori
• Saat repositori dibuka di Cursor, Calculator berjalan, dan ketika proyek tetap terbuka, beberapa jendela tambahan muncul
  • Bukan peneliti yang membuka beberapa jendela secara manual
  • Ini bukan perilaku sekali saat startup, melainkan hasil dari eksekusi ulang berkala file executable di workspace selama penggunaan normal
• Dalam serangan nyata, alih-alih Calculator, penyerang dapat menempatkan kode yang mereka kendalikan
• Catatan Sysinternals Process Monitor menunjukkan bahwa Cursor.exe menjalankan git.exe di dalam repositori sambil meneruskan perintah berikut

git rev-parse --show-toplevel

• Verifikasi terakhir dilakukan pada 30 April 2026, di Cursor 3.2.16 untuk Windows

Kerentanan yang masih tersisa di basis pengguna berskala besar

• Cursor adalah lingkungan pengembangan berbantuan AI yang digunakan dalam skala berikut
  • Lebih dari 7 juta pengguna aktif
  • Lebih dari 1 juta pengguna harian
  • Lebih dari 1 juta pengguna berbayar
  • Lebih dari 50 ribu perusahaan pengguna
• Valuasi pasar yang dilaporkan adalah 60 miliar dolar AS
• Mindgard menemukan kerentanan ini pada 15 Desember 2025 dan melaporkannya pada hari yang sama
• Menurut pengantar, setelah lebih dari 6 bulan dan lebih dari 197 versi baru, kerentanan masih ada di versi uji terbaru
• Bagian yang membahas proses respons mencatat bahwa sementara penambahan fitur dan pengumuman terus berlanjut, lebih dari 70 versi dirilis tetapi masalahnya tetap ada
• Kerentanan eksekusi kode arbitrer yang sederhana dan mudah direproduksi ini tidak terselesaikan selama berbulan-bulan, sehingga berdampak pada individu maupun organisasi yang menerapkan Cursor

Mitigasi sementara sebelum patch

• Pada sistem Windows terkelola, kebijakan AppLocker atau Windows App Control dapat digunakan untuk memblokir nama file executable tersebut di direktori workspace pengembangan
• Karena hash dapat berubah untuk setiap biner, aturan penolakan berbasis path yang cakupannya dibatasi ke root repositori atau workspace lebih sesuai daripada daftar blokir berbasis hash

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

• Windows tidak memiliki aturan bawaan umum yang memblokir child executable arbitrer hanya ketika dijalankan oleh parent process tertentu
  • Kontrol yang mengenali parent process memerlukan EDR atau produk keamanan endpoint kustom
• Pengguna umum sebaiknya membuka repositori yang tidak tepercaya hanya di VM terisolasi, Windows Sandbox, atau lingkungan sekali pakai sampai IDE dipatch
• Karena hash dapat berubah setiap kali biner diganti, daftar blokir hash file tidak boleh diandalkan untuk kerentanan ini

Proses koordinasi yang terhenti setelah pelaporan

• Laporan awal dikirim ke email pelaporan keamanan yang ditentukan di security.txt milik Cursor, tetapi tidak ada konfirmasi penerimaan
• Mindgard mencoba menemukan kontak keamanan yang tepat melalui email tindak lanjut dan permintaan kontak publik
• CISO Cursor menjawab bahwa kegagalan otomatisasi internal membuat proses HackerOne yang direncanakan tidak dimulai, lalu mengundang Mindgard secara manual ke program bug bounty privat
• Laporan yang diajukan ulang di HackerOne awalnya ditutup sebagai Informative dan di luar cakupan
  • Mindgard mengajukan keberatan atas keputusan tersebut
  • Setelah HackerOne mereproduksi masalahnya, laporan dibuka kembali, dan dikonfirmasi bahwa detailnya telah diteruskan ke Cursor
• Setelah itu, permintaan pembaruan, eskalasi melalui HackerOne, serta kontak langsung ke CISO dan manajemen Cursor tidak mendapat jawaban berarti
• Mindgard tidak menerima bukti bahwa perbaikan telah dimulai, tim engineering sedang menyelidiki, atau risiko telah disampaikan kepada pengguna yang terdampak

Linimasa dari pelaporan hingga pengungkapan penuh

• 15 Desember 2025

  • Mindgard menemukan kerentanan
  • Melaporkannya ke [e-mail]

• 18 Desember 2025

  • Mengirim tindak lanjut untuk meminta konfirmasi penerimaan

• 13 Januari 2026

  • Mengunggah posting LinkedIn untuk mencari kontak di Cursor
  • Dalam komentar, seorang pengguna menunjuk CISO Cursor

• 15 Januari 2026

  • CISO Cursor memberi tahu bahwa otomatisasi undangan bug bounty privat HackerOne gagal dan mengundang secara manual
  • Mindgard mengajukan kerentanan melalui HackerOne

• 16 Januari 2026

  • Laporan ditutup sebagai Informative dan di luar cakupan
  • Mindgard mengajukan keberatan atas keputusan tersebut
  • Setelah reproduksi berhasil, laporan dibuka kembali

• 20 Januari 2026

  • HackerOne mengonfirmasi bahwa laporan telah diteruskan ke Cursor

• 16 Februari, 3 Maret 2026

  • Mindgard meminta pembaruan, tetapi tidak menerima respons

• 17 Maret 2026

  • Meminta pembaruan langsung kepada CISO Cursor

• 18 Maret 2026

  • HackerOne memberi tahu bahwa mereka telah menghubungi Cursor

• 1 April 2026

  • Mindgard kembali meminta pembaruan, tetapi tidak menerima respons
  • HackerOne juga mengonfirmasi tidak ada pembaruan dari Cursor

• 1 Juni 2026

  • Mindgard memberi tahu HackerOne tentang niat untuk melakukan pengungkapan

• 3 Juni 2026

  • HackerOne memberikan panduan pengungkapan

• 14 Juli 2026

  • Memublikasikan posting berisi detail kerentanan

Mengapa pengungkapan terkoordinasi tidak berujung pada perlindungan pengguna

• Pengungkapan terkoordinasi pada umumnya berjalan melalui pelaporan, dialog, pembahasan tingkat keparahan, investigasi engineering, pengembangan perbaikan, perlindungan pengguna, lalu publikasi
• Proses ini berfungsi ketika semua pihak yang terlibat berbagi tujuan yang sama: mengurangi risiko
• Dalam kasus ini, selama 7 bulan tidak ada keterlibatan bermakna dari vendor, sehingga proses tidak pernah mencapai tahap pengurangan risiko
• Platform berskala besar yang berubah cepat bisa saja membutuhkan waktu untuk memperbaiki masalah, tetapi sulit untuk terus menunggu ketika selama berbulan-bulan tidak ada komunikasi, pembaruan, atau kemajuan yang terlihat
• Peneliti hanya memiliki dua pilihan tersisa
  • Tetap diam dan membiarkan pengguna terus bekerja dengan asumsi keliru bahwa mereka aman
  • Melakukan pengungkapan agar organisasi dapat memahami risikonya dan memutuskan apakah akan merespons
• Mindgard memilih pengungkapan penuh, yang digunakan ketika semua jalur lain gagal

Pertanyaan yang ditinggalkan oleh bug bounty dan sistem respons keamanan AI

• Untuk penyebab tertundanya penyelesaian, diajukan beberapa kemungkinan berikut
  • Apakah program bug bounty modern sedang kelebihan beban
  • Apakah volume laporan menjadi sulit ditangani karena model seperti Mythos yang kemampuannya meningkat
  • Apakah Cursor menurunkan prioritas keselamatan pengguna karena fokus pada akuisisi SpaceX
  • Dalam situasi yang melibatkan miliaran dolar, apakah keselamatan pengguna benar-benar menjadi perhatian
• Penyebaran produk AI membuat jumlah temuan keamanan meningkat tajam, dan banyak di antaranya tidak masuk rapi ke klasifikasi kerentanan yang sudah ada
• Prosedur klasifikasi dan intake yang diandalkan selama sekitar 20 tahun kini cepat gagal di lingkungan AI karena asumsi dasarnya terguncang
• Jika pipeline pengungkapan kelebihan beban, industri perlu menyampaikannya secara transparan agar peneliti, pelanggan, dan pengguna dapat menilai situasi
• Perusahaan yang tumbuh cepat harus mengatasi kegagalan keamanan sekaligus memperlakukan pengguna sebagai pelanggan bernilai, bukan subjek eksperimen pembelian

Syarat untuk memercayai alat pengembangan AI

• Perusahaan AI meminta akses yang belum pernah seluas ini ke kode, repositori, terminal, informasi rahasia, dan alur kerja, sementara batas antara saran dan eksekusi juga makin kabur
• Pengguna mempercayakan source code, kredensial, kekayaan intelektual proprietari, dan fungsi yang semakin otonom kepada software produksi
• Sistem tidak boleh dipercaya hanya karena meningkatkan produktivitas; kepercayaan harus diperoleh melalui respons terhadap laporan keamanan, komunikasi dengan pengguna terdampak, dan prioritas perbaikan
• Kepercayaan membutuhkan akuntabilitas, dan akuntabilitas membutuhkan komunikasi, tetapi ketika pengguna, peneliti, dan platform pengungkapan bahkan tidak mendapat pembaruan status dasar selama berbulan-bulan, akuntabilitas itu sulit diverifikasi
• Mindgard memublikasikan detail lengkap agar organisasi punya kesempatan menilai eksposur, menerapkan kontrol kompensasi, dan mengevaluasi postur keamanan mereka
• Ketika terus menyembunyikan informasi tidak lagi melindungi pengguna, melainkan hanya melindungi kesunyian, keselamatan pengguna harus diprioritaskan meskipun tidak nyaman

[GN⁺]

Opini Hacker News

• Dari sudut pandang penerima laporan keamanan, laporan berkualitas rendah yang dihasilkan LLM membanjir hingga sulit ditangani, dan umumnya tidak memahami desain produk atau cakupan keamanan. Kadang ada juga laporan yang sangat bagus sehingga semuanya tetap harus diperiksa langsung, tetapi mengirim lebih banyak “bukti” bertele-tele buatan LLM bukanlah solusi, dan tulisan ini pun tampaknya sebagian besar ditulis dengan LLM
  Untuk kasus ini juga, jika ada biner berbahaya yang ditempatkan di lingkungan tempat perangkat lunak dapat menjalankan kode atau biner arbitrer, maka kecuali Cursor memang menyatakan akan bertanggung jawab atas keamanan lingkungan pengguna, ini tampaknya lebih dekat pada tanggung jawab pihak yang harus mengisolasi dan melindungi workspace tersebut
  Saat membuat laporan CVE dengan LLM, sebaiknya LLM dipakai untuk proses reproduksi yang menentukan, lalu isi utamanya ditulis sendiri secara ringkas sambil menghapus kata sifat berlebihan dan hiperbola khas LLM

  • Hanya karena repositori yang baru diklon dibuka di Cursor, biner di dalamnya tidak boleh dijalankan otomatis
  • Variabel PATH memang ada untuk mengendalikan masalah seperti ini. Jika pemahaman saya benar, Cursor langsung menambahkan repositori ke PATH tanpa persetujuan pengguna
  • Tidak ada solusi yang mudah, dan jika keamanan dianggap penting maka perlu menambah tenaga peninjau sesuai perubahan lingkungan. Menambahkan satu lapisan pemeriksaan LLM lagi tidak akan menyelesaikannya

• Akar masalahnya adalah Cursor tidak memandang kloning repositori dan eksekusi kode sebagai batas keamanan yang berbeda. Cursor pada dasarnya menonaktifkan Workspace Trust[0], dan cukup dengan membuka repositori yang memiliki "runOn": "folderOpen" di .vscode/tasks.json, kode arbitrer sudah bisa dijalankan[1]
  [0] https://cursor.com/docs/agent/security#workspace-trust
  [1] https://www.oasis.security/blog/cursor-security-flaw

• Mindgard disebut pertama kali menemukan kerentanan ini pada 15 Desember 2025 dan melaporkannya beberapa kali pada hari itu dan setelahnya, tetapi bahkan setelah 6 bulan dan lebih dari 197 versi baru, masalah ini masih ada di Cursor terbaru
  Awalnya laporan itu ditutup sebagai laporan informasional/di luar cakupan, lalu setelah banding HackerOne membukanya kembali, mereproduksinya, dan meneruskannya ke Cursor, tetapi setelah itu permintaan pembaruan, pertanyaan tambahan, eskalasi melalui HackerOne, hingga kontak ke eksekutif Cursor semuanya tidak mendapat jawaban, sehingga sulit memahami mengapa Cursor merespons seperti ini

  • Prosedur penanganan CVE itu sendiri sudah rusak. Dengan berkembangnya AI berbentuk agen, program pengungkapan kerentanan di HackerOne dan perusahaan kini dibanjiri sekaligus oleh laporan berkualitas rendah dan laporan yang benar-benar sangat bagus, dan karena AI yang sama bisa menulis keduanya, hampir mustahil membedakannya hanya dari permukaan
    Akibatnya perusahaan tidak lagi merespons seperti dulu, dan bahkan di konferensi keamanan siber bulan Juni ada suasana kuat bahwa responsible disclosure sudah mati atau sedang sekarat, sehingga lebih baik mengungkapkannya secara terbuka. Kasus Microsoft dan Nightmare Eclipse sering dikutip
  • Muncul juga kemungkinan adanya backdoor yang disengaja. Jika NSA atau FBI menaruh git.exe di repositori yang menarget seseorang lalu membuat target mengklonnya, payload bisa dijalankan
    Karena Cursor berbasis VS Code, saya jadi penasaran apakah hal yang sama juga terjadi di VS Code

• Sulit untuk sepenuhnya setuju bahwa ini adalah kerentanan kritis. Agar bisa benar-benar dieksploitasi, penyerang harus lebih dulu menaruh file eksekusi berbahaya bernama git.exe di folder kode pengguna, dan ini mirip dengan menyebut perubahan .bashrc agar ls menjadi alias yang menjalankan /tmp/mega-big-virus.sh sebagai kerentanan
  Ini memang jalur serangan, tetapi jika file seperti itu sudah masuk ke sistem file maka bisa dianggap kompromi awal sudah terjadi

  • Hanya dengan mengklon repositori GitHub dan membukanya di Cursor sebagai editor default, pengguna bisa terinfeksi. Ini seperti saat memasukkan CD lalu autorun.exe berjalan dan Windows terinfeksi
    Memang bisa saja dikatakan bahwa semua file repositori dan biner mencurigakan seperti git.exe harus diperiksa sendiri oleh pengguna di lingkungan terisolasi, tetapi di dunia nyata yang mengendalikan hal ini bukan pengguna melainkan kebijakan keamanan yang mencegah eksekusi otomatis, dan di Cursor pun seharusnya dinonaktifkan
  • Berbeda dengan .bashrc, folder kode sering diambil dari sumber yang tidak tepercaya. Hanya karena dibuka untuk meninjau proyek GitHub, itu tidak boleh sampai mengizinkan eksekusi kode arbitrer
    Namun di IDE utama, batas seperti ini sebenarnya sudah lama runtuh, dan fitur remote SSH serta devcontainer di VS Code juga secara desain mengizinkan eksekusi kode jarak jauh
  • Sejak dua paragraf pertama halaman itu sudah dijelaskan dengan jelas bahwa setelah membuka proyek, Cursor mencari biner Git di beberapa lokasi termasuk workspace saat ini, dan jika git.exe berbahaya diletakkan di root repositori maka file itu dijalankan tanpa input atau konfirmasi dari pengguna. Ini bukan tulisan yang menyembunyikan perilaku intinya
  • Hanya dengan mengklon repositori dan membukanya di IDE saja, itu setara dengan memberi izin eksekusi kode jarak jauh kepada pemilik repositori, dan sulit menganggapnya sebagai kontrak yang secara implisit termasuk dalam tindakan membuka folder
  • Bahkan 30 tahun lalu sudah ada serangan urutan pencarian DLL, misalnya menaruh DLL pengganti yang terinfeksi di folder MP3 atau foto agar dimuat oleh Winamp atau penampil foto Windows, dan kasus ini sangat mirip

• Cursor menjalankan file eksekusi arbitrer tanpa konfirmasi memang terasa aneh, dan fakta bahwa para peneliti tidak mendapat tanggapan yang layak selama berbulan-bulan juga mengkhawatirkan
  Namun contoh menjalankan kalkulator bisa sedikit menyesatkan. File eksekusi berbahaya itu harus sudah diunduh ke sistem terlebih dahulu, dan saat Cursor mencoba menjalankannya, saya memahami bahwa ACL akan aktif dan menanyakan izin untuk pertama kali menjalankan aplikasi baru yang tidak ditandatangani. Untuk eksploitasi nyata, ACL mungkin harus sepenuhnya dinonaktifkan

  • Jika muncul dialog “Apakah Anda ingin menjalankan git.exe?”, besar kemungkinan orang akan mengira Cursor memang memerlukan Git dan pengaturan izinnya sedang bermasalah, lalu tetap menyetujuinya
  • Hal yang sama juga bisa terjadi jika seseorang memakai PS1 yang menampilkan branch Git saat ini sambil memasukkan direktori saat ini ke PATH. Kalau begitu, apakah Bash juga harus diajukan sebagai CVE berisiko tinggi menjadi pertanyaan

• Ini tampaknya bukan bug khusus Cursor, melainkan terkait dengan urutan pencarian khas Windows yang mencari file eksekusi di direktori kerja saat ini sebelum Windows memeriksa PATH. Banyak program lain di Windows kemungkinan terekspos pada serangan serupa

  • Perangkat lunak yang memperhatikan keamanan sudah memperbaiki masalah ini
    Seperti dijelaskan di https://go.dev/blog/path-security, Command dan LookPath mencari program di direktori yang tercantum dalam PATH saat ini sesuai kebiasaan sistem operasi, tetapi pada masa kini perilaku yang juga mencakup direktori saat ini sering kali tidak terduga dan menimbulkan masalah keamanan
    https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
  • Ini bisa dengan mudah dimitigasi dengan mencari file eksekusi Git yang sebenarnya di jalur sistem yang sudah dikenal atau membiarkan pengguna mengatur jalurnya, dan setahu saya VS Code juga menanganinya dengan cara seperti itu
  • Ini adalah jebakan keamanan lama dan sudah dikenal baik yang wajib diantisipasi saat mengembangkan perangkat lunak untuk Windows
  • Kalau begitu, pada akhirnya ini terdengar seperti bug sekaligus kerentanan pada Cursor versi Windows

• Sering sekali perusahaan tidak memprioritaskan keamanan, dan meski disayangkan, ada sisi yang bisa dimengerti. Bisa juga dimengerti ketika startup keamanan yang lelah menunggu memilih mengungkapkannya agar setidaknya sebagian biaya yang dikeluarkan bisa dipulihkan lewat efek publisitas, dan ada kalanya pengungkapan kerentanan secara terbuka memang diperlukan
  Namun, jika benar-benar ingin membantu penyelesaiannya, rasanya mereka bisa melakukan lebih dari sekadar mendesak di HackerOne dan sekali mengirim pesan LinkedIn ke CISO. Sekarang semuanya terasa pahit karena tampak seolah tak ada yang benar-benar peduli

  • Tidak jelas apa yang dimaksud dengan sungguh-sungguh membantu penyelesaian, dan apa tepatnya biaya hangus yang dimaksud di sini. Secara keseluruhan terdengar terlalu samar

• Saya penasaran mengapa Cursor mengeksekusi file eksekusi secara otomatis, dan dari alur pengambilan keputusan seperti apa perilaku ini muncul. Vim juga pernah punya masalah menjalankan kode tak terduga saat memuat file karena fitur eksplisit seperti %{expr}, tetapi sulit memahami mengapa Cursor justru mencari git.exe dan fitur ini sebenarnya membantu siapa
  Bahkan dari sudut pandang orang yang belum pernah memakai Cursor, saya jadi penasaran mengapa CVE yang tampak redundan dan seolah mudah diperbaiki seperti ini bisa ada

  • Alur yang umum adalah meminta Cursor merangkum repositori yang sudah ada dan menulis README, lalu Cursor membaca repositori dan kodenya, kemudian menjalankan perintah Git untuk menyediakan metadata seperti branch pengembangan atau tag sebelumnya
    Masalahnya, ketika diminta mengevaluasi repositori jarak jauh, setelah mengkloning repositori lalu menjalankan git ... di direktori kerja, Windows bisa menganggap file git yang ada di direktori itu sebagai target yang harus dijalankan. Kode juga bisa langsung dijalankan saat beralih ke repositori yang tidak tepercaya atau branch yang telah disusupi
    Solusi umumnya adalah menggunakan jalur lengkap ke Git yang terpasang di sistem; meski merepotkan untuk diketik manusia, bagi Cursor ini pekerjaan sepele
  • Tampaknya tujuannya adalah menemukan Git milik pengguna yang sebenarnya agar agen bawaan bisa membaca konteks di berbagai branch dan worktree. Ada cara yang lebih aman, tetapi sedikit jalan pintas seperti ini mudah sekali gagal dalam alur kerja berbantuan AI, dan juga mudah terlewat dalam klasifikasi bug yang memanfaatkan AI

• Karena agen pengembang sering diberi izin untuk mengambil dan mengunggah repositori Git, ini menjadi jalur serangan rantai pasok yang sangat besar. Jika agen Cursor yang sedang berjalan mengambil file terbaru dan penyerang telah menanam file eksekusi di proyek, tiba-tiba ratusan ribu orang bisa menjalankan EXE sembarang dengan hak pengguna biasa

• Laporannya agak terasa seperti tulisan AI. Untuk mengeksploitasinya, muatan berbahaya harus sudah ada di PC lewat proses seperti clone atau download, jadi saya paham tingkat keparahannya, tetapi tetap berharap situasi seperti itu tidak terjadi sejak awal

  • Agen coding modern kadang mengkloning repositori dan membaca kode saat ditanya tentang API yang dokumentasinya tidak jelas, jadi kerentanan ini memang bisa dieksploitasi di dunia nyata
  • Muatan berbahaya bisa berada di repositori jarak jauh. Cukup git clone repositorinya lalu membukanya dengan Cursor, maka kompromi selesai
  • Jika Anda pengembang open source, Anda bahkan bisa menerima pull request yang berisi git.exe
  • Biasanya orang tidak menganggap mengunduh repositori dan melihat source code sebagai hal yang sama dengan mengaktifkan muatan berbahaya, dan justru itulah bagian yang mengkhawatirkan. Meski gaya AI terasa mengganggu, yang seharusnya dikritik adalah isi kerentanannya, bukan cara penulisannya
  • Sulit memastikan bahwa muatan harus sudah ada di PC sebelumnya. Jika lewat prompt injection bisa diarahkan untuk menjalankan perintah seperti download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;), ada kemungkinan agen akan mengunduh git.exe lalu menjalankannya