--- title: "LiteLLM 1.107.0 Disusupi Pencuri Kredensial, Cek Server AI" description: "Paket LiteLLM 1.107.0 di PyPI dan Docker sempat berisi malware pencuri kredensial pada 21 Oktober 2026. Ini cara mengecek server dan langkah pemulihannya." url: "https://nivelva.com/insight/litellm-1-107-0-pencuri-kredensial" category: "Keamanan/Cyber Security" tags: ["litellm","supply chain attack","pypi","kunci api","keamanan ai"] author: "Lucas Tan" published: "2026-11-12T15:33:00+07:00" updated: "2026-11-12T15:33:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # LiteLLM 1.107.0 Disusupi Pencuri Kredensial, Cek Server AI > **Jawaban singkat:** Pada 21 Oktober 2026, LiteLLM 1.107.0 di PyPI, Docker Hub, dan GHCR disusupi malware yang mencuri kunci API AI, kredensial cloud, dan rahasia lain. Bila server kamu memasangnya, anggap sudah disusupi, bangun ulang dari versi 1.106.2, dan rotasi semua kunci. Apakah server AI kamu memasang atau menarik LiteLLM pada 21 Oktober 2026? Kalau ya, segera periksa versinya. LiteLLM 1.107.0 yang terbit hari itu di PyPI, Docker Hub, dan GitHub Container Registry (GHCR) ternyata berisi malware pencuri kredensial. Versi bersih terakhir adalah 1.106.2. LiteLLM banyak dipakai sebagai proxy atau router yang menyimpan kunci API berbagai penyedia model AI sekaligus. Itulah yang membuat insiden ini berbahaya: satu server yang terinfeksi bisa membocorkan kunci OpenAI, Anthropic, Google, kredensial cloud, sampai kata sandi database proxy dalam sekali jalan. ## Apa yang terjadi pada LiteLLM 1.107.0? Menurut laporan insiden resmi LiteLLM, penyerang memegang kredensial GitHub CLI milik tiga developer, salah satunya pemilik organisasi GitHub. Tim LiteLLM menduga token itu diambil dari log deployment internal mereka yang terbuka ke internet. Dengan akses tersebut, penyerang mematikan proteksi branch, memaksa perubahan masuk, dan mengarahkan workflow rilis ke repositori tiruan bernama `Berri-AI/litellm` (bukan `BerriAI/litellm`). Kode aplikasi LiteLLM sendiri tidak diubah. Yang disusupi adalah paket instalasinya. Laporan resmi menyebut tag sumber `v1.107.0` di GitHub tidak berisi file berbahaya, dan pelanggan enterprise yang menarik dari registry privat tidak terdampak. Rentang waktu artefak berbahaya pada 21 Oktober 2026 (UTC), menurut laporan resmi LiteLLM: | Artefak | Tag atau versi | Waktu aktif (UTC) | |:--|:--|:--| | PyPI | `litellm==1.107.0`, ketujuh wheel | 11.39 sampai 13.23 | | Docker Hub | `v1.107.0`, `latest`, `main-latest`, `main-stable` | 11.46 sampai 14.20 | | GHCR | tag yang sama, termasuk image `litellm-database` dan `litellm-non_root` | 11.46 sampai sekitar 13.51 | Di waktu Indonesia bagian barat (UTC+7), rentang itu kira-kira pukul 18.39 sampai 21.20 WIB. Endor Labs juga mencatat source distribution (sdist) 1.107.0 dibangun dari revisi berbahaya. ## Bagaimana malware ini bekerja? Paket berbahaya menambahkan tiga file ke folder site-packages Python: `cook.pth`, `cook.py`, dan `sitecustomize.py`. Python otomatis menjalankan baris import di file `.pth` dan memuat `sitecustomize` setiap kali interpreter dijalankan. Akibatnya, malware aktif setiap ada proses Python di lingkungan itu, bahkan bila LiteLLM tidak pernah di-import. Menurut analisis Endor Labs dan BleepingComputer, yang dikumpulkan antara lain: - Kredensial cloud (AWS, Azure, GCP), konfigurasi Docker dan Kubernetes, serta metadata instance. - Kunci SSH, GPG, dan TLS, token Git, npm, PyPI, file `.env`, dan konfigurasi CI. - File kredensial alat AI dan semua variabel lingkungan yang tidak kosong. - Data browser seperti kata sandi tersimpan dan cookie. - Bila `DATABASE_URL` diatur, isi tabel kredensial dan model di database proxy LiteLLM, artinya semua kunci penyedia AI yang dikelola proxy. Data dienkripsi lalu dikirim ke domain tiruan `litellm[.]dev`. Selain itu, `sitecustomize.py` menyalakan proses loader terpisah yang setiap jam mengambil kode baru dari server penyerang dan menjalankannya tanpa pemeriksaan. Jadi selain mencuri data, host yang terinfeksi bisa menerima perintah lanjutan. > **Jangan langsung menjalankan pip:** > > Laporan resmi LiteLLM memperingatkan bahwa menjalankan Python atau `pip` di lingkungan yang terinfeksi akan memicu malware lagi. Periksa dulu memakai perintah non-Python seperti `find`, `ls`, dan `docker`, atau dari lingkungan yang bersih. ## Langkah mengecek dan memulihkan server Langkah ini merangkum saran laporan resmi LiteLLM dan Endor Labs. Jalankan di setiap server, container, dan runner CI yang mungkin memasang LiteLLM pada 21 Oktober 2026. ### 1. Cari jejak versi 1.107.0 tanpa menjalankan Python ```bash sudo find / -type d -name 'litellm-1.107.0.dist-info' 2>/dev/null sudo find / -path '*site-packages*' \( -name 'cook.pth' -o -name 'cook.py' \) 2>/dev/null ls -la /tmp/remote_code_loader.lock /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null ``` Periksa juga `sitecustomize.py` di folder site-packages lingkungan virtual yang memakai LiteLLM. File dengan nama itu bisa saja sah di sistem tertentu, jadi lihat isinya, jangan langsung dihapus tanpa dicek. Laporan resmi menegaskan: tidak menemukan apa-apa belum membuktikan lingkungan itu bersih. ### 2. Cek image Docker dan file dependensi ```bash docker images --digests | grep -i litellm grep -rn "1.107.0" requirements*.txt poetry.lock uv.lock 2>/dev/null ``` Digest image index yang disusupi adalah `sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e`. Bila kamu memakai tag `latest` atau `main-stable` dan menarik image di rentang waktu tadi, anggap terdampak. Cek juga log CI dari 21 Oktober. ### 3. Hentikan proses loader dan isolasi host Matikan deployment yang terdampak. Cari proses yang memegang file kunci loader: ```bash sudo lsof /tmp/remote_code_loader.lock ``` Hentikan proses tersebut dengan `kill`, lalu putus akses keluar host bila memungkinkan. Bila tim keamananmu butuh bukti, simpan salinan disk atau log sebelum menghapus apa pun. ### 4. Bangun ulang dari versi bersih Hapus `cook.pth`, `cook.py`, `sitecustomize.py`, dan file `__pycache__` terkait bila ingin membersihkan cepat. Menghapus folder paket litellm saja tidak cukup. Cara yang dianjurkan adalah membangun ulang virtual environment atau image dari nol dengan versi yang dikunci: ```bash pip install litellm==1.106.2 ``` Untuk Docker, kunci image dengan digest, bukan dengan tag `latest`. Blokir juga `litellm==1.107.0` di proxy paket internal bila ada. Panduan memasang LiteLLM dari awal ada di [cara pasang LiteLLM sebagai router banyak model AI](https://nivelva.com/insight/cara-pasang-litellm-sebagai-router-banyak-model-ai). ### 5. Rotasi semua kredensial yang bisa dijangkau host Bila 1.107.0 sempat berjalan di host yang punya akses internet keluar, anggap datanya sudah terkirim. Laporan resmi meminta kamu merotasi: - Semua kunci penyedia AI yang tersimpan di database proxy LiteLLM, termasuk master key dan virtual key. - Kata sandi di `DATABASE_URL`. - Peran IAM instance atau task, serta kredensial cloud lain di host itu. - Rahasia apa pun di variabel lingkungan proses mana pun di host tersebut, termasuk token SSH, Git, dan CI. Di AWS, periksa CloudTrail untuk panggilan `GetCallerIdentity` dari peran instance sekitar waktu instalasi dan pemakaian kredensial dari luar infrastrukturmu. Pantau juga dasbor tagihan penyedia AI untuk lonjakan pemakaian yang tidak wajar. ## Pelajaran dari insiden ini Kasus ini contoh nyata [serangan rantai pasok](https://nivelva.com/insight/apa-itu-supply-chain-attack-contoh-kasusnya): penyerang tidak membobol servermu, tetapi menitipkan malware di paket yang kamu percaya. Beberapa kebiasaan yang mengurangi risikonya: kunci versi dependensi, jangan memakai tag `latest` di produksi, beri jeda sebelum mengambil rilis baru, dan jangan menyimpan kunci API lebih banyak dari yang dibutuhkan di satu host. Laporan LiteLLM juga mengingatkan bahwa log yang mencatat isi respons bisa ikut menyimpan token rahasia, sehingga log pun perlu dijaga. ## Checklist singkat - Cari `litellm-1.107.0.dist-info`, `cook.pth`, dan file penanda di `/tmp`. - Cocokkan digest image Docker dan file lock dependensi. - Hentikan loader, isolasi host, simpan bukti bila perlu. - Bangun ulang dengan `litellm==1.106.2` atau image yang dikunci digest. - Rotasi semua kunci AI, kredensial cloud, dan kata sandi database proxy. ## Pertanyaan yang sering diajukan ### Saya memakai LiteLLM versi lain, apakah terdampak? Menurut laporan resmi LiteLLM, pengguna versi lain tidak terdampak selama tidak menarik artefak 1.107.0 atau tag Docker yang terdampak pada rentang waktu 21 Oktober 2026. Pengguna tag latest atau main-stable yang menarik image di rentang itu perlu memeriksa. ### Apakah cukup memperbarui ke versi yang lebih baru? Tidak. File berbahaya bisa tertinggal di site-packages dan loader bisa tetap berjalan. Bangun ulang lingkungan dari nol dan rotasi semua kredensial, karena data mungkin sudah terkirim. ### Apakah tanda tangan image bisa dipakai untuk memastikan image aman? Tidak untuk kasus ini. Laporan resmi menyebut image v1.107.0 yang disusupi juga membawa tanda tangan sah dari kunci lama, sehingga tanda tangan saja tidak membuktikan image bersih. Cocokkan digest. ### Apakah ini punya nomor CVE? Sumber yang dirujuk artikel ini tidak mencantumkan nomor CVE untuk insiden ini. Rujukan utamanya adalah laporan insiden resmi di dokumentasi LiteLLM. ## Sumber - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/litellm-1-107-0-pencuri-kredensial Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com