Pembaruan WordPress Masih Bisa Dieksploitasi Saat Memasang Patch CVE-2026-119977
Memasang pembaruan keamanan WordPress ternyata tidak selalu langsung menghilangkan risiko serangan. Peneliti keamanan menemukan bahwa proses instalasi patch untuk kerentanan CVE-2026-119977 masih dapat membuka kesempatan bagi penyerang untuk menjalankan kode pada server, tepat ketika pembaruan sedang berlangsung.
Temuan yang diungkap pada 6 November 2026 ini berasal dari Umut Bayram, peneliti Picus Security. Ia menemukan bahwa mekanisme pembaruan WordPress masih menggunakan kode lama yang rentan ketika mengekstrak paket pembaruan untuk pertama kalinya.
Akibatnya, pada kondisi tertentu, penyerang tanpa akun dapat memanfaatkan direktori sementara yang dibuat selama proses update. Kesempatan tersebut hanya berlangsung singkat, tetapi cukup untuk menjalankan instalasi WordPress sementara dan mengeksekusi kode PHP dengan hak akses server web.
Masalah ini menjadi perhatian karena CVE-2026-119977 sebelumnya telah dikonfirmasi masuk dalam eksploitasi aktif dan tercatat dalam katalog Known Exploited Vulnerabilities (KEV) milik CISA.
Mengapa Patch WordPress Masih Menyisakan Celah?
CVE-2026-119977 merupakan kerentanan time-of-check to time-of-use (TOCTOU) dalam proses pembaruan WordPress Core.
Secara sederhana, TOCTOU terjadi ketika kondisi keamanan suatu objek diperiksa pada satu waktu, tetapi objek tersebut berubah atau digunakan dalam kondisi berbeda sebelum proses selesai.
Pada proses pembaruan WordPress, paket versi baru diekstrak ke direktori sementara di dalam:
wp-content/upgrade
Direktori tersebut dapat berisi salinan file WordPress, termasuk file installer. Dalam kondisi tertentu, direktori sementara ini dapat diakses melalui web server.
Masalahnya, ketika patch CVE-2026-119977 dipasang, proses ekstraksi masih dijalankan menggunakan kode updater lama yang belum diperbaiki.
Pada WordPress versi 5.9 dan lebih baru, kode lama tersebut menggunakan nama folder yang berasal dari nama file paket unduhan. Pola ini memungkinkan nama direktori sementara diperkirakan dalam kondisi tertentu.
Penyerang yang mengetahui nama direktori dan berhasil mengakses installer sebelum folder dihapus dapat mencoba menjalankan instalasi WordPress terpisah menggunakan database miliknya sendiri.
Jika berhasil, penyerang dapat menjalankan kode PHP dengan hak akses web server. Akses tersebut berpotensi digunakan untuk membaca atau mengubah file pada instalasi WordPress utama.
Patch Pertama Justru Menjadi Momen Risiko Terakhir
WordPress sebelumnya telah memperbaiki CVE-2026-119977 dengan memperkenalkan nama direktori sementara yang acak. Mekanisme ini membuat lokasi file installer lebih sulit diprediksi pada pembaruan berikutnya.
Namun, perlindungan tersebut belum sepenuhnya berlaku selama proses pemasangan patch pertama kali.
Alasannya, kode updater yang menjalankan proses ekstraksi masih merupakan kode lama. Dengan kata lain, perubahan keamanan baru belum sepenuhnya aktif ketika paket perbaikan sedang dipasang.
Setelah versi yang telah diperbaiki berhasil terpasang, proses pembaruan berikutnya menggunakan mekanisme penamaan direktori yang lebih aman. File wp-config.php dari salinan sementara juga tidak lagi disalin untuk menimpa file konfigurasi utama.
Temuan ini memperlihatkan adanya perbedaan antara kondisi setelah patch terpasang dan kondisi ketika patch sedang dipasang.
Karena itu, administrator perlu mengamankan direktori pembaruan sebelum memulai proses instalasi.
Tidak Semua Proses Update Memiliki Risiko yang Sama
Peneliti menjelaskan bahwa tingkat paparan bergantung pada paket pembaruan yang digunakan.
WordPress dapat menggunakan dua jenis paket:
- Complete package: Paket lengkap yang berisi seluruh file instalasi WordPress, termasuk file installer.
- Partial package: Paket yang hanya berisi file yang berubah dari versi sebelumnya.
Paket lengkap selalu menyertakan file installer. Sementara itu, paket parsial hanya menimbulkan risiko jika file yang disertakan memungkinkan salinan sementara dijalankan sebagai instalasi WordPress.
Namun, penggunaan paket parsial tidak otomatis berarti sebuah situs aman.
WordPress dapat beralih ke paket lengkap jika file inti situs tidak cocok dengan checksum resmi atau ketika pembaruan dilakukan sebagai instalasi ulang.
Peneliti juga mengingatkan bahwa faktor penentu bukan sekadar apakah pembaruan menggunakan paket lengkap atau parsial, melainkan apakah kode updater yang sedang berjalan sudah diperbaiki.
Pada situs yang mengaktifkan pembaruan otomatis di latar belakang, proses instalasi menggunakan mekanisme updater yang sama. Karena itu, pembaruan otomatis juga perlu mempertimbangkan pengamanan direktori sementara tersebut.
WP-CLI Tidak Otomatis Menghilangkan Risiko
Administrator yang terbiasa mengelola WordPress melalui terminal mungkin menganggap penggunaan WP-CLI dapat menghindari masalah ini.
Namun, perintah wp core update tetap menggunakan mekanisme updater yang sama untuk mengunduh dan mengekstrak paket ke direktori sementara.
Artinya, menjalankan pembaruan melalui WP-CLI bukan solusi khusus untuk menghindari celah selama proses instalasi patch pertama.
Peneliti merekomendasikan pendekatan berbeda, yaitu membatasi akses web ke direktori wp-content/upgrade sebelum melakukan pembaruan.
Cara Mengamankan WordPress Sebelum Memasang Patch
Langkah utama yang disarankan adalah mencegah web server melayani permintaan HTTP menuju direktori wp-content/upgrade.
Pembatasan ini tidak mengganggu proses pembaruan WordPress karena sistem tetap dapat mengakses direktori tersebut secara langsung melalui filesystem server.
Untuk administrator yang menggunakan Nginx, aturan berikut dapat diterapkan pada konfigurasi server:
location ^~ /wp-content/upgrade/ {
deny all;
}Sementara itu, pada Apache, akses dapat dibatasi melalui konfigurasi virtual host:
<Directory "/path/ke/wordpress/wp-content/upgrade">
Require all denied
</Directory>Ganti /path/ke/wordpress dengan lokasi instalasi WordPress yang sebenarnya.
Jika administrator hanya memiliki akses ke file .htaccess, aturan berikut dapat ditambahkan pada .htaccess di direktori utama WordPress, sebelum aturan rewrite WordPress:
RedirectMatch 403 ^/wp-content/upgrade/Setelah konfigurasi diterapkan, pastikan permintaan menuju alamat /wp-content/upgrade/ menghasilkan respons HTTP 403 Forbidden.
Jangan menempatkan file .htaccess di dalam direktori wp-content/upgrade sebagai solusi. Proses updater lama dapat menghapus isi direktori tersebut sebelum mengekstrak paket pembaruan, sehingga aturan perlindungan ikut terhapus.
Setelah akses web berhasil diblokir, administrator dapat melanjutkan pembaruan WordPress ke versi yang telah diperbaiki.
Alternatif: Memperbarui WordPress di Luar Web Root
Peneliti juga menyarankan metode pembaruan manual yang dilakukan di luar web root, yaitu direktori yang dapat diakses langsung oleh web server.
Dalam pendekatan ini, paket WordPress diekstrak di lokasi yang tidak dapat diakses melalui web. File inti kemudian disalin ke instalasi yang sebenarnya tanpa menimpa wp-config.php maupun direktori wp-content.
Setelah file inti diperbarui, administrator menjalankan proses pembaruan database jika diperlukan.
Metode tersebut menghindari pembuatan salinan installer sementara di lokasi yang dapat dijangkau melalui HTTP.
Namun, proses manual membutuhkan kehati-hatian. Administrator harus memiliki cadangan file dan database, memastikan integritas paket, serta memahami struktur instalasi WordPress sebelum mengganti file inti.
Apa yang Harus Diperiksa Jika Situs Pernah Terpapar?
CVE-2026-119977 sebelumnya telah dikaitkan dengan aktivitas eksploitasi. Wordfence melaporkan adanya permintaan mencurigakan yang menargetkan jalur installer sementara, termasuk percobaan yang dilakukan untuk mendeteksi momen ketika situs sedang diperbarui.
Administrator yang masih menggunakan versi rentan atau mencurigai adanya eksploitasi perlu melakukan pemeriksaan menyeluruh.
Beberapa indikator yang patut diperhatikan meliputi:
- Permintaan tidak biasa ke file PHP di
wp-content/upgrade. Periksa log akses web untuk menemukan permintaan yang tidak sesuai dengan aktivitas pembaruan normal. - Akun administrator tidak dikenal. Tinjau seluruh akun yang memiliki hak administrator dan periksa waktu pembuatannya.
- Plugin yang tidak pernah dipasang. Periksa perubahan daftar plugin dan aktivitas instalasi yang tidak memiliki persetujuan.
- File PHP mencurigakan di direktori upgrade. Cari file yang tidak berasal dari proses pembaruan resmi.
- Perubahan file inti WordPress. Bandingkan integritas file dengan distribusi resmi untuk menemukan modifikasi yang tidak sah.
Jika ditemukan indikasi kompromi, jangan hanya menghapus file mencurigakan. Lakukan investigasi terhadap kemungkinan akses tidak sah, perubahan konfigurasi, pencurian kredensial, dan persistensi penyerang.
Rotasi kata sandi administrator, kredensial database, serta rahasia lain yang mungkin terpapar juga perlu dipertimbangkan setelah bukti diamankan.
WordPress Versi Lama Tetap Perlu Mendapat Perhatian
CVE-2026-119977 memengaruhi WordPress versi 4.7 hingga 7.1.3. Perbaikan tersedia melalui WordPress 7.1.4 dan pembaruan untuk sejumlah cabang versi lama.
Sementara itu, WordPress 4.6 dan versi sebelumnya tidak lagi menerima pembaruan keamanan untuk masalah ini. Situs yang masih menggunakan versi tersebut perlu dipindahkan ke versi WordPress yang didukung.
Administrator sebaiknya tidak hanya memastikan nomor versi sudah berubah, tetapi juga memverifikasi bahwa proses pembaruan selesai dengan benar dan tidak meninggalkan file atau akun mencurigakan.
Pembaruan Keamanan Harus Disertai Perlindungan Proses Instalasi
Temuan terbaru ini menunjukkan bahwa memasang patch tidak selalu menjadi langkah yang sepenuhnya bebas risiko. Pada kasus CVE-2026-119977, mekanisme lama masih digunakan selama proses instalasi perbaikan, sehingga muncul kesempatan eksploitasi sebelum perlindungan baru aktif.
Bagi pengelola situs WordPress, langkah paling penting adalah membatasi akses web ke direktori wp-content/upgrade sebelum memasang pembaruan yang relevan.
Setelah itu, pastikan WordPress berjalan pada versi yang telah diperbaiki, periksa integritas file, dan tinjau log untuk mencari tanda-tanda aktivitas mencurigakan.
Dengan mengamankan proses pembaruan sekaligus memeriksa kemungkinan kompromi sebelumnya, administrator dapat mengurangi risiko bahwa upaya memperbaiki kerentanan justru menjadi kesempatan terakhir bagi penyerang untuk mengambil alih situs.
