Kecerdasan Buatan
LiteLLM Disusupi Malware Pencuri Data, Ini Cara Cek dan Amankan Server
Rilis LiteLLM 1.107.0 di PyPI dan Docker sempat disusupi malware pencuri kredensial pada 21 Oktober 2026. Ini versi yang kena, data yang diincar, cara cek, dan
LiteLLM, library Python yang banyak dipakai untuk menghubungkan aplikasi ke berbagai model AI, kembali kebobolan. Pada 21 Oktober 2026, versi 1.107.0 yang terbit di PyPI dan Docker ternyata berisi malware pencuri kredensial sekaligus pintu belakang untuk menjalankan kode dari jarak jauh. Versi itu memang hanya beredar sekitar dua jam, tapi dampaknya bisa besar karena LiteLLM diunduh sekitar 23 juta kali per minggu.
Artikel ini akan menjelaskan versi mana saja yang terdampak, data apa yang diincar malware tersebut, bagaimana cara mengecek apakah server atau laptop ikut kena, dan langkah apa yang perlu diambil supaya aman. Ada juga catatan khusus buat tim dan developer di Indonesia yang memakai LiteLLM sebagai proxy AI di aplikasi mereka.
Kronologi singkat kebobolan LiteLLM 1.107.0
Menurut laporan resmi tim LiteLLM, pipeline rilis mereka dibobol pada dini hari 21 Oktober waktu Amerika. Penyerang lalu mendorong versi palsu 1.107.0 ke PyPI dan registry Docker. Dalam waktu WIB, urutannya kira-kira seperti ini:
- 18.39 WIB (21 Okt): paket
litellm==1.107.0muncul di PyPI, lengkap dengan tujuh file wheel untuk macOS, Linux, dan Windows. - 18.46 WIB: image Docker dengan tag
v1.107.0,latest,main-latest, danmain-stabledi Docker Hub dan GHCR ikut diarahkan ke image berbahaya. - 20.23 WIB: paket di PyPI ditarik setelah dikarantina.
- 20.51 WIB: tag di GHCR sudah tidak bisa diakses.
- 21.20 WIB: tag di Docker Hub dibersihkan dan diarahkan kembali ke sumber yang aman.
Tim LiteLLM menyatakan insiden ini sudah ditangani (contained), tapi investigasi masih berjalan. Mereka juga menegaskan bahwa semua versi sebelumnya aman, dan pelanggan Enterprise yang memakai rilis privat tidak terdampak.
Catatan: Ini adalah kebobolan kedua LiteLLM di 2026. Pada Maret lalu, versi 1.82.7 dan 1.82.8 juga disusupi dengan trik yang mirip. Datadog Security Labs menyebut belum ada bukti kaitan langsung antara dua insiden tersebut.
Yang membuat kasus ini lebih licik, kode sumber resmi di tag GitHub v1.107.0 justru bersih. File berbahaya baru masuk saat proses build, karena artefak yang terbit dibangun dari repositori yang dikendalikan penyerang.
Versi yang kena dan versi yang aman
Supaya tidak bingung, berikut daftar singkatnya berdasarkan rilis resmi LiteLLM, OSV, dan peneliti keamanan:

Terdampak:
- PyPI:
litellm==1.107.0, semua tujuh wheel. - Docker Hub dan GHCR: tag
v1.107.0,latest,main-latest, danmain-stable, selama jendela waktu di atas. - Image turunan seperti
ghcr.io/berriai/litellm-databasedanghcr.io/berriai/litellm-non_rootjuga ikut tercatat dalam laporan resmi.
Aman:
litellm==1.106.2, yang disebut sebagai versi aman terbaru.- Versi kandidat
1.107.0rc1dan1.107.0rc2. - Rilis privat untuk pelanggan Enterprise.
Hal penting yang sering terlewat ada di tag Docker yang bisa berubah seperti latest. Kalau server menarik image latest di jam-jam tersebut, server itu perlu dianggap ikut terpapar, walaupun tim tidak pernah mengetik angka 1.107.0 secara sengaja.
Cara kerja malware di LiteLLM palsu
Peneliti JFrog dan OSV menemukan tiga file tambahan di setiap wheel: cook.pth, cook.py, dan sitecustomize.py. Ketiganya dipasang langsung di folder site-packages, bukan di dalam folder LiteLLM.
Akibatnya cukup serius. Malware ini berjalan setiap kali Python dinyalakan, bahkan kalau aplikasi sama sekali tidak memanggil import litellm. Pembagian tugasnya seperti ini:
cook.pthhanya berisi perintahimport cook, sehingga otomatis dieksekusi saat Python start.cook.pyadalah pencuri data yang menamai dirinya "privcollect". Data hasil curian dienkripsi dengan kunci RSA-4096, lalu dikirim ke alamat yang meniru domain LiteLLM.sitecustomize.pyberjalan di latar belakang dan setiap jam mengambil daftar domain dari sebuah repo GitHub, lalu mengunduh dan menjalankan kode dari sana. Fungsinya mirip remote shell.
JFrog juga mencatat bahwa source tarball (sdist) tidak berisi tiga file itu, hanya ada tambahan pengaturan data = "cook" di pyproject.toml. Artinya, orang yang hanya memeriksa kode sumber atau tag Git bisa tidak sadar bahwa wheel yang terpasang sudah berbeda.
Data apa saja yang diincar
Daftar target malware ini panjang, dan sebagian besar justru data yang paling sensitif di mesin developer maupun server produksi.

Berdasarkan analisis OSV dan JFrog, yang dikumpulkan antara lain:
- Password dan riwayat browser.
- Kunci SSH, riwayat shell, dan variabel lingkungan (environment variables).
- Kredensial cloud AWS, Google Cloud, dan Azure, termasuk metadata instance cloud.
- Rahasia Kubernetes, Docker, Vault, dan CI/CD.
- Konfigurasi alat AI developer seperti folder
~/.cursor,~/.claude,~/.kiro, dan Windsurf. - Kunci privat GPG dan TLS.
- File
.npmrc,.pypirc, dan.git-credentials. - Kredensial proxy LiteLLM itu sendiri, termasuk API key ke penyedia model AI.
Poin terakhir ini yang paling bikin pusing. Banyak tim memakai LiteLLM sebagai gerbang ke OpenAI, Anthropic, Google, atau DeepSeek, jadi satu server yang kena bisa membocorkan semua API key model AI sekaligus. Tagihan API yang tiba-tiba membengkak adalah salah satu tanda yang patut dicurigai.
Cara cek apakah server atau laptop ikut kena
Langkah pertama adalah memastikan versi yang terpasang. Tapi ada satu peringatan penting dari tim LiteLLM: jangan langsung menjalankan pip install di lingkungan yang dicurigai, karena setiap kali Python menyala, termasuk saat menjalankan pip, malware ikut berjalan lagi.
Gunakan perintah shell biasa yang tidak memanggil Python. Contohnya:
# Cari file berbahaya di semua folder site-packages
find / -path "*site-packages*" \( -name "cook.pth" -o -name "cook.py" \) 2>/dev/null
find / -name "sitecustomize.py" -path "*site-packages*" 2>/dev/null
# Cek file penanda yang ditinggalkan malware
ls -la /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null
# Cek versi lewat folder metadata, tanpa menjalankan Python
ls -d /path/ke/venv/lib/python3*/site-packages/litellm-*.dist-info
Untuk Docker, cek riwayat image dan digest yang dipakai server:
Baca juga OpenAI Bikin Aturan Baru, Router dan Gateway AI Wajib Minta Izin Mulai 20 November
- Jalankan
docker images --digests | grep litellmuntuk melihat digest image yang tersimpan. - Bandingkan dengan digest berbahaya yang diumumkan LiteLLM, misalnya yang diawali
sha256:1bbcb1443bc9. - Periksa log deploy atau CI: apakah ada pull image
latest,main-latest, ataumain-stableantara pukul 18.46 dan 21.20 WIB pada 21 Oktober?
Tips: Jangan lupa cek pipeline CI/CD dan laptop developer. Malware ini menargetkan rahasia CI dan konfigurasi editor AI, jadi mesin yang hanya dipakai untuk testing pun tetap berisiko.
Langkah amankan kalau ternyata terpapar
Kalau hasil pengecekan menunjukkan versi 1.107.0 pernah terpasang, anggap mesin itu sudah dibobol. Panduan dari LiteLLM, Datadog, dan JFrog kurang lebih sejalan:

- Isolasi mesin dari jaringan supaya pintu belakang tidak bisa menerima perintah baru.
- Hapus
cook.pth,cook.py,sitecustomize.py, beserta file.pycyang terkait, langsung dari shell. - Matikan proses loader yang berjalan di latar belakang.
- Bangun ulang dari image yang bersih, lalu kunci versi ke
litellm==1.106.2. - Ganti (rotate) semua kredensial yang bisa diakses dari mesin itu, dan lakukan dari mesin lain yang bersih. Ini termasuk API key AI, akses cloud, token GitHub, password database, dan master key proxy LiteLLM.
- Audit log penggunaan kredensial selama jendela paparan, misalnya login cloud yang aneh atau lonjakan pemakaian API.
Urutannya penting. Mengganti kredensial dari mesin yang masih terinfeksi hanya akan membuat kredensial baru ikut dicuri lagi.
Catatan buat developer dan startup di Indonesia
LiteLLM cukup populer di kalangan developer Indonesia, terutama tim yang membangun chatbot, agen AI, atau layanan internal yang perlu berpindah-pindah antara beberapa penyedia model. Banyak juga yang memasangnya lewat Docker di VPS lokal karena praktis.
Beberapa hal yang relevan untuk kondisi di sini:
- Waktu kejadian jatuh di malam hari WIB. Jendela 18.39 sampai 21.20 WIB adalah jam yang sering dipakai untuk deploy setelah jam kantor, jadi tim di Indonesia justru perlu lebih teliti mengecek log.
- Banyak VPS memakai tag
latest. Kebiasaan ini praktis, tapi kasus ini menunjukkan risikonya. Sebaiknya kunci versi dan digest image. - Tagihan API dalam dolar. Kalau API key bocor, tagihan bisa membengkak dalam hitungan jam. Pasang batas pemakaian (usage limit) di dashboard penyedia model.
- Tim kecil sering berbagi satu key. Startup atau UMKM yang memakai satu API key untuk semua layanan sebaiknya mulai memisahkan key per aplikasi, supaya kalau satu bocor, dampaknya tidak menyebar.
Cara mencegah kejadian serupa ke depan
Kasus supply chain seperti ini tidak bisa dicegah 100 persen dari sisi pengguna, tapi risikonya bisa dikurangi cukup jauh dengan kebiasaan sederhana:
- Kunci versi (pinning) di
requirements.txtataupyproject.toml, lengkap dengan hash bila memungkinkan, misalnya lewatpip install --require-hashes. - Jangan langsung naik ke versi terbaru di hari rilis. Memberi jeda satu sampai dua hari sering cukup untuk menghindari paket berbahaya yang biasanya cepat ketahuan.
- Pakai digest, bukan tag, untuk image Docker di produksi.
- Simpan rahasia di secret manager, bukan di file
.envyang bisa dibaca semua proses. - Pasang pemindai dependensi seperti OSV-Scanner atau fitur keamanan bawaan GitHub supaya peringatan paket berbahaya cepat masuk.
Komunitas masih memantau perkembangan insiden ini lewat issue #47826 di repositori LiteLLM, dan tim LiteLLM berjanji memperbarui laporan penyebabnya begitu investigasi selesai.
Poin penting
- LiteLLM 1.107.0 di PyPI dan Docker sempat berisi malware pada 21 Oktober 2026.
- Malware berjalan setiap Python dinyalakan, tanpa perlu
import litellm. - Targetnya kredensial cloud, API key AI, kunci SSH, rahasia CI, dan password browser.
- Versi aman terbaru adalah 1.106.2.
- Kalau terpapar: isolasi, hapus file, bangun ulang, lalu ganti semua kredensial dari mesin bersih.
Referensi
- LiteLLM (2026). Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised
- Datadog Security Labs (2026). LiteLLM supply chain compromise: What you need to know
- JFrog Security Research (2026). LiteLLM Hijacked Again: Malicious 1.107.0 Wheels Steal Credentials and Load Remote Code
- OSV (2026). MAL-2026-2144: Malicious code in litellm (PyPI)
- Wiz (2026). LiteLLM Compromised, Steals Credentials
- DeAI (2026). DeAI Daily Brief, 22 October 2026
Pertanyaan Umum
Versi LiteLLM mana yang terkena malware?
Apakah aplikasi yang tidak memanggil import litellm tetap berbahaya?
Bagaimana cara cek LiteLLM tanpa memicu malware?
Kredensial apa yang harus diganti?
Apakah pengguna LiteLLM Enterprise ikut terdampak?
Kesimpulan
Kebobolan LiteLLM 1.107.0 adalah pengingat bahwa paket open source yang sangat populer pun bisa jadi pintu masuk serangan. Jendelanya memang hanya sekitar dua jam, tapi malware ini mengincar data paling berharga, mulai dari API key AI sampai kredensial cloud.
Langkah paling aman adalah mengecek semua server, pipeline CI, dan laptop developer yang memakai LiteLLM, lalu turun ke versi 1.106.2. Kalau ada tanda terpapar, bersihkan mesin dan ganti semua kredensial dari perangkat yang bersih. Ke depan, kebiasaan mengunci versi dan digest image akan sangat membantu mengurangi risiko serupa.
Komentar (0)
Belum ada komentar. Jadilah yang pertama berbagi pendapat!
Tinggalkan komentar