Website Anda mungkin masih menampilkan produk, menerima pertanyaan, dan membantu penjualan. Namun, ketika pembaruan keamanan tertahan karena sistem lama tidak kompatibel, ada pekerjaan penting yang perlu segera dibereskan.
Melalui jasa pembuatan ulang website, saya membantu Anda membahas pembaruan sistem sekaligus kebutuhan bisnisnya: fungsi yang perlu dipertahankan, bagian yang menghambat, dan pengelolaan setelah website baru digunakan. Anda berdiskusi langsung dengan saya, Dicky Ibrohim, untuk menentukan lingkup pekerjaan sebelum memutuskan biaya.
Kasus PHP2Shell pada Oktober 2026 memperjelas pentingnya keputusan tersebut. Langkah awalnya adalah memeriksa paparan dan menerapkan perbaikan yang tersedia. Pembangunan ulang menjadi pilihan ketika kondisi website memang membutuhkan perubahan lebih jauh.
Hampir 70% menggunakan PHP. Apa artinya bagi website Anda?
Menurut W3Techs pada 23 Oktober 2026, PHP digunakan oleh 69,3% website yang bahasa pemrograman servernya dapat mereka identifikasi. Angka ini menunjukkan luasnya penggunaan PHP; angka tersebut tidak mengukur jumlah website yang rentan atau sudah diretas. Statistik PHP W3Techs.
Karena PHP dipakai begitu luas, celah pada mesinnya dapat memengaruhi banyak jenis aplikasi. Pemilik usaha perlu mengetahui apakah website miliknya memakai versi yang terdampak dan apakah perbaikannya sudah benar-benar diterapkan.
Status itu tidak dapat dipastikan hanya dari tampilan beranda yang masih normal. Versi perangkat lunak, paket dari penyedia server, konfigurasi, dan kondisi aplikasi perlu diperiksa bersama.
Kerentanan PHP yang dikenal sebagai PHP2Shell
PHP2Shell digunakan oleh penelitinya sebagai nama demonstrasi eksploit dan riset mengenai kerentanan PHP. Dua celah yang dibahas dilacak sebagai CVE-2026-109618 dan CVE-2026-109619. Publikasi riset mencantumkan kontribusi Wiz Research, OpenAI Codex Security, dan Calif. Penjelasan asal nama PHP2Shell oleh penelitinya.
NCSC Belanda juga memakai nama tersebut dalam informasi penanganan kerentanan. Dalam artikel ini, PHP2Shell disebut untuk mengidentifikasi topik keamanan. Artikel dan penawaran jasa ini independen serta tidak mengatasnamakan pihak peneliti atau pengelola proyek PHP. Informasi operasional NCSC-NL.
Keduanya memiliki tingkat keparahan kritis, dengan skor CVSS 4.0 sebesar 9,2 dari 10. CVSS adalah sistem penilaian keparahan kerentanan, bukan persentase kemungkinan website Anda akan diretas.
- CVE-2026-109618: kesalahan penanganan kondisi kehabisan memori dapat meninggalkan data internal dalam keadaan tidak valid. Pada kondisi yang dapat dieksploitasi, penyerang bisa menjalankan kode dari jarak jauh tanpa masuk ke akun. Advisory resmi PHP untuk CVE-2026-109618.
- CVE-2026-109619: keadaan internal dari permintaan sebelumnya dapat tetap merujuk memori yang sudah dilepas. Pemakaian kembali keadaan tersebut pada kondisi tertentu dapat membuka jalan bagi eksekusi kode jarak jauh. Advisory resmi PHP untuk CVE-2026-109619.
Eksekusi kode jarak jauh, atau remote code execution (RCE), berarti penyerang dapat menjalankan kode pada server dalam batas akses proses yang berhasil diserang. Konsekuensi yang mungkin timbul mencakup pembacaan data yang dapat dijangkau proses tersebut, perubahan isi website, atau gangguan layanan. Dampak sebenarnya bergantung pada hak akses dan lingkungan sistem.
PHP menyatakan instalasi yang melayani permintaan web perlu segera ditangani, dengan risiko tertinggi pada Apache mod_php, tempat eksploitasi telah didemonstrasikan sebelum kode aplikasi berjalan. Tingkat paparan pada konfigurasi lain tetap perlu dinilai; keberadaan PHP saja tidak membuktikan serangan telah berhasil. Pengumuman keamanan PHP, 21 Oktober 2026.
Versi PHP yang menerima perbaikan
Perbaikan untuk kedua CVE tersebut dirilis pada 21 Oktober 2026 dalam:
| Cabang PHP | Rilis perbaikan |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Penyedia distribusi Linux atau dukungan jangka panjang dapat menyediakan paket perbaikan melalui jalurnya sendiri. Karena itu, mintalah konfirmasi paket dan pembaruan yang terpasang, terutama jika penyedia menerapkan backport, yaitu membawa perbaikan ke paket versi lama. Panduan pembaruan PHP.
Ada perkembangan tambahan pada 23 Oktober 2026. PHP menerbitkan imbauan tentang jalur RCE pada kombinasi konfigurasi dan kode aplikasi yang tidak umum. Pengelola diminta meninjau pengaturan session upload progress dan mengikuti mitigasi resminya sampai rilis perbaikan berikutnya. Jadi, daftar versi di atas harus dibaca bersama imbauan terbaru, bukan sebagai jaminan seluruh risiko sudah selesai. Imbauan PHP, 23 Oktober 2026.
Kendalanya: website lama belum tentu siap menerima pembaruan
Pada sebagian website, menaikkan versi PHP memunculkan masalah lain: tema gagal dimuat, plugin berhenti bekerja, atau fungsi khusus menghasilkan kesalahan. Kemampuan WordPress inti berjalan pada suatu versi PHP belum otomatis membuktikan seluruh tema, plugin, dan kode tambahannya kompatibel. Dokumentasi WordPress sendiri meminta pengguna memeriksa kompatibilitas dan menyiapkan cadangan sebelum pembaruan. Panduan pembaruan PHP WordPress.
Situasi seperti ini perlu penilaian yang lebih terarah. Identifikasi penghalang pembaruan, status pemeliharaan komponennya, kemungkinan pengganti, dan besarnya perubahan yang diperlukan.
Dari jawabannya, kita dapat membandingkan biaya memperbaiki bagian tertentu dengan membangun ulang website. Mengganti tampilan saja belum menyelesaikan ketergantungan teknis yang membuat pembaruan selalu tertunda.
Dukungan PHP lama memiliki batas
Per 23 Oktober 2026, PHP 8.1 dan versi sebelumnya sudah berakhir dukungan resminya. Untuk cabang yang masih didukung, jadwal dukungan keamanan PHP adalah:
| Cabang | Dukungan keamanan sampai |
|---|---|
| PHP 8.2 | 31 Desember 2026 |
| PHP 8.3 | 31 Desember 2027 |
| PHP 8.4 | 31 Desember 2028 |
| PHP 8.5 | 31 Desember 2029 |
Jadwal tersebut membantu memilih tujuan migrasi yang sesuai dengan kompatibilitas aplikasi dan masa pemeliharaan yang dibutuhkan. Jadwal dukungan resmi PHP.
Untuk PHP2Shell, tim keamanan PHP menyediakan backport sumber minimal bagi PHP 7.4, 8.0, dan 8.1. Sebagian vendor juga menyediakan dukungan lanjutan. Ketersediaan perbaikan khusus ini tidak mengembalikan status dukungan reguler versi tersebut. Cakupan paket dari vendor tetap perlu dikonfirmasi. Keterangan dukungan dan backport PHP.
React2Shell: teknologi baru juga membutuhkan pemeliharaan
Contoh penting pada React dan Next.js adalah React2Shell, CVE-2025-55182, yang diumumkan pada 3 Desember 2025. Celah pada React Server Components ini memperoleh skor CVSS 10,0 dan memungkinkan eksekusi kode jarak jauh tanpa autentikasi pada aplikasi yang terdampak. Ini adalah kasus terdahulu yang relevan untuk perencanaan website, bukan pengumuman baru Oktober 2026. Pengumuman resmi React.
Dampaknya pada Next.js berkaitan dengan penggunaan App Router dan komponen RSC yang rentan. Advisory awal mencakup versi tertentu pada jalur Next.js 15, 16, serta rilis percobaan 14.3. Aplikasi yang sudah menerima perbaikan tidak boleh disamakan dengan versi rentannya. Advisory resmi Next.js.
React2Shell bukan kerentanan yang otomatis menyerang semua aplikasi Node.js. React juga menjelaskan bahwa aplikasi yang tidak menggunakan server, atau tidak memakai perangkat yang mendukung React Server Components, tidak terdampak oleh CVE ini.
Pelajarannya berguna saat memilih teknologi pengganti: pastikan komponen yang digunakan dapat diperbarui dan ada pihak yang menangani pemeliharaannya. Untuk React dan Next.js, ikuti rilis perbaikan terkini pada jalur yang didukung karena advisori lanjutan juga telah diterbitkan. Panduan pembaruan React.
Di era AI, kemampuan memperbarui website semakin penting
NCSC Selandia Baru menjelaskan bahwa pelaku ancaman semakin menggunakan AI untuk menemukan dan mengeksploitasi kerentanan. Untuk celah yang baru dipublikasikan, AI dapat memperpendek waktu antara penemuan dan eksploitasi, sehingga organisasi memiliki waktu lebih sedikit untuk menerapkan perbaikan. Panduan NCSC, 18 Juni 2026.
Bagi pemilik usaha, implikasinya adalah memperbaiki kemampuan merespons: mengetahui komponen yang dipakai, siapa yang mengelola pembaruannya, dan bagaimana perubahan diuji sebelum diterapkan.
AI juga dapat membantu pekerjaan pertahanan dan pengembangan. Namun, tampilan yang berhasil dibuat dengan AI belum membuktikan formulir, hak akses, penyimpanan data, serta integrasinya sudah bekerja dengan benar.
Di sinilah bantuan engineer berguna. Anda dapat membahas kebutuhan dengan orang yang menerjemahkannya menjadi pilihan teknis dan pemeriksaan fungsi sesuai lingkup pekerjaan. Penggunaan AI tetap memerlukan penilaian terhadap hasil serta batas aksesnya; NCSC juga menekankan pembatasan kewenangan dan perlindungan informasi ketika AI digunakan pada sistem. Panduan penggunaan AI dari NCSC.
Kapan cukup diperbarui, dan kapan perlu dibuat ulang?
Keputusan pembangunan ulang sebaiknya mengikuti hasil pemeriksaan. Gunakan kerangka berikut untuk memulai diskusi:
| Kondisi website | Pilihan yang patut dinilai |
|---|---|
| Komponen masih didukung dan pembaruan kompatibel | Terapkan pembaruan, lalu periksa fungsi penting. |
| Hambatan berasal dari beberapa plugin atau fungsi tertentu | Perbaiki atau ganti komponen yang menghambat. |
| Banyak komponen ditinggalkan dan pembaruan berulang kali gagal | Bandingkan perbaikan menyeluruh dengan pembangunan ulang. |
| Kebutuhan usaha sudah jauh berbeda dari rancangan lama | Rencanakan ulang struktur, fungsi, dan cara pengelolaannya. |
| Ada tanda penyusupan atau perubahan tanpa izin | Dahulukan penanganan insiden dan pemeriksaan sistem terkait. |
Tabel ini adalah kerangka keputusan, bukan diagnosis website tertentu. Jika ada indikasi infeksi, lihat lingkup pemeriksaan dan pembersihan malware website sebelum merencanakan perpindahan.
Pembuatan ulang tidak boleh menunda penanganan celah yang sedang terbuka. Selama website lama masih melayani pengunjung, pembaruan atau mitigasi yang sesuai tetap perlu dikerjakan oleh pengelolanya.
Bangun ulang website dengan fungsi yang memang dibutuhkan bisnis
Saya menawarkan pengembangan website custom yang dibahas dari kebutuhan usaha Anda. Untuk website lama, diskusinya dimulai dari bagian yang masih berguna: alamat halaman, informasi layanan, materi produk, formulir, dan hubungan ke sistem lain.
Sebagai ilustrasi, perusahaan jasa yang hanya membutuhkan profil, katalog layanan, dan jalur pertanyaan mungkin dapat menggunakan rancangan yang lebih sederhana. Toko dengan transaksi, stok, serta akun pelanggan membutuhkan fungsi dan pengelolaan yang berbeda. Keduanya sebaiknya tidak dipaksa memakai paket teknis yang sama. Untuk kebutuhan profil usaha, pembahasan website company profile custom dapat membantu menentukan halaman dan fungsi awal.
Prioritas yang dapat dibahas dalam penawaran meliputi:
- Menata struktur informasi agar pengunjung memahami layanan dan menemukan langkah berikutnya.
- Menentukan formulir, katalog, pemesanan, atau integrasi yang benar-benar diperlukan.
- Memperjelas bagian konten yang dapat diperbarui sendiri jika fasilitas edit termasuk dalam pekerjaan.
- Memilih konten yang dipindah dan merencanakan penanganan alamat halaman yang berubah.
- Membahas pembaruan, pemeriksaan fungsi, akses serah terima, serta dukungan yang disepakati.
Nilai pendekatan custom terletak pada penyesuaian tersebut. Jika bisnis menambah layanan atau cabang, perubahan informasinya bisa direncanakan bersama berdasarkan kebutuhan dan kemampuan sistem. Pengembangan berikutnya tetap memerlukan penilaian lingkup, waktu, dan biaya.
Platform pembuat website juga dapat menjadi pilihan bila fitur dan batas paketnya mencukupi. Sebelum memilih, periksa pengelolaan konten, integrasi, biaya perpanjangan, dan cara mengambil data saat ingin pindah atau ketika layanan berhenti. Ekspor teks dan gambar belum tentu menghasilkan website utuh yang langsung berjalan di tempat lain.
Pertimbangan yang sama berlaku pada layanan saya: kode sumber tidak termasuk secara otomatis, memerlukan penawaran terpisah, dan tidak selalu tersedia. Akses akun, lisensi, berkas serah terima, serta kemungkinan migrasi harus dijelaskan sesuai kesepakatan.
Jika website mengumpulkan data pelanggan atau memakai analitik, tentukan pula data yang diperlukan, siapa yang dapat mengaksesnya, dan layanan pihak ketiga yang terlibat. Website custom tetap perlu mengelola ketergantungan tersebut.
Pertahankan nilai konten dan rencanakan perpindahan SEO
Website lama mungkin sudah memiliki halaman yang dikenal pelanggan, dibagikan mitra, atau tampil di pencarian. Saat membangun ulang, halaman-halaman itu perlu diinventarisasi agar perpindahannya terarah.
Jika alamat berubah, pemetaan URL lama ke halaman pengganti yang relevan dan pengalihan permanen perlu direncanakan. Tautan internal serta peta situs juga perlu mengikuti struktur baru. Google menjelaskan bahwa perpindahan situs dapat menimbulkan perubahan peringkat sementara ketika halaman dirayapi dan diindeks ulang. Panduan migrasi Google Search Central.
Karena itu, bahas penanganan migrasi SEO sebelum pekerjaan dimulai. Tidak ada dasar untuk menjanjikan peringkat atau trafik pasti tetap sama setelah pembangunan ulang.
Biaya jelas sejak awal, perawatan jelas setelah tayang
Biaya pembuatan ulang dipengaruhi oleh kondisi website lama, jumlah jenis halaman, fungsi, kesiapan konten, integrasi, serta pekerjaan pemindahan data. Jadwal juga bergantung pada akses yang tersedia dan proses persetujuan.
Dalam penawaran, pisahkan biaya pengerjaan dari pengeluaran berulang seperti domain, hosting, lisensi, penyimpanan, atau layanan tambahan. Kebutuhan perawatan dan bantuan setelah tayang perlu disebut secara terpisah agar Anda mengetahui siapa yang menangani pembaruan berikutnya.
Website baru tetap dapat memiliki kerentanan di kemudian hari. Pembangunan ulang membantu mengganti bagian yang bermasalah dan menata pengelolaan sesuai lingkup; keamanan berkelanjutan tetap memerlukan pembaruan, pengelolaan akses, serta kesiapan pemulihan. Tidak ada janji kebal serangan atau bebas perawatan.
Informasi kerentanan, versi, dan status dukungan dalam artikel ini diperiksa pada 23 Oktober 2026.
Pertanyaan yang sering diajukan
Apakah semua website PHP harus dibuat ulang karena PHP2Shell?
Tidak. Periksa versi dan paket PHP yang digunakan, terapkan perbaikan resmi yang sesuai, lalu nilai kompatibilitas aplikasinya. Pembangunan ulang menjadi pertimbangan jika hambatan teknis atau kebutuhan bisnis tidak memadai untuk diselesaikan melalui pembaruan dan perbaikan terbatas.
Apakah langsung pindah ke Next.js menyelesaikan masalah keamanan?
Perpindahan teknologi tidak otomatis menjamin keamanan. React2Shell menunjukkan bahwa aplikasi pada teknologi modern pun dapat memiliki kerentanan serius. Pilihan teknologi perlu disertai pembaruan dan pemeliharaan komponen yang digunakan.
Apakah memperbarui PHP sekaligus membersihkan website yang sudah diretas?
Pembaruan menutup kerentanan yang diperbaiki oleh rilis tersebut. Jika sudah terjadi penyusupan, pemeriksaan dan pemulihan perlu menangani perubahan berbahaya serta akses yang mungkin telah disalahgunakan. Kondisi website perlu dinilai sebelum menentukan pekerjaan pemulihan.
Apa yang perlu disiapkan untuk pembahasan awal?
Siapkan alamat website, masalah yang terlihat, fungsi yang harus tetap berjalan, dan target perubahan. Informasi hosting atau versi perangkat lunak dapat membantu jika tersedia. Cukup kirim gambaran awal; kata sandi dan data pelanggan tidak diperlukan pada pesan pertama.
