Penyalahgunaan GitHub MCP: Akses ke Repositori Privat melalui MCP

• Kerentanan serius ditemukan pada integrasi GitHub MCP, yang memungkinkan penyerang memanipulasi agen pengguna melalui GitHub Issue berbahaya dan membocorkan data repositori privat
• Kerentanan ini merupakan jenis baru yang disebut Toxic Agent Flow, di mana agen dipicu oleh prompt berbahaya untuk mengekspos data yang tidak diinginkan ke repositori publik
• Kerentanan ini muncul bukan karena cacat pada alat itu sendiri, melainkan dari keterbatasan arsitektural, dan kebiasaan penggunaan yang realistis seperti kebijakan konfirmasi penggunaan yang sederhana turut memperbesar risiko
• Untuk pertahanan yang efektif, perlu diterapkan langkah perlindungan agen yang sistematis seperti kontrol izin yang terperinci dan pemantauan keamanan berkelanjutan
• Karena alignment model saja tidak cukup, langkah keamanan tingkat sistem di seluruh lingkungan MCP dan agen menjadi penting

---

Ringkasan

Invariant menemukan kerentanan yang sangat serius pada integrasi GitHub MCP yang banyak digunakan (14.000 stars). Kerentanan ini memungkinkan penyerang membuat GitHub Issue berbahaya untuk memanipulasi agen pengguna dan membocorkan data dari repositori privat ke luar

Masalah ini merupakan kasus pertama yang ditemukan oleh pemindai deteksi otomatis Toxic Agent Flow milik Invariant. Dalam skenario seperti ini, agen diarahkan untuk melakukan tindakan yang tidak dimaksudkan, sehingga menimbulkan dampak seperti kebocoran data atau eksekusi kode berbahaya

Karena industri belakangan ini mulai mengadopsi coding agent dan IDE secara luas, ini adalah saat yang penting untuk meningkatkan kewaspadaan terhadap serangan semacam ini

Skenario serangan

• Persiapan serangan

  • Diasumsikan pengguna telah menghubungkan klien MCP seperti Claude Desktop dengan server GitHub MCP
  • <user>/public-repo: repositori publik tempat siapa pun dapat membuat Issue
  • <user>/private-repo: repositori privat yang menyimpan data internal perusahaan dan sejenisnya
  • Penyerang membuat Issue berbahaya di repositori publik (termasuk prompt injection)
  • Saat pengguna memberikan permintaan biasa seperti “tolong lihat daftar issue di public-repo”, agen mengambil Issue repositori publik dan terekspos pada injeksi tersebut

• Alur serangan

  • Begitu agen membaca Issue berbahaya, agen mengambil data repositori privat ke dalam konteks, lalu membuatnya dalam bentuk PR di repositori publik sehingga dapat diakses siapa pun
  • Proses ini didefinisikan sebagai Toxic Agent Flow, dan dapat dideteksi secara otomatis di lingkungan nyata dengan analis keamanan Invariant

Demonstrasi serangan

• Sebagai contoh, serangan direproduksi menggunakan repositori publik (ukend0464/pacman) dan beberapa repositori privat
• Penyerang membuat Issue berbahaya di repositori publik, dan prompt injection dijalankan saat agen mengambil daftar Issue repositori tersebut
• Ketika pengguna meminta bantuan kepada Claude 4 Opus, Claude menjalankan injeksi melalui integrasi GitHub MCP
  • Claude Desktop pada dasarnya meminta konfirmasi saat menggunakan tool, tetapi banyak pengguna menjalankannya dengan kebijakan "selalu izinkan" sehingga bertindak tanpa sadar
• Agen mengekstrak data repositori privat dan mengeksposnya sebagai PR publik
• Dalam eksperimen, informasi sensitif seperti nama proyek privat, rencana relokasi tempat kerja, dan gaji ikut bocor

Deteksi Toxic Agent Flows

• Kerentanan ini dapat terjadi meskipun tool MCP yang ada tidak dikompromikan, karena dipicu oleh informasi tidak tepercaya yang masuk dari platform eksternal (GitHub)
• Dalam sistem agen berskala besar, analisis dan mitigasi risiko seperti ini sangat rumit jika dilakukan manual, sehingga Invariant mengembangkan metode deteksi otomatis untuk memungkinkan analisis ancaman secara proaktif

Cakupan dampak dan langkah penanganan

• Kerentanan ini tidak terbatas pada agen/klien tertentu dan memengaruhi semua agen yang menggunakan server MCP
• Ini bukan cacat pada kode server GitHub MCP itu sendiri, melainkan masalah desain, sehingga tidak dapat diselesaikan hanya dengan patch pada server GitHub
• Diajukan dua strategi penanganan utama

1. Kontrol izin yang terperinci

• Dalam lingkungan integrasi MCP, perlu diterapkan prinsip hak akses minimum agar agen hanya dapat mengakses repositori yang benar-benar diperlukan
• Otorisasi berbasis token tradisional saja memiliki keterbatasan dari sisi kegunaan
• Dengan lapisan keamanan runtime dinamis seperti Invariant Guardrails, kontrol akses dapat diperkuat sesuai konteks workflow
  • Contoh kebijakan: hanya mengizinkan akses ke satu repositori per sesi untuk mencegah kebocoran informasi lintas repositori
  • Contoh definisi kebijakan:

    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"]
    

  • Kebijakan dapat diuji melalui Guardrails Playground dan sejenisnya

2. Pemantauan keamanan berkelanjutan

• Selain langkah pencegahan, diperlukan alat pemantauan yang kuat untuk memindai interaksi antara agen dan sistem MCP secara real-time
• Contoh: menerapkan Invariant MCP-scan untuk pemantauan dan deteksi anomali
• Dengan memanfaatkan mode proxy terbaru, diagnosis real-time dimungkinkan hanya dengan mengalihkan trafik MCP melalui proxy tanpa mengubah infrastruktur saat ini
• Melalui pengawasan yang komprehensif, kerentanan dapat dideteksi, upaya kompromi dicatat, dan alur berbahaya dihentikan lebih dini

Mengapa alignment model saja tidak cukup

• Bahkan model bahasa besar terbaru (misalnya Claude 4 Opus) pun mudah terekspos pada serangan prompt injection sederhana
• Pelatihan alignment dasar saja tidak dapat mencegah seluruh variasi serangan yang beragam dan bergantung konteks di lingkungan deployment nyata
• Karena itu, mekanisme deteksi konteks dan sistem keamanan di tingkat sistem harus dibangun secara terpisah dari tahap model

Kesimpulan

• Invariant membuktikan adanya kerentanan serius pada server GitHub MCP yang memungkinkan agen diambil alih melalui GitHub Issue berbahaya dan menyebabkan kebocoran repositori privat
• Kerentanan ini merupakan contoh representatif yang ditemukan oleh sistem deteksi otomatis Invariant, dan serangan serupa terus terjadi di berbagai lingkungan termasuk MCP
• Penggunaan pemindai keamanan khusus seperti MCP-scan dan Guardrails menjadi kunci untuk adopsi dan operasi sistem MCP/agen yang aman

Referensi dan kontak

• Untuk penerapan keamanan tambahan atau kebutuhan konsultasi, dapat menghubungi [e-mail]

Penulis:
Marco Milanta
Luca Beurer-Kellner

[crawler]

Kedengarannya besar, tetapi pada dasarnya ini hanyalah masalah prompt injection + terlalu banyaknya izin yang bisa digunakan MCP.
Jadi terasa seperti sedang mempromosikan alat yang bisa mengendalikan izin MCP dari luar.
Akan bagus jika izin yang bisa digunakan MCP dibedakan antara prompt yang masuk dari luar dan prompt yang hanya dimasukkan dari dalam.

[GN⁺]

Opini Hacker News

• Saya merasa serangan ini belum sepenuhnya dipahami. Jika Anda memberi Claude access token, maka apa pun instruksi yang diberikan tentang bagaimana token itu harus digunakan, Claude bisa diarahkan untuk melakukan apa pun dalam cakupan izin token tersebut. Jika Anda memberikan kredensial ke LLM, Anda harus menganggap semua izin dari kredensial itu bisa dimanfaatkan oleh LLM. Ini terutama perlu diperhatikan jika pemanggilan penggunaan tool diizinkan otomatis. Namun, GitHub memiliki access token yang izinnya bisa dibatasi secara rinci, jadi jika hanya diberi izin untuk mengakses repositori tertentu, cakupan yang bisa disalahgunakan LLM jadi terbatas. Serangan ini hanya mungkin jika LLM memiliki akses ke seluruh akun, dan masalahnya justru ada pada pemberian kredensial berisiko seperti itu kepada Claude

  • Bagian penting dalam topik ini adalah, seperti kebanyakan serangan prompt injection, LLM ditempatkan dalam lingkungan di mana ia sekaligus memiliki dua dari setidaknya tiga hal: data yang dikendalikan penyerang, informasi sensitif, dan kemampuan eksfiltrasi data. Prinsip dasar desain agen adalah hanya membolehkan maksimal dua pada saat yang sama, dan aturan seperti ini perlu diterapkan untuk mencegah masalah keamanan. Misalnya, saat melihat issue yang dibuat oleh orang tak tepercaya, konteks LLM sudah terkontaminasi oleh data buatan penyerang. Setelah itu, jika ia mengakses informasi sensitif, maka fitur seperti koneksi internet harus dimatikan. Jika mengikuti model ini, sistem tetap aman bahkan tanpa token per repositori. Sayangnya, MCP tidak punya alat yang menjamin hal ini

  • Memang ada masalah token yang diatur dengan izin terlalu luas, tetapi di saat yang sama para developer juga tidak ingin membuka satu token untuk setiap repositori. Jadi mereka memberi token izin luas sambil mempercayai LLM tanpa syarat. Kehati-hatian semacam ini bijak, tetapi dalam praktiknya banyak pemain ekosistem tidak menjalankannya. Alasan laporan ini penting adalah karena ia mengedukasi bahwa jika LLM punya izin dan data tak tepercaya, apa pun bisa dibajak. Solusinya adalah membatasi cakupan penggunaan token secara dinamis. Kami sedang meneliti metode ini di daftar ini

  • Ini adalah masalah yang bisa muncul pada layanan seperti Railway. Railway kadang meminta akses ke seluruh repositori GitHub bahkan untuk deploy satu proyek, sedangkan Netlify menghormati pemberian izin hanya ke repositori yang diinginkan. GitHub seharusnya memblokir persetujuan untuk aplikasi yang tidak menghormati pembatasan akses seperti ini

  • Ini adalah pola yang selalu terulang setiap kali teknologi baru muncul. Seolah-olah prinsip keamanan dasar boleh diabaikan dalam konteks baru. Padahal, meskipun memakai teknologi terbaru yang "mengilap", prinsip keamanan dasar sama sekali tidak boleh diabaikan. Di dunia kripto pun, penipuan dan kejahatan finansial lama terulang kembali karena pelajaran lama diabaikan hanya karena teknologinya berbeda

  • Jika chatbot berinteraksi dengan pengguna, kita harus berasumsi chatbot itu akan melakukan apa pun yang diizinkan dalam batas kemampuannya. Chatbot hanyalah lapisan kemudahan di atas API, jelas bukan mekanisme keamanan tersendiri

• Jika tertarik pada MCP dan keamanan agen, ada beberapa materi yang sudah kami kerjakan. Lihat Claude execution trace untuk seluruh skenario serangan (tautan), security scanner untuk koneksi MCP (tautan), serangan tool poisoning MCP (blog), kasus eksploit WhatsApp MCP (blog), lapisan keamanan Guardrails untuk agen (blog), dan AgentDojo yang mengevaluasi keamanan serta utilitas agen AI secara bersama (blog)

• Saya ragu ini benar-benar layak disebut sebagai sebuah "eksploit". Jika Anda memberi agen token yang bisa mengakses repositori privat, ya tentu ia bisa mengaksesnya. MCP cuma server API. Kalau sesuatu tidak ingin diekspos lewat API, jangan beri izinnya sejak awal

  • Seperti banyak orang lain, saya juga membaca komentar dulu sebelum artikelnya. Kalau melihat isi artikel sebenarnya, issue berbahaya didaftarkan di GitHub, dan di dalam issue itu ada prompt yang memakai LLM untuk mendorong eksfiltrasi data. Ketika pemilik repositori memicu agen, agen tersebut dibuat bertindak mengikuti prompt berbahaya itu

  • Ini adalah eksploit yang sungguh-sungguh memanfaatkan kesalahan manusia (atau rasa percaya diri berlebihan). Masalahnya adalah orang-orang terbawa hype lalu dengan tenang memberikan token akses GitHub sensitif skala penuh kepada LLM

  • Topiknya penting jadi saya ingin sedikit menyentil: semua orang harus memahami dengan tepat risiko eksekusi tool AI. Agen saat ini mengeksekusi tool berdasarkan perhatian/konteks saat itu, dan perhatian ini mudah dipengaruhi oleh hasil eksekusi tool atau prompt. Tetapi di komentar orang hanya mengulang argumen sederhana seperti, "ini terjadi karena token-nya diberikan." Di sini, bahkan setelah masalah dijelaskan dengan benar, masih disayangkan ada yang terus mengaburkan pokok bahasan dengan sikap seperti "ya karena pengguna mengizinkannya." Ini argumen klasik yang keliru terhadap masalah confused deputy. Selain itu, orang mengusung "ini tanggung jawab pengguna", tetapi sebenarnya masalahnya juga karena MCP sendiri tidak menyediakan kontrol lanjutan pasca-akses atau logging. Saya baru merasa tenang jika logging wajib tersedia. Lalu ada juga yang meremehkan riset keamanan sambil menyebutnya "akal sehat", padahal membicarakan keamanan tidak pernah buruk. Hanya karena kerentanannya lemah bukan berarti tidak layak dibahas. Bahkan bisa dibilang ini sama seperti SQL injection. Dan saya rasa berbahaya jika orang tidak memahami sudut pandang bahwa sistem bisa dikontaminasi secara tidak langsung (mengirim muatan berbahaya lewat pendaftaran issue publik). Terakhir, sayang sekali ada yang terlalu defensif dan tidak terbuka pada pandangan baru

• Dari sudut pandang keamanan, saat LLM melihat teks dari sumber yang tidak tepercaya, kita harus menganggap sumber itu bisa mengendalikan bagaimana keluaran LLM dihasilkan. Jika hasilnya berujung pada pemanggilan tool, maka sumber tak tepercaya itu sekarang juga dapat memakai tool tersebut. Saat mencari informasi terkait, saya juga merasa dokumentasi Guardrails dari invariant labs agak bernuansa pemasaran. Dari sisi keamanan, cukup menyeramkan bahwa strukturnya begitu rumit sampai butuh produk guardrail seperti ini. Juga terasa disayangkan bahwa kalau perusahaan AI sejak awal merancang sistem dengan fokus keamanan, mungkin produk seperti ini tidak akan diperlukan

  • Ini masalah yang mudah jika pemisahan input dilakukan dengan baik. Cukup tandai prompt dengan tag seperti <github_pr_comment>, gunakan hanya sebagai baca-saja, dan tegaskan agar jangan pernah ditafsirkan sebagai perintah. Serangan kali ini sebenarnya strukturnya agak kompleks. Rasanya mirip isu prompt injection chatbot tempo hari. Sekarang MCP juga mulai jadi masalah

  • Saya juga penasaran apakah mungkin melatih LLM agar sebagian teks ditandai sebagai data mentah/tidak murni, sehingga interpretasi instruksional dari bagian itu diabaikan

  • Sebenarnya perusahaan AI memang memikirkan desain keamanan. Namun "eksploit" kali ini hanya mungkin dalam skenario saat keamanan dimatikan (dengan peringatan tebal). Misalnya Claude Desktop secara default meminta persetujuan langsung untuk setiap pemanggilan tool. Tetapi banyak pengguna mengatur ke “always allow” sehingga tidak memantau tindakan satu per satu

  • Pola kerentanan perangkat lunak seperti ini secara tradisional terus berulang, dan agak lucu sekaligus menjengkelkan bahwa hal yang sama selalu muncul pada teknologi baru. Polanya adalah "menerima input pengguna, lalu menafsirkannya dan menjalankannya sebagai perintah dalam lingkungan yang tidak terlindungi dengan baik." Kita sudah melihat cerita ini di SQL injection, XSS, PHP include, dan lain-lain, dan sekarang terulang lagi pada LLM

• Saya tidak merasa MCP itu sendiri revolusioner atau secara khusus rentan terhadap peretasan (meskipun saya punya pandangan terpisah soal MCP). Ini terasa seperti teknik prompt injection yang dibungkus secara marketing. Saat saya merancang sistem agen, saya selalu memakai filosofi: “apa pun yang bisa diakses agen, bisa diakses juga oleh siapa pun yang dapat mengakses agen itu.” Saya tidak menyerahkan kontrol akses kepada LLM, dan saya menegaskan bahwa tanggung jawab keamanan atas pekerjaan agen selalu ada pada subjek peminta itu sendiri. Dari awal sampai akhir tulisan ini, yang benar-benar harus kita perhatikan adalah resource apa saja yang benar-benar diberi akses kepada agen. Jika akses ke data email diizinkan, lalu email berisi prompt injection membujuk LLM agar mencuri token keamanan dan mengirimkannya, itu adalah risiko yang benar-benar serius

  • Menempelkan label MCP pada ini terasa seperti tren “kami taruh di blockchain” sepuluh tahun lalu. Pernyataan seperti "karena LLM adalah pihak yang menyetujui dan bertindak, maka prinsip least privilege harus diterapkan secara ketat" itu sudah jelas bagi siapa pun yang berpengalaman, tetapi mungkin generasi baru memang harus belajar lagi dasar-dasar ini

• Contoh serangan nyata dan respons agennya bisa dilihat di sini. Ada sisi lucunya karena agen benar-benar berhasil menyelesaikan serangan itu sepenuhnya

• Saya juga mencoba agen coding Google's Jules seminggu lalu, dan permintaan izin GitHub OAuth-nya meminta akses penuh ke semua repositori dan izin dalam akun. Desain seperti ini memang sebagian karena kemudahan developer, tetapi alur autentikasi GitHub OAuth sendiri juga turut menyebabkannya. Seharusnya sejak awal lebih mudah untuk memberi izin terbatas per repositori dan kemudian meminta izin tambahan bila perlu. Namun realitasnya kita terpaksa membuat akun GitHub terpisah yang hanya diberi akses ke repositori tertentu (contoh akun). Sangat merepotkan. Dokumentasi resmi GitHub juga memang menyarankan membuat machine user terpisah seperti ini, tetapi penetapan cakupan repositori default seharusnya lebih mudah. Kalau ada yang tahu cara lebih baik, saya benar-benar ingin mengetahuinya

  • Di halaman pengaturan GitHub, Anda bisa membatasi izin Jules ke repositori tertentu

• Saya merasa klaim tulisan ini terlalu dibesar-besarkan. Penjelasan bahwa eksfiltrasi data terjadi hanya dengan issue sederhana, padahal sebenarnya itu hanya mungkin jika pengguna sendiri melakukan banyak langkah yang berisiko dari sisi keamanan. Artinya, pengguna harus menyiapkan server MCP, memberi kredensial yang bisa mengakses repo publik dan privat, mengizinkan LLM mengakses server itu dan membaca issue repositori, lalu benar-benar membaca issue berbahaya itu sendiri, serta mengatur agar hasilnya dipublikasikan ke luar. Ini memang hasil yang buruk, tetapi tidak benar-benar layak disebut “kerentanan keamanan yang diserang pihak lain secara jahat.” Ini adalah konsekuensi karena pengguna sendiri membaca data tak tepercaya dan mengatur hasilnya untuk dikirim ke tempat tak tepercaya. Meski begitu, GitHub MCP juga punya sebagian tanggung jawab. Tidak mencegah pemrosesan silang antara repositori publik dan privat adalah masalah

  • Pada dasarnya, kita tidak boleh mengabaikan bahwa bahkan perintah sesederhana “tolong ringkas issue-issue ini” pun bisa menyebabkan instruksi berbahaya yang tertanam langsung di issue dieksekusi

  • Sudut pandang marketing MCP juga penting. Protokolnya sendiri memang seharusnya dipisahkan agar hanya lingkungan atau pengguna tepercaya yang bisa mengakses. Masalahnya, tidak ada cara standar untuk scoping atau autentikasi pada server MCP. Saya merasa ada masalah mendasar di seluruh industri kita soal cara penggunaan/implementasinya, lebih daripada pada GitHub MCP itu sendiri. Dalam praktiknya, saat memakai server MCP kustom, kami juga meneruskan informasi non-AI tambahan (ID, JWT, dan lain-lain) untuk melakukan blokir keamanan

  • Karena demam AI belakangan ini, kenyataannya banyak orang menerapkan konfigurasi dan alur berbahaya seperti ini tanpa berpikir panjang. Memang mudah mengatakan “hal seperti ini seharusnya tidak digunakan”, tetapi justru karena itulah guardrails benar-benar diperlukan. Orang sering membuat keputusan berisiko

  • Terkait argumen agar jangan mencampur repositori publik dan privat, pada praktiknya ini adalah pemanggilan tool yang sepenuhnya terpisah. Dari sudut pandang server MCP, tidak ada cara untuk mendeteksi interaksi tersebut

• Saya menemukan bahwa diskusi sekarang berlangsung di thread HN tersebut

  • Seperti yang sudah disebut di sana, risiko keamanannya jelas. Yaitu, jika Anda memberi sistem hak akses ke data privat dan juga mengizinkan pengguna eksternal memasukkan teks input arbitrer, maka pada akhirnya Anda secara tidak langsung juga memberi pengguna eksternal akses ke data privat itu. Ini masalah yang mudah dicegah jika hanya mengikuti praktik keamanan standar

  • Komentar saat ini telah dipindahkan dan dikumpulkan di sini

• MCP hanyalah satu protokol, dan ada banyak kasus serupa seperti A2A maupun pendekatan yang lebih primitif. Anda bahkan bisa menyuruh LLM membaca dokumentasi GitHub API lalu menggunakan token untuk memanfaatkan API itu. Memang belum semua LLM punya kemampuan pada level ini, tetapi sebentar lagi akan begitu. Mengamankan mekanisme pendaftaran tool secara sempurna pada praktiknya nyaris mustahil. Tanggung jawab akhir atas eksfiltrasi data pada akhirnya ada pada LLM. Para developer menginginkan peningkatan produktivitas dari LLM, sehingga entah keamanannya harus terjamin, atau kita akan sampai pada situasi di mana semua laptop perlu ditambahi firewall keamanan. Yang benar-benar merepotkan adalah, di masa depan mungkin sampai terjadi duel “LLM untuk menangkap LLM nakal” yang bahkan mengeksploitasi firewall keamanan itu sendiri