CVE-2026-119977 WordPress: Celah Saat Update Core Sudah Dipakai Menyerang, Update ke 7.1.4

Jawaban langsung: CVE-2026-119977 membuat penyerang tanpa login bisa menjalankan kode di server WordPress saat update core berjalan. CISA memasukkan celah ini ke katalog KEV pada 3 November 2026, jadi celah ini sudah dipakai menyerang. Hari ini, cek versi WordPress, update ke 7.1.4 atau rilis aman di cabang Anda, lalu cari tanda di log.

Celah ini ada di WordPress 4.7 sampai 7.1.3. Skor CVSS 3.1 dari Wordfence adalah 8.1, tetapi CISA menulis eksploitasi "active" dan dampak teknis "total". Situs yang sudah update otomatis tetap perlu cek tanda, karena jendela update jatuh di masa serangan.

Kondisi utama: Situs memakai WordPress core di bawah rilis aman, dan web server menyajikan folder wp-content/upgrade/. Batas: Artikel ini tidak memuat isi request, payload, atau urutan serangan.

Kami membaca catatan CVE-2026-119977, advisory Wordfence, pengumuman WordPress 7.1.4, CISA KEV, dan API versi resmi WordPress pada 4 November 2026, pukul 06.35 sampai 06.50 WIB. Kami menguji 3 skrip cek, update core, dan 3 aturan blokir di container podman dengan image resmi WordPress, WP-CLI, MariaDB, dan nginx. Kami tidak menguji serangan.

Masalah: celah di proses update yang seharusnya melindungi Anda

Update core adalah langkah keamanan utama WordPress, tetapi celah ini ada di proses update itu sendiri.

Saat update core berjalan, WordPress mengunduh paket rilis dan membongkarnya ke folder wp-content/upgrade/. Folder ini ada di dalam folder web, jadi web server biasanya menyajikannya. Proses ini hanya berlangsung beberapa detik, dan advisory Wordfence menyebutnya jendela upgrade.

WordPress merilis 7.1.4 pada 28 Oktober 2026, bersama rilis keamanan untuk cabang 4.7 sampai 7.0. Catatan CVE terbit 31 Oktober. Pada 3 November, CISA menambah celah ini ke CISA KEV dengan batas waktu 6 November untuk instansi federal AS.

Per 4 November 2026, halaman advisory Wordfence menulis 13.330 serangan yang diblokir dalam 24 jam terakhir. Angka ini hanya mencakup situs yang memakai firewall Wordfence.

Cara kerja: folder staging yang bisa ditebak

Bagian ini memakai ringkasan resmi dan isi patch. Tujuannya membantu Anda memilih langkah, bukan menjelaskan cara menyerang.

Ringkasan dari catatan CVE

Menurut catatan CVE-2026-119977, update core dengan paket penuh memakai path staging yang bisa ditebak dan bisa dibuka lewat web. Akibatnya penyerang tanpa login bisa menjalankan kode di server selama jendela upgrade. Kelas celah ini adalah CWE-367, race condition antara waktu cek dan waktu pakai.

Vektor CVSS menulis AC:H, artinya serangan hanya berhasil pada saat yang tepat. Status KEV menunjukkan bahwa penyerang tetap berhasil di lapangan.

Apa yang diubah patch

Kami membandingkan kode di image resmi 7.1.3 dan 7.1.4. Patch membuat 3 perubahan:

• Nama folder kerja di wp-content/upgrade/ mendapat 16 karakter acak (class-wp-upgrader.php).
• Folder upgrade mendapat berkas index.php, agar isinya tidak bisa didaftar lewat web.
• Update tidak pernah menyalin wp-config.php dari folder kerja ke situs (update-core.php).

Analisa Rama Digital: perubahan ke-3 ada di berkas update dari paket baru, jadi sudah berlaku saat update ke 7.1.4. Perubahan ke-1 dan ke-2 berlaku mulai update sesudahnya. Batas: kami membaca kode dan tidak menguji serangan.

Status eksploitasi per 4 November 2026

Sumber	Status
CISA KEV	Masuk 3 November 2026, batas waktu 6 November 2026
CISA SSVC di catatan CVE	Exploitation: active, Technical Impact: total
Wordfence	13.330 serangan diblokir dalam 24 jam
WordPress.org	Minta semua situs update segera

Skor 8.1 masuk kelas High. Kami tetap menulis peringatan kritis, karena celah ini sudah dipakai, tanpa login, dan berakhir dengan eksekusi kode.

Siapa yang paling berisiko

Risiko bergantung pada cara situs Anda update dan cara server menutup folder upgrade.

Kondisi situs	Risiko	Alasan
Update otomatis mati, versi di bawah rilis aman	Tertinggi	Situs tertahan di versi rentan. Update manual berikutnya membuka jendela yang sama
Update antara 28 Oktober dan 3 November, log belum dicek	Tinggi	Jendela update jatuh di masa serangan
Banyak situs WordPress di 1 server	Tinggi	Banyak jendela update. 1 situs yang dibobol membuka server untuk semua situs
nginx dengan aturan prefix biasa	Periksa	Di uji kami, berkas .php di folder upgrade tetap terbuka
Aturan blokir di dalam folder upgrade	Periksa	Di uji kami, update menghapus .htaccess di folder itu
7.1.4, folder diblokir, log bersih	Rendah	Tetap cari tanda dari waktu sebelum update

Server WordPress sering juga menjalankan runtime PHP dan panel hosting. Patch juga komponen itu, misalnya untuk peringatan PHP2Shell dan celah Control Web Panel CVE-2026-77876.

Versi rentan dan versi aman

Semua versi 4.7.0 sampai 7.1.3 rentan, kecuali rilis aman di cabang masing-masing. Pakai tabel ini untuk menentukan tindakan.

Versi WordPress	Status per 4 November 2026	Rilis aman
7.1.0 sampai 7.1.3	Rentan	7.1.4
7.0.0 sampai 7.0.7	Rentan	7.0.8 atau 7.1.4
6.9.0 sampai 6.9.10	Rentan	6.9.11
6.8.0 sampai 6.8.11	Rentan	6.8.12
6.7.0 sampai 6.7.10, 6.6.0 sampai 6.6.10	Rentan	6.7.11, 6.6.11
6.5, 6.4, 6.3	Rentan di bawah x.14	6.5.14, 6.4.14, 6.3.14
6.2, 6.1, 6.0	Rentan	6.2.15, 6.1.16, 6.0.18
5.0 sampai 5.9	Rentan	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, 5.9.20
4.7 sampai 4.9	Rentan	4.7.39, 4.8.34, 4.9.35
Di bawah 4.7	Di luar CVE ini, tanpa patch keamanan	Naik ke 7.1.4

Data versi berasal dari catatan CVE-2026-119977, advisory Wordfence, dan API versi resmi WordPress. Menurut pengumuman WordPress 7.1.4, WordPress 7.2 Beta 3 juga sudah memuat perbaikan ini.

Prasyarat sebelum mulai

• Akses SSH dengan sudo ke server, atau akun administrator di dasbor WordPress.
• WP-CLI di server bila Anda memakai perintah wp. Langkah 1 dan 3 juga bisa lewat dasbor.
• Backup database dan berkas terbaru, misalnya snapshot VPS atau backup dari panel hosting.
• Akses ke log akses web server, misalnya /var/log/apache2/ atau /var/log/nginx/.
• Daftar semua situs WordPress yang Anda kelola, termasuk situs staging dan situs lama.

Langkah 1: Cek versi WordPress

Simpan skrip ini sebagai cek-versi-wp.sh di folder ~/cek. Skrip membaca $wp_version dari wp-includes/version.php, lalu membandingkannya dengan rilis aman di cabang yang sama.

#!/usr/bin/env bash
# Cek versi WordPress core terhadap CVE-2026-119977 (RCE saat jendela upgrade, CISA KEV 3 November 2026).
# Data: catatan CVE dari CNA Wordfence dan API resmi api.wordpress.org (versi aman per cabang).
# Pakai di server: sudo bash cek-versi-wp.sh /var/www/html
# Pakai untuk versi yang Anda salin dari server lain: bash cek-versi-wp.sh 6.9.10 7.0.8 7.1.4
# Skrip hanya membaca berkas. Skrip tidak mengubah apa pun.

# Versi aman pertama per cabang 4.7 sampai 7.1.
declare -A AMAN=(
  [4.7]=4.7.39 [4.8]=4.8.34 [4.9]=4.9.35 [5.0]=5.0.31 [5.1]=5.1.28 [5.2]=5.2.30 [5.3]=5.3.27
  [5.4]=5.4.25 [5.5]=5.5.24 [5.6]=5.6.23 [5.7]=5.7.21 [5.8]=5.8.19 [5.9]=5.9.20 [6.0]=6.0.18
  [6.1]=6.1.16 [6.2]=6.2.15 [6.3]=6.3.14 [6.4]=6.4.14 [6.5]=6.5.14 [6.6]=6.6.11 [6.7]=6.7.11
  [6.8]=6.8.12 [6.9]=6.9.11 [7.0]=7.0.8 [7.1]=7.1.4
)

# lebih_kecil A B: benar bila versi A di bawah versi B.
lebih_kecil() { [ "$1" != "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]; }

cek() {
  local v="$1" cabang aman
  if ! [[ $v =~ ^[0-9]+\.[0-9]+(\.[0-9]+)?$ ]]; then
    printf '%-9s TIDAK DIKENAL, cocokkan manual dengan tabel versi aman\n' "$v"
    return
  fi
  [[ $v =~ ^[0-9]+\.[0-9]+$ ]] && v="$v.0"
  cabang=${v%.*}
  aman=${AMAN[$cabang]}
  if [ -n "$aman" ]; then
    if lebih_kecil "$v" "$aman"; then
      if [ "$aman" = 7.1.4 ]; then
        printf '%-9s RENTAN CVE-2026-119977 -> update ke 7.1.4\n' "$v"
      else
        printf '%-9s RENTAN CVE-2026-119977 -> update ke %s atau 7.1.4\n' "$v" "$aman"
      fi
    else
      printf '%-9s AMAN untuk CVE-2026-119977 (cabang %s)\n' "$v" "$cabang"
    fi
  elif lebih_kecil "$v" 4.7.0; then
    printf '%-9s DI LUAR CVE INI, tetapi tanpa patch keamanan -> update ke 7.1.4\n' "$v"
  else
    printf '%-9s DI ATAS 7.1, cocokkan manual dengan pengumuman WordPress\n' "$v"
  fi
}

DIR=/var/www/html
VERSI=()
for x in "$@"; do
  if [ -d "$x" ]; then DIR="$x"; else VERSI+=("$x"); fi
done

if (( ${#VERSI[@]} > 0 )); then
  for v in "${VERSI[@]}"; do cek "$v"; done
  exit 0
fi

BERKAS="$DIR/wp-includes/version.php"
if [ ! -r "$BERKAS" ]; then
  echo "Berkas versi tidak terbaca: $BERKAS"
  echo "Tulis folder WordPress sebagai argumen, contoh: sudo bash cek-versi-wp.sh /var/www/html"
  exit 1
fi
v=$(sed -nE "s/^\\\$wp_version *= *'([^']+)'.*/\1/p" "$BERKAS" | head -n1)
echo "Folder WordPress: $DIR"
cek "${v:-tidak-terbaca}"

# Di server: baca versi dari folder WordPress
sudo bash cek-versi-wp.sh /var/www/html
# Cek versi yang Anda salin dari situs lain
bash cek-versi-wp.sh 6.8.11 6.9.10 7.0.8 7.1.4
# Cara manual tanpa skrip
grep wp_version /var/www/html/wp-includes/version.php
cd /var/www/html && sudo -u www-data wp core version

Dari dasbor, buka Dasbor > Pembaruan. Halaman ini menulis versi Anda dan versi terbaru.

Cek hasil: "RENTAN" berarti lanjut ke langkah 2 dan 3 hari ini. "AMAN" tetap berarti jalankan langkah 5, karena update Anda mungkin jatuh di masa serangan.

Langkah 2: Cek folder upgrade dan update otomatis

Skrip ini menjawab 2 pertanyaan: apakah web menyajikan folder upgrade, dan apakah update otomatis core aktif.

Simpan skrip ini sebagai cek-upgrade-wp.sh. Skrip menulis 2 berkas teks uji kecil, memintanya lewat HTTP, lalu menghapus keduanya. Berkas kontrol di wp-content/ memastikan alamat situs benar.

#!/usr/bin/env bash
# Cek 2 hal untuk CVE-2026-119977: apakah web menyajikan folder wp-content/upgrade, dan apakah update otomatis core aktif.
# Pakai di server: sudo bash cek-upgrade-wp.sh /var/www/html https://contoh.co.id
# Skrip menulis 2 berkas teks uji kecil, meminta keduanya lewat HTTP, lalu menghapus keduanya.

DIR="${1:-/var/www/html}"
URL="${2%/}"
if [ ! -r "$DIR/wp-config.php" ] && [ ! -r "$DIR/../wp-config.php" ]; then
  echo "wp-config.php tidak ada di $DIR. Tulis folder WordPress sebagai argumen 1."
  exit 1
fi
if [ -z "$URL" ]; then
  echo "Tulis alamat situs sebagai argumen 2, contoh: https://contoh.co.id"
  exit 1
fi
CONF="$DIR/wp-config.php"
[ -r "$CONF" ] || CONF="$DIR/../wp-config.php"

echo "1. Update otomatis core"
konstanta() { grep -E "^[^/#]*define\( *['\"]$1['\"] *, *$2" "$CONF" >/dev/null; }
mati=0
if konstanta AUTOMATIC_UPDATER_DISABLED true; then echo "   MATI: AUTOMATIC_UPDATER_DISABLED = true"; mati=1; fi
if konstanta WP_AUTO_UPDATE_CORE false; then echo "   MATI: WP_AUTO_UPDATE_CORE = false"; mati=1; fi
if konstanta DISALLOW_FILE_MODS true; then echo "   MATI: DISALLOW_FILE_MODS = true"; mati=1; fi
d="$(cd "$DIR" && pwd)"
while [ -n "$d" ]; do
  for vcs in .git .svn .hg .bzr; do
    if [ -e "$d/$vcs" ]; then echo "   MATI: ada $d/$vcs, WordPress tidak update otomatis di folder version control"; mati=1; fi
  done
  [ "$d" = / ] && break
  d="$(dirname "$d")"
done
if konstanta DISABLE_WP_CRON true; then echo "   PERIKSA: DISABLE_WP_CRON = true, pastikan cron server memanggil wp-cron.php"; fi
(( mati == 0 )) && echo "   AKTIF menurut wp-config.php (update keamanan berjalan lewat WP-Cron)"

echo "2. Folder wp-content/upgrade lewat web"
UP="$DIR/wp-content/upgrade"
buat_up=0
if [ ! -d "$UP" ]; then mkdir -p "$UP" && buat_up=1; fi
nama="rd-cek-$(date +%s)-$RANDOM.txt"
echo "uji" > "$DIR/wp-content/$nama"
echo "uji" > "$UP/$nama"
bersih() { rm -f "$DIR/wp-content/$nama" "$UP/$nama"; (( buat_up == 1 )) && rmdir "$UP" 2>/dev/null; }
trap bersih EXIT
kode_kontrol=$(curl -sk -o /dev/null -w '%{http_code}' --max-time 15 "$URL/wp-content/$nama")
kode=$(curl -sk -o /dev/null -w '%{http_code}' --max-time 15 "$URL/wp-content/upgrade/$nama")
echo "   Kontrol wp-content/$nama: HTTP $kode_kontrol"
echo "   Uji wp-content/upgrade/$nama: HTTP $kode"
if [ "$kode_kontrol" != 200 ]; then
  echo "   TIDAK PASTI: berkas kontrol tidak terbuka. Cek alamat situs atau folder WordPress."
elif [ "$kode" = 200 ]; then
  echo "   TERBUKA: web menyajikan folder upgrade. Pasang aturan blokir di langkah 4."
else
  echo "   DIBLOKIR: web tidak menyajikan folder upgrade (HTTP $kode)."
fi

sudo bash cek-upgrade-wp.sh /var/www/html https://contoh.co.id

Image resmi WordPress menyajikan folder upgrade dengan HTTP 200. Skrip juga membaca AUTOMATIC_UPDATER_DISABLED, WP_AUTO_UPDATE_CORE, DISALLOW_FILE_MODS, dan folder version control seperti .git. Setiap item ini mematikan update otomatis core.

Cek hasil: "TERBUKA" berarti pasang langkah 4. "MATI" berarti situs tidak update sendiri, jadi langkah 3 wajib manual.

Langkah 3: Update ke 7.1.4 atau rilis aman di cabang Anda

Hanya update yang menutup celah ini. Bila bisa, pasang aturan langkah 4 lebih dulu, lalu update.

# 1. Buat backup lewat panel hosting atau snapshot VPS lebih dulu.
cd /var/www/html
# 2. Update core ke versi terbaru (7.1.4)
sudo -u www-data wp core update
# 3. Cek berkas core terhadap checksum resmi. Baca setiap baris Warning.
sudo -u www-data wp core verify-checksums
# 4. Cek lagi versi
sudo bash ~/cek/cek-versi-wp.sh /var/www/html

1. Buat backup database dan berkas lebih dulu.
2. Update lewat Dasbor > Pembaruan, atau lewat WP-CLI.
3. Jalankan wp core verify-checksums. Baca setiap baris Warning, bukan hanya baris Success.
4. Jalankan lagi cek-versi-wp.sh. Hasil yang benar: "AMAN".
5. Ulangi di setiap situs, termasuk staging dan situs lama.

Di uji kami, update 7.1.3 ke 7.1.4 memakai paket partial wordpress-7.1.4-partial-3.zip. Reinstall dengan --force memakai paket penuh. Kedua update berhasil dengan aturan langkah 4 aktif.

Untuk tetap di cabang lama, misalnya 6.8.12, WP-CLI punya opsi wp core update --minor. Kami tidak menguji opsi ini. Rilis cabang lama menutup celah ini, tetapi rencanakan naik ke 7.1 pada jadwal maintenance berikutnya.

Cek hasil: skrip versi menulis "AMAN" di setiap situs, verify-checksums tanpa baris Warning, dan beranda terbuka normal.

Langkah 4: Blokir folder upgrade lewat web

Langkah ini tidak menutup celah. Langkah ini menutup jalur web ke folder upgrade sebagai lapisan tambahan, sebelum dan sesudah update.

pengumuman WordPress 7.1.4 dan catatan CVE tidak menulis workaround resmi. Analisa Rama Digital: kami menyusun aturan ini dari isi patch. Kondisi: web server membaca aturan dari .htaccess atau dari konfigurasi server. Batas: aturan ini tidak membersihkan situs yang sudah dibobol.

4a. Apache dan hosting dengan .htaccess

Taruh 5 baris ini di baris paling atas .htaccess utama, di luar blok # BEGIN WordPress. WordPress menulis ulang isi blok itu, tetapi tidak menyentuh baris di luarnya.

# BEGIN Blokir folder upgrade
<IfModule mod_alias.c>
RedirectMatch 403 /wp-content/upgrade/
</IfModule>
# END Blokir folder upgrade

# Simpan 5 baris di atas sebagai ~/cek/aturan-upgrade.txt, lalu:
cd /var/www/html && sudo cp .htaccess .htaccess.bak
cat ~/cek/aturan-upgrade.txt .htaccess.bak | sudo tee .htaccess >/dev/null
head -n 6 .htaccess
sudo bash ~/cek/cek-upgrade-wp.sh /var/www/html https://contoh.co.id
# Batal: kembalikan salinan
# sudo cp .htaccess.bak .htaccess

Jangan taruh aturan di dalam folder wp-content/upgrade/. Di uji kami, update core menghapus berkas .htaccess di folder itu. Aturan di .htaccess utama bertahan sesudah update partial dan sesudah reinstall paket penuh.

Bila Anda punya akses ke konfigurasi Apache, blok ini juga memberi HTTP 403 di uji kami. Ganti path dengan folder situs Anda.

# /etc/apache2/conf-enabled/blokir-upgrade.conf (Debian dan Ubuntu)
<Directory /var/www/html/wp-content/upgrade>
    Require all denied
</Directory>

# Cek sintaks, lalu muat ulang Apache tanpa memutus koneksi
sudo apache2ctl -t && sudo apache2ctl -k graceful

4b. nginx

Pakai pengubah ^~. Di uji kami, aturan prefix biasa memblokir berkas .txt, tetapi berkas .php tetap terbuka, karena blok regex location ~ \.php$ menang. Aturan dengan ^~ memblokir keduanya.

# Di blok server situs, sebelum blok location ~ \.php$
location ^~ /wp-content/upgrade/ {
    deny all;
}

# Cek sintaks, lalu muat ulang nginx
sudo nginx -t && sudo nginx -s reload

Kami tidak menguji LiteSpeed dan OpenLiteSpeed. Di server apa pun, cek hasilnya dengan skrip langkah 2.

Cek hasil: skrip langkah 2 menulis "DIBLOKIR", dan beranda tetap HTTP 200.

Langkah 5: Cari tanda pemakaian

Celah ini sudah dipakai sebelum banyak situs update, jadi cari tanda dari 28 Oktober sampai hari ini.

Simpan skrip ini sebagai cek-tanda-wp.sh. Skrip membaca log akses web, folder upgrade, wp-config.php, dan folder wp-content/uploads. Skrip mencetak jumlah request dan IP, bukan isi request.

#!/usr/bin/env bash
# Cari tanda pemakaian CVE-2026-119977 di log akses web, folder upgrade, wp-config.php, dan folder uploads.
# Pakai: sudo bash cek-tanda-wp.sh /var/www/html [berkas log lain ...]
# Skrip hanya membaca berkas. Skrip mencetak jumlah request dan IP, bukan isi request.

DIR="${1:-/var/www/html}"
shift
LOGS=("$@")
if (( ${#LOGS[@]} == 0 )); then
  for f in /var/log/apache2/access.log* /var/log/nginx/access.log* /var/log/httpd/access_log*; do
    [ -e "$f" ] && LOGS+=("$f")
  done
fi
tanda=0
ip_teratas() { awk '{print $1}' | sort | uniq -c | sort -rn | head -n 5 | awk '{printf "   IP %s: %s\n", $2, $1}'; }

echo "1. Request ke /wp-content/upgrade/ di log akses web"
if (( ${#LOGS[@]} == 0 )); then
  echo "   Log akses tidak ada. Tulis path log sebagai argumen."
  echo "2. Request ke setup-config.php di dalam folder upgrade"
  echo "   Log akses tidak ada."
else
  # Abaikan berkas uji dari skrip langkah 2.
  baris=$(zcat -f "${LOGS[@]}" 2>/dev/null | grep -F '/wp-content/upgrade/' | grep -v 'rd-cek-')
  jumlah=$(printf '%s' "$baris" | grep -c .)
  if (( jumlah > 0 )); then
    sukses=$(printf '%s\n' "$baris" | awk '$9 == 200' | grep -c .)
    echo "   TANDA: $jumlah request, $sukses dengan HTTP 200"
    printf '%s\n' "$baris" | ip_teratas
    tanda=$((tanda + 1))
  else
    echo "   0 request"
  fi
  echo "2. Request ke setup-config.php di dalam folder upgrade"
  jumlah=$(printf '%s' "$baris" | grep -c 'setup-config\.php')
  if (( jumlah > 0 )); then
    echo "   TANDA: $jumlah request"
    printf '%s\n' "$baris" | grep 'setup-config\.php' | ip_teratas
    tanda=$((tanda + 1))
  else
    echo "   0 request"
  fi
fi

echo "3. Isi folder wp-content/upgrade (selain index.php)"
UP="$DIR/wp-content/upgrade"
if [ -d "$UP" ]; then
  sisa=$(find "$UP" -mindepth 1 -maxdepth 1 ! -name index.php ! -name 'rd-cek-*' | wc -l)
  echo "   $sisa item"
  find "$UP" -mindepth 1 -maxdepth 1 ! -name index.php ! -name 'rd-cek-*' -printf '   %TY-%Tm-%Td %TH:%TM  %f\n' | head -n 5
  liar=$(find "$UP" -name wp-config.php 2>/dev/null | wc -l)
  if (( liar > 0 )); then
    echo "   TANDA: $liar berkas wp-config.php di dalam folder upgrade"
    tanda=$((tanda + 1))
  fi
else
  echo "   Folder tidak ada"
fi

echo "4. wp-config.php"
CONF="$DIR/wp-config.php"
[ -r "$CONF" ] || CONF="$DIR/../wp-config.php"
if [ -r "$CONF" ]; then
  echo "   Terakhir berubah: $(date -r "$CONF" '+%Y-%m-%d %H:%M')"
  for k in DB_HOST DB_NAME DB_USER; do
    nilai=$(grep -E "define\( *['\"]$k['\"]" "$CONF" | head -n1 | sed -E "s/.*define\( *['\"]$k['\"] *, *//; s/ *\);.*//")
    echo "   $k: ${nilai:-tidak ada}"
  done
  echo "   Pastikan 3 nilai ini milik database Anda sendiri."
else
  echo "   wp-config.php tidak terbaca"
fi

echo "5. Berkas PHP di wp-content/uploads"
if [ -d "$DIR/wp-content/uploads" ]; then
  php=$(find "$DIR/wp-content/uploads" -type f -iname '*.php*' ! -name index.php 2>/dev/null)
  jumlah=$(printf '%s' "$php" | grep -c .)
  if (( jumlah > 0 )); then
    echo "   TANDA: $jumlah berkas"
    printf '%s\n' "$php" | head -n 5 | sed 's/^/   /'
    tanda=$((tanda + 1))
  else
    echo "   0 berkas"
  fi
else
  echo "   Folder tidak ada"
fi

echo
if (( tanda > 0 )); then
  echo "Hasil: $tanda TANDA. Lanjut ke respons insiden."
else
  echo "Hasil: tidak ada TANDA dari 5 cek ini. Lanjut cek checksum dan akun admin."
fi

# Cek log akses, folder upgrade, wp-config.php, dan uploads
sudo bash cek-tanda-wp.sh /var/www/html
# Log di lokasi lain, misalnya log per situs
sudo bash cek-tanda-wp.sh /var/www/html /var/log/nginx/contoh.co.id.access.log*
# Cek berkas core dan daftar admin
cd /var/www/html
sudo -u www-data wp core verify-checksums
sudo -u www-data wp user list --role=administrator --fields=user_login,user_registered
# Jam update core: waktu ubah version.php
date -r wp-includes/version.php '+%Y-%m-%d %H:%M'

Pengunjung biasa dan proses update WordPress tidak meminta folder upgrade lewat web. Jadi setiap request ke /wp-content/upgrade/ dari IP luar patut dicek. Nama setup-config.php berasal dari rujukan kode di catatan CVE-2026-119977.

Untuk tahu jam update core, lihat waktu ubah wp-includes/version.php. Menurut komentar di update-core.php, update menyalin berkas ini paling akhir. Bandingkan jam itu dengan jam request di log.

Cek hasil: skrip menulis "tidak ada TANDA", verify-checksums tanpa Warning, dan daftar admin hanya berisi orang yang Anda kenal. Log bisa dihapus penyerang, jadi tidak ada tanda belum berarti aman.

Bila ada 1 tanda saja, ubah situs ke mode maintenance, lalu simpan log web, isi folder upgrade, dan wp-config.php sebagai bukti. Ganti password admin, database, hosting, dan SFTP, lalu ganti salt dengan wp config shuffle-salts agar semua sesi login berakhir. Pulihkan dari backup bersih sebelum 28 Oktober, lalu update ke 7.1.4 sebelum situs kembali online.

Bila situs menyimpan data pelanggan, UU 27/2022 tentang Pelindungan Data Pribadi mewajibkan pemberitahuan tertulis paling lambat 3 kali 24 jam sesudah kebocoran data pribadi. Baca juga panduan security, privacy, dan UU PDP untuk perusahaan.

Contoh: 1 pagi respons untuk 3 situs WordPress

Simulasi ini memakai data dummy. Nama situs, waktu, dan hasil bukan data pelanggan.

Waktu (WIB)	Situs dummy	Yang dicek	Hasil	Tindakan
08.00	toko-a (7.1.4, update otomatis 28 Oktober)	Langkah 1 dan 5	AMAN, tetapi 3 request ke folder upgrade dari IP asing	Respons insiden
08.20	kantor-b (6.8.11, update otomatis mati)	Langkah 1 dan 2	RENTAN, folder upgrade TERBUKA	Langkah 4, lalu update
08.40	blog-lama (4.6.30, tidak dirawat)	Langkah 1	Di luar CVE ini, tanpa patch	Backup, lalu naik ke 7.1.4 atau matikan
09.10	Semua situs di server nginx	Langkah 4	Aturan memakai prefix biasa	Ganti ke ^~, cek lagi

Pelajaran dari simulasi: versi aman tidak membuktikan situs bersih. Toko-a sudah 7.1.4, tetapi langkah 5 tetap menemukan tanda dari jendela update.

Siapa yang memasang patch

Tanggung jawab patch berbeda per jenis layanan, jadi tabel ini membantu Anda tahu siapa yang bergerak hari ini.

Jenis layanan	Pemegang patch	Yang Anda kerjakan
Hosting bersama dengan cPanel atau panel lain	Anda, terutama bila update otomatis mati	Cek versi di dasbor, update, dan minta log akses ke penyedia
Hosting WordPress managed	Penyedia	Minta bukti versi dan hasil cek log tertulis
VPS sendiri	Tim Anda	Langkah 1 sampai 5
Situs buatan agensi atau freelancer	Sesuai kontrak perawatan	Tanya versi hari ini, lalu minta jadwal update

Rekomendasi Rama Digital: jangan matikan update otomatis core tanpa pengganti. Bila harus mati, jadwalkan cek versi mingguan dan patch dalam 24 jam untuk celah yang masuk KEV. Patch juga kernel server, misalnya untuk celah TCP kernel Linux CVE-2026-98432.

Checklist hari ini

1. Buat daftar semua situs WordPress. Pemilik: tim web. Bukti: daftar situs dan versi.
2. Cek versi dengan langkah 1. Pemilik: admin situs. Bukti: output skrip.
3. Cek folder upgrade dan update otomatis dengan langkah 2. Pemilik: admin situs. Bukti: output skrip.
4. Pasang aturan langkah 4. Pemilik: admin server. Bukti: skrip langkah 2 menulis "DIBLOKIR".
5. Buat backup, lalu update. Pemilik: admin situs. Bukti: output skrip versi sesudah update.
6. Cari tanda dengan langkah 5. Pemilik: admin situs dan tim keamanan. Bukti: output skrip, verify-checksums, dan daftar admin.
7. Nyalakan lagi update otomatis core bila mati tanpa alasan tertulis.

Tanya jawab

Apakah celah ini sudah dipakai menyerang?

Ya. CISA memasukkan CVE-2026-119977 ke KEV pada 3 November 2026 dengan status eksploitasi aktif. Wordfence menulis 13.330 serangan yang diblokir dalam 24 jam per 4 November 2026.

Situs saya update otomatis ke 7.1.4. Apakah saya sudah aman?

Celahnya sudah tertutup, tetapi jendela update Anda jatuh di masa serangan. Jalankan langkah 5 dan bandingkan jam update dengan log akses.

Skornya hanya 8.1. Mengapa artikel ini menulis peringatan kritis?

Celah ini sudah masuk KEV, tanpa login, dan berakhir dengan eksekusi kode. CISA menulis dampak teknis "total".

Apakah plugin firewall bisa menggantikan update?

Tidak. Firewall bisa memblokir sebagian serangan, tetapi hanya update yang menutup celah di kode core. Pasang keduanya.

Saya memakai nginx. Aturan mana yang benar?

Pakai location ^~ /wp-content/upgrade/ { deny all; }. Di uji kami, prefix biasa tanpa ^~ tetap membuka berkas .php.

Apakah aturan blokir mengganggu update WordPress?

Tidak di uji kami. Update membaca folder upgrade lewat sistem berkas, bukan lewat web. Update partial dan reinstall paket penuh tetap berhasil dengan aturan aktif.

WordPress saya masih di bawah 4.7. Apakah saya terdampak?

Catatan CVE tidak mencantumkan versi itu. Tetapi versi itu tidak menerima patch keamanan lagi, jadi buat backup lalu naik ke 7.1.4.

Langkah berikutnya

Batas yang tetap berlaku: langkah 4 tidak menutup celah, dan update tidak menghapus akses yang sudah dipakai penyerang. Bila situs Anda menunjukkan tanda di langkah 5, atau Anda butuh bantuan audit dan pemulihan, pakai Vibe Code Rescue. Untuk 1 masalah mendesak hari ini, jadwalkan sesi 30 menit.

Sumber

• catatan CVE-2026-119977: ringkasan teknis, CVSS 3.1 skor 8.1, CWE-367, rentang versi rentan, dan rujukan kode.
• advisory Wordfence: pelapor, tanggal publikasi 28 Oktober 2026, daftar rilis aman, dan jumlah serangan yang diblokir.
• pengumuman WordPress 7.1.4: tanggal rilis, daftar perbaikan keamanan, dan cara update.
• CISA KEV: tanggal masuk 3 November 2026 dan batas waktu 6 November 2026.
• API versi resmi WordPress: rilis aman per cabang per 4 November 2026.
• class-wp-upgrader.php dan update-core.php: kode WordPress 7.1.4 yang mengubah folder kerja dan penyalinan wp-config.php.
• RFC 5737: blok IP dokumentasi untuk data dummy di artikel ini.
• UU 27/2022 tentang Pelindungan Data Pribadi: kewajiban melapor kebocoran data pribadi.