Cloudflare mengumumkan perlindungan WAF untuk dua kerentanan WordPress berisiko tinggi: CVE-2026-60137 berupa SQL injection pada WordPress 6.8 ke atas dan CVE-2026-63030 berupa unauthenticated remote code execution pada WordPress 6.9 ke atas dalam kondisi tertentu. Aturan firewall mengurangi risiko sementara, tetapi tidak memperbaiki kode. Pemilik situs harus memperbarui core, memeriksa log, menguji backup, dan mencari indikator kompromi.
Versi mana yang terdampak
Menurut Cloudflare, CVE-2026-60137 memengaruhi WordPress mulai versi 6.8 dan memungkinkan input yang dirancang khusus mengubah query database. CVE-2026-63030 memengaruhi versi 6.9 ke atas dan dapat memungkinkan eksekusi kode tanpa login melalui batch endpoint REST API ketika persistent object cache tidak digunakan.
WordPress 6.8.6 memperbaiki SQL injection karena jalur RCE tidak ada pada seri 6.8. WordPress 6.9.5, 7.0.2, dan 7.1 Beta 2 mendapat perbaikan untuk keduanya. Admin perlu memeriksa versi aktual dari dashboard atau WP-CLI, bukan mengandalkan ingatan maupun label paket hosting.
- 6.8 hingga sebelum 6.8.6: periksa paparan SQL injection.
- 6.9 hingga sebelum 6.9.5: periksa SQL injection dan RCE.
- 7.0 hingga sebelum 7.0.2: segera update ke rilis perbaikan.
- Beta tidak cocok untuk situs produksi.
WAF membantu, tetapi bukan patch
Cloudflare menyebarkan dua aturan yang menargetkan request SQL injection dan jalur RCE. Pelanggan free mendapat aturan melalui Free Ruleset, sedangkan paket berbayar perlu memastikan Managed Rules aktif serta action tetap Block. Override global ke Log dapat membuat aturan tidak menghentikan serangan.
Firewall bekerja di depan aplikasi dan dapat melewatkan variasi baru, trafik yang tidak melewati proxy, atau akses internal. Kode rentan tetap berada di server. Karena itu WAF adalah defense in depth selama maintenance, bukan alasan menunda update. Origin sebaiknya tidak dapat diakses langsung dari internet.
Urutan respons yang aman
Pertama, buat snapshot file serta database dan verifikasi backup sebelumnya dapat dipulihkan. Kedua, aktifkan maintenance window dan perbarui WordPress ke versi patched. Ketiga, uji login, editor, REST API, plugin, cache, checkout, serta form. Jangan menonaktifkan kontrol keamanan hanya agar update cepat selesai.
Setelah patch, periksa Security Events, access log, PHP log, cron, admin user, plugin aktif, mu-plugin, theme, uploads, wp-config, dan file core. Bandingkan checksum core melalui WP-CLI. Cari request aneh ke endpoint batch serta file PHP baru di lokasi yang tidak semestinya.
- Backup sebelum perubahan, tetapi jangan menimpa evidence.
- Patch core dari kanal resmi.
- Flush cache setelah verifikasi aplikasi.
- Ganti credential jika ada tanda kompromi.
Jika situs diduga sudah disusupi
Jangan hanya update lalu menganggap selesai. Isolasi situs, simpan log, dan tentukan kapan aktivitas mencurigakan dimulai. Periksa persistence melalui akun, cron, plugin palsu, web shell, database option, dan scheduled task hosting. Rotasi password WordPress, database, SSH, API, serta secret setelah host dinyatakan bersih.
Restore dari backup hanya jika tanggal serta integritasnya dipercaya. Data konten baru perlu diekspor dengan hati-hati agar payload tidak ikut kembali. Untuk situs bisnis atau data pelanggan, libatkan respons insiden dan ikuti kewajiban pemberitahuan yang berlaku.
Pencegahan setelah insiden
Aktifkan update minor otomatis, staging, monitoring file, least privilege, 2FA, dan backup offsite. Hapus plugin serta theme yang tidak dipakai. Batasi akses admin, XML-RPC bila tidak dibutuhkan, dan koneksi origin. Catat owner untuk patch agar notifikasi keamanan tidak kehilangan tanggung jawab.
TenFourSeven menyarankan latihan restore serta inventory versi setiap bulan. WAF, malware scanner, dan plugin keamanan saling melengkapi tetapi tidak menggantikan core hygiene. Kecepatan patch dan kemampuan memulihkan situs merupakan kontrol paling nyata untuk WordPress yang terhubung internet.
Untuk pengelola yang memakai shared hosting, cek juga apakah auto-update benar-benar berjalan pada akun tersebut dan apakah panel hosting menyimpan salinan sebelum perubahan. Pisahkan akun editor dari administrator, cabut akun mantan anggota tim, dan pastikan alamat email pemulihan masih aktif. Situs yang menggunakan CDN perlu menghapus cache setelah patch supaya pengujian tidak membaca respons lama. Catat versi WordPress, waktu update, hasil checksum, serta siapa yang melakukan verifikasi dalam log perubahan sederhana. Dokumentasi ini membantu ketika insiden berikutnya terjadi dan mencegah tim mengulang pemeriksaan yang sama tanpa bukti.
CVE-2026-60137 dan CVE-2026-63030 menunjukkan celah core WordPress dapat berkembang dari manipulasi query menuju eksekusi kode tanpa login. Aturan Cloudflare memberi lapisan proteksi cepat, tetapi update ke 6.8.6, 6.9.5, 7.0.2, atau rilis patched yang sesuai tetap menjadi tindakan utama. Backup, audit log, checksum, credential rotation, dan pencarian persistence diperlukan bila ada dugaan eksploitasi. Jangan menunggu dashboard terlihat rusak sebelum merespons.