LiteLLM CVE-2026-42271: Rantaian Kerentanan Gerbang AI yang Mencapai CVSS 10.0 RCE

• POST /mcp-rest/test/connection

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

Kedua-dua titik akhir menerima konfigurasi pelayan MCP lengkap dalam badan permintaan JSON, termasuk medan Cmd, args, dan env yang digunakan oleh pengangkutan stdio untuk melancarkan proses pelayan . Apabila pengguna yang disahkan memanggil salah satu titik akhir dengan konfigurasi ini, LiteLLM mengambil nilai Cmd yang dibekalkan dan melancarkannya sebagai subproses pada mesin hos, menjalankannya dengan keistimewaan sistem pengendalian yang sama seperti proses proksi LiteLLM itu sendiri .

Pada mulanya, BerriAI mendedahkan ini sebagai pepijat pelaksanaan kod jarak jauh yang disahkan—penyerang memerlukan kunci API yang sah untuk mencapai titik akhir tersebut, dan tiada semakan berasaskan peranan untuk menyekat siapa yang boleh memanggilnya. Malah pengguna dalaman dengan keistimewaan rendah dengan sebarang kunci API proksi yang sah boleh melaksanakan arahan sewenang-wenangnya pada hos . Namun, ceritanya tidak berakhir di situ.

Pintasan BadHost Starlette yang Menghapuskan Keperluan Pengesahan

Kerentanan kedua ialah CVE-2026-48710, yang digelar "BadHost" oleh para penyelidik. Ini adalah kelemahan pengesahan pengepala hos dalam Starlette, rangka kerja ASGI ringan yang menjadi asas kepada FastAPI, vLLM, dan ribuan aplikasi web Python lain—termasuk LiteLLM . Semua versi Starlette dari 0.8.3 hingga 1.0.0 terjejas .

Punca utamanya adalah perselisihan penghurai antara cara Starlette menghalakan permintaan masuk dan cara ia membina semula URL untuk logik aplikasi . Lapisan penghalaan ASGI menggunakan laluan HTTP mentah daripada permintaan untuk memutuskan titik akhir mana yang mengendalikannya. Tetapi request.url—URL yang dilihat oleh perisian tengah aplikasi dan dekorator—dibina semula dengan menggabungkan nilai mentah pengepala Host dengan laluan permintaan, tanpa pengesahan yang betul .

Dengan menyuntik aksara pembatas autoriti-ke-laluan URI seperti ? atau # ke dalam pengepala Host, penyerang boleh menjadikan request.url.path kelihatan berbeza sepenuhnya daripada laluan yang dihalakan sebenar . Perisian tengah melihat laluan yang tidak berbahaya seperti /, sementara penghala menghantar permintaan ke titik akhir sasaran sebenar di belakang tabir. Sebarang perisian tengah pengesahan berasaskan laluan yang mempercayai request.url.path boleh dipintas dengan mudah .

Menggabungkan Rantaian: Dari 8.7 ke 10.0

Dekorator pengesahan LiteLLM memeriksa request.url.path untuk menentukan sama ada permintaan memerlukan kunci API yang sah. Pintasan BadHost membenarkan penyerang memanipulasi URL tersebut supaya perisian tengah pengesahan melihat laluan yang tidak memerlukan pengesahan, sementara penghala ASGI pada masa yang sama menghantar permintaan ke salah satu titik akhir suntikan arahan MCP yang terdedah .

Ini menghapuskan satu-satunya pintu kawalan akses yang menghalang internet daripada pelaksanaan arahan sewenang-wenangnya. Penyerang tanpa bukti kelayakan dan tanpa akses sebelumnya ke rangkaian boleh menghantar satu permintaan HTTP yang direka khas untuk memintas pengesahan sepenuhnya dan menjalankan arahan sistem pengendalian pada hos proksi LiteLLM . Horizon3.ai mengesahkan rantaian penuh ini berfungsi dan memberikannya skor CVSS gabungan 10.0—keterukan maksimum—kerana ia mencapai pelaksanaan kod jarak jauh tanpa pengesahan .

Apa yang Penyerang Boleh Lakukan dengan Akses Ini

Eksploitasi yang berjaya memberikan penyerang pelaksanaan arahan dengan keistimewaan proses proksi LiteLLM. Dari situ, permukaan ancaman berkembang dengan cepat:

• Pelaksanaan arahan sewenang-wenangnya: Penyerang boleh memasang pintu belakang, perisian hasad, pelombong mata wang kripto, atau sebarang perisian lain yang dibenarkan oleh keistimewaan proses hos .
• Kecurian bukti kelayakan berskala besar: Proksi LiteLLM terletak di antara aplikasi dan berpuluh-puluh pembekal LLM. Ia menyimpan kunci API untuk OpenAI, Anthropic, Azure, AWS Bedrock, Google, dan perkhidmatan lain yang disambungkan dalam pangkalan data atau pembolehubah persekitarannya . Mengeksploitasi kerentanan ini membolehkan penyerang mencuri setiap bukti kelayakan yang disimpan dalam satu operasi.
• Pergerakan sisi melalui infrastruktur AI: Dengan kunci API awan yang dicuri dan akses shell ke hos proksi, penyerang boleh beralih ke perkhidmatan yang disambungkan, pelayan MCP dalaman, pangkalan data vektor, dan rangka kerja ejen hiliran .
• Implikasi ekosistem yang lebih luas: Kelemahan BadHost Starlette menjejaskan lebih 400,000 projek bersandar, termasuk aplikasi FastAPI, pelayan vLLM, penggunaan pelayan MCP, dan rangka kerja ejen AI. Mana-mana daripada ini yang menggunakan perisian tengah pengesahan berasaskan laluan pada versi Starlette sebelum 1.0.1 juga terdedah kepada pintasan pengesahan .

Mengapa Tindakan CISA Meningkatkan Keperluan Mendesak

Penambahan CVE-2026-42271 oleh CISA ke katalog KEV pada 8 Jun 2026 mengesahkan bahawa kerentanan ini bukan sekadar teori—penyerang sedang memperalatkannya secara aktif sekarang . Di bawah Arahan Operasi Mengikat 22-01 (BOD 22-01), semua agensi cawangan eksekutif awam persekutuan A.S. mesti menampal kerentanan yang disenaraikan dalam KEV dalam jangka masa pemulihan yang ditetapkan. CISA juga amat mengesyorkan agar semua organisasi, awam dan swasta, menganggap penambahan KEV sebagai keutamaan tampalan kecemasan .

Langkah-langkah Pemulihan Segera

Pembaikan untuk eksploitasi berantai ini memerlukan kemas kini pada dua bahagian depan, ditambah dengan beberapa langkah pertahanan mendalam untuk menangani pendedahan bukti kelayakan:

1. Naik taraf LiteLLM ke versi 1.83.7 atau lebih baru. Keluaran ini menghapuskan keupayaan titik akhir ujian MCP untuk melaksanakan arahan yang dibekalkan pengguna secara langsung, menutup vektor suntikan arahan sepenuhnya .
2. Naik taraf Starlette ke versi 1.0.1 atau lebih baru. Tampalan ini mengesahkan pengepala Host masuk terhadap spesifikasi URL dan mengabaikan pengepala yang mengandungi aksara tidak sah, mencegah helah kekeliruan laluan yang memberi kuasa kepada pintasan pengesahan .
3. Tukar setiap bukti kelayakan yang disimpan dengan serta-merta. Anggapkan bahawa sebarang kunci API, token akses, atau bukti kelayakan pangkalan data yang pernah disimpan oleh proksi LiteLLM telah dikompromi. Tukar semua kunci pembekal OpenAI, Anthropic, Azure, AWS, dan lain-lain, dan periksa papan pemuka pengebilan untuk penggunaan yang tidak sah .
4. Sekat titik akhir di proksi songsang atau WAF. Sebagai langkah pertahanan mendalam semasa tampalan dilancarkan, konfigurasikan proksi songsang atau tembok api aplikasi web anda untuk menggugurkan sebarang permintaan ke

   POST /mcp-rest/test/connection

   dan

   POST /mcp-rest/test/tools/list

   sebelum ia sampai ke aplikasi .
5. Audit untuk akses tanpa kebenaran secara retrospektif. Periksa log proksi LiteLLM untuk aktiviti luar biasa pada titik akhir ujian MCP, terutamanya permintaan dari alamat IP yang tidak dijangka atau yang mempunyai pengepala Host yang dimanipulasi .

Keterukan CVSS 10.0 gabungan, eksploitasi aktif di persekitaran sebenar, dan penunjukan KEV oleh CISA bermakna organisasi yang menjalankan perkhidmatan berkuasa LiteLLM atau Starlette harus menganggap ini sebagai acara tampal-dan-tukar kecemasan. Tetingkap antara eksploitasi aktif dan kecurian bukti kelayakan sudah pun terbuka.