Kenapa Pembaruan Plugin WordPress Ditunda 6 Jam dan Apa Dampaknya

Tiga hari lalu seorang pemilik toko online di Bekasi mengirim pesan ke saya. Pesannya cuma satu kalimat: “Mas, plugin Elementor di dashboard-nya kok nggak muncul tulisan update-nya? Kemarin di grup orang udah pada update.”

Saya buka dasbor itu. Versi yang terpasang memang versi lama. Tapi file ZIP versi baru sudah bisa diunduh dari wordpress.org, dan nomor versinya lebih tinggi. Jadi ini bukan masalah koneksi, bukan cache, bukan izin file. WordPress-nya sengaja belum mendistribusikannya.

Alasannya, sejak 5 Juni 2026 setiap rilis plugin dan theme di direktori WordPress.org harus menunggu masa tunggu sebelum dikirim ke pengguna. Awalnya 24 jam, lalu dipangkas menjadi 6 jam. Dan sejak 9 September 2026, masa tunggu itu bukan lagi sekadar jeda. Di dalamnya sekarang berjalan pemeriksaan keamanan otomatis yang bisa memblokir rilis secara permanen.

Untuk sebagian besar pemilik website UMKM, ini kabar baik. Untuk yang punya toko WooCommerce dengan banyak plugin berbayar, ini kabar buruk yang belum terasa keruhannya.

Yang saya cek di website sendiri

Sebelum menulis ini saya cek antond.net, karena kami rutin mengerjakan maintenance website klien.

Saya cek empat hal. Hasilnya sangat informatif, dan sebagian cukup mengagetkan.

Pertama, versi WordPress antond.net. Saya cek dua kali, lewat meta tag di halaman depan dan lewat feed RSS. Dua-duanya menyebut WordPress 7.1.2.

Kedua, server antond.net tidak memakai Cloudflare. Header responsnya menunjukkan Hostinger, dengan platform: hostinger dan server: hcdn.

Ketiga, PHP-nya versi 7.4.33.

Keempat, ini yang perlu Anda perbaiki kalau website Anda punya masalah serupa. File robots.txt antond.net punya blok duplikat yang saling bertabrakan.

Baris pertama memblokir folder WooCommerce dan administrative WordPress. Baris yang lebih bawah, dari Yoast, menulis ulang seluruh blok itu dengan Disallow: kosong untuk semua user agent.

Artinya aturan asli di baris atas praktis jadi tidak berlaku.

Saya tidak menyebut ini untuk menyalahkan siapa pun. Plugin Yoast memang begitu cara kerjanya, dan banyak website punya pola serupa.

Saya akan memperbaikinya. Tapi saya tidak ingin menipu Anda dengan mengarang hasil yang belum ada, jadi saya cukup laporkan apa yang saya temukan.

Langkah praktis untuk Anda

Berikut urutan kerja yang saya sarankan, dari yang paling cepat.

Pertama, cek apakah website Anda benar-benar perlu buru-buru. Kalau Anda memakai plugin premium berbayar, daftar plugin yang update dari luar direktori. Itu bagian dari website Anda yang tidak diperiksa WordPress sama sekali.

Kedua, kalau ada plugin yang sedang dalam masa tunggu, jangan langsung unduh ZIP-nya. Unggahan manual melewati pemeriksaan, jadi Anda justru membuang satu lapisan keamanan yang sengaja dibuat WordPress.

Ketiga, untuk plugin gratis dari direktori, tunggu. Enam jam itu tidak lama dibanding risiko memakai rilis yang belum diperiksa.

Keempat, untuk plugin berbayar yang Anda beli sendiri, tidak ada yang perlu menunggu. Ambil dari server vendors, tapi tetap cek changelog-nya sebelum menekan tombol update.

Alasannya sederhana. Kalau plugin gratis sekarang sudah dijaga oleh WordPress, sedangkan jalur masuk Anda sendiri tidak, maka titik lemahnya ada di tempat yang paling sering dilupakan.

Ringkasan dalam satu tabel

Sumber plugin	Diperiksa WordPress?	Apa yang harus Anda lakukan
Direktori WordPress.org	Ya, otomatis	Tunggu 6 jam, lalu update
Plugin premium dari server pengembang	Tidak	Ambil manual, cek changelog
ZIP hasil unduhan manual	Tidak	Jangan, ini membuang lapisan keamanan
Kode kustom milik Anda sendiri	Tidak	Jaga manual, review berkala

Tabel ini sengaja dibuat pendek, karena intinya memang cuma satu kalimat.

Penutup

Ada satu pelajaran yang bisa diambil dari perubahan ini. WordPress mengambil langkah yang benar untuk mengunci rantai pasoknya.

Backdoor yang tertangkap pada 28 Juli 2026 benar-benar tidak pernah sampai ke satu pun situs. Itu hasil yang ingin kita lihat.

Sebenarnya apa yang terjadi

Inisiatif resminya bernama Protect The Shire, diumumkan Matt Mullenweg pada 5 Juni 2026 dengan target mengunci sekitar 78.000 plugin dan theme di direktori resmi WordPress.org.

Logikanya masuk akal dan saya setuju dengan arahnya. Plugin baru yang masuk direktori sudah melewati tinjauan manusia. Tapi setelah itu, pembaruan berikutnya mengalir tanpa batas.

Seorang pengembang bisa mendorong rilis pada pukul dua pagi, dan dalam hitungan menit file itu sudah terpasang di ratusan ribu situs yang menyalakan pembaruan otomatis. Apakah aman atau berbahaya, tidak ada yang memeriksa sebelum file itu sampai.

Inilah celah yang ditutup inisiatif ini.

Tapi satu langkah benar tidak menghapus langkah yang masih terbuka di sisi Anda sendiri.

Kalau website Anda sekarang kehilangan pembaruan plugin dan Anda bingung kenapa, Anda tidak sendirian. Itu perilaku yang disengaja, dan akan selesai dalam hitungan jam.

Yang perlu Anda lakukan hari ini cuma satu: pastikan kata sandi administrator Anda kuat, dan cek daftar plugin berbayar yang Anda pakai.

Sisanya, tunggu enam jam. Itu bukan masalah. Itu sistem yang bekerja.

Studio kasus yang membuat mekanisme ini lahir

Pada 28 Juli 2026, seorang pengembang mendorong rilis baru untuk plugin yang punya sekitar 20.000 instalasi aktif.

Tidak banyak yang berubah dari sisi fitur. Yang ditambahkan adalah sepotong kode kecil. Fungsi yang di-hook ke init dengan prioritas 1, artinya berjalan di setiap permintaan sebelum WordPress sempat melakukan autentikasi apa pun.

Fungsi itu membaca sebuah token dari parameter kueri, lalu membandingkannya dengan hash SHA-256 yang ditulis langsung di dalam kode plugin.

Siapa pun yang membaca kode sumbernya secara publik akan bisa mengirim token itu, lalu masuk ke WordPress sebagai administrator miliknya sendiri.

Plugin itu bernama Advanced Responsive Video Embedder, rilis 10.8.7. Yang membuat kejadian ini penting bukan karena keretasannya besar, tapi karena urutan waktunya.

Wordfence, perusahaan keamanan WordPress, menemukan kodenya kurang dari dua jam setelah dimasukkan. Sistem otomatis juga menangkapnya dan memberi skor tinggi.

Setelah Wordfence memberi tahu Tim Plugin, plugin itu ditutup untuk unduhan dalam 26 menit.

Perhatikan urutan itu baik-baik. Deteksi sudah bekerja. Yang belum ada adalah jalur dari “pemeriksa bilang ini berbahaya” ke “rilis ini berhenti bergerak” yang tidak bergantung pada satu orang yang sedang duduk di depan komputer di zona waktu yang tepat.

Perubahan 9 September menutup celah itu.

Perlu saya sampaikan terus terang, satu kejadian bukan pola. Belum ada bukti apakah backdoor yang sengaja ditulis untuk mendapat skor rendah akan lolos.

Tapi mekanismenya sudah terbukti berhasil dalam satu kasus, dan tidak ada yang lebih buruk dari kondisi sebelumnya, ketika tidak ada pemeriksaan sama sekali.

Tim Plugin juga membagi pola yang paling sering menaikkan skor. Ini berguna karena menunjukkan bahwa temuan paling sering adalah ketidaksengajaan, bukan serangan.

Pola pertama: endpoint REST, AJAX, atau admin-post yang tidak punya pemeriksaan kapabilitas. Catatan dari tim: nonce saja bukan otorisasi.

Pola keempat: unserialize() dipanggil pada data permintaan atau pada respons dari server jarak jauh.

Pola kelima: opsi, user meta, atau pengaturan yang ditulis dari endpoint yang bisa diakses pengguna anonim.

Pola terakhir ini punya catatan yang agak mencolok. Kode PHP yang sudah dipaketkan atau diminifikasi, penyertakan file secara dinamis, dan kode yang diambil dari server lain terlihat sama oleh pemeriksa seperti backdoor.

Selama masa tunggu itu, beberapa model AI bersama Jetpack Scan membaca perubahan kode pada tiap rilis. Hasilnya saling dicek lalu digabung menjadi satu skor keamanan. Skor lebih tinggi berarti risiko yang lebih besar.

Kalau skornya melewati ambang batas, rilisnya diblokir otomatis begitu pemeriksaan selesai. Tidak ada orang yang perlu sedang terbangun atau ada yang harus menekan tombol. Semua pengembang plugin untuk rilis itu menerima surel berisi temuannya.

Satu hal yang perlu diluruskan, karena sering disalahpahami. Skor tinggi tidak berarti niat jahat.

Kalau proses build Anda menghasilkan salah satu itu, siap-siap menghadapi pertanyaan dari pemeriksa.

Dan kalau Anda hanya pemilik website, bukan pengembang, bagian ini sebenarnya tidak perlu Anda khawatirkan. Saya sertakan supaya Anda paham kalau suatu saat plugin favorit Anda tiba-tiba tidak bisa diupdate.

Kalau tiris blokir, apa yang terjadi

Kalau sebuah rilis diblokir, plugin itu tidak akan dibagikan sampai masalahnya selesai.

Jalur tercepat untuk membukanya ada tiga langkah. Pertama, pengembang meninjau temuan yang dilaporkan. Kedua, ia memperbaiki masalahnya dan menerbitkan rilis baru. Ketiga, kalau rilis baru itu skornya di bawah ambang batas, proses normal berjalan lagi.

Kalau ada temuan yang keliru, pengembang bisa menghubungi Tim Plugin.

Tapi tim-nya juga memberi tahu apa adanya bahwa mereka menangani volume review yang sangat tinggi, jadi menerbitkan rilis yang sudah diperbaiki hampir selalu lebih cepat daripada menunggu peninjauan manual atas banding.

Banyak orang mengira masa tunggu 6 jam itu netral, tidak ada yang untung dan tidak ada yang rugi. Kenyataannya tidak begitu.

Untuk serangan rantai pasok, penundaan jelas membantu. Penyerang butuh waktu sedekat mungkin antara mendorong rilis berbahaya dan masuk ke ribuan situs.

Untuk celah yang sudah dipublikasikan, urutannya berbalik. Saat celah diumumkan, jam penyerang sudah berjalan. Patchstack menulis angka yang tidak nyaman di sini: waktu median menuju eksploitasi massal untuk celah yang banyak dieksploitasi sekitar lima jam.

Lima jam. Lebih pendek dari enam jam penundaan.

Itu sebabnya angka median enam jam terasa aneh bagi pemilik toko. Logikanya sederhana: Anda punya jendela paparan yang lebih panjang daripada rata-rata penyerang.

Ada usulan jalur cepat untuk rilis yang pemeriksaan bersihnya selesai tanpa temuan, sehingga waktu tunggunya hanya berlangsung selama proses pemindaian.

Tapi itu masih usulan, bukan perubahan yang sudah diterapkan.

Ringkasan sekali lagi, kalau Anda cuma punya satu menit

Kalau Anda cuma punya satu menit, ini yang perlu Anda ingat. Pembaruan plugin yang telat muncul itu normal, bukan error. Jangan buru-buru mengunduh ZIP secara manual.

Plugin berbayar tidak punya pemeriksaan ini sama sekali. Jaga manual. Dan yang paling menentukan, kata sandi administrator Anda.

Sebelum menutup, satu catatan teknis untuk Anda yang punya banyak website klien.

Kalau Anda memakai tool pemeliharaan massal, tool itu membaca dari API pembaruan yang sama dengan dasbor WordPress. Jadi kalau sumbernya terlambat, tool Anda juga terlambat.

Ini yang saya maksud dengan titik buta enam jam. Untuk satu website, itu tidak berarti apa-apa. Untuk sepuluh website, itu sepuluh titik buta sekaligus.

Celah yang tidak sengaja dibuat oleh pengembang bisa mendapat skor setinggi malware yang sengaja ditanam. Yang diukur adalah risiko, bukan niat.

Kalau Anda adalah pengembang plugin dan rilisnya diblokir, itu bukan tuduhan.

Yang paling penting untuk pemilik website UMKM

Inilah bagian yang sering terlewat, dan ini yang paling penting untuk Anda yang punya toko online.

Pertama, penundaan itu juga berlaku untuk pembaruan keamanan. Ini bukan cuma formalitas.

Patchstack mengukur langsung perilaku update API WordPress.org dan mendapati hal yang tidak menyenangkan. Perbaikan untuk celah yang sudah dipublikasikan menunggu hampir sama lamanya dengan rilis biasa yang cuma mengubah warna tombol.

Dalam sampel 17 hari mereka, ada 81 rilis yang menutup celah keamanan, dari 79 plugin berbeda dengan total sekitar 9,9 juta instalasi.

Tiga puluh di antaranya punya skor CVSS 7.0 ke atas, dan sembilan di atas 9,0.

Salah satu plugin yang menutup celah penghapusan file sewenang-wenang bahkan bernilai 10,0, yaitu skor tertinggi yang bisa dicapai.

Bandingkan dengan ini. Di salah satu kasus inti WordPress yang mereka dokumentasikan, percobaan eksploitasi dimulai sekitar 90 menit setelah versi yang sudah ditambal dirilis.

Penundaan 6 jam melindungi Anda dari rilis berbahaya. Tapi penundaan yang sama membuat Anda 6 jam lebih rentan dari patch yang sudah tersedia.

Kedua, dan ini yang paling sering terlewat, pemeriksaan otomatis ini hanya berlaku untuk plugin dan theme yang diambil dari direktori WordPress.org.

Plugin premium yang lisensinya Anda beli dari pengembang langsung memeriksa pembaruan ke server mereka sendiri. ZIP yang Anda unggah sendiri. Kode kustom yang dibuat untuk Anda.

Semuanya di luar jangkauan pemeriksaan ini.

Untuk toko WooCommerce, daftar ini biasanya berisi plugin yang paling dekat dengan uang Anda: payment gateway, integrasi pengiriman, penanganan langganan.

Ketiga, ada jebakan yang tidak terlihat. Plugin bisa dihapus dari direktori, tapi Anda tetap menjalankannya. Pemeriksaan otomatis tidak pernah melihat ke dalam folder plugin di server Anda.

Keempat, cara paling umum sebuah website diretas bukan karena plugin berbahaya, tapi karena ada orang yang berhasil login dengan kata sandi administrator yang lemah atau bocor, lalu mengunggah plugin dari luar.