Waspada bugs di PHP

Pada Oktober 2026, komunitas teknologi dan pengelola website di seluruh dunia dikejutkan oleh temuan dua kerentanan keamanan kritis pada PHP, bahasa pemrograman server-side yang digunakan secara luas untuk membangun website dan aplikasi web.

Kerentanan yang ramai dibicarakan dengan sebutan PHP2Shell tersebut dapat memungkinkan penyerang menjalankan kode dari jarak jauh pada server yang rentan, bahkan tanpa harus memiliki akun atau melakukan login terlebih dahulu. Kondisi ini membuat masalah tersebut jauh lebih serius dibandingkan bug biasa yang hanya menyebabkan tampilan website rusak atau aplikasi berhenti bekerja.

Pada 21 Oktober 2026, tim pengembang PHP merilis pembaruan keamanan untuk memperbaiki kedua kerentanan tersebut. Pengguna PHP dianjurkan segera memperbarui instalasi mereka ke versi yang telah diperbaiki.

Informasi resmi mengenai pembaruan tersebut dapat dibaca melalui website resmi PHP.
1. Apa yang sebenarnya terjadi?

Kasus PHP2Shell berkaitan dengan dua kerentanan kritis pada inti PHP (PHP core), bukan sekadar masalah pada plugin, tema, atau framework tertentu.

Kedua kerentanan tersebut terdaftar dengan identitas:

    CVE-2026-109618: berkaitan dengan kerusakan pengelolaan memori ketika PHP mengalami kondisi kehabisan memori (out-of-memory).

    CVE-2026-109619: berkaitan dengan kondisi internal yang masih menggunakan status atau referensi memori lama setelah memori tersebut dilepaskan.

Keduanya memiliki tingkat keparahan CVSS 9,2 dari 10 menurut informasi yang dipublikasikan terkait rilis keamanan tersebut.

Risiko utamanya adalah remote code execution (RCE), yaitu kemungkinan penyerang menjalankan kode pada server dari jarak jauh melalui jalur serangan yang memanfaatkan kerentanan tersebut.

Artinya, risiko tidak hanya berkaitan dengan satu halaman website. Jika server berhasil dieksploitasi, dampaknya dapat menjalar ke file aplikasi, data yang dapat diakses oleh proses PHP, konfigurasi, dan layanan lain yang memiliki keterkaitan dengan server tersebut.

Penting untuk dipahami bahwa ditemukannya kerentanan tidak berarti setiap website yang menggunakan PHP telah diretas. Namun, website yang menjalankan instalasi rentan perlu segera ditangani.
2. Apakah benar terjadi kebocoran PHP?

Istilah “kebocoran PHP” yang beredar perlu dipahami dengan tepat.

Dalam kasus ini, perhatian publik muncul setelah informasi mengenai kerentanan kritis beredar sebelum jadwal pengungkapan dan pembaruan keamanan yang direncanakan. Situasi tersebut mempercepat proses pengumuman dan penerbitan patch oleh tim PHP.

Jadi, isu utamanya bukan sekadar bahwa kode sumber PHP bocor dan seluruh website otomatis terbuka. Kasus ini berkaitan dengan informasi tentang kelemahan keamanan pada PHP yang beredar sebelum proses pengungkapan terkoordinasi selesai.

Ketika informasi kerentanan diketahui pihak yang tidak bertanggung jawab sebelum banyak server diperbarui, terdapat risiko bahwa penyerang akan mencoba membuat eksploitasi untuk memanfaatkan kelemahan tersebut.

Inilah alasan pembaruan keamanan menjadi sangat penting. Setelah perbaikan dipublikasikan, pihak yang mempelajari perubahan kode dapat lebih mudah memahami bagian yang sebelumnya bermasalah dan mengembangkan metode serangan terhadap server yang belum diperbarui.

Kronologi dan penjelasan proses pengungkapan dapat dibaca dalam penjelasan resmi PHP Foundation.
3. Mengapa kerentanan tersebut bisa terjadi?

PHP merupakan perangkat lunak yang kompleks. Di balik proses sederhana seperti membuka halaman website, PHP menangani permintaan HTTP, memori, sesi pengguna, pemrosesan data, dan berbagai operasi internal lainnya.

Dua kerentanan PHP2Shell berkaitan dengan pengelolaan memori dan status internal saat permintaan diproses.
A. Kesalahan penanganan kondisi kehabisan memori

Kerentanan pertama berkaitan dengan kondisi ketika PHP mengalami kehabisan memori pada saat data internal suatu permintaan belum sepenuhnya disiapkan.

Dalam kondisi tertentu, proses pembersihan internal dapat memperlakukan data yang belum valid seolah-olah data tersebut sudah siap digunakan. Kesalahan ini berpotensi menyebabkan kerusakan memori dan membuka jalan bagi eksekusi kode dari jarak jauh.
B. Penggunaan status internal yang sudah tidak valid

Kerentanan kedua berkaitan dengan status internal yang seharusnya sudah tidak digunakan lagi setelah memori dilepaskan.

Jika status tersebut masih dapat digunakan oleh permintaan berikutnya sebelum diinisialisasi kembali dengan benar, proses PHP dapat mengakses referensi yang sudah tidak valid. Dalam kondisi yang dapat dieksploitasi, hal ini juga dapat menyebabkan eksekusi kode.

Kedua masalah tersebut berada pada lapisan inti PHP. Karena itu, memperbaiki kode aplikasi saja tidak cukup untuk menjamin bahwa kerentanan pada runtime PHP telah diatasi.
4. Versi PHP apa yang harus diperbarui?

Tim PHP merilis versi keamanan pada 21 Oktober 2026 untuk memperbaiki kedua kerentanan tersebut.
Cabang PHP    Versi perbaikan
PHP 8.5    8.5.12
PHP 8.4    8.4.27
PHP 8.3    8.3.36
PHP 8.2    8.2.35

Gunakan versi perbaikan yang sesuai dengan cabang PHP yang digunakan, atau versi keamanan yang lebih baru apabila telah tersedia.

Perhatian: PHP 8.5.11 bukan versi perbaikan untuk dua kerentanan ini. Jika website Anda menggunakan PHP 8.5.11, tingkatkan setidaknya ke PHP 8.5.12 atau rilis keamanan yang lebih baru.

Pengguna PHP 8.4, 8.3, dan 8.2 juga tidak harus langsung berpindah ke PHP 8.5 hanya untuk mendapatkan perbaikan ini. Mereka dapat menggunakan versi perbaikan pada cabang masing-masing, selama versi tersebut masih sesuai dengan dukungan dan kebijakan keamanan penyedia sistem mereka.

Sementara itu, PHP 8.1 dan versi yang lebih lama sudah tidak menerima pembaruan keamanan dari proyek PHP utama. Beberapa penyedia sistem operasi atau layanan dukungan jangka panjang mungkin menyediakan perbaikan tambahan, sehingga status dukungan perlu diperiksa secara terpisah.

Rujukan versi dan pengumuman resmi: PHP Security Advisory.
5. Bagaimana cara mengantisipasi dan melindungi website?

Berikut beberapa langkah yang perlu dilakukan pemilik website, administrator server, dan pengembang aplikasi.
A. Periksa versi PHP yang benar-benar digunakan website

Jangan hanya mengandalkan versi PHP yang tampil pada terminal atau komputer lokal.

Pada hosting, versi PHP untuk website dapat berbeda dari versi PHP CLI. Website juga dapat menggunakan versi berbeda untuk subdomain, direktori, atau aplikasi yang terpisah.

Jika menggunakan cPanel, periksa versi yang ditetapkan melalui fitur seperti MultiPHP Manager atau pengaturan PHP yang disediakan oleh hosting.

Pastikan versi yang berjalan pada permintaan website benar-benar sudah diperbarui. Setelah perubahan, verifikasi kembali menggunakan metode yang aman dan sesuai dengan lingkungan hosting. Jika menggunakan halaman phpinfo() untuk pemeriksaan sementara, batasi aksesnya dan hapus halaman tersebut setelah selesai.
B. Perbarui PHP ke versi yang telah diperbaiki

Ini merupakan tindakan paling penting.

Jika menggunakan shared hosting, tanyakan kepada penyedia hosting apakah versi PHP yang tersedia sudah mencakup perbaikan keamanan tersebut. Jika versi yang diperlukan belum tersedia, minta jadwal pembaruan atau petunjuk migrasi yang aman.

Jika mengelola server sendiri, perbarui paket PHP melalui sumber paket resmi atau vendor yang digunakan. Untuk instalasi PHP-FPM, Apache, atau LiteSpeed, pastikan layanan terkait telah memuat runtime yang diperbarui sesuai prosedur sistem.

Jangan menganggap mengganti nomor versi di konfigurasi aplikasi sudah cukup. Pembaruan harus benar-benar mengganti instalasi PHP yang menjalankan permintaan website.
C. Lakukan backup sebelum pembaruan

Sebelum mengubah versi PHP, lakukan backup file aplikasi, database, dan konfigurasi penting.

Backup berguna untuk pemulihan jika pembaruan menimbulkan masalah kompatibilitas. Namun, backup bukan pengganti patch keamanan.

Simpan salinan backup di lokasi yang terpisah dan terlindungi agar tidak mudah diakses melalui website.
D. Uji kompatibilitas aplikasi

Versi PHP yang lebih baru dapat mengubah perilaku fungsi tertentu atau menampilkan peringatan yang sebelumnya tidak terlihat.

Aplikasi lama mungkin menggunakan fungsi yang sudah tidak didukung, sintaks yang tidak kompatibel, atau library yang belum siap untuk versi PHP terbaru.

Sebelum diterapkan secara luas, uji aplikasi pada lingkungan staging jika tersedia. Periksa proses login, formulir, upload file, laporan, integrasi API, pencetakan, dan fungsi database.

Jika hosting menyediakan beberapa versi PHP, pilih versi yang telah diperbaiki dan didukung, lalu lakukan pengujian fungsional sebelum mengalihkan seluruh trafik produksi.
E. Periksa indikasi kompromi

Pembaruan PHP melindungi sistem dari kerentanan yang diperbaiki, tetapi tidak otomatis membersihkan server yang mungkin sudah disusupi.

Jika server menggunakan versi rentan, periksa log akses web, log sistem, aktivitas akun, perubahan file yang tidak dikenal, dan proses yang berjalan tidak semestinya. Prioritaskan pemeriksaan terhadap file yang baru berubah, akun yang tidak dikenal, dan aktivitas administratif yang mencurigakan.

Jika terdapat indikasi kompromi, jangan hanya menghapus satu file yang mencurigakan. Isolasi sistem sesuai prosedur insiden, simpan log dan bukti yang relevan, periksa cakupan akses penyerang, dan lakukan pemulihan dari sumber yang telah diverifikasi bersih.

Apabila kredensial diduga terekspos, ganti kredensial terkait setelah jalur akses diamankan.
F. Terapkan keamanan berlapis

Selain memperbarui PHP, pemilik website sebaiknya menerapkan praktik keamanan berikut:

    Gunakan versi PHP dan library yang masih mendapatkan pembaruan keamanan.

    Batasi hak akses file dan direktori sesuai kebutuhan aplikasi.

    Jangan menyimpan file rahasia atau backup pada direktori publik.

    Lindungi file konfigurasi, kredensial database, dan token API.

    Terapkan autentikasi yang kuat, pembatasan akses administratif, serta pencatatan aktivitas.

    Lakukan backup berkala dan uji pemulihannya.

    Pantau pengumuman keamanan resmi dari PHP, penyedia hosting, framework, dan library yang digunakan.

Web Application Firewall (WAF) dan sistem pemantauan dapat membantu sebagai lapisan pertahanan tambahan. Namun, keduanya tidak boleh dianggap sebagai pengganti pembaruan PHP.
6. Apakah aplikasi PHP lama harus langsung dipindahkan ke PHP 8.5?

Tidak selalu.

Ada perbedaan antara memperbarui patch keamanan dan melakukan migrasi ke cabang PHP yang berbeda.

Jika aplikasi menggunakan PHP 8.4, misalnya, pembaruan ke versi 8.4.27 merupakan jalur untuk mendapatkan perbaikan pada cabang tersebut. Tidak semua aplikasi harus langsung berpindah ke PHP 8.5.

Namun, jika aplikasi masih menggunakan PHP 7.x atau PHP 8.1, persoalannya lebih luas. Versi tersebut sudah berada di luar dukungan keamanan utama proyek PHP. Pengelola website perlu menyusun rencana migrasi ke versi yang didukung atau memastikan ada penyedia yang memberikan perbaikan keamanan untuk instalasi tersebut.

7. Kesimpulan

Kasus PHP2Shell menjadi pengingat bahwa keamanan website tidak hanya ditentukan oleh kualitas kode yang dibuat pengembang, tetapi juga oleh keamanan runtime dan lingkungan server tempat aplikasi dijalankan.

Dua kerentanan kritis yang diumumkan pada Oktober 2026 menunjukkan bahwa kesalahan pada pengelolaan memori di tingkat inti bahasa pemrograman dapat berpotensi berdampak luas.

Karena itu, pemilik website dan administrator server sebaiknya segera memeriksa versi PHP yang digunakan, memasang pembaruan yang sesuai, menguji kompatibilitas aplikasi, dan memeriksa indikasi kompromi apabila menggunakan versi yang rentan.

Jangan menunda pembaruan keamanan hanya karena website masih terlihat berjalan normal. Website yang dapat dibuka tanpa masalah belum tentu menggunakan komponen yang aman.

Langkah paling tepat adalah memeriksa versi PHP yang benar-benar berjalan, memperbaruinya ke rilis yang telah diperbaiki, dan memastikan seluruh aplikasi tetap berfungsi setelah pembaruan.