PHP Sudah EOL, Bisakah Mendapatkan Patch Keamanan Tanpa Upgrade?

PHP yang sudah End of Life (EOL) masih mungkin mendapatkan patch keamanan tanpa migrasi ke cabang PHP yang lebih baru. Perbaikannya dapat berasal dari paket distribusi Linux, penyedia dukungan jangka panjang, atau patch source code yang kemudian dibangun ulang. Namun, tidak semua versi, kerentanan, atau instalasi PHP mempunyai jalur patch yang sama. Keberadaan patch juga harus diperiksa untuk kerentanan tertentu, bukan disimpulkan hanya dari nama layanan vendor.

Hal ini penting bagi pengelola website lama yang belum kompatibel dengan PHP terbaru. Mengganti PHP 7.4 dengan PHP 8.4, misalnya, dapat memerlukan perubahan plugin, framework, library, atau kode aplikasi. Sebaliknya, memperbarui paket PHP 7.4 yang sama dengan perbaikan hasil backport dapat memberi waktu untuk merencanakan migrasi. Proses tersebut tidak otomatis menuntut upgrade MySQL atau MariaDB, walaupun ekstensi database, dependency, dan fungsi aplikasi tetap harus diuji setelah pembaruan.

Apa arti EOL bagi patch keamanan PHP?

Menurut jadwal dukungan resmi PHP, setiap cabang PHP mendapat masa dukungan aktif dan kemudian dukungan perbaikan keamanan. Setelah mencapai EOL, proyek PHP tidak lagi menjanjikan rilis pembaruan reguler untuk cabang tersebut. Per 23 Oktober 2026, PHP 8.1 dan versi yang lebih lama sudah EOL, sedangkan PHP 8.2 masih menerima perbaikan keamanan hingga 31 Desember 2026.

Istilah tidak mendapat dukungan upstream tidak sama dengan mustahil diperbaiki. Upstream adalah proyek PHP yang merilis interpreter resmi. Distribusi Linux dan perusahaan penyedia dukungan tambahan dapat mengambil perubahan keamanan, menyesuaikannya dengan cabang lama, lalu menerbitkan paket baru. Proses inilah yang disebut security backport. Nomor versi PHP utama bisa tetap sama, sementara nomor revisi paket vendor berubah.

Contoh aktualnya muncul dalam rilis keamanan 21 Oktober 2026 untuk CVE-2026-109618 dan CVE-2026-109619. PHP resmi menerbitkan versi 8.2.35, 8.3.36, 8.4.27, dan 8.5.12. Untuk PHP 7.4, 8.0, dan 8.1 yang sudah EOL, tim keamanan PHP justru menyediakan minimal source backport, bukan rilis PHP resmi baru lengkap dengan paket siap instal. Pengumuman dan tautan menuju cabang source tersedia di advisory PHP tanggal 21 Oktober 2026.

Tiga jalur mendapatkan patch untuk PHP EOL

Sebelum mencari paket, periksa siapa yang memasang dan mengelola PHP. PHP bawaan Ubuntu melalui APT, PHP alternatif yang dikelola penyedia hosting, dan PHP yang dikompilasi oleh control panel adalah instalasi berbeda. Patch untuk satu jenis instalasi tidak boleh langsung diterapkan ke jenis lain walaupun keduanya sama-sama menampilkan PHP 7.4 atau PHP 8.1.

Ketiganya bisa mempertahankan cabang PHP aplikasi, tetapi tidak identik dalam biaya maupun tanggung jawab. Paket vendor umumnya lebih praktis bagi pengelola server yang menggunakan repositori sesuai dukungannya. Source backport lebih cocok untuk operator yang memiliki kendali penuh atas proses build PHP dan sanggup menguji hasilnya. Mengunduh sebuah file patch lalu mengunggahnya ke direktori WordPress bukan cara menambal kerentanan interpreter.

Bukti konkret: Ubuntu tetap menambal PHP 8.1 dan PHP 7.4

Canonical menerbitkan USN-8948-1 pada 21 Oktober 2026 untuk dua celah tersebut. Pada Ubuntu 22.04 LTS, paket php8.1-fpm yang diperbaiki mempunyai versi 8.1.2-1ubuntu2.28. Nomor dasarnya tetap PHP 8.1 meskipun dukungan upstream PHP 8.1 sudah berakhir. Ini contoh nyata paket PHP yang diperbaiki tanpa memindahkan aplikasi ke PHP 8.2, 8.3, atau 8.4.

Untuk sistem lebih lama, USN-8948-2 mencantumkan perbaikan PHP 7.4 pada Ubuntu 20.04 LTS melalui Ubuntu Pro/ESM, termasuk paket php7.4-fpm versi 7.4.3-4ubuntu2.29+esm5. Advisory yang sama mencantumkan paket untuk PHP 7.2 pada Ubuntu 18.04 LTS, PHP 7.0 pada Ubuntu 16.04 LTS, dan PHP 5.5 pada Ubuntu 14.04 LTS, sesuai skema dukungan masing-masing. Jangan menganggap paket Ubuntu Pro itu otomatis tersedia bagi server yang memakai repositori PHP pihak ketiga atau PHP hasil kompilasi panel.

Perbedaan nomor versi sering membuat pengguna keliru. PHP 8.1.2-1ubuntu2.28 bukan PHP upstream 8.1.2 yang dibiarkan tanpa perubahan sejak rilis awal. Sufiks paket Ubuntu menandai revisi paket distribusi. Status keamanan untuk CVE tertentu harus ditentukan dari advisory vendor dan changelog paket, bukan semata-mata mencocokkan tiga digit versi dengan daftar rilis PHP.net.

Apakah ada perusahaan pihak ketiga yang menyediakan patch PHP EOL?

Ada, dan layanannya terdokumentasi secara publik. Salah satu contohnya adalah TuxCare Extended Lifecycle Support. Dokumentasi cPanel menjelaskan integrasi paket alt-phpXX yang mendapatkan pembaruan keamanan untuk versi PHP yang sudah EOL. Integrasi itu menggunakan WHM MultiPHP Manager dan lisensi yang sesuai, bukan mekanisme pembaruan APT biasa.

Untuk kerentanan Oktober 2026, advisory TuxCare bertanggal 22 Oktober 2026 mencantumkan paket alt-php72 versi 7.2.34-97.el10 yang mencakup kedua CVE. Ini bukti rilis spesifik, bukan sekadar janji layanan. Namun, paket dalam advisory itu ditujukan pada produk dan platform yang tercantum. Pengguna Ubuntu atau aaPanel tidak boleh memasangnya begitu saja.

Alternatif lainnya adalah Zend PHP Long-Term Support. Zend menyatakan menyediakan dukungan lanjutan untuk PHP 7.2, 7.3, 7.4, dan 8.1 melalui runtime ZendPHP, termasuk perbaikan terkait PHP2Shell. Layanan itu dapat dipertimbangkan oleh pengelola aplikasi legacy yang membutuhkan patch dan dukungan vendor, tetapi kompatibilitas deployment, detail kontrak, serta cakupan patch harus dikonfirmasi sebelum migrasi runtime.

Jadi, keberadaan penyedia pihak ketiga bukan berarti seluruh versi PHP EOL otomatis aman. Periksa daftar cabang PHP yang dilayani, advisory CVE spesifik, tanggal rilis paket, jenis sistem operasi, dan apakah paket baru benar-benar menggantikan interpreter yang digunakan website. Layanan jangka panjang memberi waktu untuk migrasi, bukan menghapus seluruh risiko aplikasi lama, plugin abandoned, atau sistem operasi yang juga sudah melewati masa dukungan.

Bagaimana dengan source backport langsung dari tim PHP?

Pada insiden Oktober 2026, PHP menghubungkan tiga cabang patch source khusus untuk PHP 7.4, 8.0, dan 8.1 melalui advisory resminya. Ini pengecualian penting dari kebijakan EOL: tim keamanan PHP menyediakan perubahan source minimal untuk membantu pengguna yang membangun PHP sendiri atau belum mempunyai akses ke vendor LTS. Mereka tidak menerbitkan rilis upstream baru untuk ketiga cabang tersebut, sehingga tidak ada tombol update PHP resmi setara rilis 8.3.36.

Penerapan source backport membutuhkan proses teknis: memperoleh source dari sumber yang dapat diverifikasi, memeriksa commit patch untuk cabang yang tepat, membangun ulang interpreter beserta ekstensi yang bergantung pada build tersebut, menguji di staging, lalu mengganti proses PHP-FPM atau handler web. Detail proses berbeda antar lingkungan, sehingga tidak aman memberikan satu perintah kompilasi universal untuk semua server produksi. Risiko lain adalah perubahan perilaku di area yang terkait langsung dengan perbaikan keamanan, sehingga pengujian upload, session, dan fungsi aplikasi tetap diperlukan.

Patch tersebut khusus menangani CVE-2026-109618 dan CVE-2026-109619. Memakai source backport ini tidak menjadikan PHP 7.4, 8.0, atau 8.1 kembali berada dalam masa dukungan reguler, dan tidak menjamin semua kerentanan lama lain ikut tertutup. Untuk penggunaan jangka panjang, rencanakan perpindahan ke cabang PHP yang masih didukung.

Cara menentukan patch yang cocok untuk server Anda

Langkah pertama adalah mengidentifikasi instalasi PHP yang benar-benar melayani website. Satu VPS dapat memiliki PHP dari APT, binary aaPanel, dan beberapa versi PHP-FPM yang berjalan berdampingan. Hasil php -v di SSH hanya menunjukkan PHP CLI default, belum tentu sama dengan interpreter yang dipakai domain publik.

1. Catat versi PHP untuk website dan CLI. Periksa pengaturan domain di hosting panel, pool PHP-FPM, dan jalur executable yang aktif. Untuk inspeksi awal dari SSH, gunakan perintah berikut tanpa mengubah konfigurasi.

php -v
command -v php
readlink -f "$(command -v php)"

Jika memakai Ubuntu dengan paket PHP dari repositori distribusi, periksa versi paket dan kandidat pembaruannya. Contoh berikut hanya relevan bila paket php8.1-fpm memang terpasang dan digunakan website.

dpkg-query -W -f='${Version}\n' php8.1-fpm
apt-cache policy php8.1-fpm

2. Tentukan pemilik pembaruan. Jika PHP berasal dari repositori Ubuntu yang didukung, cocokkan dengan USN dan pembaruan paket. Jika menggunakan cPanel/CloudLinux atau ZendPHP, periksa kanal keamanan vendornya. Jika PHP dikompilasi sendiri atau oleh aaPanel, jangan berasumsi bahwa pembaruan APT otomatis menambal binary tersebut.
3. Cocokkan dua CVE dengan advisory yang tepat. Pastikan sumber pembaruan secara eksplisit mencantumkan CVE-2026-109618 dan CVE-2026-109619, atau mengacu pada advisory yang memuat keduanya. Periksa status dan versi paket untuk OS Anda, bukan hanya klaim umum “PHP sudah di-patch”.
4. Backup dan uji rencana pembaruan. Simpan snapshot bila ada, backup website serta database, dan salin konfigurasi PHP-FPM, modul, serta vhost. Pada sistem APT, gunakan simulasi transaksi paket untuk memeriksa apakah ada dependency atau paket lain yang akan ikut berubah. Jangan melanjutkan bila daftar perubahan tidak sesuai rencana.
5. Terapkan patch melalui pengelola aslinya. Gunakan repositori dan prosedur vendor pemilik runtime. Setelah pembaruan, restart worker PHP yang relevan, verifikasi nomor revisi paket, periksa log, lalu uji halaman, login, formulir, upload, session, cron, dan koneksi database.

Untuk contoh Ubuntu 22.04 yang memakai PHP 8.1 dari APT, bentuk simulasi sebelum pembaruan terbatas adalah sebagai berikut. Ini bukan perintah universal untuk semua server dan tidak menggantikan pemeriksaan paket ekstensi lain yang terpasang.

sudo apt update
sudo apt-get -s install --only-upgrade php8.1-fpm php8.1-cli

Baca seluruh hasil simulasi lebih dahulu, termasuk paket yang akan dipasang, diperbarui, atau dihapus. Jika paket PHP 8.1 tidak berasal dari repo Canonical yang menerbitkan advisory tersebut, hentikan pendekatan ini dan periksa vendor sebenarnya. Pada aaPanel, panduan cara update PHP di aaPanel membahas binary panel dan prosedur pemeriksaannya. Jangan mencampur PHP bawaan aaPanel dengan paket APT hanya karena keduanya mempunyai nomor versi yang sama.

Apakah patch PHP EOL mengharuskan upgrade MySQL atau MariaDB?

Tidak secara otomatis. PHP adalah runtime aplikasi, sedangkan MySQL dan MariaDB merupakan server database yang mempunyai siklus rilis dan patch tersendiri. Backport pada interpreter PHP dapat dipasang sambil mempertahankan versi database yang telah digunakan aplikasi, selama driver, ekstensi PHP, konfigurasi koneksi, dan aplikasi tetap kompatibel.

Yang perlu diperhatikan adalah cara melakukan pembaruannya. Menjalankan pembaruan seluruh sistem tanpa meninjau paket dapat memperbarui komponen lain yang tidak direncanakan, termasuk database jika terdapat paket yang memenuhi syarat. Itulah sebabnya inventaris paket, simulasi transaksi, backup, dan pengujian setelah deploy tetap penting. Jangan menjanjikan “tanpa perubahan apa pun” hanya karena cabang PHP tidak berubah.

Pembaruan server database bisa dibutuhkan karena alasan keamanan atau masa dukungan database itu sendiri, tetapi kebutuhannya harus diputuskan lewat audit terpisah. Untuk PHP EOL yang sedang dibahas di sini, pertanyaan pertama adalah apakah interpreter PHP yang melayani website telah menerima fix untuk kedua CVE, bukan apakah MySQL sudah dinaikkan ke versi mayor terbaru.

Kapan patch PHP lama tidak cukup?

Backport menutup masalah keamanan yang secara spesifik dicakup paket atau perubahan source tersebut. Ia tidak memperbarui otomatis WordPress, framework, plugin, Composer, OpenSSL, atau sistem operasi. Selain itu, PHP EOL dapat memiliki bug atau isu kompatibilitas lain yang tidak tercakup dalam kontrak extended support. Karena itu, status aman tidak boleh disimpulkan hanya dari adanya satu patch CVE.

Jika penyedia hosting tidak mendukung cabang PHP yang digunakan, tidak tersedia backport untuk kombinasi OS dan runtime Anda, atau hasil pengujian patch gagal, pendekatan yang lebih tepat adalah merencanakan migrasi aplikasi. Untuk website yang rusak saat mencoba pindah ke PHP baru, panduan memperbaiki website error setelah update PHP membahas diagnosis kompatibilitas kode, plugin, dependency, dan service. Artikel itu berbeda dengan pembahasan backport: masalahnya bukan mencari sumber patch PHP EOL, melainkan memperbaiki aplikasi agar siap memakai runtime yang didukung.

Untuk konteks dua kerentanan Oktober 2026, laporan patch keamanan PHP RCE kritis menjelaskan versi upstream yang sudah diperbaiki. Artikel ini melengkapi laporan tersebut dengan pilihan bagi pemilik aplikasi legacy, bukan menawarkan langkah yang sama untuk semua pengguna PHP.

Pertanyaan umum tentang patch PHP EOL

Apakah PHP 7.4 masih bisa ditambal pada Oktober 2026?

Bisa untuk kerentanan tertentu melalui mekanisme yang terbukti tersedia, seperti paket PHP 7.4 Ubuntu 20.04 melalui Ubuntu Pro/ESM atau minimal source backport yang ditautkan proyek PHP untuk dua CVE Oktober 2026. Keberhasilan penerapan tetap bergantung pada OS, asal instalasi PHP, dan hasil verifikasi paket atau build yang dipakai.

Apakah ada patch gratis untuk PHP EOL?

Ada jalur yang tidak mewajibkan pembelian layanan PHP LTS, misalnya paket keamanan Ubuntu yang termasuk dalam dukungan rilis OS yang relevan atau source backport yang diterbitkan tim PHP. Namun, akses paket bergantung pada skema dukungan dan biaya operasional tetap dapat muncul untuk pekerjaan audit, build, pengujian, serta pemeliharaan.

Apakah patch keamanan PHP bisa dipasang seperti plugin WordPress?

Tidak untuk kerentanan yang berada di interpreter PHP. Patch harus mencapai binary atau paket runtime yang mengeksekusi request, kemudian proses worker terkait memakai versi hasil pembaruan. Memasang plugin WordPress, mengubah tema, atau memperbarui library Composer tidak otomatis menutup celah pada inti PHP.

Apakah backport membuat PHP EOL aman dipakai selamanya?

Tidak. Backport dapat mengatasi CVE tertentu dan memberi waktu untuk migrasi, tetapi masa dukungan upstream tetap sudah berakhir. Jika vendor berhenti menyediakan patch, risiko kerentanan baru kembali menjadi masalah. Rencana akhir yang lebih terukur tetap mengarah pada cabang PHP yang didukung beserta pembaruan aplikasi yang diperlukan.

Langkah berikutnya bagi pemilik website PHP lama

Jika website belum kompatibel dengan PHP terbaru, jangan memilih antara membiarkannya rentan atau melakukan upgrade tergesa-gesa tanpa pengujian. Periksa lebih dahulu asal runtime, keberadaan patch vendor untuk CVE yang relevan, kecocokan ekstensi, dan risiko perubahan paket. Jika tersedia backport yang didukung serta dapat diverifikasi, gunakan sebagai jembatan sambil menyiapkan migrasi aplikasi secara bertahap.

Pengelola website yang tidak memiliki akses teknis untuk mengaudit runtime dan dependency dapat mempertimbangkan bantuan developer atau administrator server. Layanan maintenance website CodeF dapat menjadi titik awal konsultasi kebutuhan audit dan pemeliharaan, dengan lingkup pekerjaan patch PHP EOL ditentukan setelah lingkungan server diperiksa. Tidak ada satu paket atau metode backport yang dapat dijanjikan cocok untuk seluruh hosting.