Validasi input dan pembatasan akses tidak banyak membantu ketika runtime sendiri memproses request dalam keadaan memori yang rusak.
PHP2Shell memperlihatkan hubungan itu. Dua kerentanan di inti PHP, CVE-2026-109618 dan CVE-2026-109619, dapat memungkinkan eksekusi kode tanpa autentikasi dalam kondisi tertentu. Saya merangkum mekanismenya dan urutan penanganannya.
Peta singkat
Bagian | Inti masalah |
CVE-2026-109618 | Kegagalan alokasi memori dapat meninggalkan data internal yang belum selesai diinisialisasi. |
CVE-2026-109619 | State milik request lama masih dirujuk setelah memorinya dibebaskan. |
Penanganan | Perbarui runtime yang terdampak, mulai ulang worker, lalu verifikasi layanan yang benar-benar melayani request. |
1. Mengapa kode aplikasi yang benar tetap berisiko
PHP2Shell berada di engine PHP. WordPress, Drupal, dan Joomla dipakai peneliti sebagai target demonstrasi, tetapi nama-nama itu bukan batas cakupan kerentanannya. Aplikasi lain yang memakai runtime rentan juga perlu diperiksa. Analisis Wiz menjelaskan cakupan dan demonstrasi tersebut.
PHP menyebut seluruh instalasi yang melayani request web sebagai sasaran pembaruan, termasuk PHP-FPM, Apache dengan mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Risiko dinilai paling tinggi pada mod_php: salah satu jalur serangan yang didemonstrasikan dapat terpicu sebelum kode aplikasi berjalan.
Saya membedakan dua hal: demonstrasi membuktikan suatu jalur eksploitasi, sedangkan keberhasilan terhadap sebuah deployment tetap bergantung pada versi, konfigurasi, dan jalur kode yang dapat dicapai. Karena itu, nama framework saja tidak cukup untuk menyimpulkan aman.
2. Ketika kehabisan memori merusak keadaan internal
CVE-2026-109618 berkaitan dengan penanganan out-of-memory atau OOM. Masalahnya bukan sekadar request membutuhkan terlalu banyak RAM. Alokasi yang gagal pada titik tertentu dapat menghentikan pekerjaan ketika struktur internal baru terisi sebagian. Proses pembersihan kemudian memperlakukan struktur tersebut sebagai data yang valid. Mekanisme ini dijelaskan dalam laporan PHP Foundation.
Sebagai gambaran, bayangkan pencatatan sebuah objek terhenti setelah referensinya disimpan, tetapi sebelum seluruh isinya siap. Jika tahap berikutnya menganggap pencatatan sudah selesai, kesalahan penanganan memori dapat terjadi.
Pelajaran yang saya ambil: jalur kegagalan juga harus mempertahankan invariant. Operasi yang terputus perlu meninggalkan keadaan yang tetap dapat dibersihkan dengan benar.
3. Request berakhir, referensi lama masih hidup
CVE-2026-109619 berkaitan dengan state global yang bertahan di worker. Memori suatu request sudah dibebaskan, tetapi referensi ke memori itu belum dibersihkan. Request berikutnya yang ditangani worker yang sama dapat memakai referensi lama tersebut, sebagaimana dijelaskan PHP Foundation.
Kondisi ini disebut use-after-free: program memakai memori setelah masa kepemilikannya berakhir. Dalam PHP2Shell, dampaknya dapat melampaui crash. Penelitian juga memperlihatkan pengungkapan memori proses dan eksekusi kode melalui rangkaian eksploitasi tertentu.
Bagi saya, batas request perlu dipahami sebagai batas kepemilikan data. Worker boleh digunakan kembali, tetapi referensi ke data request sebelumnya harus diakhiri secara konsisten.
4. Perbaikan ada pada runtime
Rilis keamanan 21 Oktober menyediakan versi perbaikan berikut:
Cabang | Rilis perbaikan |
PHP 8.2 | 8.2.35 |
PHP 8.3 | 8.3.36 |
PHP 8.4 | 8.4.27 |
PHP 8.5 | 8.5.12 |
Memperbarui CMS atau dependensi aplikasi tidak dengan sendirinya mengganti PHP di bawahnya. Paket distribusi juga dapat membawa backport; cocokkan status perbaikan dengan advisory vendor, bukan hanya angka versi upstream.
Urutan pemeriksaan yang saya sarankan:
- Inventarisasi runtime pada setiap host, container, dan pool yang melayani aplikasi.
- Pasang paket perbaikan dari kanal tepercaya atau bangun ulang image yang digunakan.
- Mulai ulang layanan dan worker terkait agar proses lama tidak terus dipakai.
- Verifikasi runtime aktif dan uji alur utama, termasuk login, upload, dan pekerjaan latar.
- Catat versi paket, waktu pembaruan, dan hasil pengujian agar penanganannya dapat ditelusuri.
5. Satu catatan susulan
Sehari setelah rilis keamanan, PHP menerbitkan pemberitahuan terpisah mengenai CVE-2026-115560. Kondisinya khusus: konfigurasi session.serialize_handler memakai php_binary atau php_serialize, lalu diubah ke php dengan ini_set() sebelum session_start(), sementara upload progress tetap aktif.
PHP menyarankan session.upload_progress.enabled=0 sampai rilis bugfix berikutnya. Aplikasi yang tidak pernah mengubah serializer saat runtime dapat mempertahankan fitur tersebut. Catatan ini perlu dibaca terpisah dari dua CVE utama, supaya status patch tidak disederhanakan menjadi satu label “sudah aman”.
6. Mitigasi sementara dan pemeriksaan insiden
WAF dan perubahan konfigurasi dapat mengurangi paparan terhadap jalur tertentu. Keduanya tetap perlu dinilai berdasarkan cakupannya; pembaruan PHP menjadi prioritas.
Wiz menyebut request multipart yang tidak biasa, error batas memori, HTTP 500 berulang, cookie PHPSESSID yang abnormal, dan worker yang sering berganti sebagai petunjuk investigasi. Gejala tersebut bukan bukti tunggal kompromi. Ketiadaannya juga tidak membuktikan server aman.
Saya akan memulai dari inventaris runtime, pembaruan, dan verifikasi proses aktif, kemudian menelaah log serta indikasi insiden. PHP2Shell mengingatkan saya bahwa keamanan aplikasi merupakan pekerjaan pada satu sistem utuh: kode, runtime, proses, dan cara operasionalnya saling menentukan.
