LiteLLM Kena Auth Bypass MCP (CVE-2026-59822) — Gateway AI Ternyata Control Plane ☠️

Kalau di server kamu ada gateway LLM (LiteLLM, router OpenAI-compatible, proxy model), mending duduk dulu. Tim riset Wiz memindai ~3.074 instance LiteLLM yang kebuka di internet: 9,6% (294 instance) masih pakai master key contoh sk-1234 atau malah tanpa autentikasi sama sekali. Dari riset itu lahir CVE-2026-59822 — auth bypass di endpoint MCP yang sekarang sudah masuk daftar CISA KEV dan terbukti dieksploitasi di alam liar.

☠️ Bug-nya sesimpel apa? Satu header ngawur

LiteLLM punya dua jalur autentikasi: API key LiteLLM sendiri, dan token OAuth2 yang diteruskan ke MCP server upstream. Masalahnya di fallback: waktu validasi key gagal dengan 401/403, handler-nya tidak membedakan "ini token OAuth2 sah untuk upstream" dengan "ini sampah". Ia menelan error-nya dan lanjut dengan objek auth kosong:

except HTTPException as e:
    if e.status_code in (401, 403):
        validated_user_api_key_auth = UserAPIKeyAuth()  # bypass

Efeknya: satu request, header Authorization: Bearer a (satu huruf!), sesi MCP langsung dianggap terautentikasi.

POST /mcp/ HTTP/1.1
Authorization: Bearer a

{"jsonrpc":"2.0","method":"initialize","id":1,...}
-> HTTP 200 + header mcp-session-id

📋 Fakta singkat

Item	Detail
CVE	CVE-2026-59822 (MCP auth bypass)
Versi terdampak	LiteLLM < 1.84.0
Patch	1.84.0
Severity	High (CVSS 8.2 di OpenCVE/NVD, 8.8 di tracker lain)
Status	CISA KEV sejak 2 Sep 2026, deadline federal 16 Sep 2026
Eksploitasi	Diamati honeypot Wiz sejak 7 Juli 2026

🎯 Kenapa ini lebih gede dari sekadar "LLMjacking"

Narasi lama: gateway kena → orang pakai kuota model kamu, tagihan bengkak. Menyakitkan, tapi terbatas.

Realitanya tidak. Gateway LLM itu control plane: dia pegang API key semua provider, membaca semua prompt/response, menjalankan kode Python (custom guardrail), bisa proxy ke URL internal, dan menyambungkan model ke tools lewat MCP. Jadi bypass di /mcp/ = pintu ke semua yang tersambung: database, repo GitHub, filesystem, sampai aksi CI/CD.

Beberapa temuan lain dari riset yang sama:

• CVE-2026-59821 — custom code guardrail bisa dieksekusi di proses proxy (patch: 1.82.0-stable). Wiz melihat kodenya jalan sebagai root di container uji.
• Auth default/kosong — 191 instance publik benar-benar tanpa auth, dan sebelum patch, instance tanpa master key menganggap pemanggil tak dikenal sebagai PROXY_ADMIN. Kombinasi ini membuat RCE-nya praktis pre-auth.
• Pass-through endpoint tanpa validasi URL — admin bisa mengarahkannya ke metadata service AWS (IMDSv2) dan menarik kredensial cloud. Ini dianggap "fitur", tapi fatal kalau pintunya sudah bocor.

Ketiganya bukan satu rantai ajaib — prerequisitenya beda. Tapi semuanya berakar dari hal yang sama: gateway diperlakukan seperti middleware biasa, padahal dia selevel control plane.

🔍 Cek server sendiri, 5 menit

1. Versi: pip show litellm | grep -i version atau cek tag image container. Di bawah 1.84.0 = kena.
2. Keterpaparan: cek apakah port proxy (default 4000) dan rute /mcp/ bisa diakses dari luar.
3. Tes negatif (paling penting): kirim request initialize ke /mcp/ dengan token ngawur. Harus 401/403. Kalau 200 → bolong.
4. Log: cari sesi MCP dengan bearer token yang tidak cocok dengan key manapun.
5. Master key: pastikan bukan sk-1234 dan bukan key yang dipakai ulang di tempat lain.

🛠️ Yang harus dilakukan

• Upgrade ke ≥ 1.84.0, lalu jangan berhenti di versi minimum — advisory LiteLLM terus bermunculan, pin image + verifikasi provenance.
• Belum bisa upgrade? Blok rute /mcp/ di reverse proxy/network layer, atau matikan integrasi MCP sementara.
• Rotate: master key, key provider model, kredensial DB/OAuth yang bisa dijangkau tools MCP.
• Container jangan root, batasi egress (blok 169.254.169.254), kasih IAM minimum.
• Audit tools MCP: kalau tidak dipakai, matikan. Kalau dipakai, scope sekecil mungkin.

🐷 Catatan dari kandang Chokdi

Kami juga menjalankan gateway model yang membagi trafik ke banyak provider, dan pelajaran dari kasus ini masuk checklist internal kami: service yang pegang kredensial + punya tools = control plane, bukan "cuma middleware". Rutinitas auditnya sederhana — cek versi, tes auth negatif, dan pastikan endpoint admin/MCP tidak ikut terpublish gara-gara tunnel, docker -p, atau LoadBalancer yang lupa ditutup. Kebanyakan insiden bukan karena bug eksotis, tapi karena pintu yang tidak sengaja dibiarkan terbuka.

🎯 Kesimpulan

Satu bearer token ngawur, satu request, sesi MCP sah — itu CVE-2026-59822. Kalau kamu jalanin LiteLLM di versi di bawah 1.84.0: upgrade hari ini, tutup /mcp/, rotate kredensial, dan jangan tunggu sampai CISA KEV yang ngasih tahu. Gateway kamu nyimpen kunci seluruh infrastruktur AI kamu — perlakukan seperti itu.

Sumber: Wiz Research ("Breaking LiteLLM: From Auth Bypass to Cloud Compromise"), GitHub Advisory GHSA-7488-6r32-c95q, CISA KEV (Sep 2026), analisis Hive Security.

— Chokdi 🐷 · Content Studio · 2026