Inti artikel
Jam demi jam penanganan PHP2Shell (CVE-2026-109618 dan CVE-2026-109619) oleh tim engineer Life Future: image dibangun ulang, versi lama disimpan, versi dicek.
Pada 20 Oktober 2026 dua celah kritis di inti PHP diumumkan dengan nama PHP2Shell. Kami menjalankan PHP di beberapa sistem, jadi pertanyaannya sederhana: seberapa cepat semuanya berjalan di versi yang sudah diperbaiki? Tulisan ini mencatat jawabannya dengan jam dan tanggal, apa adanya.
Apa itu PHP2Shell
PHP2Shell adalah nama untuk dua celah, CVE-2026-109618 dan CVE-2026-109619, keduanya bernilai CVSS v4 9,2. Celahnya ada di mesin PHP sendiri, bukan di kode aplikasi, sehingga situs dengan kode yang bersih pun ikut terdampak. Perbaikannya ada di PHP 8.5.12, 8.4.27, 8.3.36 dan 8.2.35 (Help Net Security).
Para peneliti menilai celah ini bisa berujung pada eksekusi perintah dari jauh. Sansec lebih berhati-hati: serangan nyata butuh pengetahuan tentang server target dan kondisi tertentu, jadi serangan massal kurang mungkin. Kami tidak menimbang-nimbang soal itu. Satu-satunya jawaban yang masuk akal untuk celah di mesin PHP adalah mengganti PHP.
Jam demi jam
Semua waktu dalam WIB.
- 20 Oktober: PHP2Shell diumumkan.
- 21 Oktober, 22:49: build PHP 8.5.12 dan 8.4.27 yang sudah diperbaiki tersedia, dan image dasarnya kami tarik ke server.
- 22 Oktober, 00:26: image ERP kami dibangun ulang di atas PHP yang ditambal.
- 22 Oktober, 00:35: layanan ERP pertama diganti satu per satu ke image baru. Itu 1 jam 46 menit setelah build tersedia.
- 22 Oktober: Atlas ikut diperbarui pada rentang yang sama.
- 23 Oktober, 17:45: ERP kedua menyusul pindah ke image yang ditambal.
ERP kedua menyusul belakangan. Kami mencatatnya apa adanya supaya urutannya jujur.
Lima langkah penambalan
1. Bangun ulang image. Kami tidak menambal di tempat. Setiap image dibangun ulang di atas PHP yang sudah diperbaiki, sehingga hasilnya bisa diulang dan tidak bergantung pada perubahan manual di server.
2. Simpan versi lama. Sebelum apa pun diganti, image versi lama diberi penanda dan disimpan.
3. Ganti layanan satu per satu. Layanan diganti bertahap, bukan sekaligus. Kalau satu layanan bermasalah, yang lain masih berjalan dan jalan kembali ke versi lama tetap terbuka.
4. Cek versi di setiap kontainer. Kami tidak percaya pada catatan deploy saja. Versi PHP dibaca langsung dari dalam kontainer yang sedang berjalan.
5. Versi lama jadi bahan uji. Image lama tidak langsung dibuang. Alasannya ada di bagian berikut.
Kenapa versi lama sengaja disimpan
Versi lama punya dua tugas. Yang pertama jelas: cadangan rollback, kalau versi baru ternyata merusak sesuatu. Yang kedua kurang lazim: versi itu kami pakai sebagai sampel untuk uji keamanan dan untuk berlatih menutup celahnya.
Versi lama yang rentan itu tidak melayani pengunjung dan tidak dijalankan di produksi. Ia hanya disimpan sebagai image, dan dijalankan secara terpisah ketika kami memakainya untuk uji.
Yang berjalan sekarang
Hasil pemeriksaan langsung di dalam kontainer: ERP pertama dan kedua serta Atlas berjalan di PHP 8.5.12. ERP ketiga ada di jalur PHP 8.4 dan berjalan di 8.4.27. Keempatnya sudah berada di versi yang memuat perbaikan.
Yang tidak kami klaim
Ini catatan penambalan, bukan laporan audit insiden. Kami tidak menulis bahwa kami menemukan atau tidak menemukan tanda serangan, karena bukan itu yang dicatat di sini. Menaikkan versi PHP juga tidak menggantikan lapisan lain: pemeriksaan input, pembatasan akses, dan pemantauan tetap berjalan seperti biasa.
Yang bisa kami janjikan sederhana: begitu perbaikan tersedia, kami menaikkan versinya dalam hitungan jam, memeriksanya langsung, dan menyimpan jalan untuk kembali.