Celah WordPress CVE-2026-119977 Dieksploitasi, Pasang 7.1.4

Celah WordPress CVE-2026-119977 memungkinkan penyerang tanpa akun menjalankan kode di server selama beberapa detik ketika pembaruan inti WordPress sedang dipasang. Badan keamanan siber Amerika Serikat, CISA, memasukkannya ke katalog celah yang dieksploitasi pada 3 November 2026. Perbaikannya tersedia di WordPress 7.1.4 dan rilis perbaikan untuk cabang lama.

Cara kerja celah di jendela pembaruan

WordPress merilis versi 7.1.4 pada 28 Oktober 2026 sebagai rilis keamanan dan meminta pengelola situs segera memperbarui. Dalam catatan rilisnya, WordPress menyebut satu kelemahan pada proses pembaruan yang dapat berujung pada eksekusi kode jarak jauh selama jendela pembaruan. Celah ini dilaporkan oleh peneliti Umut Bayram.

Masalahnya ada pada cara WordPress memasang pembaruan inti dalam bentuk paket lengkap. Menurut advisori WordPress di GitHub, versi yang terdampak membuka isi paket baru ke folder dengan nama yang dapat ditebak di dalam folder wp-content/upgrade/. Folder itu berada di area yang dapat diakses lewat web.

Patchstack menjelaskan bahwa selama beberapa detik pembaruan berjalan, satu salinan WordPress lengkap berada di alamat yang dapat ditebak dan dapat dijelajahi. Salinan itu ikut membawa berkas setup-config.php, yaitu skrip pemasang yang biasanya hanya dipakai saat situs pertama kali dibuat, dan serangan yang tercatat menyasar berkas tersebut. Menurut advisori, penyerang tanpa akun yang berhasil memanggil salinan itu tepat waktu dapat menjalankan kode di server. Kondisi seperti ini disebut race condition: penyerang berlomba dengan proses pembaruan, dan celahnya hanya terbuka selama proses itu berjalan.

Advisori hanya menyebut pembaruan inti WordPress yang memakai paket lengkap sebagai pemicu. Menurut Patchstack, kode yang bermasalah sudah ada sejak WordPress 2.8, dan jendela ini muncul lagi pada setiap pembaruan inti, termasuk pembaruan otomatis yang berjalan tanpa campur tangan admin.

Perbaikan di 7.1.4 menambahkan karakter acak pada nama folder sementara, memasang kembali berkas index.php yang mencegah isi folder ditampilkan, dan mencegah data konfigurasi dari salinan sementara dipindahkan ke situs utama.

Status eksploitasi dan perbedaan penilaian

Serangan datang cepat. Menurut laporan SecurityWeek, Wordfence mencatat permintaan pertama yang cocok dengan aturan firewall barunya sembilan menit setelah aturan itu dipasang. Dalam 21 jam pertama, Wordfence mencatat lebih dari 18.500 permintaan yang menyasar jalur setup-config.php di folder pembaruan. Wordfence juga menyatakan penyerang harus mengenai jendela yang sangat sempit, yaitu saat WordPress membuka paket pembaruan inti.

Pada 3 November 2026, CISA memasukkan CVE-2026-119977 ke katalog Known Exploited Vulnerabilities (KEV) dengan nama “WordPress Core Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability”. Menurut The Hacker News, instansi sipil federal Amerika Serikat diberi tenggat hingga 6 November 2026 untuk memasang perbaikannya. Media yang sama mencatat lebih dari 12.600 percobaan eksploitasi yang diblokir Wordfence dalam 24 jam sebelum artikelnya terbit.

Perlu dibedakan antara percobaan dan pembobolan. Data Wordfence menunjukkan banyaknya permintaan yang diblokir. Hingga laporan SecurityWeek, Wordfence belum melaporkan situs yang berhasil dibobol. CISA sendiri menyatakan memasukkan celah ke katalog KEV berdasarkan bukti eksploitasi aktif.

Penilaian tingkat bahayanya juga berbeda. Advisori WordPress di GitHub memberi label keparahan rendah (Low). The Hacker News mencatat skor CVSS 8,1 atau tinggi. Patchstack menilai kompleksitas serangannya tinggi dan menganggapnya sulit dieksploitasi dalam praktik. Bagi pengelola situs, perbedaan angka ini tidak mengubah keputusan, karena celahnya sudah diburu secara aktif dan perbaikannya gratis.

Versi yang terdampak dan versi perbaikannya

Advisori WordPress mencantumkan semua versi dari 4.7.0 sampai 7.1.3 sebagai terdampak. Perbaikannya dikirim ke setiap cabang yang masih menerima pembaruan keamanan, dari 7.1.4 sampai 4.7.39. Situs yang memakai 7.1.x perlu naik ke 7.1.4, cabang 7.0 ke 7.0.8, cabang 6.9 ke 6.9.11, dan cabang 6.8 ke 6.8.12.

Situs dengan WordPress 4.6 atau lebih lama tidak menerima perbaikan, sehingga pengelolanya perlu pindah ke cabang yang masih didukung. WordPress.org sendiri menyatakan hanya versi terbaru yang didukung secara aktif.

WordPress 7.1.4 juga memperbaiki masalah lain. Catatan rilis WordPress.org memuat 12 butir perbaikan keamanan serta pembaruan sertifikat akar (root certificate) yang dibawa WordPress. Patchstack dan SecurityWeek mencatat total 22 kerentanan, sebagian besar berupa stored XSS, yaitu skrip jahat yang tersimpan di konten situs. Banyak di antaranya memerlukan akun dengan peran Contributor atau lebih tinggi.

Situs yang mendukung pembaruan otomatis di latar belakang akan menerima 7.1.4 dengan sendirinya. Fitur ini dapat dimatikan oleh penyedia hosting atau admin, sehingga versi setiap situs tetap perlu diperiksa.

Apa artinya bagi pengelola situs WordPress?

WordPress banyak dipakai untuk situs sekolah, kampus, dinas, organisasi nirlaba, media lokal, hingga toko UMKM di Indonesia. Banyak di antaranya dikelola oleh satu orang atau oleh vendor yang sudah tidak lagi mendampingi. Situs seperti ini paling mudah tertinggal pembaruan. Langkah berikut dapat dikerjakan hari ini, idealnya berurutan.

Periksa versi setiap situs

Buka Dasbor WordPress dan pilih menu Pembaruan (Updates) untuk melihat versi yang terpasang. Tim yang mengelola banyak situs dapat menjalankan perintah wp core version lewat WP-CLI di server. Catat situs yang masih di bawah versi perbaikan cabangnya, termasuk situs lama yang jarang dibuka, seperti situs acara atau situs program yang sudah selesai.

Blokir akses web ke folder pembaruan

Patchstack menyarankan pemblokiran di tingkat server web, karena firewall berbasis plugin PHP tidak dapat menghentikan permintaan ini. Salinan WordPress di folder sementara memuat berkasnya sendiri, sehingga plugin keamanan situs utama tidak ikut berjalan. Pada Apache, baris RedirectMatch 403 ^/wp-content/upgrade/ di berkas .htaccess utama menolak akses ke folder itu. Pada Nginx, tambahkan blok location ^~ /wp-content/upgrade/ { deny all; } sebelum aturan PHP. Pastikan juga isi folder tidak dapat ditampilkan lewat peramban.

Karena jendela celah ikut terbuka setiap kali pembaruan inti berjalan, termasuk saat memasang 7.1.4 itu sendiri, pemblokiran ini sebaiknya dipasang sebelum menekan tombol perbarui. Proses pembaruan WordPress tetap berjalan normal, karena pemasangan berkas dikerjakan langsung di server tanpa melewati akses web ke folder tersebut.

Perbarui ke versi yang aman

Pasang 7.1.4 atau versi perbaikan untuk cabang yang dipakai. Buat cadangan berkas dan basis data lebih dulu. Bila situs memakai tema atau plugin buatan sendiri, uji pembaruan di salinan situs (staging) sebelum dipasang di situs utama. Pemblokiran folder tetap layak dipertahankan setelah pembaruan.

Periksa log dan akun admin

Cari permintaan ke jalur di bawah wp-content/upgrade/, terutama yang menyebut setup-config.php, di log akses server web. Periksa juga daftar akun administrator dan plugin yang terpasang. Akun admin atau plugin yang tidak dikenal adalah tanda situs perlu diperiksa lebih dalam. Firewall dan pembaruan tidak membersihkan situs yang telanjur dibobol.

Kasus ini juga menunjukkan bahwa keamanan situs bergantung pada lapisan di bawah aplikasinya. Pada Oktober lalu, celah PHP2Shell menyerang mesin PHP yang menjalankan WordPress. Kali ini masalahnya ada di proses pembaruan WordPress sendiri. Konfigurasi server web yang rapi, seperti menolak akses ke folder sementara, menjadi bagian dari pengembangan web yang aman sejak awal.

Pertanyaan yang sering muncul

Apakah situs saya pasti sudah dibobol bila belum diperbarui?

Tidak pasti. Celah ini hanya dapat dipakai ketika pembaruan inti sedang berjalan, dan penyerang harus mengenai jendela beberapa detik itu. Meski begitu, percobaan serangan sudah tercatat dalam jumlah besar, sehingga situs yang belum diperbarui sebaiknya diperiksa lognya dan segera dipasangi perbaikan.

Apakah plugin keamanan seperti Wordfence cukup untuk mencegahnya?

Belum tentu. Patchstack menyatakan firewall berbasis PHP tidak dapat memblokir serangan ini, karena salinan WordPress di folder sementara memuat berkasnya sendiri dan tidak menjalankan plugin keamanan situs utama. Wordfence memang memasang aturan firewall baru, tetapi aturan seperti itu hanya menambah lapisan. Pemblokiran di server web dan pembaruan ke versi perbaikan tetap diperlukan.

Apakah situs WordPress.com terdampak?

Sumber-sumber yang kami rujuk membahas WordPress yang dipasang sendiri di server atau hosting. Situs di layanan terkelola mengikuti jadwal pembaruan penyedianya. Tanyakan langsung ke penyedia hosting bila Anda tidak mengelola server sendiri.

Penutup

CVE-2026-119977 menyerang momen yang biasanya dianggap aman, yaitu saat situs sedang diperbarui. Langkah penanganannya sederhana dan tidak memerlukan biaya: blokir folder pembaruan dari akses web, pasang versi perbaikan, lalu periksa log. Jika organisasi Anda mengelola banyak situs WordPress dan ingin merapikan pemantauan serta jadwal pembaruannya, layanan keamanan siber Merakit siap membantu.

Sumber

• WordPress 7.1.4 Security Release, WordPress.org, 28 Oktober 2026
• A race condition during core updates that could lead to remote code execution (GHSA-4w3m-c66w-69mg), WordPress di GitHub, 29 Oktober 2026
• WordPress 7.1.4 Security Release, Patchstack, 28 Oktober 2026
• Fresh WordPress Vulnerability in Attackers’ Crosshairs, SecurityWeek, 30 Oktober 2026 (diperbarui 4 November 2026)
• CISA Adds One Known Exploited Vulnerability to Catalog, CISA, 3 November 2026
• CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades, The Hacker News, 4 November 2026