WordPress eklenti açıkları: denetleyin, güncelleyin, değiştirin

Bir WordPress sitesinin zayıf noktası nadiren WordPress'in kendisidir. WordPress eklenti güvenlik açıklarıyla başa çıkmak dört alışkanlığa dayanır: neyin kurulu olduğunu tam olarak bilmek, hızlı güncellemek, ihtiyacınız olmayanı silmek ve artık kimsenin bakımını yapmadığı eklentileri değiştirmek.

Bu rehberde her alışkanlığı nasıl edineceğinizi, terk edilmiş eklentileri nasıl tanıyacağınızı ve bir açık kamuoyuna duyurulduğu hâlde henüz düzeltmesi çıkmamışsa, yani en sıkıntılı durumda ne yapacağınızı anlatıyoruz. Bu konu WordPress güvenlik kontrol listemizin maddelerinden biri; çoğu site için de en önemlisi.

Rakamlarla WordPress eklenti güvenlik açıkları

Ayrıntılı yıllık rakamlar, 2025 yılını kapsayan Patchstack raporu State of WordPress Security in 2026 içinde yer alıyor. Patchstack bu risklere karşı koruma satan bir güvenlik şirketidir; raporu resmî bir istatistik olarak değil, konuya hâkim kaynaklardan biri olarak okuyun. Başlıca bulgular:

• 2025'te WordPress ekosisteminde 11.334 yeni güvenlik açığı bulundu; bu, 2024'e göre %42 daha fazla.
• Açıkların %91'i eklentilerde, %9'u temalardaydı. WordPress çekirdeğinde yalnızca altı açık vardı ve hepsi düşük öncelikliydi.
• Açıkların %17'si (1.966 adet) yüksek önem derecesindeydi ve otomatik toplu saldırılarda kullanılma olasılığı yüksekti.
• Açıkların %46'sı için kamuoyuna duyurulduğu anda geliştiriciden gelen bir düzeltme yoktu.
• En çok istismar edilen kategori bozuk erişim kontrolüydü (broken access control).

Kısacası eklenti listeniz, saldırı yüzeyinizin ta kendisidir. Her eklenti, sitenizi ve sitedeki verileri emanet ettiğiniz başka bir ekibin yazdığı koddur.

Güncelleme hızı neden önemli?

Saldırganlar siteleri tek tek elle seçmez. İnterneti açıklı bir eklenti sürümü için tarar ve buldukları her siteyi otomatik olarak istismar ederler. Aynı rapora göre yoğun biçimde istismar edilen açıklarda toplu istismara kadar geçen ağırlıklı medyan süre beş saatti; yüksek etkili açıkların yaklaşık yarısı ise ilk 24 saat içinde istismar edildi.

Ayda bir yapılan bakım bu tür durumlar için fazla yavaştır. Güvenlik sürümlerinin, özellik güncellemelerinden daha hızlı bir yoldan geçmesi gerekir. Zamanında yama yapmak, GDPR (AB Genel Veri Koruma Tüzüğü) madde 32 uyarınca gereken "uygun" güvenlik önlemlerinin de temel bir parçasıdır. NIS2 Direktifi ise kapsamındaki kuruluşlar için asgari önlemler arasında güvenlik açığı yönetimini sayar (md. 21(2)(e)).

1. adım: Eklenti envanteri tutun

Varlığından haberdar olmadığınız bir şeyi ne güncelleyebilir ne de değerlendirebilirsiniz. Her site için tutacağınız basit bir envanter, bir tablo bile olsa, şunları içermelidir:

• eklentinin adı, kısa adı (slug) ve kurulu sürümü
• kaynağı: WordPress.org, ticari bir geliştirici veya size özel yazılmış kod
• neden kurulduğu ve kimin istediği
• ücretli eklentilerde lisans durumu ve yenileme tarihi
• otomatik güncellemelerin açık olup olmadığı

WP-CLI ile bu bilgilerin çoğunu tek komutla dışa aktarabilirsiniz:

wp plugin list --fields=name,status,version,update_version,auto_update

Güncel WP-CLI sürümleri, WordPress.org'un her eklenti hakkında bildiklerini de gösterebilir; eklentinin kapatılıp kapatılmadığı da buna dâhildir:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

WordPress.org'da barındırılmayan eklentilerde bu alanlar genellikle boş görünür; onları geliştiricisinden kontrol edin. Aynısını temalar için wp theme list ile yapın.

2. adım: Kullanmadığınız eklentileri silin

Bir eklentiyi devre dışı bırakmak WordPress'in onu yüklemesini durdurur, ama dosyaları sunucuda kalır. Bazı açıklar, eklentinin dosyalarına doğrudan istek gönderilerek tetiklenebilir; etkin olmayan eklentiler de zamanla güncelleme rutininin dışında kalır. WordPress'in kendi Site Sağlığı ekranı (Araçlar → Site Sağlığı) da bu konuda uyarır: etkin olmayan eklentiler saldırganlar için cazip hedeflerdir.

Bir eklentiye artık ihtiyaç yoksa önce yedek alın, ardından Eklentiler ekranında devre dışı bırakıp silin. Komut satırında:

wp plugin uninstall old-slider --deactivate

wp plugin uninstall, eklentinin kendi kaldırma rutinini çalıştırır; bu rutin eklentinin ayarlarını ve verilerini veritabanından da silebilir. Ardından dosyalar silinir. wp plugin delete ise yalnızca dosyaları kaldırır. Hâlâ ihtiyaç duyduğunuz verileri önceden dışa aktarın.

Tipik adaylar şunlardır: bir projeden kalmış test eklentileri, aynı işi yapan eklentiler (iki önbellekleme veya iki SEO eklentisi gibi), tek seferlik taşıma araçları ve işini artık WordPress çekirdeğinin kendisinin yaptığı eklentiler.

3. adım: Terk edilmiş ve nulled eklentileri değiştirin

Aktif bir geliştiricisi olmayan bir eklenti, bir sonraki açık bulunduğunda düzeltme almaz.

Bir eklentinin terk edildiğini gösteren işaretler

• Yakın zamanda güncelleme yok. Eklentinin WordPress.org sayfasındaki son güncelleme tarihine ("Last updated") bakın. WordPress.org, bir eklenti WordPress'in son 3 ana sürümüyle test edilmemişse de bir uyarı gösterir ("hasn't been tested with the latest 3 major releases of WordPress").
• WordPress.org'da kapatılmış. Kırmızı bir uyarı, eklentinin kapatıldığını ve artık indirilemediğini belirtir ("has been closed and is no longer available for download"). 60 gün sonra kapatılma nedeni de eklenir; olası nedenlerden biri "Security Issue", yani güvenlik sorunudur. Neden ne olursa olsun, eklenti kapalı kaldığı sürece WordPress.org üzerinden size hiçbir güncelleme ulaşmaz.
• Yanıtsız kalan destek konuları, özellikle de güvenlik sorunlarından bahsedenler.
• Geliştiricisinden ses çıkmayan ücretli eklentiler: değişiklik günlüğüne yeni kayıt girilmiyor, lisans yenileme çalışmıyor, destek ekibi yanıt vermiyor.

Bu bildirimler WordPress.org'un uyarılar ve ikazlar belgesinde açıklanır. Bunlardan birini gördüğünüzde, bir acil durum sizi zorlamadan önce eklentinin yerine ne koyacağınızı planlayın.

Asla nulled eklenti kullanmayın

"Nulled" eklentiler, ücretli eklentilerin lisans kontrolü kaldırılmış korsan kopyalarıdır. Kodu kimliği belirsiz üçüncü bir kişi değiştirmiştir ve başka nelerin değiştirildiğini kimse bilemez. Bu tür kopyalarda gizli arka kapılar iyi bilinen bir sorundur. Üstelik hiçbir zaman güncelleme veya destek almazlar; bir sonraki açık ortaya çıktığında onları yamalayamazsınız.

Bir sitede böyle bir eklenti bulursanız lisanslı bir kopyayla değiştirin ve siteyi ele geçirilmiş olabilecek bir site olarak ele alın.

4. adım: Otomatik güncellemeyle veya test ortamıyla hızlı güncelleyin

WordPress 5.5'ten bu yana Eklentiler ekranındaki otomatik güncelleme sütunundan her eklenti için otomatik güncellemeyi ayrı ayrı açabilirsiniz. WordPress bu güncellemeleri varsayılan olarak günde iki kez çalıştırır ve sonuçları size e-postayla bildirir (WordPress.org belgeleri). WP-CLI ile: wp plugin auto-updates enable --all.

Saldırıların ne kadar hızlı geldiği düşünüldüğünde, çoğu eklenti için doğru varsayılan otomatik güncellemedir. Yine de bozuk bir güncellemenin gerçek para kaybına yol açacağı yerlerde bir test ortamı (staging) kullanmak mantıklıdır:

Hangisini seçerseniz seçin, en az bir kez gerçekten geri yüklemeyi denediğiniz yedekler tutun ve güncelleme e-postalarını birinin okuduğundan emin olun.

5. adım: Açıkları takip edin ve harekete geçin

Eklenti açıklarını nerede araştırabilirsiniz?

• Eklentinin WordPress.org sayfasındaki veya geliştiricinin sitesindeki değişiklik günlüğü (changelog). "security fix" gibi kayıtlara bakın; ancak bazı geliştiricilerin düzeltmeleri belirsiz ifadelerle anlattığını unutmayın.
• Eklenti adına göre arama yapabileceğiniz WPScan ve Patchstack veritabanları gibi herkese açık güvenlik açığı veritabanları. Her ikisi de güvenlik hizmeti de satan şirketler tarafından işletilir.
• Ücretli eklentiler için geliştiricilerin güvenlik bildirimleri ve bültenleri.

Onlarca eklentiyi elle kontrol etmek sürdürülebilir değildir. secaudit.eu tarafından geliştirilen denetim eklentisi Security Audit & Compliance, güncel olmayan eklentileri, temaları ve çekirdeği ek bir ayar gerektirmeden işaretler. Açık kontrollerini açtığınızda kurulu sürümleri, her gece resmî CVE Listesi’nden oluşturulan ücretsiz secaudit.eu açık veritabanıyla da karşılaştırır; eklenti listeniz sitenizden hiç çıkmaz.

Henüz düzeltme yoksa ne yapmalı?

Tüm açıkların neredeyse yarısı (%46) duyurulduğu anda düzeltilmemişti. Kullandığınız bir eklentide böyle bir açık varsa:

1. Ne kadar açıkta olduğunuzu değerlendirin. Açıklı özelliğe anonim ziyaretçiler mi erişebiliyor, yoksa yalnızca oturum açmış yöneticiler mi?
2. Eklentiyi devre dışı bırakın, bir süre onsuz idare edebiliyorsanız. Düzeltme gelmezse silin.
3. Değiştirin: geliştirici sessiz kalırsa bakımı süren bir alternatife geçin.
4. Sanal yama kullanın, eklenti vazgeçilmezse. Bazı web uygulaması güvenlik duvarları (WAF) ve güvenlik hizmetleri, bilinen istismarla eşleşen istekleri engelleyen kurallar sunar. Bu size zaman kazandırır, ama kodu düzeltmez.
5. Sitenin ele geçirilip geçirilmediğini kontrol edin, özellikle açık siz fark etmeden önce bir süredir biliniyorsa. Bir WordPress sitesinin hacklendiğini gösteren belirtiler listemiz iyi bir başlangıç noktasıdır.

Eklenti satıyorsanız: Siber Dayanıklılık Yasası

Geliştiriciler için güvenlik açığı yönetimi yasal bir yükümlülüğe dönüşüyor ve bunun bir kısmı zaten yürürlükte. AB'deki müşterilere satılan ücretli bir eklenti veya tema, Siber Dayanıklılık Yasası (CRA) kapsamında "dijital unsurlar içeren bir ürün"dür; onu satan da üreticidir. 11 Eylül 2026 tarihinden bu yana üreticiler, ürünlerindeki aktif olarak istismar edilen açıkları ENISA'nın Tek Raporlama Platformu üzerinden bildirmek zorundadır: 24 saat içinde erken uyarı, 72 saat içinde bildirim ve bir düzeltici önlem kullanıma sunulduktan sonra 14 gün içinde nihai rapor.

11 Aralık 2027'den itibaren asıl yükümlülükler devreye girer; destek süresi boyunca güvenlik güncellemeleri, bir güvenlik açığı yönetim süreci, koordineli açıklama politikası ve yazılım malzeme listesi (SBOM) bunların arasındadır. Ücretsiz ve gelir elde edilmeyen açık kaynak eklentiler genellikle bu üretici rejiminin dışında kalır. Ayrıntıları eklenti satıcıları için Siber Dayanıklılık Yasası rehberimizde bulabilirsiniz.

Sık sorulan sorular

Devre dışı bırakılmış bir eklenti güvenli midir?

Hayır. Dosyaları sunucuda kalır ve hâlâ istismar edilebilir kod içerebilir. Kullanmadığınız eklentileri silin.

Her eklenti için otomatik güncellemeyi açmalı mıyım?

Çoğu eklenti için evet, güvenilir yedeklerle birlikte. İşiniz için kritik eklentileri önce test ortamında deneyin, ama bu gecikmeyi kısa tutun.

Güvendiğim bir eklenti WordPress.org'da kapatıldıysa ne yapmalıyım?

Düzeltilmiş bir sürümle yeniden açılana kadar onu bakımı yapılmayan bir eklenti olarak kabul edin ve şimdiden bir alternatif aramaya başlayın.

Bu makale genel bilgi niteliğindedir, hukuki danışmanlık değildir.