SSRF pada Azure MCP Server Dapat Membocorkan Token Identitas Terkelolanya ke URL

Microsoft menerbitkan CVE-2026-26118 pada 10 Maret 2026: kerentanan server-side request forgery pada Azure MCP Server Tools, paket yang memungkinkan agen AI dan klien MCP bertindak atas sumber daya Azure dalam bahasa alami. Penyerang yang dapat berinteraksi dengan agen berbasis MCP dapat mengirimkan URL berbahaya sebagai pengganti pengenal sumber daya Azure yang normal; server kemudian akan mengirim permintaan keluar ke alamat tersebut dan, dalam kata-kata Microsoft, “dapat menyertakan token identitas terkelolanya” — memberikan kepada pemanggil kredensial yang seharusnya tidak pernah dilihatnya. Microsoft memberi skor kerentanan ini CVSS 8.8 dan menilainya Penting, dan paket yang membawa perbaikan adalah 1.0.2 dan 2.0.0-beta.17. Advisori tersebut mencatat tidak ada eksploitasi dan tidak ada pengungkapan publik sebelum patch, dan tidak ada kerugian nyata yang tercatat untuknya. Insiden ini adalah salah satu entri dalam the Orca AI Incident Archive, yang menyimpan catatan lengkap beserta sumber yang dikutip, tingkat keparahan, dan penilaian keyakinan.

Apa yang sebenarnya dikatakan oleh pemberitahuan itu

Catatan Microsoft Security Response Center sangat singkat, dan hampir semua detail yang dipublikasikan tentang cacat ini berasal dari catatan tersebut atau dari jawaban Microsoft atas beberapa pertanyaan lanjutan. Deskripsi lengkapnya: “Server-side request forgery (ssrf) di Azure MCP Server memungkinkan penyerang yang berwenang untuk meningkatkan hak istimewa melalui jaringan.” Catatan CVE mereservasi pengenal tersebut pada 11 Februari 2026 dan mempublikasikannya pada 10 Maret pukul 14.00 UTC; catatan rilis Microsoft dan entri NVD keduanya mencantumkan tanggal tersebut. NVD menganalisis catatan itu dan mempublikasikannya pada 18.18 UTC sore hari yang sama. Satu-satunya pemberitahuan regulator yang ditemukan untuk artikel ini berasal dari Maroko: unit maCERT milik DGSSI memuat CVE-2026-26118 dalam buletin bertanggal 11 Maret 2026, yang mencantumkan Azure MCP Server Tools di antara produk terdampak pada tingkat risiko mereka sendiri, Important, tanpa skor terpisah dan dengan rujukan kembali ke rilis Microsoft.

Kelemahan ini dipetakan ke CWE-918, pemalsuan permintaan sisi server, dan klasifikasi dampaknya adalah eskalasi hak istimewa. Skor dasar Microsoft adalah 8.8 pada vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, dengan skor temporal 7.7 pada E:U/RL:O/RC:C — komponen E:U berarti tidak ada kode eksploit yang diketahui Microsoft saat skor ditetapkan, dan RL:O berarti perbaikan resmi tersedia. NVD mencantumkan skor dasar yang sama dan mengelompokkannya sebagai High; skala tiga langkah Microsoft sendiri menyebutnya Important.

Dua bidang sama pentingnya dengan skor. Catatan Microsoft menyatakan Dieksploitasi: Tidak dan Diungkapkan Secara Publik: Tidak. Catatan keputusan SSVC CISA pada entri NVD, bertanda waktu 5 Maret 2026, sependapat soal eksploitasi — tidak ada — sementara menilai dampak teknis total dan dapat diotomatisasi tidak. Model FIRST EPSS menempatkan probabilitas eksploitasi dalam 30 hari ke depan sekitar 1,0%, pada persentil ke-62,8, dalam pull bertanggal 3 November 2026. Ini adalah cacat yang ditemukan dan diperbaiki, bukan cacat yang diketahui telah digunakan.

Bagaimana pengenal sumber daya menjadi permintaan keluar

Azure MCP Server adalah implementasi Microsoft atas Model Context Protocol, antarmuka yang digunakan agen AI untuk memanggil alat. Alat-alatnya mengambil parameter yang diberikan agen — nama akun penyimpanan, pengenal langganan, nama basis data — dan mengubahnya menjadi panggilan terhadap bidang manajemen dan data Azure. Dokumentasi Microsoft menjelaskan bahwa server tersebut melakukan autentikasi melalui Entra ID menggunakan “kredensial pengguna Azure Anda atau identitas terkelola,” dengan akses dibatasi oleh kontrol akses berbasis peran Azure.

Cacatnya terletak pada titik di mana parameter yang seharusnya menamai sumber daya Azure justru diterima sebagai URL. Penjelasan Microsoft sendiri: penyerang "dapat mengeksploitasi masalah ini dengan mengirimkan input yang dirancang khusus ke alat Azure Model Context Protocol (MCP) Server yang menerima parameter yang disediakan pengguna. Jika penyerang dapat berinteraksi dengan agen yang didukung MCP, mereka dapat mengirimkan URL berbahaya sebagai pengganti pengenal sumber daya Azure yang normal." Server kemudian mengirimkan permintaan ke tempat yang diperintahkan kepadanya, bukan ke tempat yang dimaksudkan oleh alat tersebut.

Bagian yang mengubah gangguan menjadi eskalasi hak istimewa adalah apa yang ikut terbawa di dalamnya. Microsoft menyatakan bahwa permintaan keluar tersebut "dapat menyertakan token identitas terkelolanya," yang memungkinkan penyerang menangkap token itu "tanpa memerlukan akses administratif." Token identitas terkelola adalah kredensial bearer: siapa pun yang memegangnya dapat menyajikannya kepada layanan Azure yang menjadi kewenangan identitas tersebut, hingga token itu kedaluwarsa. Bagian yang meringankan dalam paragraf yang sama sama pentingnya — penyerang memperoleh "izin yang terkait dengan identitas terkelola MCP Server" dan, dalam kata-kata Microsoft, "tidak mendapatkan izin tingkat tenant atau administrator yang lebih luas; hanya izin yang terikat pada identitas terkelola yang dikompromikan." Radius dampaknya adalah apa pun yang diberikan seseorang kepada identitas tersebut, yang dalam praktiknya sering kali lebih luas daripada yang dibutuhkan satu alat saja.

Microsoft tidak menyebutkan nama alat atau parameter yang terdampak, dan tidak ada sumber yang ditelaah untuk artikel ini yang menyebutkannya. Kelalaian itu sendiri adalah sebuah detail: advisory tersebut menjelaskan sekelompok alat — alat yang menerima parameter yang diberikan pengguna dan dapat dipicu untuk mengambil URL — alih-alih satu endpoint tunggal.

Perbaikan itu, dan paket yang membawanya

Ini bukan pembaruan Windows. Azure MCP Server Tools dikirimkan sebagai paket NuGet untuk .NET, paket npm, dan paket Python di PyPI, dan perbaikannya adalah kenaikan versi pada paket mana pun yang digunakan oleh suatu deployment. Advisory Microsoft mencantumkan rentang yang terdampak sebagai 1.0.0 hingga sebelum 1.0.2, dan 2.0.0-beta.1 hingga sebelum 2.0.0-beta.17, di seluruh distribusi NuGet, npm, dan PyPI.

Tanggal pada registri npm menunjukkan bahwa build yang diperbaiki sudah ada di registri sebelum advisory. Versi 1.0.2 dari @azure/mcp diterbitkan pada 6 Maret 2026, empat hari sebelum CVE dipublikasikan; 2.0.0-beta.17 diterbitkan pada 6 Februari 2026, lima hari sebelum Microsoft mencadangkan pengenal CVE dan sebulan sebelum advisory muncul. Apa pun urutannya di dalam Microsoft, kode yang telah ditambal tidak ditulis sebagai respons terhadap hari publikasi. NVD dan basis data advisory GitHub sepakat tentang batas atas tersebut. Keduanya sedikit berbeda di bagian bawah rentang PyPI — NVD menyebut 2.0.0-beta.1, advisory GitHub menyebut 2.0.0b14 — perbedaan yang telah dibawa kedua catatan sejak publikasi dan yang hanya memengaruhi seberapa jauh ke belakang deployment Python perlu melihat.

Advisory itu sendiri direvisi pada 20 Maret 2026, sepuluh hari setelah publikasi, dengan catatan bahwa Microsoft telah "menambahkan produk ke tabel Security Updates yang mendokumentasikan berbagai metode pengemasan yang digunakan untuk mendistribusikan Azure MCP Server Tools." Dengan kata lain, versi pertama advisory tersebut menyebutkan produknya tetapi tidak semua kanal distribusinya, yang menjadi penting ketika remediasinya adalah "memutakhirkan paket" alih-alih "memasang KB ini."

Apa yang belum ditetapkan

Siapa yang menemukannya.Baik pengumuman Microsoft maupun catatan CVE.org tidak mencantumkan nama pelapor; kolom kredit pada CVE tersebut kosong. Itu bukan bukti bahwa tidak ada yang diberi kredit secara privat, melainkan hanya bahwa tidak ada kredit publik yang tersedia.

Eksploitasi apa pun.Microsoft mencatat tidak ada, penilaian SSVC dari CISA sependapat, dan tidak ada sumber yang ditinjau untuk artikel ini yang menggambarkan identitas yang dikompromikan di lapangan. Bidang real-harm pada catatan tersebut bernilai false, konsisten dengan hal itu. EPSS yang rendah adalah perkiraan, bukan temuan, dan tidak adanya insiden yang dilaporkan bukanlah bukti bahwa tidak ada yang terjadi.

Apakah exploit publik yang ada. Di sinilah cakupan sekunder terbelah. Sebuah unggahan Maret 2026 di blog Blueinfy menyatakan bahwa ada "exploit proof-of-concept publik, seperti yang ada di GitHub" dan memperingatkan tentang "senjataisasi yang cepat," tetapi tidak memberikan tautan, payload, atau panduan langkah demi langkah, dan tidak menunjukkan kelemahan tersebut. Catatan Microsoft menyatakan bahwa kerentanan itu tidak diungkapkan secara publik sebelum patch. Pencarian repositori GitHub untuk pengenal CVE pada 4 November 2026 mengembalikan satu repositori — sebuah lab deteksi Microsoft Sentinel yang diterbitkan 17 Maret 2026, bukan sebuah exploit — dan halaman kerentanan Mallory menyatakan bahwa dua kandidat exploit telah disaring dan ditolak. Klaim tentang kode exploit publik yang berfungsi, berdasarkan bukti yang tersedia, tidak terbukti; klaim bahwa belum ada yang mencoba juga sama-sama tidak terbukti.

Pembingkaiannya. Sebuah halaman di PolicyLayer, situs ringkasan insiden milik vendor, mengubah CVE-2026-26118 menjadi rangkaian eksekusi kode jarak jauh tanpa autentikasi yang berujung pada pengambilalihan tenant sepenuhnya, dengan menyebut nama seorang peneliti dan demonstrasi RSAC 2026. Sumber yang dikutip halaman itu sendiri berjudul SSRF, tanggal-tanggalnya tidak selaras dengan kronologi CVE, dan baik advisory Microsoft maupun pemberitaan SecurityWeek pada 10 Maret tidak menjelaskan eksekusi kode. Artikel ini memperlakukan uraian SSRF-dan-token sebagai yang mapan dan tidak mengulangi pembingkaian RCE.

Mengapa token, dan bukan permintaan, yang menjadi temuan

Server-side request forgery adalah salah satu kelas bug tertua dalam perangkat lunak web, dan dengan sendirinya biasanya merupakan cara untuk menjangkau sistem yang tidak dapat diakses langsung oleh penyerang. Yang membuat catatan ini layak dipertahankan adalah kredensial yang melekat pada permintaan tersebut. Server MCP secara desain merupakan confused deputy: server ini memegang identitas agar agen dapat bertindak atas nama pengguna, dan setiap parameter yang diteruskan agen, dari sudut pandang server, adalah teks yang dipengaruhi penyerang. Ketika salah satu parameter tersebut menjadi tujuan, bukan nama, deputi itu membawa otorisasinya sendiri ke tujuan tersebut.

Dokumentasi Microsoft memperjelas di mana risiko itu terkonsentrasi. Dokumentasi tersebut menggambarkan server lokal sebagai “ditujukan secara ketat untuk penggunaan pengembang di dalam organisasi Anda,” sementara secara terpisah menerbitkan panduan penerapan untuk server jarak jauh yang dihosting sendiri di Microsoft Foundry dan Copilot Studio — konfigurasi yang biasanya menggunakan identitas terkelola, alih-alih proses masuk pengembang sendiri, sebagai kredensial yang berlaku. Jalur pencurian token dalam advisori tersebut secara khusus berkaitan dengan identitas terkelola. Dokumen itu tidak menyatakan bahwa setiap instalasi terekspos, dan tidak menyebutkan berapa banyak yang terekspos.

Pelajaran umumnya adalah pelajaran yang kini dipakai OWASP AI Security Verification Standard untuk mengajarkan kasus ini. Bab orkestrasi AISVS mengutip CVE-2026-26118 di antara contoh-contoh yang dibahasnya dan menarik kesimpulan bahwa “{{1}}parameter alat MCP harus diperlakukan sebagai berada di bawah kendali penyerang, dan permintaan keluar dari server MCP harus melalui kebijakan egress dan origin yang sama dengan yang diharapkan untuk I/O lain yang digerakkan agen.{{/1}}” Itu adalah rekomendasi kontrol, bukan temuan tentang insiden ini, tetapi itu adalah jawaban paling konkret yang pernah diterbitkan siapa pun atas pertanyaan tentang apa yang harus berubah.

Apa yang berubah setelah

Tiga hal, dan tak satu pun dramatis. Microsoft merilis paket perbaikan di ketiga ekosistem dan merevisi advisory untuk menyebutkannya. Ekosistem intelijen kerentanan menerimanya dengan tenang: skor EPSS rendah, dan catatan NVD yang terakhir diubah pada 17 Juni 2026. Dan komunitas standar mengadopsinya sebagai studi kasus pengajaran, yang merupakan bentuk respons lebih lambat dan lebih tahan lama daripada patch.

Bagi siapa pun yang masih menjalankan build terdampak, remediasinya tidak berubah dan tidak mengesankan: pindah ke 1.0.2 atau yang lebih baru di jalur stabil, atau 2.0.0-beta.17 atau yang lebih baru di jalur pratinjau, di setiap manajer paket yang disentuh deployment. Di luar itu, logika advisory itu sendiri menyiratkan tiga kontrol — batasi apa yang dapat dijangkau server ke luar, beri identitas terkelola hanya peran yang benar-benar dibutuhkan alatnya, dan perlakukan parameter alat apa pun yang dapat menjadi URL sebagai input berbahaya. Tidak satu pun dari itu yang diperlukan untuk bisa selamat dari CVE-2026-26118. Masing-masing akan mengurangi nilai kontrol berikutnya bagi penyerang.

Bagaimana arsip mengklasifikasikan yang ini

Catatan tersebut diarsipkan sebagai kerentanan — sesuatu yang ditemukan, bukan sesuatu yang diketahui telah dieksploitasi — dengan tingkat keyakinan A, yang berarti terdokumentasi dengan baik dan sumber-sumber primer yang saling mendukung, serta tidak ditandai sebagai diperdebatkan. Bidang real-harm-nya bernilai false dan keterlibatan AI-nya terkonfirmasi, karena produk yang terdampak adalah jembatan antara agen AI dan control plane cloud, bukan layanan serbaguna yang kebetulan berada di dekatnya. Tanggalnya dicatat dengan presisi hari, 10 Maret 2026, tanpa tanggal akhir, karena ini adalah satu titik waktu, bukan sebuah kampanye. Wilayahnya global dan flag landmark bernilai false.

Satu bidang terbaca berbeda dari penilaian yang dipublikasikan. Tingkat keparahan arsip dicatat sebagai medium, pada skalanya sendiri; angka yang dipublikasikan Microsoft dan NVD adalah 8.8, yang oleh Microsoft disebut Important dan oleh NVD dikategorikan High. Ringkasan catatan diawali dengan 8.8 tersebut, dan perbedaan itu adalah perbedaan dalam pengelompokan, bukan dalam fakta.

Apa yang tidak dapat disampaikan oleh catatan itu adalah betapa besar bagian dari kisah ini yang berupa ketiadaan. Ada cacat yang menyerahkan identitas cloud kepada siapa pun yang memintanya dalam bentuk yang salah. Ada perbaikan, yang dirilis sebelum pengumuman. Tidak ada penemu yang disebut namanya, tidak ada alat yang dinamai, tidak ada eksploitasi yang terkonfirmasi, dan tidak ada cara bagi orang luar untuk mengetahui apakah ada penerapan yang dihosting pernah menjalankan build rentan sambil memegang identitas yang kuat. Imbauan keamanan itu tepat tentang apa yang dilakukan cacat tersebut dan diam tentang hampir semua hal lainnya, dan keheningan itu adalah hal yang paling berguna untuk diperhatikan darinya.