Celah RCE WordPress Core Diserang 62.969 Kali Sehari: Update ke 7.1.4 Sekarang

Celah RCE WordPress core yang ditambal di versi 7.1.4 adalah race condition saat proses update: selama jendela singkat itu, penyerang tanpa login bisa menjalankan kode PHP di server. Celah ini memengaruhi WordPress 4.7 sampai 7.1.3, dan dalam 24 jam Wordfence sudah memblokir 62.969 percobaan serangan.

WordPress dipakai sangat luas di Indonesia, dari blog pribadi, toko WooCommerce, sampai portal instansi dan kampus. Jadi meskipun syarat eksploitasinya sempit, skala pemindaiannya membuat celah ini layak ditangani hari ini, bukan minggu depan.

Artikel ini merangkum apa celahnya, siapa yang terdampak, versi aman per cabang, cara cek, mitigasi sementara, dan cara mendeteksi tanda serangan.

Apa sebenarnya celah ini?

WordPress merilis versi 7.1.4 pada 28 Oktober 2026 sebagai rilis keamanan. Isu paling serius di dalamnya dicatat di catatan rilis resmi sebagai "race condition during core updates that could lead to remote code execution", dilaporkan oleh peneliti Umut Bayram.

Celah ini tercatat sebagai advisory GitHub GHSA-4w3m-c66w-69mg dengan skor CVSS 8.1. Per artikel The Hacker News 30 Oktober 2026, celah ini belum punya nomor CVE.

Menurut penjelasan Wordfence yang dikutip The Hacker News, mekanismenya begini:

• Saat update core memakai paket penuh, WordPress membongkar file baru ke direktori sementara yang lokasinya bisa ditebak dan bisa diakses lewat web, yaitu di bawah wp-content/upgrade.
• Salinan sementara itu ikut membawa file installer WordPress.
• Penyerang yang meminta installer tersebut pada saat yang tepat, sebelum WordPress menghapus file sementara, bisa sampai ke eksekusi kode PHP.

Wordfence menyebutnya jendela waktu yang "sangat sempit". Tapi penyerang tidak perlu beruntung sekali; cukup terus mengulang permintaan sampai jendela itu terbuka.

Syarat apa yang harus terpenuhi agar bisa dieksploitasi?

Wordfence mencatat empat syarat. Semuanya harus terpenuhi bersamaan:

1. Ada update core dengan paket penuh yang berisi file installer.
2. Direktori staging bisa diakses publik lewat web dan PHP dijalankan di sana.
3. Path staging bisa ditebak atau ditemukan penyerang.
4. Penyerang selesai sebelum WordPress membersihkan file sementara.

Syarat kedua yang paling penting buat admin server. Di banyak hosting shared dan VPS dengan konfigurasi bawaan, folder di dalam wp-content memang bisa diakses lewat web dan menjalankan PHP. Itu sebabnya mitigasi di bawah fokus menutup akses web ke folder tersebut.

Seberapa ramai serangannya?

Saat 7.1.4 rilis, laporan awal seperti SecurityOnline masih menulis belum ada eksploitasi yang diketahui di lapangan, dan WordPress sendiri tidak membuka detail teknisnya. Gambarannya berubah dua hari kemudian.

The Hacker News (30 Oktober 2026) melaporkan Wordfence memblokir 62.969 serangan yang menyasar celah ini dalam 24 jam. Dua sumber serangan terbesar terus mem-polling sekelompok kecil situs selama kira-kira 14,5 jam. Mereka meminta path seperti setup-config.php dan mencoba banyak variasi nama direktori staging dan nama versi.

Polanya jelas: penyerang tidak menunggu admin update; mereka menunggu di depan pintu, berharap update terjadi saat mereka sedang mengetuk.

Siapa yang terdampak dan versi mana yang aman?

Semua WordPress 4.7 sampai 7.1.3 rentan terhadap race condition ini. WordPress memberi backport perbaikan ke cabang lama sebagai "courtesy", walaupun yang didukung aktif hanya versi terbaru. WordPress 4.6 ke bawah tidak lagi menerima update keamanan.

Ini versi aman per cabang menurut halaman versi resmi di wordpress.org:

Cabang	Versi aman	Jumlah celah yang berlaku
7.1	7.1.4	Semua (versi terbaru)
7.0	7.0.8	22
6.9	6.9.11	22
6.8 / 6.7	6.8.12 / 6.7.11	20
6.6	6.6.11	19
6.5 / 6.4	6.5.14 / 6.4.14	17
6.3 / 6.2 / 6.1 / 6.0	6.3.14 / 6.2.15 / 6.1.16 / 6.0.18	9
5.9	5.9.20	9
5.0 – 5.8	5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19	6
4.9 / 4.8 / 4.7	4.9.35 / 4.8.34 / 4.7.39	4 / 2 / 2
4.6 ke bawah	Tidak ada patch	Wajib upgrade cabang

Catatan soal angka: halaman wordpress.org menyebut total 22 kerentanan, sementara daftar yang dirinci berisi 17 isu keamanan plus pembaruan sertifikat root (akibat pencabutan eMudhra). SecurityOnline juga menulis 17 isu. Search Engine Journal memakai angka 22. Untuk keputusan patch, perbedaan ini tidak mengubah apa pun: semua cabang di atas perlu naik ke versi amannya.

Apa saja yang ikut ditambal di 7.1.4?

Selain race condition RCE, rilis ini menutup banyak stored XSS. Sebagian besar butuh akun minimal Contributor, jadi risikonya tinggi untuk situs multi-penulis, portal berita, dan situs kampus yang membuka banyak akun:

• Enam isu di Interactivity API, termasuk XSS lewat URL javascript:, binding event handler, dan prototype pollution di namespace konteks.
• Stored XSS di Customizer selective refresh, delimiter blok, label blok Comments Pagination dan Post Navigation Link, serta layar permintaan penghapusan data pribadi.
• Kebocoran informasi: perubahan Customizer yang belum terbit bisa terlihat oleh pengunjung tanpa login.
• Masalah izin: role kustom yang bisa memoderasi komentar bisa membaca, mengubah, dan menghapus catatan pada post yang tidak boleh mereka edit.

Bagaimana cara cek versi WordPress saya?

Kalau punya akses shell, WP-CLI paling cepat. Kalau tidak, baca langsung file version.php:

# Di folder root WordPress
wp core version

# Tanpa WP-CLI
grep "wp_version =" wp-includes/version.php

# Banyak situs di satu server (mis. /var/www)
find /var/www -path '*/wp-includes/version.php' \
  -exec grep -H "wp_version =" {} \;

Bandingkan hasilnya dengan tabel di atas. Misalnya 6.8.11 berarti masih rentan; harus 6.8.12 atau lebih baru.

Bagaimana cara patch dengan aman?

Masalahnya ironis: celah ini justru muncul saat proses update. Jadi urutan yang disarankan adalah tutup dulu akses web ke folder staging, baru jalankan update.

Langkah 1: blokir akses web ke wp-content/upgrade

Proses update WordPress menulis ke folder ini lewat filesystem, bukan lewat HTTP, sehingga memblokir akses web ke sana tidak mengganggu update. Untuk Nginx, tambahkan di blok server sebelum blok location ~ \.php$:

location ^~ /wp-content/upgrade/ {
    deny all;
}

Prefix ^~ penting agar aturan ini menang atas blok regex PHP. Untuk Apache, tambahkan di .htaccess root sebelum blok # BEGIN WordPress:

RedirectMatch 403 ^/wp-content/upgrade/

Uji hasilnya. Respons yang diharapkan adalah 403:

sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null -w "%{http_code}\n" https://situsanda.id/wp-content/upgrade/

Langkah 2: update core

# Naik ke rilis minor terbaru di cabang yang sama (mis. 6.9.x -> 6.9.11)
wp core update --minor

# Atau langsung ke versi terbaru
wp core update

# Verifikasi versi dan integritas file core
wp core version
wp core verify-checksums

Tanpa shell, buka Dasbor > Pembaruan. Situs dengan auto-update minor aktif biasanya sudah naik sendiri, tapi tetap cek versinya; jangan berasumsi.

Bagaimana mendeteksi apakah situs saya sudah diserang?

Wordfence menyarankan mencari permintaan mencurigakan ke file PHP di bawah wp-content/upgrade, serta akun admin, plugin, atau file PHP yang tidak dikenal. Perintah berikut membantu:

# 1) Permintaan ke file PHP di folder upgrade (log Nginx; sesuaikan path Apache)
zgrep -hE '/wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 2) Yang berhasil dijawab 200 perlu diperiksa lebih dulu
zgrep -hE '"(GET|POST) [^"]*/wp-content/upgrade/[^"]*\.php[^"]*" 200 ' /var/log/nginx/access.log*

# 3) Sisa file PHP di folder staging (normalnya kosong setelah update)
find wp-content/upgrade -type f -name '*.php'

# 4) Akun administrator, urutkan berdasarkan tanggal daftar
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 5) File PHP yang berubah sejak patch rilis (di luar cache)
find . -name '*.php' -newermt '2026-10-28' -not -path './wp-content/cache/*'

# 6) Plugin aktif; cari nama yang tidak Anda pasang
wp plugin list --status=active

Kalau menemukan respons 200 untuk installer di folder upgrade, admin baru yang tidak dikenal, atau file PHP asing, anggap situs sudah disusupi: isolasi, ganti semua kata sandi dan salt di wp-config.php, pulihkan dari backup bersih, lalu audit menyeluruh. Permintaan yang dijawab 403 atau 404 berarti pemindaian gagal, tapi IP-nya tetap layak diblokir.

Checklist cepat untuk admin

Langkah	Perintah / lokasi	Target
Cek versi	wp core version	Sesuai tabel versi aman
Tutup folder staging	Nginx location ^~ / Apache RedirectMatch	HTTP 403
Update core	wp core update	7.1.4 atau backport cabang
Cek integritas	wp core verify-checksums	Tidak ada file core berubah
Cek log	zgrep wp-content/upgrade	Tidak ada 200 ke file PHP
Cek akun	wp user list --role=administrator	Tidak ada admin asing
Rapikan akun	Pengguna > Semua Pengguna	Hapus Contributor/Author tak terpakai

Kalau server Anda juga menjalankan PHP versi lama, cek juga artikel kami tentang PHP2Shell (CVE-2026-109618 & CVE-2026-109619). Celah di level PHP dan celah di WordPress sering diserang oleh pemindai yang sama.

FAQ

Apakah celah ini punya nomor CVE?

Per laporan The Hacker News tanggal 30 Oktober 2026, belum. Rujukannya adalah advisory GitHub GHSA-4w3m-c66w-69mg dengan CVSS 8.1. Pantau NVD kalau organisasi Anda butuh nomor CVE untuk pelacakan.

Situs saya sudah auto-update. Apakah sudah aman?

Kemungkinan besar sudah naik versi, tapi pastikan dengan wp core version atau di Dasbor. Tetap jalankan pemeriksaan log dan akun admin, karena serangan menyasar momen update itu sendiri.

Apakah butuh login untuk mengeksploitasi?

Tidak. Menurut Wordfence, penyerang tanpa autentikasi bisa memanfaatkannya selama syarat jendela update terpenuhi. Yang butuh akun minimal Contributor adalah sebagian besar XSS lain di rilis ini.

Apakah memblokir wp-content/upgrade akan merusak update?

Tidak. WordPress menulis dan membaca folder itu lewat filesystem server. Aturan di Nginx atau Apache hanya menolak akses dari browser atau bot luar.

Saya masih memakai WordPress 4.6 atau lebih lama. Apa yang harus dilakukan?

Cabang itu tidak lagi menerima patch keamanan. Rencanakan upgrade ke cabang terbaru, uji dulu di staging, dan sementara itu terapkan pemblokiran folder upgrade serta WAF.

Sumber

• WordPress.org: Version 7.1.4 (daftar perbaikan dan versi backport)
• The Hacker News: WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours
• SecurityOnline: WordPress 7.1.4 Security Release
• Search Engine Journal: WordPress Announces Another Security Release, Version 7.1.4
• GitHub Advisory GHSA-4w3m-c66w-69mg