Waduh! Semua Versi PHP Terkena 2 CVE Kritis, Segera Update

Dua celah keamanan kritis pada PHP terungkap pada 21 Oktober 2026. Keduanya berpotensi memungkinkan penyerang menjalankan kode dari jarak jauh tanpa autentikasi, sehingga administrator server dan developer PHP perlu segera memeriksa versi yang digunakan dan memasang pembaruan keamanan.

Komunitas developer PHP perlu meningkatkan kewaspadaan. Pada 21 Oktober 2026, tim keamanan PHP mengumumkan dua kerentanan kritis yang dapat menyebabkan Remote Code Execution (RCE), yaitu kemampuan penyerang menjalankan kode pada server dari jarak jauh. Kedua kerentanan tersebut tercatat sebagai CVE-2026-109618 dan CVE-2026-109619.

Situasi ini menjadi perhatian serius karena PHP masih digunakan untuk menjalankan berbagai aplikasi web, mulai dari WordPress, Drupal, Laravel, hingga aplikasi backend yang dikembangkan secara khusus. Dampaknya tidak hanya berkaitan dengan kode aplikasi, tetapi juga dengan lingkungan runtime PHP yang memproses permintaan HTTP.

Berdasarkan pengumuman resmi tim PHP, pembaruan keamanan telah dirilis untuk sejumlah versi yang masih didukung. Pengelola server pun sangat disarankan untuk segera melakukan pembaruan, bukan sekadar mengandalkan konfigurasi keamanan tambahan.

Dua CVE Kritis yang Mengancam Keamanan Server PHP

Kedua kerentanan ini memiliki mekanisme berbeda, tetapi sama-sama berkaitan dengan pengelolaan memori dan kondisi internal PHP ketika menangani permintaan pengguna.

1. CVE-2026-109618: RCE melalui kerusakan saat kehabisan memori

Kerentanan pertama berkaitan dengan kondisi Out of Memory (OOM), yaitu ketika PHP mengalami kegagalan alokasi memori saat memproses permintaan.

Dalam kondisi tertentu, kegagalan tersebut dapat menghentikan proses PHP ketika data internal permintaan belum selesai diinisialisasi. Ketika proses pembersihan berjalan, PHP berpotensi memperlakukan data yang belum valid seolah-olah sudah siap digunakan.

Kondisi ini dapat memicu kerusakan memori dan membuka peluang bagi penyerang untuk menjalankan kode pada server.

Risikonya perlu diperhatikan karena pemicunya berkaitan dengan mekanisme internal PHP, bukan semata-mata kesalahan penulisan kode pada aplikasi. Oleh sebab itu, aplikasi yang terlihat normal sekalipun belum tentu terlindungi apabila runtime PHP yang digunakan masih rentan.

2. CVE-2026-109619: RCE akibat status internal yang sudah tidak valid

Kerentanan kedua berkaitan dengan stale global state, yaitu kondisi ketika status internal yang seharusnya hanya berlaku selama satu permintaan masih tersimpan setelah memori yang mendukungnya dilepaskan.

Masalah muncul ketika proses PHP berikutnya menggunakan kembali status tersebut sebelum proses inisialisasi normal selesai. Akibatnya, PHP dapat mengakses memori yang sudah tidak valid atau telah digunakan untuk keperluan lain.

Dalam kondisi yang memenuhi persyaratan eksploitasi, kesalahan tersebut dapat berkembang menjadi use-after-free dan memungkinkan eksekusi kode dari jarak jauh.

Menurut advisory keamanan PHP, permintaan yang memicu kondisi tertentu dan permintaan berikutnya dapat diproses oleh worker yang sama. Mekanisme ini membuat kerentanan berkaitan dengan siklus hidup worker dan pengelolaan status internal PHP.

Kedua CVE tersebut sama-sama berisiko tinggi karena dapat membuka jalan menuju kompromi server tanpa mengharuskan penyerang memiliki akun terlebih dahulu.

Apakah Benar Semua Versi PHP Terkena?

Ada hal penting yang perlu diluruskan. Sejumlah laporan keamanan menyebut bahwa kerentanan ini berdampak pada PHP versi lama hingga PHP 8.x. Namun, hal tersebut tidak berarti setiap versi telah diuji dan terbukti dapat dieksploitasi dalam seluruh konfigurasi.

Menurut pemberitahuan DigitalOcean, cakupan versi yang perlu diperhatikan dimulai dari PHP 5. Sementara itu, PHP secara resmi menyediakan rilis perbaikan untuk empat cabang versi yang masih didukung pada saat pengumuman.

Berikut versi yang perlu menjadi acuan administrator server:

Versi PHPRilis perbaikanPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35

Versi-versi tersebut dirilis pada 21 Oktober 2026 untuk memperbaiki kedua kerentanan.

Sementara itu, PHP 8.1 dan versi yang lebih lama tidak lagi mendapatkan pembaruan keamanan reguler dari proyek PHP. Beberapa vendor distribusi Linux atau penyedia dukungan jangka panjang mungkin menyediakan backport patch, yaitu menerapkan perbaikan keamanan pada versi lama tanpa harus menggunakan rilis upstream terbaru.

Karena itu, pengguna PHP versi lama perlu memeriksa status dukungan dari vendor masing-masing. Jika tidak tersedia perbaikan yang sesuai, migrasi ke versi PHP yang masih didukung menjadi pilihan yang lebih aman.

Server dan Aplikasi Apa Saja yang Berisiko?

Pemberitahuan resmi PHP menyebut bahwa instalasi PHP yang melayani permintaan web perlu diperiksa, termasuk lingkungan berikut:

• Apache dengan mod_php, yang disebut memiliki risiko tertinggi berdasarkan eksploitasi yang telah didemonstrasikan.

• PHP-FPM, yang umum digunakan bersama Nginx maupun Apache.

• php-cgi, yang menjalankan PHP melalui mekanisme CGI.

• FrankenPHP, yang mengintegrasikan runtime PHP dengan server web.

• LiteSpeed, termasuk lingkungan hosting yang menggunakannya untuk menjalankan aplikasi PHP.

Artinya, administrator tidak cukup hanya memeriksa satu website. Seluruh instalasi PHP pada server perlu diinventarisasi, termasuk aplikasi lama, panel administrasi, container, serta layanan yang mungkin menggunakan runtime PHP tersendiri.

Pengguna WordPress, misalnya, perlu memeriksa versi PHP yang digunakan oleh hosting mereka. Memperbarui WordPress atau plugin saja tidak otomatis memperbaiki kerentanan pada runtime PHP.

Hal serupa berlaku bagi developer Laravel dan aplikasi PHP khusus. Pembaruan dependency aplikasi tidak selalu sama dengan pembaruan interpreter PHP yang berjalan di server.

Mengapa RCE Tanpa Autentikasi Sangat Berbahaya?

Remote Code Execution merupakan salah satu jenis kerentanan yang paling serius karena dapat memungkinkan penyerang menjalankan instruksi pada sistem target.

Apabila eksploitasi berhasil, dampak yang mungkin terjadi antara lain:

• Akses terhadap data yang dapat dibaca oleh akun proses PHP.

• Perubahan file aplikasi atau konten website.

• Penyalahgunaan kredensial dan konfigurasi yang dapat diakses oleh proses tersebut.

• Penanaman kode berbahaya atau mekanisme akses lanjutan, bergantung pada hak akses dan konfigurasi server.

• Gangguan layanan yang memengaruhi ketersediaan website.

Meski demikian, keberhasilan eksploitasi tidak otomatis berarti penyerang memperoleh akses root atau kendali penuh atas seluruh server. Dampaknya bergantung pada hak akses worker PHP, isolasi proses, konfigurasi sistem, dan perlindungan tambahan yang diterapkan.

Hal yang membuat situasi ini semakin mendesak adalah potensi eksploitasi tanpa autentikasi. Penyerang tidak harus masuk ke dashboard administrator terlebih dahulu apabila jalur serangan yang rentan dapat dijangkau dari internet.

Apa yang Harus Dilakukan Administrator dan Developer?

Langkah paling penting adalah memperbarui runtime PHP ke versi yang telah mendapatkan perbaikan keamanan.

1. Periksa versi PHP yang sedang digunakan

Jalankan perintah berikut pada server:

php -v

Namun, perlu diingat bahwa perintah tersebut biasanya menampilkan versi PHP CLI. Versi PHP yang digunakan website melalui PHP-FPM atau modul Apache bisa berbeda.

Untuk memeriksa konfigurasi layanan web, periksa juga versi paket PHP yang terpasang, konfigurasi pool PHP-FPM, serta versi runtime yang benar-benar digunakan oleh aplikasi.

2. Perbarui PHP ke versi yang sudah diperbaiki

Gunakan versi perbaikan yang sesuai dengan cabang PHP:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

Untuk pengguna Linux, gunakan paket keamanan resmi dari distribusi atau vendor hosting. Jangan langsung mengganti paket dari sumber yang tidak tepercaya karena perubahan runtime dapat memengaruhi ekstensi, dependency, dan kompatibilitas aplikasi.

Setelah pembaruan, restart atau reload layanan yang relevan sesuai prosedur platform agar worker lama tidak terus menjalankan kode yang rentan.

3. Periksa semua website dan container

Jika satu server menjalankan beberapa website, periksa setiap lingkungan PHP yang digunakan. Pada infrastruktur berbasis Docker, pastikan image dasar PHP telah diperbarui dan container dibuat ulang menggunakan image yang sudah mengandung patch.

Memperbarui PHP di host tidak otomatis memperbarui PHP yang berjalan di dalam container.

4. Jika belum bisa memperbarui, kurangi paparan sementara

Tim PHP memberikan sejumlah langkah mitigasi untuk mengurangi risiko pada jalur serangan tertentu. Contohnya meliputi penonaktifan session.upload_progress.enabled, serta penonaktifan fatal_error_backtraces pada PHP 8.5.

Konfigurasi dan penerapannya harus mengikuti advisory resmi. Beberapa langkah lain juga dapat membatasi kondisi kehabisan memori dan ukuran permintaan yang diproses.

Namun, langkah-langkah tersebut bukan pengganti pembaruan keamanan. Keduanya tidak menjamin semua jalur eksploitasi dapat ditutup, sehingga administrator tetap harus merencanakan pembaruan sesegera mungkin.

5. Periksa log dan aktivitas server

Setelah melakukan pembaruan, periksa log server web, PHP-FPM, dan sistem operasi untuk mencari aktivitas yang tidak biasa. Jika server diduga telah dieksploitasi, pembaruan PHP saja belum cukup.

Administrator perlu melakukan investigasi terhadap kemungkinan perubahan file, akun atau proses mencurigakan, akses yang tidak wajar, serta paparan kredensial. Jika ditemukan indikasi kompromi, lakukan prosedur respons insiden yang sesuai.

Kesimpulan: Jangan Menunggu Website Diserang

Dua kerentanan kritis PHP yang diumumkan pada 21 Oktober 2026 menjadi pengingat bahwa keamanan website tidak hanya bergantung pada framework, plugin, atau kode aplikasi yang digunakan. Runtime PHP yang memproses permintaan web juga harus selalu mendapatkan pembaruan keamanan.

CVE-2026-109618 berkaitan dengan kerusakan saat penanganan kehabisan memori, sedangkan CVE-2026-109619 berkaitan dengan penggunaan kembali status internal yang sudah tidak valid. Keduanya berpotensi memungkinkan eksekusi kode jarak jauh tanpa autentikasi dalam kondisi yang memenuhi persyaratan eksploitasi.

Bagi administrator server, developer Laravel, pengelola WordPress, dan penyedia hosting, prioritasnya jelas: inventarisasi instalasi PHP, pasang versi yang sudah diperbaiki, restart layanan yang terdampak, dan periksa kemungkinan kompromi.

Jangan menganggap server aman hanya karena website masih bisa dibuka seperti biasa. Kerentanan pada runtime dapat tetap ada meskipun aplikasi terlihat berjalan normal.

Referensi:

1. PHP.net — Security Advisory: Critical Remote Code Execution Vulnerabilities, Update Now

2. GitHub Security Advisory — CVE-2026-109618: RCE via OOM Corruption

3. GitHub Security Advisory — CVE-2026-109619: RCE via Stale Global State

4. DigitalOcean — Critical PHP RCE Vulnerabilities: Patch Now

5. cPanel — Critical PHP Security Release: CVE-2026-109618 and CVE-2026-109619