Wiz: hampir 1 dari 10 gateway LiteLLM yang terekspos menerima kunci admin contoh sk-1234

Pada 9 September 2026, Wiz Research menerbitkan studi tentang LiteLLM, gateway AI sumber terbuka yang berada di antara aplikasi dan penyedia model yang mereka bayar, dan melaporkan bahwa 294 dari 3.074 deployment LiteLLM yang dapat dijangkau di internet publik — 9,6%, hampir satu dari sepuluh — menerima sk-1234, kunci master contoh yang tercetak dalam dokumentasi penyiapan proyek itu sendiri, atau tidak memerlukan kredensial sama sekali. String tersebut bukan kunci API biasa: di LiteLLM string itu adalah kredensial administrator sekaligus sakelar yang mengaktifkan autentikasi, sehingga siapa pun yang menyajikannya dapat membaca setiap kunci penyedia model yang tersimpan di gateway, mengawasi setiap prompt dan completion yang melewatinya, dan menjangkau setiap server alat yang terhubung melalui Model Context Protocol. Rekan penulis Wiz, Amitai Cohen dan Yaara Shriki, merangkai akses tersebut dengan eksekusi kode tingkat root dan pencurian kredensial IAM cloud host. Laporan ini bersandar pada laporan Wiz, advisory keamanan LiteLLM sendiri, dan daftar Known Exploited Vulnerabilities CISA yang menyusul, dan arsip insiden AI menyimpan catatan ini bersama tetangganya, masing-masing dengan sumber, tingkat keparahan, dan tingkat keyakinannya sendiri.

Tanggal publikasi adalah satu-satunya tanggal yang tercatat, dan itu memang tanggal publikasi. Pemindaian di balik judul berita itu dijalankan pada Februari 2026; dua cacat kode yang dijelaskan Wiz sudah mendapat perbaikan yang dirilis paling lambat pertengahan Mei, dalam rilis yang menurut catatan proyek sendiri bertanggal Maret dan Mei; pengenal CVE diterbitkan pada Juli; dan pencantuman di katalog muncul pada September. Hampir semua isi laporan itu sudah usang saat dicetak, dan itulah sebagian besar dari yang menjadi argumen laporan tersebut.

Angka 9,6% itu berasal dari satu pemindaian, dan Wiz mengatakan bahwa tindak lanjut Agustus miliknya sendiri tidak dapat dibandingkan dengannya.

Pengukurannya sederhana dan Wiz menyatakan metodenya secara gamblang: 3.074 proxy LiteLLM yang menghadap internet ditemukan melalui Shodan pada Februari 2026, masing-masing diuji apakah akan melakukan autentikasi dengan kunci contoh yang didokumentasikan. Dari jumlah itu, 294 melakukannya. Dalam kelompok tersebut, 191 tidak memiliki kunci master yang dikonfigurasi sama sekali dan akan menerima string apa pun yang ditawarkan kepada mereka; sisanya membiarkan placeholder dari panduan penyiapan tetap di tempatnya. Tidak ada dari kedua mode kegagalan itu yang memerlukan bug perangkat lunak. Keduanya hanya memerlukan alamat gateway dan nilai yang tercetak di README proyek itu sendiri.

Ini juga merupakan pemindaian dari satu vendor saja. Angka Wiz telah diulang oleh AI Safety Initiative dari Cloud Security Alliance pada 10 September dan oleh The Hacker News pada hari yang sama, tetapi keduanya mengutipnya dengan menyebut sumbernya, dan tidak ditemukan replikasi independen atas angka 3.074 untuk artikel ini. Wiz menjalankan pemindaian kedua pada Agustus 2026 dan menemukan lebih dari 85.000 instans, sekitar dua puluh tujuh kali jumlah pada Februari. Perusahaan mengatakan sebagian besar dari itu tampaknya adalah honeypot atau deployment uji, dan kedua jumlah tersebut tidak dapat dibandingkan. Tidak ada angka paparan saat ini, dan artikel apa pun yang mengutip angka tersebut sedang mengutip angka Februari.

Satu angka lain dalam laporan itu adalah telemetri Wiz sendiri, bukan hasil pemindaian: perusahaan menyatakan LiteLLM hadir di sekitar sepertiga lingkungan cloud yang diamatinya. Itu adalah pandangan vendor terhadap basis pelanggannya sendiri dan perlu disikapi dengan hati-hati, tetapi hal itu menjelaskan mengapa para peneliti memperlakukan kesalahan konfigurasi gateway sebagai masalah cloud, bukan masalah aplikasi.

Kunci master adalah kredensial admin sekaligus sakelar yang mengaktifkan autentikasi.

Desain LiteLLM memberi satu rahasia dua tugas. Kunci master mengautentikasi permintaan administratif, dan keberadaannya adalah yang memungkinkan autentikasi sama sekali: tanpa kunci master dan tanpa konfigurasi JWT atau OAuth2, proxy berjalan terbuka dan menerima setiap permintaan. Wiz mendekati basis kode dengan Claude Code dari Anthropic, mencari fitur yang mengambil input yang dikendalikan pengguna dan meneruskannya ke konteks eksekusi, dan penangan autentikasi adalah salah satu dari tiga permukaan yang ditandainya.

Sebelum v1.82.0-stable, konsekuensi dari tugas kedua itu lebih buruk daripada proxy terbuka. Wiz menemukan bahwa ketika tidak ada master key yang ditetapkan, handler autentikasi menetapkan peran PROXY_ADMIN ke setiap permintaan masuk, sehingga pemanggil yang tidak terautentikasi bukan hanya diizinkan masuk tetapi diizinkan sebagai administrator. Pull request #22095, yang dikutip dalam laporan, mengubah peran default menjadi INTERNAL_USER dan menambahkan pemeriksaan admin ke endpoint guardrail.

Akses administratif ke gateway bukanlah hak istimewa yang sempit. Instans ini menyimpan kunci API untuk setiap penyedia yang dirutekannya, yang menjadikannya target LLMjacking — menjalankan beban kerja model dengan tagihan korban. Instans ini melihat prompt dan completion. Instans ini terhubung ke luar ke server alat MCP, yang dalam deployment internal kemungkinan mencakup issue tracker, chat, database, dan pipeline deployment.

Wiz juga mendemonstrasikan jalur dari kursi administratif tersebut ke identitas cloud host. LiteLLM memungkinkan administrator mendaftarkan rute pass-through ke URL target mana pun, dan target tersebut tidak diperiksa terhadap rentang alamat privat, localhost, atau alamat metadata cloud. Mengarahkan rute ke layanan metadata instans akan mengembalikan kredensial IAM yang digunakan oleh workload tersebut. Mengalihkan layanan metadata ke IMDSv2, yang biasanya menggagalkan kelas pemalsuan permintaan ini dengan menuntut token sesi yang diperoleh secara terpisah, tidak membantu: LiteLLM meneruskan header apa pun yang berawalan x-pass- ke target dengan prefiks tersebut dihilangkan, sehingga header token dapat diselundupkan. Wiz mengatakan fitur ini boleh dibilang bekerja sebagaimana mestinya dalam model ancaman yang memercayai administrator, dan oleh karena itu tidak memiliki CVE maupun perbaikan.

Paragraf terakhir itu adalah demonstrasi, bukan serangan yang teramati. Hacker News, yang melaporkan penelitian tersebut pada 10 September, menyatakan bahwa tidak ada sumber yang melaporkan siapa pun melakukannya terhadap deployment nyata, dan bahwa itu memerlukan akses admin terlebih dahulu. Framing Wiz sama: pass-through adalah properti desain yang menjadi kerentanan hanya ketika kredensial administrator adalah string dari dokumentasi.

8.8 dan 2.1 menilai rantai yang sama dari titik awal yang berbeda

Dua CVE memuat temuan teknis, dan skor yang dipublikasikan keduanya hampir tidak mungkin lebih jauh berbeda.

CVE-2026-59822 adalah bypass autentikasi MCP, dan advisory LiteLLM menilainya High, 8.8 berdasarkan CVSS 4.0, tanpa memerlukan hak istimewa, tanpa interaksi pengguna, dan tanpa persyaratan serangan. Endpoint MCP memiliki handler autentikasi tersendiri, yang dibuat untuk menerima kunci LiteLLM atau token OAuth2 yang ditujukan ke server alat upstream. Ketika sebuah token gagal dalam validasi LiteLLM, handler tersebut menangkap 401 dan menggantinya dengan objek autentikasi kosong alih-alih menolak permintaan. Dengan demikian, token Bearer apa pun menghasilkan sesi MCP yang valid, termasuk satu karakter: proof of concept dari Wiz mengirim token bearer satu huruf dan menerima kembali pengenal sesi. Cacat ini diperbaiki pada versi 1.84.0.

CVE-2026-59821 adalah cacat guardrail, dan advisory proyek yang sama menilainya Low, 2.1, dengan hak istimewa tinggi diperlukan dan persyaratan serangan tersedia. Fitur guardrail kode kustom memungkinkan administrator mengirimkan Python yang dikompilasi dan dieksekusi oleh server. Endpoint uji Web UI memvalidasi kode terhadap daftar pola terlarang dan menghapus builtins sebelum menjalankannya; endpoint pembuatan dan pembaruan produksi tidak melakukan keduanya. Python mengisi ulang builtins saat tidak ada, sehingga kode yang dikirim menjangkau pustaka standar. Proof of concept Wiz mendaftarkan guardrail yang menjalankan perintah shell pada waktu pendaftaran — sebelum permintaan model apa pun — dan mengembalikan output perintah sebagai alasan pemblokiran, yang dalam pengujiannya kembali sebagai root. Cacat ini diperbaiki di v1.82.0-stable.

Kedua deskripsi tersebut kompatibel, dan kalimat yang merukunkan keduanya ada di dalam advisory itu sendiri: LiteLLM mencatat bahwa dalam penerapan tanpa master key yang dikonfigurasi, pemanggil dapat diperlakukan sebagai administrator proxy, dan itulah yang membuat endpoint guardrail dapat dijangkau. A 2.1 mengasumsikan pengguna yang memiliki hak istimewa. Rantai Wiz adalah yang terjadi ketika key default membuat setiap pemanggil memiliki hak istimewa. Tidak ada skor yang salah mengenai posisi awalnya masing-masing; keduanya berbeda pendapat tentang seberapa sering posisi itu tersedia.

Satu catatan penting melekat pada klaim Wiz bahwa setelah 1.82.0 penyerang yang memegang kunci default hanya dapat mengeksekusi kode di dalam sandbox. The Hacker News mengacu pada advisory terpisah Mei 2026, CVE-2026-40217, yang menjelaskan cara keluar dari sandbox tersebut melalui teknik bytecode pada versi 1.81.8 hingga sebelum 1.83.10, di dalam proses proxy yang menurut advisory berjalan sebagai root pada image container default. Untuk mencapai endpoint tersebut diperlukan kredensial administrator proxy, yang justru merupakan master key.

Angka 8.8 juga tidak universal. Catatan riset Cloud Security Alliance mengamati bahwa advisory GitLab mencantumkan skor dasar 8.2 untuk cacat yang sama dan menolak memutuskan antara kedua metodologi tersebut, hanya mencatat bahwa keduanya berada dalam rentang tinggi. Tingkat keparahan high pada catatan tersebut tidak bergantung pada angka mana yang digunakan.

Satu CVE dieksploitasi di alam liar; paparan kunci default tidak memiliki korban yang disebutkan namanya

CISA menambahkan CVE-2026-59822 ke katalog Known Exploited Vulnerabilities pada 2 September 2026 dan menetapkan tenggat perbaikan 16 September 2026 bagi agensi sipil federal; entri katalog tersebut mencantumkan CWE-287 dan CWE-306, yaitu autentikasi tidak tepat dan tidak adanya autentikasi. Catatan Cloud Security Alliance melaporkan bahwa pelacak industri menyebutnya sebagai kerentanan khusus MCP pertama dalam daftar tersebut. Wiz telah menerbitkan eksploitasi yang diamatinya: sejak 7 Juli 2026 honeypot-nya mencatat permintaan yang membawa token bearer satu karakter dan melakukan probing terhadap endpoint daftar model, dan Wiz tidak menyebutkan penggunaan lain dari kerentanan tersebut.

Tidak ada hal yang sebanding untuk kunci default. Tidak ada korban yang disebutkan namanya, tidak ada gateway yang diidentifikasi telah diambil alih melalui sk-1234, dan tidak ada telemetri yang menunjukkan 294 host sedang digunakan. Entri arsip tidak mencatat kerugian nyata, yang merupakan pernyataan tentang bukti dan bukan tentang mekanismenya: eksposurnya diukur, bukan disaksikan sedang digunakan.

Dua item lain sering dicatat bersama hal-hal ini dan bukan hal yang sama. CVE-2026-42271, eksekusi perintah melalui dua endpoint uji MCP, adalah celah LiteLLM yang benar-benar digunakan penyerang untuk menjalankan kode; honeypot Wiz mencatatnya memasang penambang kripto. Kasus Agustus 2026 yang diterbitkan Microsoft, di mana penyusup membaca variabel lingkungan kontainer gateway, memulihkan kunci master, kunci penyedia, dan string koneksi basis data, lalu menyalin catatan dari tabel model dan kunci virtual LiteLLM, menggambarkan nilai gateway yang telah dikompromikan ketimbang cara masuk baru; The Hacker News melaporkan bahwa Microsoft menilai titik masuknya sebagai rantai CVE-2026-42271.

Pandangan para pengelola adalah bahwa tidak adanya kunci master merupakan kesalahan penyiapan, bukan kerentanan.

Kebijakan keamanan LiteLLM bersifat eksplisit. Kebijakan tersebut mencantumkan di antara masalah di luar cakupan "serangan yang memerlukan kesalahan konfigurasi saat penyiapan (misalnya tidak menetapkan master_key pada konfigurasi proxy)", dan menyatakan bahwa hal-hal tersebut secara eksplisit tidak termasuk cakupan dan tidak dianggap rentan. Wiz mencapai kesimpulan yang sejalan dari arah sebaliknya ketika menyebut perilaku pass-through tersebut bisa dibilang berjalan sebagaimana mestinya.

Posisi itu telah diuji di publik. Pada 15 Agustus 2026, seorang peneliti mengajukan issue GitHub #37054, yang melaporkan bahwa proxy dengan LITELLM_MASTER_KEY yang tidak diatur mengautentikasi nilai kunci apa pun dan bahwa file docker-compose yang disertakan tidak mengaturnya. Issue tersebut ditutup 30 menit kemudian, dan satu-satunya komentar pada issue itu berasal dari akun yang sama: komentar itu mengutip instruksi kebijakan keamanan bahwa laporan harus melalui laporan kerentanan privat alih-alih issue publik, meminta maaf karena telah mengajukan secara publik, dan mengatakan bahwa laporan lengkap sedang diajukan melalui jalur advisory sebagai gantinya. Tidak ada balasan maintainer yang muncul di thread, sehingga catatan menunjukkan bahwa pelapor menarik laporan publik tersebut alih-alih adanya respons proyek terhadapnya. Tidak ada catatan publik tentang apa yang terjadi dengan pengajuan privat tersebut.

Tidak ditemukan pernyataan publik dari BerriAI yang membela atau merevisi posisi tersebut mengenai laporan September untuk artikel ini. Respons perusahaan yang terlihat ada di catatan rilis dan file konfigurasinya, bukan dalam bentuk prosa.

Penegakan itu tiba pada 3 Oktober, dua puluh empat hari setelah laporan.

Dua cacat kode tersebut telah diperbaiki jauh sebelum laporan itu. Linimasa pengungkapan Wiz mencatat eksekusi kode guardrail yang dilaporkan pada 18 Februari 2026 dan diperbaiki pada 25 Februari dalam v1.82.0, bypass MCP yang diperbaiki pada 25 April dalam v1.84.0, eksploitasi yang teramati pada 7 Juli, pengenal CVE yang diterbitkan pada 8 Juli, dan pencantuman dalam katalog pada 2 September. Artefak rilis memuat tanggal yang lebih akhir daripada tanggal perbaikannya: indeks paket menunjukkan v1.82.0 pada 1 Maret 2026 dan v1.84.0 pada 14 Mei, yang menandai kapan masing-masing perbaikan menjadi dapat dipasang, bukan kapan perbaikan itu mendarat. Dua catatan rilis pihak pertama mencantumkan tanggal perbaikan yang sama lebih akhir daripada linimasa tersebut. Rilis v1.82.0-stable di GitHub bertanggal 11 Maret 2026 dan paket 1.82.0 di PyPI 1 Maret; v1.84.0 bertanggal 14 Mei 2026 pada keduanya. Tidak ada yang diterbitkan yang menjelaskan selisih tersebut, dan itu tidak penting bagi argumen, karena setiap tanggal tersebut jatuh berbulan-bulan sebelum laporan September. Dua advisory GitHub menambahkan tanggal ketiga: keduanya diterbitkan pada 30 Juni 2026, tiga minggu sebelum pengenal CVE yang menurut Wiz keluar pada 8 Juli.

Apa yang tidak diperbaiki oleh rilis-rilis tersebut adalah nilai default. Wiz melaporkan bahwa per 9 September master key masih disetel ke sk-1234 saat memasang LiteLLM melalui Docker Compose atau pip install, dan The Hacker News mengonfirmasi bahwa panduan penyiapan masih menggunakan nilai tersebut pada hari itu. Perubahan datang dengan v1.104.0, yang diunggah ke Python Package Index pada 3 Oktober 2026, yang catatan rilisnya mencantumkannya sebagai breaking change: proxy kini menolak untuk mulai dengan master key yang tidak disetel, kosong, atau diketahui publik, menyebutkan sumber nilai buruk dalam error saat startup dan mencetak perintah yang menghasilkan nilai aman. Entri pendamping mencatat perubahan untuk berhenti mengiklankan nilai master key lemah yang diketahui publik dalam konfigurasi dan contoh yang disertakan, dan file docker-compose pada cabang utama proyek tidak lagi menyetel kunci sama sekali.

Itulah urutan yang layak dipertahankan. Kode tersebut ditambal pada musim semi. Nilai yang membuat tambalan-tambalan itu tidak memadai tetap tercantum dalam petunjuk instalasi hingga Oktober, dan baru saat itulah perangkat lunak mulai menolaknya. Tidak ada bagian dari salah satu perbaikan yang mengharuskan perbaikan lainnya menunggu.

Yang tidak berubah adalah rute pass-through ke layanan metadata instans. Rute ini masih belum memiliki CVE dan belum ada perbaikannya, karena proyek tersebut menganggap administrator sebagai pihak tepercaya. Oleh karena itu, daftar remediasi Wiz sebagian besar merupakan pekerjaan operator: kunci master yang kuat dan unik, peninjauan guardrail terdaftar yang diikuti dengan memulai ulang proses untuk menghapus kode yang tersimpan di memori, audit endpoint pass-through dengan egress kontainer yang dibatasi, dan peran IAM dengan hak istimewa minimum. Tidak satu pun dari keempatnya diperoleh hanya dengan melakukan peningkatan versi.

Apa yang tidak ditetapkan oleh catatan tersebut

• Tidak ditemukan replikasi independen atas pemindaian 3.074 host. Angka 9,6% merupakan pengukuran Wiz, dan setiap uraian lain tentangnya mengulang angka tersebut dengan menyebut sumbernya.

Tidak ada angka eksposur saat ini. Tindak lanjut pada Agustus menemukan lebih dari 85.000 instans, yang menurut Wiz sebagian besar merupakan honeypot atau deployment uji dan tidak dapat dibandingkan dengan hitungan Februari.

Tidak ada korban. Tidak ada satu pun dalam catatan yang menyebut gateway, operator, atau akun cloud yang dikompromikan melalui kunci default, dan eksploitasi yang didokumentasikan Wiz adalah terhadap bypass MCP, bukan terhadap sk-1234.

• Tidak ada bukti bahwa 294 host tersebut digunakan. Pemindaian ini menguji apakah host-host itu akan melakukan autentikasi, yang merupakan klaim lebih lemah daripada menunjukkan bahwa ada pihak yang benar-benar melakukannya.

• Belum ada tingkat keparahan yang disepakati untuk cacat guardrail. Wiz dan para pengelola menggambarkan perilaku yang sama namun menilainya dengan sangat berbeda, dan perbedaannya terletak pada hak istimewa yang masing-masing asumsikan sudah dimiliki penyerang.

Wiz juga merupakan vendor keamanan cloud yang menjual deteksi untuk kelas eksposur ini, dan laporan ditutup dengan bagian tentang bagaimana produknya sendiri mengidentifikasi deployment LiteLLM, versi yang rentan, dan instans shadow. Itu adalah konteks untuk membaca bagian remediasi, bukan alasan untuk meremehkan pengukuran yang detail teknisnya dikuatkan oleh advisory dari pihak maintainer sendiri.

Bagian dari catatan yang melampaui LiteLLM adalah rentang waktu antara dua tanggal. Kerentanan itu ditutup pada musim semi. Pengaturan default yang membuat kerentanan itu penting bagi orang luar masih dicetak dalam petunjuk instalasi pada bulan September, dan perangkat lunak baru mulai menolaknya pada bulan Oktober. Operator yang mengubah string itu tidak pernah harus menunggu semua itu.