Darurat! PHP 8.3.36 Rilis: 2 Celah Kritis Bisa Bikin Server Dibobol Tanpa Login, Segera Update!

Pada 21 Oktober 2026, tim PHP merilis PHP 8.3.36. Di hari yang sama keluar juga 8.2.35, 8.4.27, dan 8.5.12. Rilis ini menambal dua celah berstatus Critical (skor CVSS 9.2 dari 10). Keduanya berpotensi membuat orang asing menjalankan kode di server Anda tanpa perlu login.

Artikel ini ditulis untuk pemula sampai developer berpengalaman. Kita bahas dengan bahasa sehari-hari: apa yang rusak, siapa yang berisiko, apa yang harus dilakukan, dan di mana Anda bisa memeriksa sendiri faktanya (daftar sumber ada di bagian akhir).

Ringkasan 30 detik

• Masalah: cara PHP "membereskan sisa" sebuah request yang gagal ternyata bisa meninggalkan memori dalam keadaan rusak, dan keadaan rusak itu bisa dimanfaatkan penyerang.
• Dampak terburuk: Remote Code Execution (RCE), yaitu penyerang bisa menjalankan perintah di server dengan hak akses yang sama dengan aplikasi web Anda.
• Siapa terdampak: PHP sebelum 8.2.35, 8.3.36, 8.4.27, dan 8.5.12.
• Solusi utama: update PHP. Hanya itu yang disebut advisori sebagai perbaikan yang lengkap.

Istilah yang perlu Anda tahu

Celah 1: memori habis, lalu "bersih-bersih" yang keliru

(GHSA-w8hw-w9fx-j79w, CVE-2026-109618, CVSS 9.2)

Analogi. Bayangkan koki yang sedang menyiapkan pesanan lalu tiba-tiba kehabisan bahan. Ia berhenti mendadak dan meninggalkan dapur setengah berantakan. Saat petugas kebersihan masuk, ia mengira semua meja sudah rapi lalu mengambil barang dari tempat yang salah. Di PHP, "petugas kebersihan" itu adalah prosedur shutdown di akhir request.

Yang terjadi secara teknis. Saat memori habis, PHP memakai fungsi longjmp() untuk melompat keluar dan menghentikan request. Kalau kejadian itu muncul ketika sebagian memori sudah bisa dijangkau tetapi belum selesai disiapkan, lompatan tersebut meninggalkan memori dalam keadaan tidak valid. Prosedur shutdown lalu membaca atau mengambil keputusan berdasarkan data yang rusak itu, walaupun alokasi yang gagal tadi tidak berkaitan dengan data tersebut.

Bagaimana penyerang memicunya? Menurut advisori, memori habis bisa dipancing lewat request multipart (jenis request yang dipakai saat upload file/form besar) yang tetap berada dalam batas bawaan PHP. Beberapa celahnya:

• request tanpa panjang konten yang bisa dipakai,
• jumlah header per bagian tidak dibatasi,
• field file yang kosong melewati batas jumlah upload,
• nama field bersarang yang membuat pekerjaan array berlipat ganda.

Seberapa parah? Advisori menyatakan RCE tanpa autentikasi terbukti lewat HTTP terhadap Apache mod_php dengan pengaturan bawaan. Tingkat risiko per jenis server:

Jumlah worker atau trafik yang lebih besar hanya membuat penyerang butuh lebih banyak percobaan. Itu bukan perlindungan.

Cara tim PHP memperbaikinya. Penggunaan longjmp() untuk kasus OOM dihapus. Gantinya ada dua lapis: soft OOM yang ditangani rapi pada titik aman berikutnya, dan _exit() langsung kalau pemakaian memori sudah melewati ambang batas keras.

Celah 2: sisa data dari request sebelumnya

(GHSA-6wmf-4rv5-p3rp, CVE-2026-109619, CVSS 9.2)

Analogi. Seperti papan tulis di ruang rapat yang belum dihapus. Rapat berikutnya masuk, tidak sadar ada tulisan lama, lalu mengikuti petunjuk yang sudah tidak berlaku. Di PHP, satu worker melayani banyak request. Kalau data milik request lama masih "ditunjuk" setelah memorinya dibebaskan, request berikutnya yang memakai petunjuk itu akan membaca memori yang sudah bukan miliknya (disebut use-after-free).

Kapan ini terjadi? Misalnya saat sebuah fatal error (termasuk OOM atau batas waktu eksekusi habis) memotong request sebelum pembersihan selesai. Penyerang butuh dua langkah: satu request yang meninggalkan data basi, lalu satu request lain yang mengenai worker yang sama. Advisori mengonfirmasi dua jalur pemakai data basi itu: pesan diagnostik INI yang muncul sebelum request diinisialisasi, dan penanganan progres upload pada sesi. Kasus terkuat yang diperagakan memakai fitur fatal_error_backtraces di PHP 8.5.

Dampaknya: kebocoran isi memori dan, dengan susunan heap yang tepat, eksekusi kode dari jarak jauh tanpa login. Advisori menyebut eksploitasi memerlukan penyiapan yang cermat, sehingga bukan serangan yang pasti berhasil. Tetapi satu-satunya mitigasi yang andal tetap update.

Apakah server saya terdampak? Cara mengeceknya

1. Cek versi PHP. Di terminal server: php -v. Kalau Anda memakai beberapa versi, cek yang dipakai web server (mis. php8.3 -v atau lihat phpinfo()). Kalau angkanya di bawah 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sesuai cabang Anda, Anda terdampak.
2. Cek cara PHP dijalankan. mod_php di Apache adalah yang paling berisiko. PHP-FPM tetap harus di-update.
3. Pengguna hosting bersama (shared hosting)? Anda biasanya tidak bisa meng-update sendiri. Buka panel hosting (cPanel, Plesk, dan sejenisnya) atau tanyakan ke penyedia kapan versi 8.3.36 dipasang. Kalau ada pilihan "Select PHP Version", pilih versi terbaru yang tersedia.
4. Aplikasi Laravel, WordPress, dan sejenisnya tidak perlu diubah kodenya. Celah ini ada di PHP-nya, bukan di aplikasi. Yang diupdate adalah PHP di server.

Cara update

Ubuntu/Debian dengan repositori Ondřej Surý (PPA):

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli
sudo systemctl reload php8.3-fpm
php8.3 -v

Kalau memakai ekstensi lain (mis. php8.3-mysql, php8.3-pgsql), paketnya perlu ikut di-upgrade supaya versinya seragam. Pada Apache, ganti perintah reload dengan sudo systemctl reload apache2.

macOS (Homebrew):

brew upgrade php@8.3
php -v

Docker: ganti tag image ke php:8.3.36-... (varian yang Anda pakai), bangun ulang image, lalu deploy ulang container.

Catatan: versi terbaru kadang butuh waktu untuk muncul di repositori paket distro Anda. Kalau apt masih menawarkan versi yang lebih lama, tunggu dan coba lagi. Cek tanggal dan versi di halaman resmi php.net.

Kalau belum bisa update sekarang

Langkah di bawah hanya mengurangi risiko, bukan menutup celahnya. Update tetap wajib.

• Batasi post_max_size secara konservatif, dan batasi ukuran request yang sudah didekode di sisi depan (Nginx, load balancer, atau proxy).
• Hindari RLIMIT_AS dan RLIMIT_DATA, karena bisa memicu jalur yang rentan.
• Jika Anda tidak memakai fitur upload progress pada sesi, matikan dengan session.upload_progress.enabled=0, lalu restart semua worker.
• Jika memakai PHP 8.5, set fatal_error_backtraces=0.
• Untuk PHP-FPM, menurunkan pm.max_requests hingga 1 mengurangi kesempatan data basi dipakai ulang, dengan konsekuensi performa lebih rendah.

Bonus: rilis 8.3.35 (24 September 2026) juga penting

Kalau server Anda masih di 8.3.34 atau lebih lama, update ke 8.3.36 otomatis mencakup semua perbaikan di 8.3.35. Beberapa yang paling relevan untuk pemakaian sehari-hari:

Rilis 8.3.35 juga memuat perbaikan lain, antara lain heap buffer overflow pada pencocokan wildcard OpenSSL (CVE-2026-91767), integer overflow pada Phar (CVE-2026-6103), rekursi tanpa batas dan overflow pada SOAP (CVE-2026-91765 dan CVE-2025-14181), serta pembacaan di luar batas pada stream wrapper (CVE-2026-93682). Daftar lengkapnya ada di berkas NEWS pada bagian sumber.

Pertanyaan yang sering muncul

Apakah update patch akan merusak aplikasi saya? Kecil kemungkinannya. Patch release hanya berisi perbaikan bug dan keamanan, tanpa perubahan fitur. Tetap uji di server staging bila Anda punya, dan siapkan cadangan sebelum update.

Apakah firewall atau WAF cukup? Tidak. Itu bisa membantu menyaring sebagian request, tetapi advisori menyebut update sebagai satu-satunya perbaikan yang lengkap.

Apakah harus pindah ke versi mayor baru (mis. 8.4 atau 8.5)? Tidak. Cukup naik ke versi patch terbaru pada cabang yang Anda pakai (8.3.36 untuk cabang 8.3). Pastikan cabang Anda masih mendapat dukungan keamanan.

Setelah update, bagaimana memastikannya berhasil? Jalankan php -v, reload PHP-FPM atau Apache, lalu buka beberapa halaman utama situs dan periksa log error.

Sumber

Seluruh fakta dalam artikel ini diambil dari sumber primer berikut. Silakan diperiksa langsung:

• GitHub Security Advisory php-src: RCE via OOM corruption (GHSA-w8hw-w9fx-j79w, CVE-2026-109618), 21 Oktober 2026
• GitHub Security Advisory php-src: RCE via stale global state (GHSA-6wmf-4rv5-p3rp, CVE-2026-109619), 21 Oktober 2026
• GitHub Security Advisory php-src: IPv6 ACL bypass in PHP-FPM listen.allowed_clients (GHSA-62xp-839h-2637, CVE-2026-91768), 24 September 2026
• GitHub Security Advisory php-src: TLS hostname verification falls back to CN after SAN mismatch (GHSA-vvx9-73fr-5jjx, CVE-2026-91769), 24 September 2026
• GitHub Security Advisory php-src: Cross-origin credential leak in HTTP stream wrapper redirects (GHSA-fpwc-w8rq-cr92, CVE-2026-91766), 24 September 2026
• php-src: berkas NEWS cabang PHP-8.3 (daftar perbaikan 8.3.36 dan 8.3.35)
• php.net: ChangeLog PHP 8

Catatan: artikel ini disusun pada 22 Oktober 2026 dari sumber di atas. Advisori dan changelog bisa diperbarui, jadi cek ulang sumber primernya sebelum dijadikan acuan atau dikutip.