Laporan insiden resmi tim keamanan PyPI tentang serangan rantai pasok: kasus paket berbahaya LiteLLM·Telnyx dan cara bertahan

🔑 Ringkasan inti

Melalui kerentanan dependensi Trivy, token API dicuri, lalu digunakan sebagai pijakan untuk menerbitkan versi berbahaya dari paket litellm dan telnyx di PyPI. Malware dijalankan segera setelah instalasi, mengumpulkan kredensial dan file sensitif lalu mengekfiltrasikannya ke server eksternal.

---

⚠️ Mengapa malware kali ini istimewa

Sebagian besar paket berbahaya di PyPI sebelumnya adalah paket yang baru dibuat (seperti typosquatting). Serangan kali ini berbeda. Metodenya adalah menyuntikkan malware ke paket open source yang sudah digunakan luas.

Ada dua jalur penyuntikan:

• Menyerang langsung proyek open source yang memiliki repositori, alur rilis, atau autentikasi yang lemah
• Mencuri token API dan key dari mesin developer yang memasang versi terbaru

Dengan token API PyPI atau GitHub yang dicuri, penyerang kemudian mengompromikan paket open source lain dalam pola serangan berantai.

---

📅 Timeline insiden

LiteLLM

Di masa paparan versi berbahaya, paket ini diunduh lebih dari 119.000 kali.
PyPI menerima 13 laporan melalui fitur "laporkan malware".

Tahap	Waktu yang dibutuhkan
Upload → laporan pertama	1 jam 19 menit
Laporan pertama → karantina	1 jam 12 menit
Total waktu paparan	2 jam 32 menit

LiteLLM dipasang sekitar 15~20 juta kali per minggu, atau sekitar 1.700 kali per menit. Dari jumlah ini, sekitar 40~50% tidak mematok versi sehingga otomatis menerima versi terbaru.

Telnyx

Paket telnyx dikarantina secara otomatis berkat trusted reporters pool milik PyPI.

Tahap	Waktu yang dibutuhkan
Upload → laporan pertama	1 jam 45 menit
Laporan pertama → karantina	1 jam 57 menit
Total waktu paparan	3 jam 42 menit

---

🛡️ Rekomendasi keamanan untuk developer

1. Dependency cooldowns

Ini adalah strategi untuk mengatur agar paket yang baru dirilis tidak dipasang selama periode tertentu, sehingga peneliti keamanan dan pengelola PyPI punya waktu untuk merespons.

uv — saat ini sudah didukung:

# ~/.config/uv/uv.toml atau pyproject.toml  
[tool.uv]  
exclude-newer = "P3D"  # kecualikan paket yang dirilis dalam 3 hari terakhir  

pip v26.1 — dijadwalkan didukung pada April:

# ~/.config/pip/pip.conf  
[install]  
uploaded-prior-to = P3D  

> ⚠️ Cooldown bukan solusi ajaib. Jika patch keamanan diperlukan, paket tetap harus segera dipasang, jadi perlu dipakai bersama alat pemindaian kerentanan seperti Dependabot dan Renovate.

2. Dependency locking

pip freeze yang hanya mencatat versi bukan lock file. Untuk keamanan, diperlukan lock file yang benar-benar menyertakan checksum/hash.

Alat yang direkomendasikan:

• uv lock
• pip-compile --generate-hashes
• pipenv

---

🔒 Rekomendasi keamanan untuk maintainer open source

1. Perkuat keamanan alur rilis

• Jangan gunakan trigger yang tidak aman — pull_request_target di GitHub Actions sangat berbahaya
• Netralkan parameter dan input — kirim lewat environment variable untuk mencegah template injection
• Jangan gunakan referensi yang dapat berubah — gunakan commit SHA alih-alih Git tag, dan pertahankan lock file dependensi
• Konfigurasikan deployment yang memerlukan review — gabungkan Trusted Publishers + GitHub Environments agar deployment memerlukan persetujuan tambahan

Jika Anda menggunakan GitHub Actions, disarankan memeriksa kerentanan workflow dengan alat Zizmor.

2. Gunakan Trusted Publishers alih-alih token API

• Token API bersifat jangka panjang, sehingga sulit dideteksi segera saat dicuri
• Trusted Publishers menggunakan token jangka pendek, sehingga risikonya lebih rendah karena token curian harus segera dipakai
• Dengan Digital Attestations, pengguna hilir dapat mendeteksi deployment yang tidak melalui alur rilis normal

3. Wajibkan 2FA

Sejak 2024, PyPI mewajibkan 2FA untuk distribusi paket. Namun 2FA harus diterapkan bukan hanya pada akun PyPI, tetapi juga pada semua akun yang terkait dengan pengembangan open source seperti GitHub, GitLab, dan email, idealnya menggunakan hardware key.

---

💰 Untuk mendukung aktivitas ini

Aktivitas keamanan PyPI dimungkinkan melalui dukungan dari Python Software Foundation (PSF). Anda dapat menghubungi program sponsorship PSF, memberikan donasi langsung, atau mengirim email ke [e-mail].

> Posisi Mike Fiedler dan Seth Larson sebagai security engineer PyPI didukung oleh Alpha-Omega.

[yjcho9317]

Saya sempat membuat server MCP dan mengunggahnya ke npm, jadi membaca laporan insiden ini terasa cukup mengerikan.

Pada akhirnya server MCP juga langsung dipublikasikan ke npm dan PyPI, dan cukup sering ada kasus pemasangan tanpa pinning versi. Sistem pelaporan atau hal seperti trusted publisher juga masih belum ada. Meski LiteLLM hanya terekspos sedikit lebih dari 2 jam, kalau jumlah unduhannya sudah sebanyak itu, saya jadi merasa di ranah ini sekali ada yang lolos masuk, dampaknya bisa bertahan cukup lama.

Dari yang saya lihat di sisi Claude Code juga ada kasus di mana pengaturan perlindungan seperti ini tidak diterapkan dengan benar saat pip install, jadi kalau alurnya agen memasang paket sendiri secara otomatis, jadi tidak jelas harus diblok di mana.