WordPress eklentilerinin güvenliği, panelde “güncel” yazmasını kontrol etmekle sınırlı kalmıyor. Rank Math PRO olayı bunun güncel bir örneği. Üreticinin resmî olay açıklamasına göre, 15 Ekim 2026 saat 20.02 UTC ile 16 Ekim saat 07.12 UTC arasında indirilen PRO 3.0.123 paketlerinin bir bölümü zararlı yazılım içeriyordu. Türkiye saatiyle bu aralık 15 Ekim 23.02 ile 16 Ekim 10.12 arasına karşılık geliyor. Üretici etkilenen dosyaları kaldırdığını ve temiz 3.0.124 sürümünü yayımladığını belirtiyor. WordPress.org üzerinden sunulan ücretsiz Rank Math SEO eklentisi bu olaydan etkilenmiyor.
Burada önemli bir ayrım var: Zararlı paketi etkinleştiren bir sitede yalnızca güncelleme yapmak yeterli değil. Rank Math bu siteleri ele geçirilmiş kabul etmeyi ve özel kurtarma adımlarını izlemeyi istiyor. Aşağıdaki kontroller genel bakım için bir başlangıç sunuyor; olaydan etkilenen sitelerin temizliğinin yerini tutmuyor.
Önce sürümü ve güncelleme geçmişini kaydedin
WordPress yönetim panelinde Eklentiler bölümünü açın. Her eklentinin adını, geliştiricisini, kurulu sürümünü ve etkin olup olmadığını bir listeye yazın. Ardından geliştiricinin resmî sürüm notlarını okuyun. Güvenlik düzeltmesinin hangi sürümde geldiğini, hangi eski sürümleri kapsadığını ve ek işlem gerektirip gerektirmediğini kontrol edin. Uzun süredir güncellenmeyen bir eklentiyi ayrıca değerlendirin; güncelleme tarihini tek başına güvenlik belgesi saymayın.
Paneldeki sürüm numarası, paketi ne zaman kurduğunuzu her zaman açıklamaz. Barındırma sağlayıcısının işlem kayıtları, varsa önceden tutulan etkinlik günlükleri ve yedek tarihleri üzerinden güncelleme zamanını araştırın. Özellikle belirli bir dağıtım aralığını kapsayan olaylarda “bende o sürüm yok” demeden önce geçmişi inceleyin. Kayıt bulamıyorsanız sonucu “etkilenmedi” diye kapatmayın; üretici desteğine belirsizliği iletin.
İndirme kaynağını ve geliştiriciyi doğrulayın
Ücretsiz eklentiyi WordPress.org dizinindeki kendi sayfasından, ücretli eklentiyi üreticinin resmî hesabından edinin. Arama reklamı, forumdaki ZIP dosyası veya lisans kontrolü kaldırılmış bir paket üzerinden kurulum yapmayın. Alan adını ve geliştirici adını karşılaştırın. E-posta içindeki “acil güvenlik güncellemesi” bağlantısına basmak yerine üreticinin adresini kendiniz açın. WordPress’in güvenlik rehberi de eklenti ve temalar için güvenilir kaynakları esas alıyor.
Resmî kaynak kullanmak riski azaltır; her paketin güvenli olduğunu tek başına kanıtlamaz. Bir olay duyurusu varsa üreticinin son açıklamasını da okuyun. Teknoblog’un ACF eklentisinin kontrol devrine ilişkin haberi, eklentinin adı kadar geliştirici ve dağıtım kanalını takip etmenin de neden önemli olduğunu gösteren ayrı bir örnek.
Yönetici hesaplarının gerçekten kime ait olduğunu kontrol edin
Kullanıcılar bölümünde yönetici rolündeki hesapları gözden geçirin. Her hesap için sorumlu kişiyi, e-posta adresini ve bu yetkiye hâlâ ihtiyaç duyulup duyulmadığını doğrulayın. Eski bir ajans hesabını veya tanımadığınız kullanıcıyı açıklığa kavuşturmadan normal kabul etmeyin. Ancak yalnızca adı garip görünüyor diye hesap silmeyin; önce siteyi yöneten ekiple sahipliğini kontrol edin.
Günlük yazı işleri için gereken rolü kullanın, yönetici yetkisini bakım yapan kişilerle sınırlayın. Her kişiye ayrı hesap verin; güçlü, benzersiz parolalar ve iki aşamalı doğrulama kullanın. Beklenmedik yönetici hesabı ya da izinsiz değişiklik görürseniz rutin bakım akışını durdurun. Saatleri ve bulguları kaydedip barındırma sağlayıcısıyla inceleme başlatın. Hesabı kaldırmak, erişimin nasıl elde edildiğini açıklamaz.
Yedeğin varlığını değil, geri yüklenebildiğini doğrulayın
Yedekleme ekranındaki yeşil işaret tek başına yeterli değil. Dosyaları ve veritabanını birlikte içeren bir yedek seti seçin; tarihini, boyutunu, saklandığı yeri ve erişim bilgilerini kontrol edin. WordPress’in yedekleme belgesi, tam geri yükleme için bu iki parçanın da gerekli olduğunu açıklıyor. Kopyaları aynı sunucuyla sınırlamayın.
Yedeği canlı sitenin üzerine yazmadan, erişimi kısıtlı ayrı bir deneme ortamına geri yükleyin. Ana sayfayı, yönetim girişini, görselleri ve kritik formları kontrol edin. Sipariş alan sitelerde ödeme işlemlerini test modunda deneyin; deneme kopyasının gerçek müşterilere e-posta göndermesini engelleyin. Hangi yedeği ne zaman açabildiğinizi not edin. Şüpheli tarihten sonraki bir kopyayı sırf yeni olduğu için temiz saymayın.
Güncellemeden önce staging ve geri dönüş hazırlayın
Staging, canlı sitenin değişiklikleri denediğiniz kopyasıdır. Eklenti güncellemesini önce burada uygulayın; arama, üyelik, sepet ve iletişim gibi siteniz için önemli akışları kontrol edin. Güncelleme öncesi sürümleri, yedek setini ve geri dönüşü kimin yapacağını kaydedin. Bir sorun çıktığında yalnızca eski ZIP dosyasına dönmek yetmeyebilir; güncelleme veritabanını da değiştirmiş olabilir. Geri dönüş planını buna göre hazırlayın.
Rank Math olayında etkilenen paketi etkinleştirdiyseniz üreticinin özel kurtarma adımlarını sırayla izleyin. Temiz yedekten dönüş veya uzman eşliğinde temizlik, erişim bilgilerinin yenilenmesi ve güvenlik kontrolü bu sürecin parçaları. Sadece eklentiyi devre dışı bırakmak yeterli değil. Kurup hiç etkinleştirmeyenler için üretici, etkilenen dosyaları silip temiz sürümü kurmayı ve tarama yapmayı söylüyor. Kendi durumunuz belirsizse destek alın.
Bir bakım kaydı tutmak sonraki kontrolü kolaylaştırır. Her işlemde tarih, önceki ve sonraki sürüm, değişikliği yapan kişi ve kontrol edilen sayfaları yazın. Birden fazla kişi siteyi yönetiyorsa bu kaydı ortak erişilen bir yerde saklayın. Böylece beklenmedik bir değişiklikte tahmin yürütmek yerine son sağlıklı duruma hangi adımlarla dönebileceğinizi görebilirsiniz.
Bu kontrollerin sonunda elinizde güncel bir eklenti listesi, hesabı belli yöneticiler, açılabildiğini gördüğünüz yedek ve uygulanabilir bir geri dönüş planı bulunmalı. Kontrollerden biri eksikse bakım işini tamamlandı saymayın; eksik adımı ve sorumlusunu belirleyin.
