Bagi banyak instansi pemerintah desa, sekolah, dan UMKM, WordPress adalah pilihan pertama karena mudah dipasang dan dikelola. Sayangnya, kemudahan itu kini berbarengan dengan kabar kurang sedap: sebuah celah keamanan di inti WordPress (WordPress core) sudah dieksploitasi di lapangan, dan ironisnya, proses pemasangan tambalannya sendiri bisa menjadi kesempatan terakhir bagi penyerang. Celah ini tercatat sebagai CVE-2026-119977 dan sudah masuk katalog Known Exploited Vulnerabilities (KEV) milik CISA, badan keamanan siber Amerika Serikat.

Apa yang sebenarnya terjadi?

Ketika WordPress memperbarui intinya menggunakan paket lengkap (complete package), ia mengekstrak salinan versi baru ke sebuah folder sementara di dalam wp-content/upgrade. Salinan itu berisi berkas instalasi WordPress, dan biasanya bisa diakses lewat web. Penyerang yang tidak punya akun sama sekali dapat menebak nama folder tersebut, membuka instalasinya, lalu menjalankan kode di server sebelum folder sementara itu dihapus.

Menurut Umut Bayram, peneliti dari Picus Security yang menemukan masalah ini, penyerang bahkan bisa menyiapkan salinan WordPress dengan basis data miliknya sendiri, masuk ke sana, dan mengeksekusi kode PHP dengan hak akses web server. Dari titik itu, ia dapat membaca atau menulis berkas pada situs WordPress yang asli. Dalam pengujian laboratorium, jendela waktunya hanya beberapa detik — tetapi cukup untuk skrip otomatis.

Versi mana yang terdampak?

• WordPress 4.7 sampai 7.1.3 terpengaruh oleh celah ini.
• Perbaikan dirilis pada WordPress 7.1.4 serta rilis perbaikan untuk cabang-cabang lama, mulai 4.7.
• WordPress 4.6 ke bawah tidak lagi menerima pembaruan keamanan, sehingga tidak ada tambalan untuk mereka. Peneliti menyebut akar masalahnya sudah ada sejak WordPress 2.7 (2008), dan situs semacam itu sebaiknya dipindahkan ke versi yang masih didukung.
• Skor CVSS-nya 8,1 dari 10, meski pengelola WordPress sendiri menilai tingkat risikonya rendah.

Ada satu detail penting: perbaikan di 7.1.4 memang membuat nama folder sementara menjadi acak. Namun pembaruan yang memasang perbaikan itu masih dijalankan oleh kode lama yang belum ditambal. Pada situs versi 5.9 ke atas, kode lama menamai folder berdasarkan berkas yang diunduh, sehingga namanya masih bisa diprediksi satu kali terakhir. Pada versi 4.4–5.8, kode lama menambahkan karakter acak sehingga nama folder lebih sulit ditebak. Peneliti menegaskan faktor penentunya bukan paket parsial atau lengkap, melainkan apakah updater yang terpasang di situs sudah diperbaiki.

Langkah aman sebelum menekan tombol Update

Rekomendasi utama peneliti sederhana: hentikan akses web ke folder wp-content/upgrade. WordPress bekerja dengan folder itu langsung di disk, jadi memblokir akses web tidak mengganggu proses pembaruan. Urutannya:

1. Blokir folder di konfigurasi web server. Di Nginx tambahkan location ^~ /wp-content/upgrade/ { deny all; }. Di Apache tambahkan Require all denied di dalam blok <Directory> untuk folder tersebut pada konfigurasi virtual host.
2. Jika hanya bisa mengubah .htaccess, tambahkan RedirectMatch 403 ^/wp-content/upgrade/ pada .htaccess di akar WordPress, di atas aturan rewrite WordPress.
3. Jangan menaruh .htaccess di dalam folder wp-content/upgrade. Updater lama menghapus seluruh isi folder sebelum mengekstrak pembaruan, sehingga berkas itu akan hilang saat dibutuhkan.
4. Pastikan permintaan ke /wp-content/upgrade/ menghasilkan error 403. Uji lewat browser atau curl sebelum melanjutkan.
5. Baru perbarui ke WordPress 7.1.4 atau rilis perbaikan sesuai cabang versi Anda.

Alternatif: pembaruan manual di luar web root

Jalur aman lainnya adalah memperbarui secara manual di luar folder yang disajikan web server. Cadangkan berkas situs dan basis data, ekstrak rilis baru di folder yang tidak dapat diakses web, salin berkas inti ke tempatnya tanpa menyentuh wp-config.php dan wp-content, lalu jalankan pembaruan basis data WordPress. Dengan cara ini, tidak ada instalasi sementara yang pernah dibuat di folder yang bisa dijangkau web. Perlu dicatat, perintah wp core update dari WP-CLI bukan pengganti yang aman, karena ia memakai updater yang sama dan mengekstrak paket ke folder yang sama.

Tanda-tanda situs sudah disentuh

Untuk situs yang tetap berada di versi terdampak setelah rilis perbaikan, Wordfence menyarankan pemeriksaan berikut:

• Permintaan tak wajar ke berkas PHP di dalam wp-content/upgrade.
• Akun administrator yang tidak dikenal.
• Plugin yang tidak pernah dipasang oleh tim Anda.
• Berkas PHP di wp-content/upgrade yang bukan buatan Anda.

Kode yang diklaim sebagai eksploit sudah muncul di repositori GitHub publik sejak awal pekan ini, meski belum dipastikan benar-benar berfungsi. Karena itu, jangan menunda: blokir dulu folder upgrade, verifikasi 403, baru perbarui. Bagi pengelola situs desa, sekolah, atau UMKM yang tidak punya administrator teknis, langkah paling aman adalah meminta penyedia jasa hosting atau pendamping TI melakukan pemblokiran dan pembaruan ini, disertai pencadangan penuh sebelum eksekusi.

Sumber: The Hacker News — Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time; Picus Security; Advisory keamanan WordPress; CVE-2026-119977.