PHP Rentan, Pengelola Wikipedia Sampai Matikan Sistem. Website Kamu Aman?

Minggu ini, puluhan organisasi besar sengaja mematikan sebagian website dan layanan online mereka sendiri. Menurut daftar yang dikumpulkan Reuters, yang ikut mematikan antara lain penyedia IT pemerintah Jerman, situs prefektur Prancis, Pelabuhan Rotterdam, layanan web pemerintah Finlandia, Kementerian Keuangan Jepang, sampai sebagian portal BBC.

Banyak yang menyebut langkah ini pencegahan. Menurut Reuters, Wikimedia Foundation, pengelola Wikipedia, mematikan sejumlah sistem sebagai langkah pencegahan sampai bisa ditambal dengan aman.

Yang mereka tunggu adalah tambalan untuk PHP, bahasa pemrograman yang menjalankan WordPress, Joomla, Drupal, Magento untuk toko online, dan banyak website kantor. Kalau website kantormu dibikin pakai salah satunya, artikel ini buat kamu.

Kenapa Sampai Harus Dimatikan?

Dua celahnya punya nomor CVE, semacam nomor katalog resmi untuk celah keamanan: CVE-2026-109618 dan CVE-2026-109619. Tim PHP memberi keduanya skor bahaya 9,2 dari 10. Akibatnya sama: orang yang nggak punya akun bisa menjalankan perintahnya sendiri di server website-mu.

Yang bikin ini beda dari celah biasa ada dua.

Pertama, celahnya ada di PHP-nya, bukan di aplikasi. Peneliti Calif membuktikan serangan tanpa login berhasil di WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony, dan WHMCS.

Tim PHP menyebut risikonya paling tinggi di server Apache yang memakai mod_php, modul yang menjalankan PHP langsung di dalam Apache, karena serangannya bisa jalan sebelum kode aplikasi mana pun sempat jalan. WordPress-mu belum sempat ngapa-ngapain, servernya sudah kebobolan.

Kedua, detailnya bocor sebelum tambalan keluar. Tim PHP mengumumkan jadwal rilis 21 Oktober jam 14.00 UTC, alias jam 9 malam WIB.

Tapi Cloudflare menulis celah ini sudah bocor sebelum tanggal itu, dan mereka melihat lalu lintas serangan ke pelanggannya, lengkap dengan penyerang yang mengutak-atik serangannya supaya lolos dari filter. Cloudflare memasang aturan blokir untuk semua pelanggannya sejak jam 03.02 UTC, sekitar 11 jam sebelum tambalan resmi keluar.

Jadi ada jeda ketika cara menyerangnya sudah beredar, tapi obatnya belum ada. Di jeda itu, mematikan website adalah pilihan paling aman yang tersisa.

Siapa yang Nemu, dan Kenapa Baru Sekarang?

Calif melaporkan temuan pertamanya ke tim PHP pada 11 Agustus 2026. Tim Wiz Research menemukan celah yang sama secara terpisah dan melapor 24 Agustus. Menurut Calif, OpenAI juga ikut dalam temuan ini.

Jalur tertua yang ditemukan Calif sudah ada sejak PHP 5.4.0, versi yang rilis Maret 2012. Artinya celah ini numpang di website orang selama lebih dari 14 tahun tanpa ketahuan.

Calif juga cerita kalau mereka memakai AI sebagai teman memeriksa kode, dan menegaskan nggak ada model AI khusus yang dipakai: semuanya model yang bisa dipakai siapa saja.

Menurut aku, ini bagian yang paling perlu diperhatikan kantor. Kalau peneliti bisa nemu celah berumur 14 tahun pakai AI biasa, penyerang juga bisa. Celah PHP berikutnya kemungkinan nggak butuh 14 tahun buat ketahuan.

Cara Kerjanya, Tanpa Bahasa Programmer

Bayangin PHP itu petugas loket di kantor pos. Tiap pengunjung website datang bawa formulir dan barang titipan. Petugas membaca formulir, menyimpan barang di loker, melayani, lalu membersihkan loker buat pengunjung berikutnya. Satu petugas melayani banyak pengunjung bergantian.

Celah pertama (CVE-2026-109618) terjadi saat petugas kewalahan. Penyerang mengirim formulir yang dibuat sangat ribet sampai PHP kehabisan jatah memori di tengah jalan dan berhenti mendadak. Waktu beres-beres, PHP menganggap data yang baru setengah jadi itu sudah lengkap. Pengumuman keamanan resminya menyebut kondisi ini bisa dipakai untuk menjalankan perintah dari jarak jauh tanpa login.

Celah kedua (CVE-2026-109619) soal catatan basi. Kalau satu pengunjung gagal dilayani di tengah jalan, catatan petugas masih menunjuk ke loker milik pengunjung itu, padahal lokernya sudah dikosongkan dan bisa diisi orang lain.

Pengunjung berikutnya yang dilayani petugas yang sama bisa menaruh barang di loker itu, lalu petugas memakai isinya seolah-olah catatan resmi. Programmer menyebut pola ini use-after-free: memori dipakai lagi setelah dibebaskan. Salah satu jalur yang dikonfirmasi tim PHP ada di fitur yang menampilkan progres upload file.

Dua-duanya terjadi di tahap PHP membaca kiriman, sebelum WordPress atau aplikasimu menerima apa pun. Itu sebabnya Cloudflare menegaskan update kode website atau plugin saja nggak menambal celah ini.

Kalau berhasil, penyerang bisa menjalankan perintah dengan hak akses yang sama seperti website-mu. Wiz juga menunjukkan celah ini bisa membocorkan isi memori server, yang menurut mereka bisa berisi password, token login, API key (kode rahasia yang dipakai aplikasi untuk masuk ke layanan lain), dan sertifikat.

Versi Mana yang Kena, dan Mana yang Aman?

Semua PHP di bawah versi tambalan ini terdampak:

Tanggal di kolom kanan dari halaman versi resmi PHP. PHP 8.2 cuma punya waktu dua bulan lagi.

Untuk 8.1 ke bawah, tim PHP cuma menyediakan tambalan kode sumber untuk 7.4, 8.0, dan 8.1, buat yang biasa merakit PHP sendiri. Kode sumber itu bahan mentah programnya, sebelum dirakit jadi siap pakai. Sisanya bergantung pada distro Linux atau vendor yang menyediakan dukungan jangka panjang.

Ini bukan masalah kecil. Per 23 Oktober 2026, W3Techs mencatat PHP dipakai 69,3% website yang bahasa pemrograman servernya bisa mereka deteksi. Dari website PHP itu, 26,9% masih di versi 7 dan 7,7% masih di versi 5. Jadi sepertiga lebih website PHP masih di versi yang nggak dapat rilis resmi lagi.

Menurut aku, kalau website kantormu masih PHP 7, minggu ini saatnya berhenti menunda upgrade.

Cara Ngecek Website Kantormu

Kalau pakai shared hosting

Shared hosting artinya website-mu numpang di server yang dipakai bareng banyak website lain. Buka panel hosting dan cari menu pemilih versi PHP. Kalau angkanya di bawah tabel di atas, ganti ke versi yang aman kalau tersedia, atau tanya hosting. Pertanyaannya cukup satu kalimat: “Server kami sudah pakai PHP yang menambal CVE-2026-109618 dan CVE-2026-109619?”

Hosting yang mengelola PHP-nya, jadi tambalan di level server itu urusan mereka. Tugasmu memastikan mereka sudah mengerjakannya.

Kalau pegang VPS atau server sendiri

Bagian ini untuk tim IT atau vendor yang mengurus server-mu. VPS itu server virtual yang disewa.

Ini perintah untuk admin server, diketik di terminal, untuk melihat versi PHP:

php -v

Hati-hati, angka ini bisa mengecoh karena dua hal. Pertama, PHP yang dipakai website (lewat PHP-FPM, pengelola proses PHP untuk website, atau lewat Apache) bisa beda dengan PHP di terminal, jadi cek juga dari panel atau halaman info PHP yang cuma bisa dibuka admin.

Kedua, tim PHP menyebut distro Linux sudah menerima tambalan lebih dulu, dan paket distro biasanya menambal tanpa mengganti nomor versi utama. Cara paling pasti: cari nomor CVE-nya di changelog paket, alias catatan perubahannya.

Ini dua perintah untuk admin server, contoh dari Sansec, dipilih sesuai jenis Linux-nya dan diketik di terminal:

# Debian/Ubuntu (ganti php8.1 dengan versimu)
zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz
# RHEL, AlmaLinux, Rocky
rpm -q --changelog php-common | grep CVE-2026-109618

Kalau keluar baris yang menyebut CVE itu, paketmu sudah ditambal. Kalau kosong, belum.

Jangan lupa yang tersembunyi

CISA, lembaga keamanan siber Amerika, minta organisasi mendata semua tempat PHP berjalan, termasuk yang dibawa software lain. Panel admin, aplikasi internal, atau alat vendor yang di dalamnya ada PHP juga ikut dihitung. Website yang bisa diakses dari internet didahulukan.

Belum Bisa Update Hari Ini? Ini Pengaman Sementara

Bagian ini untuk tim IT atau vendor hosting-mu.

Tim PHP menulis dengan jelas: langkah di bawah ini cuma menutup sebagian jalur serangan, “do not make an installation safe.” Pakai ini sambil menunggu update, bukan sebagai pengganti.

Kalau server-mu pakai PHP-FPM, admin menaruh setelan di file pool, file setelan untuk kelompok proses PHP yang melayani website. Taruh di sana supaya aplikasi nggak bisa mengubahnya, lalu nyalakan ulang semua proses PHP itu.

Ini tiga baris untuk admin server: mematikan fitur progres upload, melepas batas memori per permintaan, dan membatasi ukuran kiriman form jadi 8 MB.

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M

Kalau server-mu pakai Apache dengan mod_php, admin menaruh setelan yang sama di php.ini, file setelan utama PHP, lalu menyalakan ulang Apache.

Ini versi yang sama untuk ditulis admin di php.ini:

session.upload_progress.enabled = 0
memory_limit = -1
post_max_size = 8M

Beberapa catatan dari pengumuman resminya, juga untuk admin:

• Kalau website-mu butuh upload file, naikkan batas kiriman jadi post_max_size = 32M, dan pastikan batas ukuran per file (upload_max_filesize) lebih kecil dari angka itu.
• Jangan pasang setelan ini dari dalam kode aplikasi (ini_set()) atau dari file setelan per folder (.user.ini), karena dibacanya sudah terlambat.
• memory_limit = -1 berarti satu permintaan dari pengunjung boleh memakai memori tanpa batas. Pasang batas di level container (wadah terpisah tempat aplikasi berjalan) atau server supaya satu proses yang boros memori nggak bikin server tumbang.
• Di PHP 8.5, tambahkan fatal_error_backtraces = 0.
• Menyembunyikan pesan error, lewat setelan display_errors atau tanda @ di kode, nggak membantu.

Kalau website-mu di belakang Cloudflare, aturan blokirnya sudah aktif. Pelanggan paket berbayar perlu memastikan Managed Ruleset, kumpulan aturan blokir siap pakai dari Cloudflare, dalam mode blokir. Tapi Cloudflare sendiri bilang ini lapisan tambahan, bukan pengganti tambalan.

Dan kalau benar-benar nggak bisa update atau masih di PHP 8.1 ke bawah, saran CISA sama dengan yang dilakukan kantor-kantor di Eropa tadi: matikan dulu sampai bisa ditambal.

Tanda yang Perlu Kamu Cari di Log

Bagian ini untuk tim IT atau vendor hosting-mu, yang bisa membuka log alias catatan aktivitas server.

Percobaan serangan sudah bermunculan. Check Point mencatat satu dari sepuluh organisasi di seluruh dunia kena percobaan serangan sejak celah ini diumumkan. Itu hitungan percobaan, bukan serangan yang berhasil.

Dari Wiz dan CISA, ini yang perlu dicari:

• Upload atau kiriman form yang aneh, lalu diikuti error batas memori PHP.
• Error 500, tanda server gagal memproses permintaan, yang muncul beruntun.
• Cookie PHPSESSID (penanda sesi pengunjung yang dipakai PHP) dengan ukuran besar atau bentuk nggak wajar.
• Proses PHP yang melayani pengunjung mati-hidup terus tanpa alasan jelas.
• Proses PHP yang tiba-tiba menjalankan shell, program untuk mengetik perintah langsung ke server, atau mengunduh file.

Menurut aku, kalau ketemu yang terakhir, update PHP saja nggak cukup. Minta orang yang paham memeriksa server itu.

Yang Bisa Kamu Lakukan Sekarang

Hari ini

• Cek versi PHP semua website kantor. Bandingkan dengan tabel di atas.
• Kalau pakai hosting, kirim pertanyaan soal dua nomor CVE tadi ke support mereka.
• Kalau belum bisa update, pasang pengaman sementara dan nyalakan WAF, penyaring serangan di depan website, kalau ada.

Minggu ini

• Data semua tempat PHP berjalan, termasuk aplikasi internal dan software vendor.
• Cari tanda serangan di log sejak 20 Oktober, hari tim PHP mengumumkan jadwal rilisnya.
• Kalau ada website di PHP 8.1 ke bawah, putuskan: upgrade, pakai dukungan vendor, atau matikan.

Bulan ini

• Jadwalkan upgrade ke PHP 8.3 atau lebih baru. PHP 8.2 berhenti dapat update 31 Desember 2026.
• Ganti password database dan API key di server yang sempat terbuka tanpa tambalan. Menurut Wiz, isi memori yang bocor bisa memuat data seperti itu.
• Bikin jadwal rutin cek update PHP, jangan nunggu berita heboh berikutnya.

Kalau kamu nggak yakin server kantormu pakai PHP versi berapa, atau ada aplikasi lama yang takut rusak kalau di-upgrade, tim KIN bisa bantu mendata dan merencanakan upgrade-nya. Hubungi KIN dengan info jenis hosting dan aplikasi yang dipakai. Jangan kirim password atau file konfigurasi lewat formulir.

Pertanyaan yang Sering Muncul

WordPress-ku sudah versi terbaru. Aman?

Belum. Celahnya ada di PHP, bukan di WordPress. WordPress terbaru di atas PHP lama tetap kena.

Website-ku di belakang Cloudflare. Masih perlu update?

Masih. Cloudflare memblokir pola serangan yang mereka kenal, tapi mereka sendiri menyarankan PHP tetap ditambal.

Masih pakai PHP 7.4. Ada tambalannya?

Nggak ada rilis resmi dari tim PHP. Ada tambalan kode sumber untuk yang biasa merakit PHP sendiri, dan sebagian distro Linux atau vendor yang menyediakan dukungan jangka panjang punya paket yang sudah ditambal. Cek ke penyedia paketmu, atau upgrade.

Apakah celah ini sudah dipakai untuk menyerang?

Percobaannya sudah ada. Cloudflare melihat lalu lintas serangan ke pelanggannya, dan Check Point mencatat percobaan di satu dari sepuluh organisasi yang mereka pantau.

Sumber

• php.net: Upcoming Critical PHP Security Release (20 Oktober 2026)
• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (21 Oktober 2026)
• php-src GitHub: GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618)
• php-src GitHub: GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619)
• php.net: Supported Versions
• php.net: PHP 5 ChangeLog
• Calif: php2shell
• Wiz Research: PHP2Shell
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Reuters (via Euronext): Factbox: Governments, companies take websites offline over PHP flaws
• W3Techs: Usage statistics of PHP
• Check Point Research: PHP2Shell: one in ten organizations impacted
• Sansec: PHP2Shell