Insiden Sertifikat emSign: Segera Update pip ke 26.2.2

Verdict: Cuitan viral yang menyebut Python dan pip install telah dikompromikan itu setengah benar, dan separuh yang benarnya cukup serius untuk ditindaklanjuti hari ini juga. Tidak ada pembobolan PyPI, tidak ada malware yang disebar lewat pip. Yang terjadi adalah insiden sertifikat: delapan sertifikat intermediate milik otoritas sertifikat eMudhra, dengan merek emSign, ternyata memakai kunci privat yang sangat lemah sehingga sertifikat palsu dapat dibuat untuk situs mana pun. Karena pip membawa bundel sertifikatnya sendiri, update sistem operasi saja tidak cukup; pip harus diperbarui satu per satu di setiap virtual environment. Artikel ini hasil validasi klaim tersebut ke sumber resminya, lengkap dengan versi aman dan cara update yang benar.

Verdict: Instruksinya Benar, Judulnya yang Berlebihan

Semua perintah dalam cuitan yang beredar akurat: naikkan pip ke 26.2.2 atau lebih baru di setiap proyek dan setiap venv, perbarui uv ke 0.13.4 atau lebih baru, segarkan sertifikat sistem, dan bangun ulang image Docker. Angka-angka itu persis sama dengan advisori resmi tim Python yang terbit 20 Oktober 2026 di forum discuss.python.org, ditulis oleh pengembang inti CPython Seth Larson dan dipertegas Christian Heimes. Bagian yang keliru adalah bingkainya. Python tidak dibobol, PyPI tidak dibobol, dan tidak ada bukti satu pun paket berbahaya tersebar akibat insiden ini. Kesalahan penamaan ini penting, karena respons yang benar untuk sertifikat CA yang cacat berbeda total dengan respons untuk gudang paket yang jebol.

Apa yang Sebenarnya Terjadi: Kunci Privat CA yang Nyaris Nol

Otoritas sertifikat, atau CA, adalah pihak yang menerbitkan sertifikat TLS yang membuat browser dan program percaya bahwa sebuah server benar-benar pemilik domain yang diklaimnya. eMudhra adalah CA asal India yang beroperasi dengan merek emSign. Dalam insiden ini, delapan sertifikat intermediate CA milik eMudhra ditemukan memakai kunci privat kurva eliptik dengan nilai skalar d lebih kecil dari 256. Satu kunci bahkan bernilai d sama dengan 4. Sebagai gambaran, kunci privat yang sehat adalah angka acak raksasa yang mustahil ditebak; kunci bernilai satu digit dapat ditebak anak sekolah. Dengan kunci seperti itu, siapa pun dapat menerbitkan sertifikat yang valid secara kriptografis untuk domain apa saja di bawah rantai intermediate tersebut, termasuk domain sebesar pypi.org dan python.org.

Ini kegagalan kriptografi, bukan peretasan konvensional. Tidak ada server yang ditembus dan tidak ada basis data yang bocor; kuncinya memang lahir dalam keadaan lemah. Konsekuensinya tetap berbahaya: penyerang yang berada di tengah jalur jaringan, misalnya di Wi-Fi publik atau jaringan yang sudah disusupi, dapat menyamar sebagai server tepercaya dan mencegat atau mengubah lalu lintas TLS. Seth Larson menyebut risikonya sebagai serangan monster-in-the-middle terhadap klien TLS, termasuk yang mengakses python.org dan pypi.org. Skenario terburuknya bersifat rantai pasok: PyPI palsu yang menyajikan paket berisi malware, dan pip versi lama akan menerimanya tanpa satu pun peringatan. Karena klien TLS pada umumnya tidak memeriksa status pencabutan sertifikat secara andal dari detik ke detik, satu-satunya cara memutus kepercayaan pada intermediate cacat ini adalah memperbarui bundel akar yang dipercaya oleh setiap program, persis seperti yang dilakukan para vendor browser dan pengelola certifi dalam hitungan hari.

Pengguna browser relatif aman lebih dulu. Chrome, Firefox, Apple, dan Microsoft telah mencabut kepercayaan terhadap kedelapan sertifikat bermasalah itu pada 17 sampai 20 Oktober. Masalah justru tertinggal di perangkat baris perintah dan pustaka yang membawa daftar sertifikatnya sendiri, terutama bundel certifi yang menjadi tulang punggung validasi TLS di ekosistem Python. certifi merilis versi 2026.10.18 yang membuang seluruh root emSign, lalu 2026.10.19 yang mengembalikan root emSign yang tidak terdampak agar situs bersertifikat emSign yang sah tidak ikut putus. Versi yang perlu dituju adalah 2026.10.19, bukan yang pertama.

Kenapa pip Paling Kena: Sertifikat Bawaan yang Tidak Bisa Dibuang

Detail paling menentukan dari insiden ini adalah perilaku pip. Dalam penegasan resmi di advisori Python, Christian Heimes menjelaskan bahwa pip selalu memuat sertifikat dari certifi yang dibundel di dalamnya, sebagai tambahan di samping trust store sistem, dan tidak ada cara yang didukung untuk menonaktifkan perilaku itu. Opsi penunjuk bundel khusus, variabel PIP_CERT, dan REQUESTS_CA_BUNDLE hanya menambahkan otoritas baru; ketiganya tidak dapat membuang otoritas yang sudah ada di dalam bundel. Akibatnya, pip di bawah 26.2.2 akan terus memercayai intermediate eMudhra yang cacat walaupun sistem operasi sudah mencabutnya. Memperbarui ca-certificates di server, saran yang benar untuk perangkat sistem, tidak menyentuh pip sama sekali.

Basis data kerentanan Safety mencatat persoalan ini sebagai advisori kritis untuk pip versi 19.1 sampai sebelum 26.2.2, dengan klasifikasi verifikasi keaslian data yang tidak memadai, sementara advisori certifi memuat skor CVSS 9,1. Pip bukan satu-satunya yang membawa bundel sendiri. Aplikasi berbasis requests dan urllib3 yang memakai certifi ikut terpapar, begitu pula installer Python untuk macOS dari python.org. Pengguna uv berada di posisi sedikit lebih baik: uv 0.13.4 membuang root emSign dari bundel bawaannya, dan selagi menunggu update, uv dapat dialihkan ke trust store sistem dengan UV_SYSTEM_CERTS=true. Jalan pintas semacam itu tidak ada untuk pip; memperbarui pip adalah satu-satunya perbaikan yang andal. Tim pip sendiri telah membuka isu untuk mengubah perilaku bawaan ini menjadi hanya memakai trust store sistem di masa depan, tetapi perubahan tersebut belum terbit dan belum tentu kompatibel dengan semua platform, sehingga pembaruan pip hari ini tidak dapat digantikan oleh pengaturan apa pun. Uraian teknis tambahan tersedia dalam liputan insiden kunci CA eMudhra dan ringkasan rilis keamanan Python.

Versi Minimum yang Aman dan Siapa Saja yang Wajib Update

Daftar versi lantai resmi dari advisori Python adalah sebagai berikut. Semua yang berada di bawah angka ini masih memercayai sertifikat cacat dan perlu dinaikkan.

Baca juga:

CV Dipoles AI Justru Ditolak Rekruter

Tim Python juga merilis pembaruan keamanan interpreter 3.15.1, 3.14.9, dan 3.13.17 yang sudah membundel pip 26.2.2. Rilis untuk 3.13 tergolong tidak biasa karena cabang itu baru masuk mode keamanan saja, tetapi dianggap perlu mengingat pip yang dibawanya dipakai untuk membuat venv baru. Komunitas ilmiah yang banyak memakai Python untuk riset dan distribusi perangkat lunak termasuk yang didorong bertindak cepat, sebagaimana terlihat pada advisori untuk komunitas OMSF dan rangkuman dampak cacat sertifikat eMudhra. Bagi yang sehari-hari membangun layanan Python, misalnya mengikuti panduan setup FastAPI untuk server LLM lokal atau setup ChromaDB lokal untuk proyek AI, setiap lingkungan dari panduan-panduan semacam itu adalah lingkungan yang perlu diperiksa satu per satu.

Cara Update yang Aman, Termasuk Jebakan saat Mengupdate pip Itu Sendiri

Langkah dasarnya sederhana. Periksa versi yang sedang berjalan, lalu naikkan:

python -m pip -V
python -m pip install -U pip
python -c "import certifi; print(certifi.__version__)"
uv self update

Ulangi pemeriksaan itu di setiap virtual environment, setiap image container, dan setiap runner CI, karena masing-masing menyimpan pip-nya sendiri dan tidak ada mekanisme pembaruan terpusat. Image Docker perlu dibangun ulang, idealnya tanpa cache layer, agar lapisan sertifikat sistemnya ikut segar. Hal yang sama berlaku untuk proyek yang dirakit dengan setup Dify self-hosted di VPS atau setup LiteLLM proxy multi model: image lama yang dibangun sebelum 20 Oktober membawa bundel lama.

Ada satu jebakan yang disorot langsung oleh Seth Larson. pip lama yang rentan dapat menjadi target justru pada saat dipakai untuk mengunduh pip baru, bila jaringan sedang disadap. Jalur yang lebih aman adalah mengunduh wheel pip baru lewat browser yang trust store-nya sudah diperbarui, memeriksa checksum SHA-256 yang diterbitkan, lalu memakai wheel itu untuk bootstrap. Tim CPython sedang memperbarui ensurepip agar venv baru di rilis interpreter mendatang langsung membawa pip yang sudah diperbaiki; sampai rilis itu tiba, kebiasaan yang disarankan adalah menaikkan pip segera setelah membuat venv baru, tanpa kecuali. Kasus ini sejajar pelajarannya dengan bedah PHP2Shell kemarin: komponen bawaan yang tidak terlihat sering menjadi penentu aman atau tidaknya sebuah sistem.

Yang Tidak Terjadi: Bukan Pembobolan PyPI, Bukan Malware

Agar catatan tetap lurus, tiga hal perlu ditegaskan. Pertama, tidak ada penyerang yang masuk ke infrastruktur Python atau PyPI; insiden ini murni kegagalan pembuatan kunci di satu CA pihak ketiga. Kedua, sampai advisori ini berusia beberapa hari, belum ada laporan eksploitasi berhasil di lapangan; serangan membutuhkan posisi di tengah jaringan, bukan sekadar koneksi internet biasa. Ketiga, frasa pip install telah dikompromikan mencampuradukkan dua hal berbeda: jalur instalasi yang berpotensi disadap pada jaringan yang tidak aman, dengan gudang paket yang benar-benar jebol. Yang pertama yang terjadi di sini. Bedanya bukan soal remeh: pada pembobolan gudang, artefak yang sudah terunduh harus dianggap beracun dan lingkungan harus dibangun ulang dari nol, sedangkan pada insiden sertifikat, memperbarui daftar kepercayaan menutup celahnya secara tuntas.

Kesimpulan Final: Daftar Kepercayaan Juga Permukaan Serangan

Pelajaran terbesar insiden emSign adalah bahwa keamanan rantai pasok tidak hanya soal kode, melainkan juga soal daftar pihak yang dipercaya oleh perangkat. Sebuah CA dapat gagal tanpa diretas, dan kegagalannya merambat ke setiap program yang membawa bundel sertifikat sendiri, meniadakan patch di level sistem operasi. Pertahanan praktisnya berlapis: ketahui perangkat apa saja yang membawa trust store sendiri, biasakan memeriksa versi pip dan uv seperti memeriksa versi runtime, dan perlakukan venv serta image container sebagai aset yang menua dan harus disegarkan. Cek versi pip di semua lingkungan hari ini; bila angkanya di bawah 26.2.2, naikkan sekarang juga.

Baca juga:

Anatomi PHP2Shell: Penyebab, Dampak, dan Cara Menanganinya