Ilustrasi teknis abstrak tentang pos pemeriksaan autentikasi pada jalur jaringan. Gerbang tinggi yang dibangun dari bingkai persegi panjang konsentris tipis berdiri di atas bidang navy hampir hitam dengan garis-garis koneksi rute samar. Bentuk token amber kecil mengantre di belakang penghalang tipis di sisi dekat, sementara satu token amber melewati bukaan gerbang tanpa hambatan, meninggalkan jejak cahaya. Garis putus-putus menyebar dari gerbang ke bawah menuju gugusan longgar node layanan geometris kecil. Struktur slate yang sejuk, aksen teal dan amber yang terkendali, karya garis datar seperti vektor, tanpa teks, tanpa angka, tanpa logo organisasi mana pun, dan tanpa orang. Logo OrcaRouter dikompositkan di sudut kanan bawah.
AI Safety Incidents

CISA Menambahkan Bypass Autentikasi MCP LiteLLM ke KEV: Token Bearer Apa Pun Sudah Cukup

Penulis

Rowan Sterling

Tanggal Terbit

Model terbaru · 20Lihat semua model →
Benchmark: Artificial Analysis · diperbarui setiap hari
Kembali ke semua artikel

Pada 2 September 2026, Badan Keamanan Siber dan Infrastruktur Amerika Serikat menambahkan CVE-2026-59822 ke katalog Kerentanan yang Diketahui Dieksploitasi sebagai "Kerentanan Autentikasi Tidak Tepat BerriAI LiteLLM", salah satu dari tujuh cacat dalam kumpulan hari itu. Bug tersebut terdapat pada endpoint MCP Streamable HTTP LiteLLM: ketika validasi kunci LiteLLM gagal, fallback passthrough OAuth2 menggantikannya dengan objek UserAPIKeyAuth() kosong alih-alih menolak permintaan, sehingga header Authorization Bearer yang dibuat-buat sekalipun membuka sesi MCP yang terautentikasi. Penyerang yang mencapai endpoint tersebut dapat melihat daftar dan memanggil setiap alat MCP yang dikonfigurasi pada gateway, dan melalui alat-alat itu menjangkau layanan di belakangnya. Semua versi sebelum 1.84.0 terdampak, dan lembaga sipil federal diberi waktu hingga 16 September untuk memperbaikinya. Catatan ini — pencantuman KEV untuk bypass autentikasi MCP LiteLLM — adalah satu entri dalam the OrcaRouter AI Incident Archive, yang menyimpan kumpulan catatan lengkap dan entri-entri di sekitar insiden ini.

Alasan bug pada proxy lebih penting daripada yang disiratkan skor CVSS-nya adalah apa yang berada di belakang proxy tersebut. Tim riset ancaman Wiz mengatakannya secara langsung: "Proxy LiteLLM dapat menyimpan kunci untuk setiap penyedia model yang dirutekannya, termasuk OpenAI, Anthropic, Azure, dan Gemini. Proxy ini juga mungkin berjalan dengan izin IAM cloud dan terhubung ke layanan internal melalui server alat MCP. Satu kompromi saja dapat memberi penyerang akses ke kredensial dan layanan di hilir proxy, bukan hanya ke proxy itu sendiri." Wiz Research mengatakan pihaknya menemukan celah tersebut, dan honeypot Wiz kemudian mencatat upaya untuk memanfaatkannya.

Mekanisme: pemeriksaan gagal yang mengembalikan sesi yang valid

Advisory BerriAI sendiri, GHSA-7488-6r32-c95q, menjelaskan cacat tersebut dalam dua kalimat: "Handler autentikasi MCP mendukung passthrough OAuth2 untuk server MCP hulu, tetapi jalur fallback dapat menggantikan validasi kunci LiteLLM yang gagal dengan objek UserAPIKeyAuth() kosong. Hal ini memungkinkan permintaan dengan header Authorization yang dipalsukan mencapai perkakas MCP tanpa kunci LiteLLM yang valid." Kata pentingnya adalah fallback. Kode tersebut memiliki cabang untuk deployment yang meneruskan token OAuth server MCP hulu secara langsung, dan ketika kunci LiteLLM gagal divalidasi, cabang itu mengembalikan objek autentikasi kosong alih-alih error.

Screenshot of the GitHub security advisory GHSA-7488-6r32-c95q, titled 'MCP Authentication Bypass via OAuth2 Passthrough Fallback' and marked High with a CVSS v4 score of 8.8 out of 10. The package table shows litellm on pip, affected versions below 1.84.0, patched versions at or above 1.84.0. The Impact section states that LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token, that the MCP auth handler's OAuth2 passthrough fallback could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object, and that an attacker could list and call configured MCP tools and access connected services exposed through MCP. A Patches section says the issue is fixed in 1.84.0. A Workarounds section says that if upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at the reverse proxy or API gateway. The severity panel lists Attack Vector Network, Complexity Low, Requirements None, Privileges Required None; the CVE ID field reads CVE-2026-59822.

Objek autentikasi yang kosong tidak sama dengan tidak adanya objek autentikasi. Kode hilir melihat UserAPIKeyAuth yang berhasil dikonstruksi lalu melanjutkan proses, tanpa tenant, tanpa pengguna, dan tanpa cakupan yang melekat padanya. Tulisan Wiz lebih blak-blakan soal konsekuensi praktisnya: "ketika validasi token gagal, alih-alih menolak permintaan, server mengembalikan objek UserAPIKeyAuth() kosong tanpa pembatasan apa pun. Token Bearer apa pun (bahkan hanya satu karakter, misalnya x) memberikan akses MCP penuh."

OrcaRouter card titled 'What the fallback path did', subtitled that the failure happened after validation rather than before it, in every version before LiteLLM 1.84.0. Four stages run left to right. Stage 1, Request arrives: the attacker holds no LiteLLM key, and a code block shows GET /mcp/ with the header Authorization: Bearer x. Stage 2, Key validation: the supplied token is checked and does not resolve to a key, marked FAIL, with a red tag reading NO REJECTION. Stage 3, OAuth2 passthrough fallback: intended for upstream OAuth tokens, it returned an object rather than an error, showing UserAPIKeyAuth(), with an amber tag reading EMPTY, NO SCOPE. Stage 4, MCP tooling: tools can be listed and called and connected services reached, showing tools/list followed by tools/call, with a green tag reading SESSION AUTHENTICATED. A lower band headed 'Why it held' explains that the branch returned a constructed authentication object rather than a boolean, so downstream code had a valid-looking UserAPIKeyAuth to read and no reason to ask whether the key behind it existed. A footer credits BerriAI advisory GHSA-7488-6r32-c95q and Wiz Research's 27 August 2026 write-up.

Yang didapat penyerang dari itu adalah menu. Protokol MCP mengekspos daftar alat, sehingga sesi yang terautentikasi mengembalikan nama dan skema setiap alat yang telah dikonfigurasi untuk dijangkau gateway — basis data, repositori kode, API internal, dalam contoh Wiz. Advisory vendor menyatakan efeknya secara gamblang: "Penyerang dapat menggunakan ini untuk mendaftar dan memanggil alat MCP yang dikonfigurasi serta mengakses layanan terhubung yang diekspos melalui MCP." Panggilan alat tersebut kemudian dieksekusi dengan otoritas apa pun yang dimiliki proxy itu sendiri terhadap backend tersebut, yang merupakan masalah konsentrasi kredensial yang dijelaskan Wiz.

Perbaikan pada Mei, CVE pada Juli, tenggat federal pada September

Tanggal-tanggalnya tidak selaras seperti yang mungkin diasumsikan pembaca, dan celah waktunya justru bagian yang menarik. LiteLLM 1.84.0 — versi pertama yang disebut advisory sebagai telah ditambal — diunggah ke PyPI pada 14 Mei 2026, menurut metadata rilis milik indeks paket itu sendiri. Pengenal CVE dicadangkan melalui CVE Program pada 7 Juli 2026 dan catatannya diterbitkan pada hari berikutnya, 8 Juli; entri OSV PYSEC-2026-3479 menyusul pada 23 Juli. Pencantuman dalam daftar KEV muncul pada 2 September, dengan tenggat remediasi 16 September.

OrcaRouter timeline card titled 'From patch to federal deadline', subtitled that the fixed build shipped sixteen weeks before the KEV listing and that the patch was never the bottleneck. Five dated rows, each with the source that records it: 14 May 2026, LiteLLM 1.84.0 published, per PyPI release metadata; 7 July 2026, CVE identifier reserved with the CVE Program, per the CVE.org record; 8 July 2026, CVE-2026-59822 published, assigned by GitHub as CNA, with the OSV record PYSEC-2026-3479 following on 23 July; 2 September 2026, added to CISA KEV as one of seven entries that day, added on evidence of active exploitation; 16 September 2026, federal remediation deadline, due date set for federal civilian agencies under BOD 26-04. A footer reads that dates are as recorded by each source named in the right-hand column.

Dua hal menyusul. Pertama, build yang telah ditambal tersedia untuk publik selama lebih dari tiga bulan sebelum CISA mencantumkan celah tersebut sebagai dieksploitasi — jadi organisasi yang terikat tenggat waktu memiliki pembaruan yang berfungsi selama seluruh periode itu, dan penambahan ke KEV bukanlah momen ketika perbaikan muncul. Kedua, kesenjangan versi telah melebar sejak saat itu: rilis LiteLLM saat ini di PyPI adalah 1.106.5, diunggah pada 27 Oktober 2026. Deployment yang masih berada pada versi apa pun di bawah 1.84.0 kini tertinggal lebih dari dua puluh rilis minor, bukan sekadar kurang satu patch.

Apa yang ditetapkan oleh daftar tersebut, dan apa yang tidak

Peringatan CISA untuk batch tersebut menyatakan bahwa penambahan dilakukan "berdasarkan bukti eksploitasi aktif", dan entri yang dapat dibaca mesin dalam katalog untuk CVE-2026-59822 mencantumkan tanggal ditambahkan 2 September 2026, tenggat waktu 16 September 2026, nilai penggunaan kampanye ransomware yang diketahui "Tidak Diketahui", dan dua kelemahan: CWE-287 (autentikasi tidak tepat) dan CWE-306 (autentikasi hilang untuk fungsi kritis).

• Terkonfirmasi: CISA menilai celah tersebut telah dieksploitasi secara aktif dan memasukkannya ke dalam daftar remediasi federal. Catatan SSVC NVD, yang diatribusikan kepada CISA Coordinator dan bertanda waktu 2 September 2026, mencatat eksploitasi sebagai "active", dapat diotomatiskan sebagai "yes", dan dampak teknis sebagai "partial".

• Terkonfirmasi: eksploitasi teramati di lingkungan terkendali. Wiz menerbitkan lalu lintas honeypot yang menunjukkan permintaan dengan token satu karakter yang menyelidiki endpoint enumerasi model: sebuah GET ke /v1/models yang membawa "Authorization: Bearer x". The Hacker News, yang melaporkan kumpulan KEV pada 3 September, menggambarkan aktivitas yang sama sebagai Wiz yang mengamati "upaya eksploitasi yang melibatkan CVE-2026-59822 terhadap honeypot-nya untuk menyelidiki endpoint enumerasi model."

• Ditetapkan: skor tingkat keparahan keduanya ada dan berbeda menurut kerangka kerja. Advisory BerriAI menilai cacat tersebut CVSS 4.0 sebesar 8.8, tinggi, dengan kerahasiaan tinggi, integritas rendah, dan ketersediaan tidak ada; penilaian CVSS 3.1 NIST sendiri, yang merupakan primer di NVD, menempatkannya pada 8.2. Kedua angka tersebut menggambarkan cacat yang sama dalam sistem penilaian yang berbeda dan tidak boleh dibandingkan seolah-olah yang satu menggantikan yang lain.

• Tidak terbukti: adanya korban yang disebutkan namanya. Baik peringatan CISA, advisory BerriAI, tulisan Wiz, maupun liputan The Hacker News tidak mengidentifikasi organisasi yang alat MCP-nya terjangkau melalui celah ini, atau melaporkan kredensial atau data yang diambil dari salah satunya. Catatan publik tentang eksploitasi adalah telemetri honeypot dan penetapan federal, bukan pelanggaran yang diungkapkan.

• Tidak dapat dipastikan: bahwa tidak ada kelompok ransomware yang menggunakannya. Kolom KEV bertuliskan "Unknown", yang merupakan nilai yang diberikan CISA, bukan temuan ketiadaan dalam hal apa pun.

Preseden Juni, dan rantai eksekusi kode jarak jauh bukanlah ini.

Ini adalah celah LiteLLM kedua yang masuk ke katalog KEV pada 2026, dan yang sebelumnya mudah tertukar dengannya. CVE-2026-42271, yang ditambahkan pada 8 Juni 2026 dengan tenggat 22 Juni, adalah injeksi perintah pada endpoint pengujian server MCP LiteLLM: Wiz menjelaskan endpoint yang memungkinkan pengguna menguji konfigurasi server MCP sebelum menyimpannya, dengan field command diteruskan ke eksekusi subprocess tanpa validasi. Penyerang mengirimkan konfigurasi server stdio palsu yang perintahnya mengunduh dan menjalankan cryptominer, dan mengembalikan handshake MCP yang tampak valid sehingga pengujian tersebut terlihat berhasil. Entri CISA untuk celah ini mencantumkan CWE-78 dan CWE-77 — injeksi perintah dan argumen, bukan autentikasi.

Kerentanan itu adalah yang dapat dirantai. Wiz menyatakan CVE-2026-42271 "dapat dirantai dengan bypass validasi header host Starlette (CVE-2026-48710) untuk mencapai RCE yang sepenuhnya tanpa autentikasi", dan bahwa peneliti eksternal telah mengaitkan kelompok ransomware Qilin dengan eksploitasi aktif rantai tersebut. CVE-2026-48710 ditambahkan ke katalog KEV dalam batch 2 September yang sama dengan bypass LiteLLM, dengan tenggat 16 September yang sama, dan catatan katalog CISA sendiri untuk cacat Starlette menyatakan bahwa cacat itu dapat dirantai dengan CVE-2026-42271. Kaitan Qilin adalah bagian dari pasangan tersebut. Ini bukan temuan tentang CVE-2026-59822, dan tidak ada apa pun dalam sumber yang ditinjau yang mengaitkan kelompok ransomware tersebut dengan bypass autentikasi.

Satu detail administratif membedakan kedua entri LiteLLM: tindakan yang diwajibkan dalam daftar Juni mengacu pada BOD 22-01, direktif operasional yang mengikat yang lebih lama, sedangkan daftar September mengacu pada BOD 26-04, "Prioritizing Security Updates Based on Risk". Peringatan CISA tidak menjelaskan perubahan tersebut, dan katalog tidak menganotasinya.

Apa yang berubah setelah

Jalur remediasi ini singkat. Advisory dari BerriAI merekomendasikan peningkatan ke versi 1.84.0 atau yang lebih baru, dan menawarkan solusi sementara bagi tim yang tidak dapat segera beralih: "nonaktifkan rute MCP atau blokir akses ke /mcp/ dan endpoint MCP terkait di reverse proxy atau API gateway Anda." Solusi sementara itu bersifat kasar — menghilangkan kemampuannya alih-alih membatasinya — tetapi itulah satu-satunya mitigasi yang disebutkan vendor untuk deployment yang belum ditambal.

Teks tindakan wajib CISA untuk titik masuk menempatkan lembaga federal pada trade-off yang sama: terapkan mitigasi sesuai instruksi vendor dan sejalan dengan BOD 26-04, “atau hentikan penggunaan produk jika mitigasi tidak tersedia”, dengan tanggung jawab pada setiap lembaga untuk mengevaluasi paparan internet suatu aset. Direktif ini hanya mengikat lembaga cabang eksekutif sipil federal; CISA mendorong organisasi lain untuk mengadopsi prioritisasi berbasis risiko yang sama tanpa mewajibkannya.

Apakah ada pihak di luar honeypot yang bertindak berdasarkan tenggat waktu tersebut tidak diketahui publik. Baik CISA maupun BerriAI tidak menerbitkan angka tentang berapa banyak penerapan LiteLLM yang terekspos, berapa banyak yang ditambal sebelum 16 September, atau berapa banyak yang terjangkau melalui bypass tersebut.

Apa yang masih terbuka?

Ada tiga celah yang perlu dinyatakan secara terbuka, bukan ditutupi. Tidak ada laporan insiden publik yang mengaitkan CVE-2026-59822 dengan intrusi tertentu, sehingga pencantuman dalam KEV bersandar pada bukti eksploitasi dari CISA dan pengamatan honeypot dari Wiz, bukan pada korban yang terdokumentasi. Tidak ada pernyataan vendor tentang bagaimana jalur fallback sampai ditulis seperti itu, atau berapa lama jalur tersebut ada sebelum 1.84.0 — advisory menjelaskan cacat dan perbaikannya, bukan riwayatnya. Dan tenggat waktu dalam batch itu tidak seragam: lima dari tujuh entri yang ditambahkan pada 2 September memiliki tenggat 5 September, sedangkan entri LiteLLM dan Starlette memiliki tenggat 16 September. CISA tidak menjelaskan alasannya.

Yang telah dipastikan lebih sempit dan lebih berguna daripada skor tersebut. Satu karakter dalam header Authorization, pada versi yang terdampak, tidak dapat dibedakan dari kunci yang valid oleh endpoint MCP — dan versi yang berperilaku demikian tidak lagi menjadi versi terkini pada Mei 2026.