Celah Update WordPress CVE-2026-119977 Dieksploitasi: Cek Versi dan Amankan Situs

CVE-2026-119977 adalah celah race condition di proses update WordPress Core yang memungkinkan penyerang tanpa login menjalankan kode PHP di server, tepat saat situs sedang di-update. Celah ini memengaruhi WordPress 4.7 sampai 7.1.3, sudah dieksploitasi, dan masuk katalog CISA KEV dengan tenggat 6 November 2026.

Yang membuatnya unik: celah ini justru terbuka ketika Anda melakukan hal yang benar, yaitu meng-update WordPress. Jadi urutan langkahnya penting. Artikel ini membahas cara kerjanya, versi mana yang aman, cara mengecek situs Anda, dan cara mencari jejak serangan di log.

Ringkasan cepat: apa yang perlu Anda tahu?

Item	Detail
ID	CVE-2026-119977 (advisory WordPress: GHSA-4w3m-c66w-69mg)
Jenis	Race condition TOCTOU (CWE-367) pada update Core paket penuh
Dampak	Eksekusi kode PHP jarak jauh tanpa autentikasi
Skor	CVSS 3.1: 8.1 (AV:N/AC:H/PR:N/UI:N). WordPress sendiri menilainya "Low"
Versi terdampak	WordPress Core 4.7 sampai 7.1.3
Versi aman	7.1.4 (rilis 28 Oktober 2026) atau backport per cabang, misalnya 7.0.8, 6.9.11, 6.8.12
Status	Dieksploitasi; masuk CISA KEV 3 November 2026, tenggat instansi federal AS 6 November 2026
Penemu	Umut Bayram

Bagaimana celah ini bekerja?

Saat WordPress melakukan update Core paket penuh, file versi baru diekstrak dulu ke folder sementara (staging) di wp-content/upgrade/, lalu dipindahkan menggantikan file lama. Pada versi terdampak, nama folder ini bisa ditebak karena mengikuti nama paket, dan di banyak server folder itu bisa diakses lewat web serta mengizinkan PHP berjalan.

Di dalam salinan paket itu ikut terbawa installer wp-admin/setup-config.php. Installer ini bisa berjalan tanpa konfigurasi situs. Menurut analisis ThreatDefence, PoC yang beredar memanfaatkannya untuk mempromosikan konfigurasi database milik penyerang menggantikan file asli, lalu menjalankan kode di server.

Jendela serangannya sempit, hanya hitungan detik. Karena itu skor CVSS memberi nilai Attack Complexity "High". Tapi penyerang tidak perlu beruntung sekali; bot cukup terus mengirim request ke path yang mungkin sampai ada situs yang sedang update. Patchstack juga menemukan bahwa rutin pembersihan versi lama menghapus index.php pelindung, sehingga di server yang mengaktifkan directory listing, nama folder bisa dibaca langsung.

Kenapa firewall plugin bisa terlewati?

Installer yang berada di folder staging berjalan tanpa memuat konfigurasi WordPress. Artinya firewall yang berjalan sebagai plugin WordPress biasa mungkin tidak pernah melihat request tersebut. Wordfence sendiri memperingatkan bahwa request PHP langsung bisa melewati firewall tingkat plugin tanpa mode Extended Protection. Perlindungan terbaik ada di level web server, CDN, atau WAF.

Siapa yang terdampak?

• Semua situs WordPress Core 4.7 sampai 7.1.3 yang belum menerima patch, termasuk situs staging, demo, dan situs lama yang terlupakan.
• Situs yang foldernya wp-content/upgrade bisa diakses publik dan mengizinkan eksekusi PHP. Ini konfigurasi umum di shared hosting.
• Situs dengan WordPress 4.6 atau lebih lama tidak lagi mendapat patch keamanan sama sekali, jadi harus dimigrasikan ke cabang yang didukung.
• Agensi dan penyedia hosting yang mengelola banyak instalasi: satu server bisa berisi puluhan situs dengan versi berbeda.

Perlu diingat: celah ini bukan di plugin atau tema, melainkan di Core. Situs dengan plugin minimal pun tetap terdampak.

Seberapa serius eksploitasinya?

Data yang tersedia sebagian besar berasal dari Wordfence dan mencerminkan percobaan yang diblokir, bukan pembobolan yang terkonfirmasi:

• Aturan firewall Wordfence aktif 28 Oktober pukul 20.30 UTC, dan request serangan pertama terlihat sembilan menit kemudian.
• Lebih dari 18.500 request ke path setup-config.php di staging dalam 21 jam pertama.
• Catatan Wordfence per 4 November menyebut 12.289 serangan diblokir dalam 24 jam terakhir. Media lain mengutip angka berbeda (13.095 dan 62.969 per 24 jam) karena diambil di waktu berbeda.
• CISA menambahkan celah ini ke KEV pada 3 November berdasarkan bukti eksploitasi aktif, tanpa menyebut pelaku atau kaitan ransomware.
• PoC yang berfungsi muncul di GitHub pada 4 November. Ada pula repo "bypass 7.1.4" palsu yang hanya berisi tautan unduhan pendek dan tampaknya umpan malware. Jangan menjalankannya.

Ada perbedaan penilaian yang patut dicatat. Wordfence (sebagai CNA) dan Tenable memberi skor 8.1, sementara advisory WordPress menilainya "Low" dan tidak mencantumkan nomor CVE. Perbedaan ini wajar karena sulitnya memenangkan balapan, tapi status KEV menunjukkan celah ini sudah dipakai di dunia nyata.

Versi mana yang aman?

WordPress 7.1.4 menambal 22 celah sekaligus, dan perbaikan di-backport ke cabang lama. Untuk celah update ini, cabang 4.7 ke atas menerima perbaikan.

Cabang	Versi aman minimum	Catatan
7.1	7.1.4	Rilis terbaru, satu-satunya yang didukung aktif
7.0	7.0.8	Menerima ke-22 perbaikan
6.9	6.9.11	Menerima ke-22 perbaikan
6.8 / 6.7	6.8.12 / 6.7.11	20 dari 22 perbaikan
6.0 sampai 6.6	6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18	Jumlah perbaikan makin sedikit
4.7 sampai 5.9	Contoh: 5.9.20, 5.0.31, 4.9.35, 4.7.39	Sebaiknya naik ke 7.1.4
4.6 ke bawah	Tidak ada	Wajib migrasi ke cabang yang didukung

Bagaimana cara mengecek versi WordPress?

Cara termudah: buka Dasbor → Pembaruan. Kalau punya akses SSH, gunakan WP-CLI dari folder instalasi:

# Versi Core yang terpasang
wp core version

# Cek apakah ada update yang tersedia
wp core check-update

# Tanpa WP-CLI: baca langsung dari file versi
grep "wp_version =" wp-includes/version.php

# Banyak situs di satu server (contoh: semua di /var/www)
for d in /var/www/*/; do
  [ -f "$d/wp-includes/version.php" ] && \
  echo "$d $(grep -oP "wp_version = '\K[^']+" "$d/wp-includes/version.php")"
done

Bagaimana cara update dengan aman?

Karena update itu sendiri membuka jendela serangan di versi lama, urutan yang disarankan adalah: blokir akses web ke folder staging dulu, baru update.

Langkah 1: blokir wp-content/upgrade di web server

# Nginx: di dalam blok server situs, lalu: nginx -t && systemctl reload nginx
location ^~ /wp-content/upgrade/ {
    deny all;
}

# Apache: di konfigurasi virtual host (sesuaikan path DocumentRoot)
<Directory "/var/www/html/wp-content/upgrade">
    Require all denied
</Directory>

Lebih baik taruh aturan di konfigurasi server atau CDN daripada mengandalkan .htaccess di dalam folder itu. Di Cloudflare atau WAF lain, blokir request yang path-nya diawali /wp-content/upgrade/. Lalu pastikan aturannya jalan:

# Harus mengembalikan 403, bukan daftar isi folder atau 200
curl -s -o /dev/null -w "%{http_code}\n" https://situsanda.id/wp-content/upgrade/

Langkah 2: update dan verifikasi

wp core update
wp core version            # pastikan 7.1.4 atau versi aman cabang Anda
wp core verify-checksums   # file Core harus cocok dengan rilis resmi

Update otomatis bisa gagal diam-diam, jadi jangan berasumsi situs sudah aman sebelum mengecek versinya. Kalau memakai managed hosting, tanyakan mitigasi apa yang mereka pasang; IONOS dan Pantheon misalnya melaporkan mitigasi di tingkat platform, tapi itu bukan pengganti update.

Bagaimana mendeteksi apakah situs sudah dibobol?

Belum ada IOC tetap (IP, user agent, atau nama webshell) yang dipublikasikan, jadi perburuan mengandalkan pola path dan waktu. Pengunjung normal tidak pernah meminta file PHP di folder staging, jadi setiap hit layak diperiksa, dan respons 200 adalah prioritas.

# 1) Request ke file PHP di folder staging (termasuk log lama terkompresi)
zgrep -hE '"(GET|POST) /wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log* | head -50

# 2) Respons 200 = prioritas tinggi
zgrep -hE '"(GET|POST) /wp-content/upgrade/[^ ]*\.php[^"]*" 200 ' /var/log/nginx/access.log*

# 3) Sisa file di folder staging (normalnya hanya index.php)
find wp-content/upgrade -mindepth 1 ! -name index.php

# 4) File PHP yang tidak semestinya ada di uploads
find wp-content/uploads -name "*.php"

# 5) Waktu update vs waktu ubah wp-config.php
#    Update Core tidak pernah menulis wp-config.php
stat -c '%y %n' wp-includes/version.php wp-config.php

# 6) Admin dan plugin yang tidak dikenal
wp user list --role=administrator --fields=ID,user_login,user_registered
wp plugin list

Jika wp-config.php berubah pada waktu yang sama dengan update, periksa nilai DB_HOST, DB_NAME, DB_USER, dan $table_prefix. Tanda lain yang perlu dicari: proses PHP atau web server yang menjalankan sh, curl, atau wget, serta koneksi keluar ke port 3306 di alamat publik yang bukan server database Anda.

Kalau menemukan tanda pembobolan?

1. Matikan situs dan simpan salinan file, database, dan log sebagai bukti.
2. Periksa situs lain di server yang sama dan kredensial yang tersimpan di sana.
3. Bangun ulang dari rilis resmi yang sudah ditambal, pasang ulang plugin dan tema dari sumber resmi, pulihkan konten dari backup sebelum update.
4. Ganti password database, salt dan key di wp-config.php, password admin, serta API key dan kredensial hosting. Kalau situs menyimpan API key layanan pihak ketiga, rotasi juga; kasus LLMjacking menunjukkan betapa mahalnya kunci yang bocor.

Pertanyaan yang sering diajukan

Situs saya sudah update otomatis, apakah aman?

Kemungkinan besar sudah tertambal, tapi cek versinya dengan wp core version atau dasbor. Update yang berjalan di versi lama tetap melewati jendela rawan, jadi tetap periksa log di sekitar waktu update.

Apakah tenggat 6 November berlaku untuk situs di Indonesia?

Tidak secara hukum. Tenggat itu berlaku bagi instansi federal sipil AS. Namun status KEV adalah sinyal kuat bahwa celah ini sudah diserang, sehingga semua pemilik situs sebaiknya menambal secepatnya.

Saya pakai Wordfence versi gratis, apakah terlindungi?

Belum. Aturan firewall untuk pengguna Wordfence Free baru dijadwalkan 27 November 2026. Lagi pula, request langsung ke file PHP staging bisa melewati firewall level plugin. Update dan blokir folder di web server.

Apakah memblokir wp-content/upgrade mengganggu proses update?

Tidak. Proses update berjalan di sisi server lewat sistem file, bukan lewat request HTTP ke folder itu. Aturan ini hanya menutup akses dari luar.

Saya menemukan repo GitHub "bypass 7.1.4", perlu dicoba?

Jangan. Repo seperti itu dilaporkan hanya berisi tautan unduhan pendek dan tampaknya umpan malware yang menyasar admin dan peneliti.

Celah ini bergabung dengan daftar CVE yang dieksploitasi cepat setelah patch rilis, seperti celah GitLab CVE-2026-97229. Polanya sama: jarak antara patch dan serangan kini hitungan menit, bukan minggu.

Sumber

• WordPress.org: Version 7.1.4 (daftar perbaikan dan versi backport)
• ThreatDefence: WordPress CVE-2026-119977, Hunting the 7.1.4 Upgrade RCE
• SOC Prime: CVE-2026-119977 WordPress Core RCE Exploited
• Tech Insider: WordPress CVE-2026-119977, CISA Sets Nov. 6 Deadline
• WindowsForum: CISA Flags WordPress CVE-2026-119977 as Actively Exploited
• nFlo: CVE-2026-119977, RCE During WordPress Core Upgrades