PHP2Shell dan Node2Shell: Apa yang Terjadi dan Cara Mengamankan Server Anda

Dalam dua hari berturut-turut, dua teknologi yang menjalankan sebagian besar aplikasi web mendapat tambalan darurat. Komunitas keamanan menjulukinya PHP2Shell dan Node2Shell. Kalau aplikasi Anda berjalan di PHP atau Node.js, dan sebagian besar aplikasi instansi memang begitu, ini bukan berita yang boleh dilewatkan.

Kabar baiknya, perbaikannya sudah tersedia. Kabar buruknya, perbaikan itu hanya berguna kalau benar-benar dipasang.

Ringkasan Cepat

Gambar 1

PHP2Shell: Celah di Jantung PHP

Tim Wiz Research menemukan beberapa celah kritis di PHP inti, bahasa yang menurut mereka menjalankan 70% situs web di dunia. Yang membuatnya serius: celahnya ada di PHP itu sendiri, bukan di aplikasi yang berjalan di atasnya. Artinya, kode aplikasi yang rapi pun tidak otomatis aman. wizwiz

Menurut Wiz, setiap versi PHP yang dirilis dalam satu dekade terakhir, sampai PHP 5.4, terdampak oleh setidaknya satu celah ini. Wiz mendemonstrasikan serangan tanpa autentikasi pada WordPress, Drupal, dan Joomla, tetapi menegaskan bahwa ketiganya hanyalah contoh. Aplikasi sederhana pun bisa rentan. wiz

Apa akar masalahnya, dalam bahasa sederhana?

Semua celah ini berkaitan dengan cara PHP menangani kesalahan fatal saat memproses permintaan, terutama kehabisan memori. Kesalahan itu bisa meninggalkan kondisi internal PHP yang rusak setelah permintaan berakhir tiba-tiba, lalu permintaan atau worker berikutnya memakai ulang kondisi basi tersebut. Akibatnya bisa berupa kebocoran atau kerusakan memori. wiz

Bayangkan karyawan yang pergi mendadak di tengah pekerjaan tanpa membereskan meja. Karyawan berikutnya memakai meja itu dengan berkas setengah jadi, dan bisa salah mengambil berkas rahasia.

Gambar 2

Apa dampaknya?

• Kebocoran memori. Wiz menunjukkan bahwa penyerang dapat membaca data sensitif dari memori proses PHP, termasuk kata sandi, token, dan kunci API, tanpa perlu eksekusi kode. wiz

• Eksekusi kode jarak jauh (RCE). Tanpa login, penyerang dapat menjalankan perintah di server.

• Dampak turunan. Pengambilalihan server, pencurian data, dan perusakan tampilan situs.

• Versi PHP yang sudah diperbaiki

Menurut ringkasan Brandefense, PHP2Shell diperbaiki di PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35. Cabang PHP yang sudah tidak didukung resmi tidak boleh Anda anggap aman hanya karena tidak ada kabar. Cek apakah distribusi Linux atau penyedia hosting Anda menyediakan perbaikan khusus untuk versi tersebut, atau rencanakan migrasi. brandefense

Node2Shell: Celah di Dekoder Brotli Node.js

Sehari setelahnya muncul Node2Shell. Nama ini dipakai peneliti dan media sosial untuk CVE-2026-111497, celah di dekoder Brotli di dalam Node.js. Brotli adalah format kompresi data yang umum dipakai di web. brandefense

Ada beberapa hal yang perlu dipahami secara proporsional:

Menurut laporan The Hacker News, server HTTP Node.js biasa tidak mendekode isi permintaan Brotli begitu saja, sehingga perlu middleware atau pemanggilan eksplisit. Risikonya ada pada aplikasi yang mengolah data Brotli dari sumber tidak tepercaya. thehackernews

Semgrep menyebut konfigurasi Express, Koa, dan Fastify dapat menjangkau dekoder ini, dan berdampak pada sejumlah paket pihak ketiga. semgrep

Node.js menilai tingkat keparahannya tinggi, bukan kritis, meski beberapa situs menuliskannya kritis. pasqualepillitteri

Peneliti Imperva mendemonstrasikan eksekusi kode pada image resmi Node.js 24.22.0 untuk Linux arm64. Namun laporan itu juga menyebut belum ada eksploitasi di dunia nyata yang dilaporkan per 22 Oktober. thehackernewsthehackernews

Menurut Aikido, eksploitnya tidak berhasil di setiap percobaan. aikido

Jadi tidak perlu panik, tetapi jelas bukan alasan untuk menunda update, karena bukti konsep sudah publik.

Versi Node.js yang sudah diperbaiki

Perbaikan dirilis di Node.js v22.23.4 dan v24.22.1 (keduanya LTS), serta v26.12.1 (Current). kaptentekno

Poin yang paling penting bagi instansi: Node.js 20 dan yang lebih lama sudah end-of-life dan tidak akan mendapat perbaikan, begitu pula Node.js 25, 23, dan 21. Selain itu, Node.js tidak menerbitkan solusi sementara di dalam runtime. Satu-satunya jalan adalah memperbarui versi.

Gambar 3

Kenapa Ini Penting untuk Instansi dan Vendor

1. Banyak aplikasi instansi berjalan di PHP atau Node.js, dari portal, aplikasi layanan, sampai sistem internal buatan vendor lama.

2. Versi runtime sering tertinggal. Aplikasi legacy kadang masih berjalan di PHP atau Node.js yang sudah tidak didukung, karena “yang penting jalan”. Kasus ini mengingatkan bahwa runtime juga perlu dipelihara, bukan hanya aplikasinya.

3. Siapa yang bertanggung jawab? Pada proyek dengan banyak vendor, sering tidak jelas siapa yang memperbarui server setelah serah terima.

4. Rahasia di memori. Token, kunci API, dan kata sandi yang bocor dari memori berdampak ke seluruh sistem terhubung, termasuk SSO dan API gateway.

5. AI mengubah kecepatan. Wiz mencatat bahwa model AI mutakhir membuat pengembangan dan penyesuaian eksploit bisa selesai dalam hitungan jam, tidak lagi berminggu-minggu. Jeda antara rilis tambalan dan serangan massal kemungkinan makin pendek. wiz

Langkah yang Bisa Dilakukan Hari Ini

1. Inventarisasi: tahu apa yang Anda jalankan

Catat semua server dan aplikasi, lalu versi PHP dan Node.js-nya. Termasuk server percobaan, aplikasi lama, dan aplikasi milik vendor. Perintah dasarnya sederhana: php -v untuk PHP dan node -v untuk Node.js. Untuk aplikasi dalam kontainer, cek versi di dalam image, bukan hanya di server induknya.

2. Perbarui ke versi yang diperbaiki

Prioritaskan server yang menghadap internet. Sesuaikan dengan versi perbaikan di atas, atau paket pembaruan dari distribusi Linux Anda.

3. Restart layanan dan bangun ulang image

Pembaruan paket belum efektif sebelum proses lama dimuat ulang. Restart PHP-FPM atau web server, restart layanan Node.js, dan bangun ulang serta deploy ulang image kontainer supaya memakai runtime baru. Image lama yang masih berjalan tetap rentan.

4. Pasang pengaman sementara, bukan pengganti

Beberapa penyedia melaporkan sudah menambahkan aturan WAF untuk kedua celah ini. Jika Anda memakai CDN atau WAF, periksa apakah aturan tersebut aktif. Perlakukan ini sebagai penahan sementara. Mengenai PHP2Shell, pernyataan di rujukan yang saya baca jelas: tidak ada mitigasi yang lengkap dan memperbarui adalah satu-satunya pilihan aman. Wikipedia

5. Pantau tanda-tanda mencurigakan (PHP)

Wiz menyarankan memperhatikan permintaan multipart yang tidak biasa diikuti galat batas memori atau HTTP 500 berulang, cookie PHPSESSID yang besar atau janggal, dan worker PHP yang sering mati-hidup tanpa sebab. Ini petunjuk untuk penyelidikan, bukan pengganti update. wiz

6. Pertimbangkan rotasi rahasia pada server rawan

Untuk server yang sempat terbuka ke internet dengan versi lama, pertimbangkan mengganti kunci API, token, dan kata sandi yang dipakainya, terutama jika ada tanda aktivitas mencurigakan.

7. Rencanakan keluar dari versi yang sudah tidak didukung

Aplikasi di PHP atau Node.js yang sudah EOL perlu jadwal migrasi, atau setidaknya perlindungan berlapis (isolasi jaringan, WAF, pembatasan akses) sambil menunggu migrasi.

8. Untuk hosting bersama atau dikelola vendor

Tanyakan secara tertulis ke penyedia: versi apa yang berjalan, kapan diperbarui, dan siapa penanggung jawabnya.

Gambar 4

Kesalahan yang Sering Terjadi

Sudah update paket, tapi lupa restart. Proses lama masih memakai versi lama.

Hanya update server induk, bukan image kontainer.

Menganggap “aplikasi saya aman karena kodenya rapi”. Celah ada di runtime.

Mengandalkan WAF saja. Itu penahan sementara.

Mengabaikan aplikasi lama yang “jarang dipakai”. Aplikasi yang terlupakan sering jadi pintu masuk.

Tidak ada pemilik yang jelas untuk pembaruan setelah proyek serah terima.

Panik berlebihan. Cukup bertindak terukur: inventarisasi, update, verifikasi.

Checklist Cepat

Daftar server dan aplikasi beserta versi PHP dan Node.js sudah ada

Server yang menghadap internet diprioritaskan

PHP diperbarui ke versi yang diperbaiki (atau paket distribusi yang setara)

Node.js diperbarui ke 22.23.4, 24.22.1, atau 26.12.1

Layanan sudah di-restart dan image kontainer sudah di-rebuild serta di-deploy

Aturan WAF atau CDN dicek sebagai lapisan tambahan

Log dipantau untuk pola mencurigakan

Rotasi rahasia dipertimbangkan untuk server rawan

Rencana migrasi dari versi EOL sudah dijadwalkan

Penanggung jawab pembaruan runtime jelas tertulis

Pelajaran yang Lebih Besar

PHP2Shell dan Node2Shell menunjukkan dua hal. Pertama, runtime adalah bagian dari keamanan aplikasi, bukan sekadar “mesin di bawah”. Kedua, tambal cepat itu soal proses, bukan soal teknologi: ada inventaris, ada pemilik, ada jadwal, dan ada cara memverifikasi bahwa pembaruan benar-benar terpasang. Instansi yang punya proses semacam itu akan bereaksi dalam jam, bukan minggu.

Butuh Bantuan Memeriksa dan Mengamankan Aplikasi Anda?

Dhiyari membantu instansi dan perusahaan memetakan versi runtime, memperbarui server dan kontainer, serta merapikan proses pembaruan keamanan, termasuk untuk aplikasi lama yang sudah berjalan. Hubungi kami untuk diskusi awal mengenai kondisi sistem Anda.