Darurat PHP2Shell: Audit Kilat Server dan Kewajiban UU PDP

Bayangkan Anda menitipkan fotokopi KTP, nomor HP, dan alamat rumah ke sebuah toko online, sekolah, atau koperasi. Data itu tidak disimpan di laci, melainkan di sebuah komputer yang menyala 24 jam di pusat data: server. Pertanyaannya, siapa yang menjaga server itu ketika ada kabar pintunya bisa dibobol?

Pekan ini pertanyaan tersebut bukan lagi teori. Pada 21 Oktober 2026, tim pengembang PHP mengumumkan dua celah kritis yang dinamai PHP2Shell (CVE-2026-109618 dan CVE-2026-109619) dengan skor keparahan 9,2 dari 10. Celah ini memungkinkan penyerang menjalankan perintah di server dari jarak jauh tanpa perlu login, dan para peneliti melaporkan celah ini sudah dipakai menyerang di internet.

Di hari yang sama, Node.js, mesin lain yang banyak dipakai untuk aplikasi chat, bot, dan layanan real-time, juga merilis pembaruan keamanan untuk sejumlah celah. Dua kabar dalam satu hari. Bagi pengelola server, artinya satu: audit kilat, sekarang juga.

Apa itu audit kilat?

Audit kilat bukan pemeriksaan berminggu-minggu oleh konsultan. Ini pemeriksaan cepat, beberapa jam saja, untuk menjawab empat pertanyaan sederhana:

Apakah server kita memakai versi yang rentan? Misalnya, PHP versi berapa yang sedang melayani pengunjung.
Apakah sudah ada tanda-tanda dibobol? Berkas baru yang mencurigakan, proses asing, atau catatan akses yang janggal.
Pintu apa saja yang terbuka ke internet? Tidak semua layanan perlu bisa diakses dari luar.
Apa yang bisa ditambal hari ini, dan bagaimana cara mundur kalau tambalannya bermasalah?

Pertanyaan keempat sering dilupakan. Menambal server tanpa cadangan seperti mengganti ban di jalan tol tanpa ban serep: kalau gagal, kita terjebak di tengah jalan.

Yang perlu dicari saat audit

Ada beberapa hal yang patut dicari dalam audit kilat. Hal-hal ini mudah terlewat bukan karena pengelolanya malas, tetapi karena server terus berubah dan hal kecil mudah terlupa.

Versi lama yang "masih jalan". Aplikasi tetap berfungsi, pengunjung tidak mengeluh, jadi tidak ada yang merasa perlu memperbarui. Padahal ada versi yang sudah tidak mendapat tambalan sama sekali. Untuk PHP2Shell, tim PHP merilis perbaikan untuk PHP 8.2.35, 8.3.36, 8.4.27, dan 8.5.12. Versi di luar daftar itu harus ditangani dengan cara lain atau dinaikkan versinya.

Pintu database terbuka ke internet. Database adalah lemari tempat data pribadi disimpan. Idealnya lemari ini hanya bisa dibuka dari dalam server. Kalau pintunya ternyata terbuka ke publik, periksa catatan servernya: bisa jadi sudah ada banyak percobaan masuk dengan menebak kata sandi dari alamat yang tidak dikenal. Program pemindai otomatis terus mencari pintu seperti ini di internet.

Aplikasi yang sudah tidak dipakai, tapi masih menyala. Alat otomasi yang dulu pernah dicoba, situs lama yang domainnya sudah mati, layanan yang pemiliknya lupa. Semua itu tetap menjadi pintu yang harus dijaga. Aplikasi yang tidak dipakai lebih baik dimatikan dan dihapus, setelah datanya dicadangkan.

Kata sandi yang dipakai bersama banyak aplikasi. Mengganti kata sandi database itu langkah baik. Tetapi kalau satu akun dipakai beberapa aplikasi sekaligus, menggantinya bisa membuat aplikasi lain berhenti bekerja. Sebelum mengganti, catat dulu semua aplikasi yang memakai kata sandi tersebut, termasuk yang menyimpannya di berkas pengaturan lama.

Apa hubungannya dengan UU PDP?

Di sinilah urusan teknis berubah menjadi urusan hukum. Indonesia punya Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP). Undang-undang ini memberi masa penyesuaian dua tahun (Pasal 74), yang sudah berakhir pada Oktober 2024. Artinya, kewajibannya kini berlaku penuh.

Setidaknya ada tiga pasal yang terkait langsung dengan situasi seperti PHP2Shell.

Pasal 35: wajib menjaga keamanan. Pasal ini menyatakan bahwa Pengendali Data Pribadi "wajib melindungi dan memastikan keamanan Data Pribadi yang diprosesnya", termasuk dengan menyusun dan menerapkan langkah teknis operasional serta menentukan tingkat keamanan sesuai sifat dan risiko datanya. Pengendali Data Pribadi adalah pihak yang menentukan untuk apa data dikumpulkan: toko online, sekolah, rumah sakit, koperasi, instansi.

Dengan kata lain, membiarkan server memakai versi yang sudah diumumkan rentan, atau membiarkan pintu database terbuka ke internet, sulit disebut "memastikan keamanan".

Pasal 46: lapor dalam 3 24 jam. Kalau terjadi kegagalan pelindungan data, misalnya data pelanggan bocor karena server dibobol, pengendali wajib memberi tahu secara tertulis kepada pemilik data dan lembaga yang berwenang paling lambat 3 24 jam. Pemberitahuan itu minimal memuat data apa yang terungkap, kapan dan bagaimana terjadinya, serta upaya penanganan dan pemulihannya. Dalam kondisi tertentu, pengendali juga wajib mengumumkannya kepada masyarakat.

Di sini audit kilat punya peran kedua. Tanpa catatan pemeriksaan yang rapi, sulit menjawab dengan jujur apakah data sudah bocor atau belum. Para praktisi hukum menyebut laporan baru wajib bila memang terjadi kegagalan pelindungan data. Serangan yang berhasil ditangkis tanpa data terungkap tidak otomatis harus dilaporkan. Tetapi untuk bisa mengatakan "tidak ada yang bocor", kita perlu bukti dari hasil pemeriksaan, bukan sekadar perasaan.

Pasal 57: sanksi administratif. Pelanggaran kewajiban seperti Pasal 35 dan 46 dapat dikenai sanksi administratif: peringatan tertulis, penghentian sementara pemrosesan data, penghapusan data, sampai denda administratif paling tinggi 2% dari pendapatan atau penerimaan tahunan. Belum lagi kerugian yang tidak tertulis di undang-undang: kepercayaan pelanggan yang hilang.

Yang bisa Anda lakukan, meski bukan orang IT

Anda tidak perlu bisa membuka server untuk ikut menjaga data. Kalau Anda pemilik usaha, pengurus sekolah, atau pengelola lembaga yang memakai situs atau aplikasi, ajukan pertanyaan ini ke vendor atau tim IT minggu ini:

"Apakah server kita sudah diperiksa untuk PHP2Shell dan pembaruan Node.js bulan ini? Boleh saya lihat catatannya?"
"Apakah database kita bisa diakses langsung dari internet?"
"Aplikasi apa saja yang masih menyala di server kita, dan mana yang sudah tidak dipakai?"
"Kalau pembaruan gagal, berapa lama kita bisa kembali ke kondisi sebelumnya?"
"Kalau data pelanggan bocor, siapa yang menyusun pemberitahuan 3 24 jam, dan ke siapa dikirim?"

Kalau jawabannya "nanti dicek" untuk semua pertanyaan, itulah tanda yang paling jelas bahwa audit kilat perlu dilakukan sekarang, bukan nanti.

Penutup

Celah keamanan akan selalu ada. Yang membedakan adalah seberapa cepat kita memeriksa, menambal, dan mencatat. UU PDP pada dasarnya tidak menuntut server yang mustahil dibobol. Ia menuntut kesungguhan: bahwa data orang lain yang kita simpan dijaga dengan langkah yang nyata, dan bahwa kita jujur ketika penjagaan itu gagal.

Data pribadi yang kita simpan adalah titipan. Menjaganya bukan hanya kewajiban hukum, tetapi juga amanah.