Celah Keamanan WordPress: Amankan Update ke 7.1.4

Celah keamanan WordPress CVE-2026-119977 adalah kelemahan di inti WordPress (bagian utama, bukan plugin) yang muncul justru saat situs sedang di-update. Penyerang tanpa login bisa menyusup lewat folder sementara update, lalu mengambil alih situs. Situs dengan versi 7.1.3 ke bawah terdampak. Solusinya: blokir folder /wp-content/upgrade/ dulu, baru update ke WordPress 7.1.4 atau versi perbaikan di cabangnya.

CVE adalah nomor resmi untuk setiap celah keamanan yang sudah diumumkan. Celah yang satu ini sudah dipakai penyerang sungguhan. Badan keamanan siber Amerika Serikat, CISA, memasukkannya ke daftar celah yang sudah dieksploitasi pada 3 November 2026.

Celah ini berbeda dari dua kasus yang pernah kami bahas, yaitu celah PHP php2shell dan celah Laravel dan Next.js. Kali ini masalahnya ada di WordPress sendiri. Jadi, situs yang hanya memakai plugin resmi dan tema bawaan pun tetap perlu dicek.

Apa yang terjadi pada celah keamanan WordPress ini?

Celah ini ada di proses update inti WordPress. Para ahli menyebutnya race condition, yaitu celah yang muncul karena ada jeda waktu singkat yang bisa disalip penyerang.

Saat update, WordPress tidak langsung menimpa file lama. Paket baru dibongkar dulu ke folder sementara di wp-content/upgrade/, baru kemudian disalin ke situs. Menurut Picus Security (4 November 2026), folder itu biasanya bisa dibuka dari browser. Isinya salinan WordPress yang lengkap, termasuk halaman instalasi.

Salinan ini tidak menemukan file pengaturan situs yang asli. Akibatnya, ia mengira WordPress belum pernah dipasang. Penyerang lalu membuka halaman instalasi itu dan mengisi data database miliknya sendiri. Hasilnya, terbentuk file pengaturan palsu (wp-config.php, file yang menyimpan alamat database situs).

File palsu itu ikut tersalin ke situs yang asli. Situs kemudian tersambung ke database milik penyerang. Dari sana penyerang bisa membuat akun admin, memasang plugin berisi kode jahat, dan menjalankan perintah di server.

Bayangkan toko yang sedang direnovasi. Rak baru ditaruh sebentar di gudang belakang yang pintunya tidak dikunci. Sebelum rak dipindah ke depan, orang asing masuk dan menyelipkan kunci palsu di antara barang itu.

Menurut catatan rilis resmi WordPress (28 Oktober 2026), perbaikannya ada di versi 7.1.4. Perbaikan yang sama juga dibuat untuk cabang lama, mulai dari 7.0.8 dan 6.9.11 sampai 4.7.39. WordPress 4.6 ke bawah tidak lagi mendapat perbaikan keamanan.

Kenapa celah ini perlu ditangani segera?

Celah ini mendesak karena sudah dipakai untuk menyerang, bukan sekadar temuan di atas kertas. Katalog CISA khusus berisi celah yang terbukti dieksploitasi.

Data katalog CISA mencatat celah ini masuk pada 3 November 2026. Instansi federal AS diberi tenggat sampai 6 November 2026 untuk menanganinya. Tenggat tiga hari tergolong pendek, sehingga menjadi tanda bahwa risikonya dianggap serius.

Security Affairs (4 November 2026) mengutip data dari Wordfence, perusahaan keamanan WordPress. Dalam 21 jam pertama setelah aturan firewall-nya aktif, Wordfence mencatat lebih dari 18.500 permintaan ke halaman instalasi di folder sementara itu. Perlu dicatat, angka itu adalah percobaan serangan, bukan jumlah situs yang berhasil dibobol. Angka itu tetap menunjukkan bahwa penyerang aktif memindai situs WordPress.

Media keamanan menyebut skor CVSS celah ini 8,1 atau tingkat High. CVSS adalah skala 0 sampai 10 untuk mengukur seberapa berbahaya sebuah celah.

Situs yang paling berisiko adalah yang fitur update otomatisnya dimatikan. Contohnya website sekolah yang dibuat vendor beberapa tahun lalu, lalu tidak pernah disentuh lagi. Contoh lain, situs travel umrah yang sengaja tidak di-update saat musim keberangkatan karena takut tampilannya berubah. Kalau situs Anda masuk kelompok ini, jadwalkan pengecekan secepatnya.

Hal yang sering terlewat: proses update juga berisiko

Menekan tombol update saja belum menutup celah sepenuhnya. Picus, peneliti yang menemukan celah ini, menjelaskan alasannya.

Saat Anda update dari versi lama, pembongkaran paket masih dikerjakan oleh kode update versi lama. Folder sementaranya masih mudah ditebak penyerang. Kode baru memang sudah mencegah file pengaturan asli ditimpa. Namun menurut Picus, selama folder itu belum dihapus, penyerang masih bisa menjalankan kode lewat salinan sementara tersebut.

Jadi ada satu jendela serangan terakhir, persis saat update berlangsung. Cara menutupnya adalah memblokir akses web ke folder /wp-content/upgrade/ sebelum update. Menurut Picus, WordPress tidak pernah butuh folder itu dibuka lewat browser. Jadi, memblokirnya tidak mengganggu proses update.

Langkah aman update WordPress ke 7.1.4

Urutannya sederhana: cek versi, blokir folder, cadangkan, update, lalu periksa. Langkah berikut bisa Anda jalankan bersama tim IT atau penyedia hosting.

1. Buka menu Dashboard > Updates (Dasbor > Pembaruan) dan catat versi WordPress yang terpasang.
2. Minta tim IT memblokir folder /wp-content/upgrade/. Setelah itu, buka alamat https://domain-anda/wp-content/upgrade/. Hasilnya harus kode 403, artinya akses ditolak.
3. Buat cadangan file dan database sebelum update. Cadangan ini berbeda fungsi dengan SSL, seperti dijelaskan di artikel SSL dan backup website.
4. Update ke 7.1.4, atau ke versi perbaikan di cabang yang Anda pakai. Ini terutama penting untuk situs yang update otomatisnya mati.
5. Setelah update, cek daftar pengguna. Pastikan tidak ada admin baru yang tidak dikenal.
6. Cek daftar plugin. Hapus plugin yang tidak pernah dipasang tim Anda, lalu minta tim IT memeriksa lebih lanjut.
7. Minta tim IT memeriksa apakah file wp-config.php berubah dan apakah ada jejak akses ke halaman instalasi di catatan server.

Situs yang masih memakai WordPress 4.6 ke bawah tidak akan mendapat perbaikan. Untuk situs seperti ini, rencanakan pindah ke versi yang masih didukung.

Agensi atau tim yang mengelola banyak situs sebaiknya membuat daftar inventaris dulu. Isinya alamat situs, versi WordPress, status update otomatis, jenis server, dan penanggung jawabnya. Setelah itu, blokir folder di semua server, lalu update bertahap sesuai jadwal. Dengan cara ini tidak ada situs yang terlewat.

Untuk tim IT atau vendor Anda: aturan blokir dan cek log

Bagian ini bisa langsung Anda teruskan ke tim IT, penyedia hosting, atau vendor. Aturan di bawah diambil dari panduan Picus (4 November 2026).

Untuk server Nginx:

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

Untuk Apache di konfigurasi virtual host (sesuaikan path):

<Directory "/var/www/html/wp-content/upgrade">
    Require all denied
</Directory>

Bila hanya bisa memakai .htaccess, taruh baris ini di folder utama WordPress, di atas blok rewrite WordPress:

RedirectMatch 403 ^/wp-content/upgrade/

Beberapa catatan penting dari Picus:

• Jangan menaruh file .htaccess di dalam folder wp-content/upgrade/, karena updater versi lama menghapus isi folder itu sebelum membongkar paket.
• Perintah wp core update di WP-CLI bukan pengganti, karena memakai updater dan folder sementara yang sama.
• Pilihan lain adalah update manual: bongkar paket di /tmp, lalu salin dengan rsync tanpa menyertakan wp-config.php dan wp-content.

Versi perbaikan per cabang menurut dokumentasi WordPress: 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, dan seterusnya sampai 4.7.39. Daftar lengkapnya ada di halaman versi 7.1.4 di Referensi.

Untuk mencari jejak percobaan serangan, cari permintaan ke pola wp-content/upgrade/*/setup-config.php di access log, misalnya:

grep -E "wp-content/upgrade/.*setup-config\.php" /var/log/nginx/access.log*

Kami juga menyarankan pemeriksaan berikut, berdasarkan cara kerja serangannya: daftar admin (wp user list --role=administrator), nilai DB_HOST dan DB_NAME di wp-config.php, serta plugin yang dipasang di sekitar waktu update.

Bila Anda belum punya tim yang memegang server, Anaverse, software house dan IT consultant di Pekanbaru, Riau, bisa membantu memeriksa versi, memasang aturan blokir, dan menjadwalkan update. Detailnya bisa Anda lihat di halaman layanan pembuatan dan perawatan website, atau ceritakan kondisi situs Anda lewat halaman kontak.

Pertanyaan yang sering diajukan

Apakah situs WordPress saya pasti sudah diretas?

Belum tentu. Lebih dari 18.500 permintaan yang dicatat Wordfence adalah percobaan serangan, bukan bukti situs berhasil dibobol. Meski begitu, setelah update tetap periksa daftar admin, plugin, dan catatan akses server.

Apakah update otomatis WordPress sudah cukup?

Menurut WordPress, situs yang mendukung update otomatis akan memulai update sendiri. Namun menurut Picus, update dari versi lama masih menyisakan satu jendela serangan selama proses berjalan. Karena itu, sebaiknya blokir folder /wp-content/upgrade/ dan pastikan versi akhirnya sudah benar.

Apakah memblokir folder upgrade membuat update gagal?

Tidak. Menurut Picus, WordPress tidak pernah butuh folder itu dibuka lewat browser, jadi update tetap berjalan normal. Pastikan saja alamat folder itu menjawab kode 403 sebelum update dimulai.

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

WordPress 4.6 ke bawah tidak lagi mendapat perbaikan keamanan, menurut dokumentasi WordPress (Oktober 2026). Blokir folder upgrade sebagai pengaman sementara. Setelah itu, rencanakan pindah ke versi yang masih didukung.

Referensi

• WordPress.org News: WordPress 7.1.4 Security Release (28 Oktober 2026)
• WordPress Documentation: Version 7.1.4, daftar perbaikan dan versi backport
• Picus Security: CVE-2026-119977, When Updating WordPress Becomes the Vulnerability (4 November 2026)
• Security Affairs: U.S. CISA adds WordPress flaw to its Known Exploited Vulnerabilities catalog (4 November 2026)
• CISA: data katalog Known Exploited Vulnerabilities (entri CVE-2026-119977, ditambahkan 3 November 2026)