WordPress, eklenti ve tema güncellemelerini dağıtıma çıkmadan önce otomatik güvenlik incelemesinden geçirerek yüksek riskli sürümleri kullanıcıya ulaşmadan engellemeye başladı. Yeni sistem, 28 Temmuz 2026’da yaklaşık 20 bin aktif kuruluma sahip bir eklenti sürümüne gizli arka kapı eklendiğini yakaladı ve zararlı paket WordPress.org güncelleme API’si üzerinden hiç dağıtılmadı.
Şirket, bu yaklaşımın özellikle yayın ile dağıtım arasındaki boşluğu kapatmayı hedeflediğini belirtiyor. WordPress Resmî Eklenti Deposu Eş Lideri David Perez, yeni eklentilerin dizine alınmadan önce incelendiğini ancak sonraki güncellemelerin sürekli yayımlandığını hatırlattı. Perez, bir eklentinin bugün güvenli görünürken ilerleyen bir sürümde açık ya da kötü amaçlı kod taşıyabileceğini söyledi.
WordPress, bir sürümün depoya gönderilmesi ile son kullanıcılara açılması arasında tutarlı bir inceleme adımı bulunmamasının kötü niyetli saldırılar için kapı aralayabildiğini vurguladı. Bu eksikliği gidermek için 5 Haziran 2026’dan bu yana tüm WordPress eklenti ve temaları, Protect The Shire adı verilen yeni güvenlik girişimi kapsamında otomatik güncelleme öncesinde bir bekleme sürecine alınıyor.
İlk uygulamaya alındığında 24 saat olan bu bekleme süresi, şu anda 6 saate düşmüş durumda. WordPress, bu gecikmeyi bilinçli olarak sisteme sürtünme eklemek için kullandığını söylüyor; amaç, zararlı güncellemelerin son kullanıcılara anında ulaşmasını engellemek.
28 Temmuz’da yaşanan olayda otomatik inceleme, yaklaşık 20 bin etkin kuruluma sahip bir eklenti sürümünde arka kapı buldu. Sürüm soğuma penceresi içindeydi; bu nedenle ele geçirilmiş paket dağıtıma hiç girmedi. WordPress, eklentinin adını açıklamadı. Eklenti, Wordfence’in WordPress güvenlik ekibini güncelleme hakkında uyarmasından 26 dakika sonra indirmeye kapatıldı.
WordPress’e göre yeni mekanizma yalnızca güncellemenin içeriğine bakmıyor, aynı zamanda dağıtım zincirindeki riski de azaltıyor. Yayınlanan her eklenti ve tema sürümü, bekleme süresi boyunca WordPress.org tarafında yapay zekâ modelleri ve Jetpack Scan ile analiz ediliyor. Sistem, sonuçları çapraz doğrulayıp tek bir güvenlik puanına dönüştürüyor; puan yükseldikçe risk de artıyor. Yüksek riskli görülen sürümler inceleme tamamlanır tamamlanmaz otomatik olarak bloklanıyor. Eşik altındaki sürümler ise olağan akışa devam ediyor.
Bu süreçte eklenti geliştiricilerine yalnızca sürüm engellendiğinde bulguları içeren bir e-posta gönderiliyor. WordPress, yüksek risk puanının her zaman kasıtlı kötü niyet anlamına gelmediğini de özellikle not ediyor; sistem, yanlışlıkla eklenmiş güvenlik açıklarını da, bilerek yerleştirilmiş zararlı kodları da aynı sınıfta değerlendiriyor.
Perez, güvenlik incelemesinin herhangi bir klasik denetimin baktığı açık sınıflarını hedeflediğini söyledi ve geliştiricileri WordPress Coding Standards ile PHP_CodeSniffer (PHPCS) kurallarına uymaya çağırdı. WooCommerce uzantısı yayımlayanlara ise Quality Insights Toolkit (QIT) test platformunu kullanmaları tavsiye ediliyor.
Risk puanını yukarı taşıyabilen kod kalıpları arasında, yetki kontrolü olmadan açılmış REST, AJAX veya admin-post uç noktaları yer alıyor. Burada nonce kullanımı tek başına yetkilendirme sayılmıyor. Aynı şekilde, $wpdb->prepare() kullanılmadan kurulan sorgular da risk yaratıyor.
İnceleme, istek verisinden oluşturulan dosya yollarını, yüklemeleri, silmeleri ya da include işlemlerini; request verisi ya da uzaktan gelen yanıt üzerinde çalışan unserialize() kullanımını; aboneler veya kimliği doğrulanmamış kullanıcılar tarafından erişilebilen uç noktalardan yazılan seçenek, kullanıcı meta verisi ya da ayar kayıtlarını da işaret edebiliyor. Çalışma anında çekilen veya değerlendirilen kod ile gizlenmiş ya da paketlenmiş kod da puanı yükselten işaretler arasında.
Bir sürüm engellendiğinde geliştiricinin kısıtlamaları kaldırmasının tek yolu, bulguları inceleyip sorunları düzeltmesi ve yeni bir sürüm yayımlaması. Yeni sürüm yüksek risk eşiğinin altına düşerse, bu kez olağan soğuma sürecinden geçerek dağıtıma açılıyor. Perez, bir bulgunun hatalı göründüğü durumlarda yazarların Eklenti Ekibi ile temas kurabileceğini de söyledi; ancak ekibin çok yüksek sayıda inceleme yürüttüğünü, bu yüzden düzeltilmiş bir sürüm yayımlamanın çoğu zaman itirazın manuel olarak değerlendirilmesini beklemekten daha hızlı olduğunu vurguladı.