Rantai Eksploitasi LiteLLM: Dari Injeksi Perintah Hingga Eksekusi Kode Jarak Jauh Tanpa Otentikasi

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Kedua endpoint ini menerima konfigurasi server MCP lengkap dalam badan (body) permintaan JSON, termasuk field Cmd, args, dan env yang digunakan oleh transport stdio untuk meluncurkan proses server . Ketika pengguna yang terotentikasi memanggil salah satu endpoint dengan konfigurasi ini, LiteLLM mengambil nilai Cmd yang diberikan dan menjalankannya sebagai subproses di mesin host, dengan hak akses sistem operasi yang sama dengan proses proxy LiteLLM itu sendiri .

Awalnya, BerriAI mengungkapkan ini sebagai bug RCE terotentikasi—penyerang memerlukan kunci API yang valid untuk mencapai endpoint tersebut, dan tidak ada pemeriksaan berbasis peran untuk membatasi siapa yang bisa memanggilnya. Bahkan pengguna internal dengan hak istimewa rendah yang memiliki kunci API proxy yang valid pun dapat mengeksekusi perintah sewenang-wenang di host . Tapi ceritanya tidak berhenti di situ.

Bypass 'BadHost' Starlette yang Menghilangkan Syarat Otentikasi

Kerentanan kedua adalah CVE-2026-48710, yang dijuluki "BadHost" oleh para peneliti. Ini adalah celah validasi host header di Starlette, framework ASGI ringan yang menjadi fondasi bagi FastAPI, vLLM, dan ribuan aplikasi web Python lainnya—termasuk LiteLLM . Semua versi Starlette dari 0.8.3 hingga 1.0.0 terpengaruh .

Akar masalahnya adalah perbedaan cara parsing antara bagaimana Starlette merutekan permintaan masuk dan bagaimana ia merekonstruksi URL untuk logika aplikasi . Lapisan routing ASGI menggunakan path HTTP mentah dari permintaan untuk menentukan endpoint mana yang menanganinya. Tetapi request.url—URL yang dilihat oleh middleware dan dekorator aplikasi—dibangun ulang dengan menggabungkan nilai header Host mentah dengan path permintaan, tanpa validasi yang memadai .

Dengan menyuntikkan karakter pemisah URI seperti ? atau # ke dalam header Host, penyerang dapat membuat request.url.path tampak benar-benar berbeda dari path yang sebenarnya dirutekan . Middleware melihat path yang tampaknya aman seperti /, sementara router di belakang layar meneruskan permintaan ke endpoint target yang sebenarnya. Setiap middleware otentikasi berbasis path yang mempercayai request.url.path dapat dilewati dengan mudah .

Menggabungkan Rantai: Dari 8.7 ke 10.0

Dekorator otentikasi LiteLLM memeriksa request.url.path untuk menentukan apakah sebuah permintaan memerlukan kunci API yang valid. Bypass 'BadHost' memungkinkan penyerang memanipulasi URL tersebut sehingga middleware otentikasi melihat path yang tidak memerlukan otentikasi, sementara router ASGI secara bersamaan mengirimkan permintaan ke salah satu endpoint injeksi perintah MCP yang rentan .

Ini menghilangkan satu-satunya gerbang kontrol akses yang berdiri antara internet dan eksekusi perintah sewenang-wenang. Seorang penyerang tanpa kredensial dan tanpa akses sebelumnya ke jaringan dapat mengirim satu permintaan HTTP yang dibuat khusus yang sepenuhnya melewati otentikasi dan menjalankan perintah sistem operasi di host proxy LiteLLM . Horizon3.ai mengonfirmasi bahwa rantai penuh ini berfungsi dan memberinya skor CVSS gabungan 10.0—tingkat keparahan maksimum—karena mencapai RCE tanpa otentikasi .

Apa yang Bisa Dilakukan Penyerang dengan Akses Ini

Eksploitasi yang berhasil memberi penyerang eksekusi perintah dengan hak istimewa dari proses proxy LiteLLM. Dari sana, permukaan ancaman meluas dengan cepat:

• Eksekusi perintah sewenang-wenang: Penyerang dapat memasang backdoor, malware, penambang mata uang kripto, atau perangkat lunak lain apa pun yang diizinkan oleh izin proses host .
• Pencurian kredensial skala besar: Proxy LiteLLM berada di antara aplikasi dan puluhan penyedia LLM. Proxy ini menyimpan kunci API untuk OpenAI, Anthropic, Azure, AWS Bedrock, Google, dan layanan terhubung lainnya dalam database atau variabel lingkungannya . Mengeksploitasi kerentanan ini memungkinkan penyerang mencuri setiap kredensial yang tersimpan dalam satu operasi.
• Pergerakan lateral melalui infrastruktur AI: Dengan kunci API cloud yang dicuri dan akses shell ke host proxy, penyerang dapat beralih ke layanan terhubung, server MCP internal, basis data vektor, dan framework agen hilir .
• Implikasi ekosistem yang lebih luas: Celah 'BadHost' Starlette memengaruhi lebih dari 400.000 proyek dependen, termasuk aplikasi FastAPI, server vLLM, deployment server MCP, dan framework agen AI. Siapa pun yang menggunakan middleware otentikasi berbasis path pada versi Starlette sebelum 1.0.1 juga rentan terhadap bypass otentikasi .

Mengapa Langkah CISA Meningkatkan Urgensi

Penambahan CVE-2026-42271 ke katalog KEV oleh CISA pada 8 Juni 2026 menegaskan bahwa kerentanan ini bukanlah teoretis—penyerang sedang aktif mempersenjatai dan menggunakannya saat ini . Berdasarkan Binding Operational Directive 22-01, semua lembaga cabang eksekutif sipil federal AS diwajibkan untuk menambal kerentanan yang terdaftar di KEV dalam jangka waktu remediasi yang ditentukan. CISA juga sangat menyarankan semua organisasi, baik publik maupun swasta, untuk memperlakukan penambahan ke dalam KEV sebagai prioritas penambalan darurat .

Langkah-Langkah Remediasi Segera

Perbaikan untuk eksploitasi berantai ini memerlukan pembaruan di dua sisi, ditambah beberapa langkah pertahanan berlapis untuk mengatasi paparan kredensial:

1. Upgrade LiteLLM ke versi 1.83.7 atau lebih baru. Rilis ini menghapus kemampuan endpoint uji MCP untuk mengeksekusi perintah yang disediakan pengguna secara langsung, menutup sepenuhnya vektor injeksi perintah .
2. Upgrade Starlette ke versi 1.0.1 atau lebih baru. Tambalan ini memvalidasi header Host yang masuk berdasarkan spesifikasi URL dan mengabaikan header yang mengandung karakter tidak valid, mencegah trik 'path confusion' yang mendukung bypass otentikasi .
3. Putar (rotate) setiap kredensial yang tersimpan segera. Asumsikan bahwa setiap kunci API, token akses, atau kredensial basis data yang pernah disimpan oleh proxy LiteLLM telah dikompromikan. Putar semua kunci penyedia seperti OpenAI, Anthropic, Azure, AWS, dan lainnya, dan periksa dasbor penagihan untuk penggunaan yang tidak sah .
4. Blokir endpoint di reverse proxy atau WAF. Sebagai langkah pertahanan berlapis saat tambalan sedang digulirkan, konfigurasikan reverse proxy atau Web Application Firewall (WAF) Anda untuk memblokir setiap permintaan ke

   POST /mcp-rest/test/connection

   dan

   POST /mcp-rest/test/tools/list

   sebelum mencapai aplikasi .
5. Audit akses tidak sah secara retrospektif. Periksa log proxy LiteLLM untuk aktivitas yang tidak biasa pada endpoint uji MCP, terutama permintaan dari alamat IP yang tidak terduga atau yang memiliki header Host yang dimanipulasi .

Tingkat keparahan gabungan CVSS 10.0, eksploitasi aktif di alam liar, dan penunjukan katalog KEV oleh CISA berarti organisasi yang menjalankan layanan bertenaga LiteLLM atau Starlette harus memperlakukan ini sebagai peristiwa tambal-dan-putar (patch-and-rotate) darurat. Jendela antara eksploitasi aktif dan pencurian kredensial sudah terbuka.