WordPress’te En Yaygın 10 Güvenlik Açığı ve Korunma Yöntemleri

WordPress, dünyadaki web sitelerinin yaklaşık yüzde kırkını çalıştıran en popüler içerik yönetim sistemidir. Bu popülerlik beraberinde büyük bir saldırı yüzeyi de getirir: saldırganlar her gün milyonlarca WordPress sitesini otomatik araçlarla tarayarak bilinen açıkları sömürmeye çalışır. İyi haber şu ki, WordPress hack vakalarının büyük çoğunluğu sıfırıncı gün açıklarından değil, ihmal edilen klasik güvenlik hatalarından kaynaklanır. Bu rehberde WordPress’te en yaygın 10 güvenlik açığını, her birinin gerçek dünyada nasıl sömürüldüğünü ve sitenizi korumak için atmanız gereken pratik adımları ele alacağız.

Neden WordPress Bu Kadar Sık Hedef Alınır?

WordPress’in saldırganlar için cazip olmasının birkaç temel nedeni vardır:

• Yaygınlık: Tek bir açık milyonlarca siteyi etkileyebilir; saldırganlar için ölçek ekonomisi sağlar.
• Açık kaynak yapısı: Çekirdek kodun yanı sıra binlerce eklenti ve tema kamuya açıktır; saldırganlar kaynak kodu analiz ederek açık arar.
• Eklenti ekosistemi: 60.000’den fazla eklenti vardır ve kalite kontrolü değişkendir. Açıkların büyük çoğunluğu çekirdekte değil, üçüncü taraf eklentilerde bulunur.
• Kullanıcı profili: WordPress kullanıcılarının önemli bir bölümü teknik bilgi sahibi olmayan kişilerdir; güncelleme, yedekleme ve güvenlik sertleştirmesi sıklıkla ihmal edilir.
• Standart yapı: Yönetici paneli URL’si, dosya yolları ve veritabanı yapısı çoğu sitede aynıdır; bu da otomatik saldırı araçlarını kolaylaştırır.

Şimdi en sık karşılaşılan açıkları teker teker inceleyelim.

1. Güncel Olmayan WordPress Çekirdeği, Eklenti ve Temalar

Hacklenmiş WordPress sitelerinin büyük çoğunluğunun arkasında tek bir sebep vardır: güncellenmemiş yazılım. Bir güvenlik açığı duyurulduğu anda, saldırganlar etkilenen sürümleri tarayan botları devreye alır. Açık duyurusu ile sömürü arasındaki süre çoğu zaman saatlerle ölçülür.

En kritik risk eklentilerdedir. Wordfence ve Patchstack raporlarına göre WordPress açıklarının yüzde doksandan fazlası üçüncü taraf eklentilerden gelir. Özellikle uzun süredir güncellenmeyen veya geliştirici desteği bırakılmış (abandoned) eklentiler ciddi tehdit oluşturur.

Korunma adımları:

• WordPress çekirdeğini, eklentileri ve temaları düzenli olarak güncelleyin; mümkünse auto-update özelliğini açın.
• Kullanmadığınız eklenti ve temaları yalnızca devre dışı bırakmakla yetinmeyin, tamamen silin. Pasif dosyalar bile saldırı yüzeyidir.
• Bir yıldan uzun süredir güncellenmemiş veya WordPress.org’dan kaldırılmış eklentileri terk edin.
• Güncelleme öncesi mutlaka tam yedek alın ve mümkünse staging ortamında test edin.
• WPScan, Patchstack veya Wordfence Intelligence gibi kaynaklardan açık bildirimlerine abone olun.

2. Zayıf Parolalar ve Brute Force (Kaba Kuvvet) Saldırıları

Brute force, WordPress’e yönelik en eski ve en yaygın saldırı türüdür. Saldırgan, /wp-login.php sayfasına saniyede yüzlerce kullanıcı adı ve parola kombinasyonu göndererek hesap ele geçirmeye çalışır. “admin”, “administrator”, “root” gibi varsayılan kullanıcı adları ve “123456”, “password”, “qwerty” gibi yaygın parolalar saldırganların ilk denediği kombinasyonlardır.

Saldırının daha tehlikeli bir varyantı credential stuffing‘tir: başka sitelerden sızdırılmış kullanıcı adı/parola çiftleri WordPress giriş sayfasında denenir. Parolasını birden fazla sitede kullanan kullanıcılar bu saldırıya açıktır.

Korunma adımları:

• Varsayılan admin kullanıcı adını asla kullanmayın; tahmin edilmesi güç bir kullanıcı adı seçin.
• En az 16 karakterli, büyük/küçük harf, rakam ve özel karakter içeren parolalar oluşturun. Bir parola yöneticisi kullanın.
• İki adımlı doğrulamayı (2FA) mutlaka etkinleştirin. Wordfence, WP 2FA veya Google Authenticator entegrasyonu sağlayan eklentiler kullanılabilir.
• Giriş denemelerini sınırlayın: Limit Login Attempts Reloaded gibi eklentilerle başarısız giriş sonrası IP’yi geçici olarak engelleyin.
• Giriş sayfasını /wp-login.php dışında özel bir URL’ye taşıyın (örn. WPS Hide Login).
• Mümkünse wp-admin dizinine sunucu seviyesinde IP kısıtlaması veya HTTP Basic Auth (htpasswd) ekleyin.

3. SQL Injection (SQL Enjeksiyonu)

SQL Injection, kullanıcıdan gelen verinin doğrudan veritabanı sorgusuna eklendiği durumlarda ortaya çıkar. Saldırgan, form alanı veya URL parametresi üzerinden gönderdiği özel hazırlanmış girdiyle veritabanından veri çekebilir, kullanıcı parolası hash’lerini sızdırabilir, hatta yeni yönetici hesabı oluşturabilir.

WordPress çekirdeği $wpdb->prepare() ile parametrize sorgu kullandığı için iyi korunur; ancak üçüncü taraf eklentilerde SQL Injection açıkları sıkça bulunur. Özellikle arama, filtreleme, raporlama ve özel form eklentileri tarihsel olarak risklidir.

Korunma adımları:

• Eklenti ve temaları güncel tutun (1. maddeye bakın).
• WPScan veya Patchstack ile sitenizdeki eklentilerin bilinen açıklarını tarayın.
• Önünüze bir Web Application Firewall (WAF) koyun: Cloudflare WAF, Sucuri, Wordfence veya sunucu tarafında ModSecurity OWASP CRS.
• Özel kod yazıyorsanız her zaman $wpdb->prepare() kullanın; string concatenation ile sorgu oluşturmayın.
• Veritabanı kullanıcısının yetkisini gerekli olanla sınırlayın; DROP, GRANT gibi yetkiler genelde gerekli değildir.
• Varsayılan wp_ tablo önekini değiştirin; tek başına yeterli değildir ama otomatik araçların işini zorlaştırır.

4. Cross-Site Scripting (XSS)

XSS, saldırganın bir web sayfasına kötü amaçlı JavaScript kodu enjekte etmesidir. Ziyaretçi sayfayı açtığında bu kod tarayıcısında çalışır; çerezleri çalabilir, oturumu ele geçirebilir, kullanıcıyı sahte sayfalara yönlendirebilir veya yönetici tarayıcısında istek yapabilir.

WordPress’te en sık görülen XSS senaryoları şunlardır:

• Yorum alanlarında filtrelenmemiş HTML/JavaScript girdisi.
• Form eklentilerinin output aşamasında veriyi escape etmemesi.
• Tema ve eklentilerin echo $_GET['param'] gibi güvensiz kalıplar kullanması.
• Yönetici panelinde gösterilen eklenti ayarlarında stored XSS.

Korunma adımları:

• Eklenti ve temaları güncel tutun; XSS yamaları en sık yayınlanan düzeltmeler arasındadır.
• Bilinmeyen kullanıcılardan gelen yorumları onaya tabi tutun; spam filtresi olarak Akismet veya Antispam Bee kullanın.
• HTTP yanıt başlıklarınıza Content Security Policy (CSP), X-XSS-Protection, X-Content-Type-Options: nosniff ekleyin.
• Özel kod yazıyorsanız çıktıyı her zaman esc_html(), esc_attr(), esc_url(), wp_kses() ile temizleyin.
• WAF kuralları çoğu klasik XSS denemesini engeller; CDN seviyesinde aktif edin.

5. Cross-Site Request Forgery (CSRF)

CSRF, oturumu açık bir yöneticiyi farkında olmadan istemediği bir işlem yapmaya zorlayan saldırı türüdür. Yönetici, başka sekmede açık bir kötü amaçlı sayfayı ziyaret ettiğinde, sayfa arka planda WordPress sitesine istek gönderir: yeni kullanıcı oluştur, eklenti yükle, ayar değiştir gibi.

WordPress, bu saldırıya karşı nonce (number used once) mekanizmasıyla korunur. Ancak nonce kontrolünü eksik veya hatalı uygulayan eklentiler ciddi açıklar yaratır; geçmişte popüler eklentilerde defalarca CSRF kaynaklı yönetici hesabı oluşturma açığı bulunmuştur.

Korunma adımları:

• Tüm eklentileri güncel tutun; CSRF açıkları için yamaları zaman geçirmeden uygulayın.
• İki adımlı doğrulama, yöneticiye yönelik CSRF’in etkisini büyük ölçüde azaltır.
• Önemli işlemler sonrası yöneticiyi oturumdan otomatik çıkaracak şekilde oturum süresini kısaltın.
• Özel form veya AJAX endpoint yazıyorsanız wp_nonce_field() ve check_admin_referer() / check_ajax_referer() kullanmadan istek işlemeyin.
• Çerez güvenliği için SameSite=Lax veya Strict politikasını uygulayın.

6. Güvensiz Dosya Yükleme Açıkları

Birçok WordPress eklentisi kullanıcıya dosya yükleme imkânı verir: galeri, form eki, profil resmi, ürün dosyası vb. Yükleme aşamasında dosya türü ve içeriği yeterince doğrulanmazsa, saldırgan PHP uzantılı bir shell (web kabuğu) yükleyerek sunucuda komut çalıştırabilir. Bu, çoğu zaman tam sunucu ele geçirilmesiyle sonuçlanır.

Klasik hatalar:

• Dosya uzantısının yalnızca client-side (JavaScript) ile kontrol edilmesi.
• .php, .phtml, .phar uzantılarının kara liste yerine beyaz liste ile filtrelenmemesi.
• Yüklenen dosyanın wp-content/uploads içinde doğrudan çalıştırılabilir olması.
• Dosya adının kullanıcıdan gelen değerle korunmadan oluşturulması (Path Traversal).

Korunma adımları:

• wp-content/uploads dizininde PHP çalıştırmayı sunucu seviyesinde engelleyin. .htaccess ile:

  <FilesMatch "\.(php|phtml|phar|php5|php7|php8)$">
    Require all denied
  </FilesMatch>

  Nginx’te benzer location bloğu kullanın.

• Yükleme işlevi olan eklentileri güncel tutun ve mümkünse az sayıda, iyi bakılan eklentilerle sınırlayın.
• Kullanıcı bazlı yükleme yetkilerini gözden geçirin: Subscriber rolünün dosya yüklememesi gerekir.
• WAF ile yüklenen dosya içeriğini tarayın; Imunify360, Wordfence veya Sucuri bu konuda etkilidir.

7. Yanlış Dosya ve Dizin İzinleri

Linux sunucularda dosya izinleri yanlış ayarlandığında, saldırgan küçük bir açıktan yetkilerini yükseltebilir veya sitedeki diğer kullanıcıların alanlarına sıçrayabilir. Özellikle paylaşımlı hostinglerde 777 izinli bir dizin tüm sunucu için risk oluşturur.

WordPress için önerilen izinler:

• Dizinler: 755
• Dosyalar: 644
• wp-config.php: 600 veya 640
• Sahiplik: dosyaların web sunucu kullanıcısı (örn. nobody, www-data) yerine site sahibi kullanıcıya ait olması, sunucu kullanıcısının yalnızca grup üyesi olması idealdir.

Korunma adımları:

• cPanel’de “Fix File Permissions” aracını kullanın veya SSH ile şu komutları çalıştırın:

  find /home/kullanici/public_html -type d -exec chmod 755 {} \;
  find /home/kullanici/public_html -type f -exec chmod 644 {} \;
  chmod 600 /home/kullanici/public_html/wp-config.php

• Paylaşımlı hostingte suPHP, PHP-FPM with user pools veya CloudLinux CageFS kullanan sağlayıcıları tercih edin.
• 777 izninden mutlak surette kaçının; “çalıştı, izinleri açtım” geçici çözümler kalıcı açığa dönüşür.

8. wp-config.php ve Hassas Dosyaların Korunmaması

wp-config.php WordPress’in en kritik dosyasıdır; veritabanı bilgileri, kimlik doğrulama anahtarları (SALT) ve sürücü ayarları burada tutulur. Bu dosyanın içeriği saldırganın eline geçerse sitenin tamamı tehlikededir. Yedek alma araçlarının bıraktığı wp-config.php.bak, wp-config.old gibi dosyalar tarayıcıdan doğrudan indirilebilir ve sızıntıya yol açabilir.

Aynı tehlike .git dizininin, debug.log, .env, phpinfo.php ve veritabanı dump dosyalarının halka açık dizinlerde bırakılması için de geçerlidir.

Korunma adımları:

• wp-config.php‘yi mümkünse public_html‘in bir üst dizinine taşıyın. WordPress bunu otomatik olarak okur.
• Aşağıdaki .htaccess kuralını ekleyin:

  <Files wp-config.php>
    Require all denied
  </Files>
  <FilesMatch "\.(bak|old|sql|log|env)$">
    Require all denied
  </FilesMatch>

• WordPress kurulumunda secret keys‘i api.wordpress.org/secret-key/1.1/salt/ üzerinden yenileyin; bir ihlal şüphesi sonrası mutlaka değiştirin.
• WP_DEBUG‘ı üretim ortamında false, en azından WP_DEBUG_DISPLAY‘ı false yapın; debug.log‘u tarayıcıdan erişilemez konuma alın.
• FTP yerine her zaman SFTP veya SSH kullanın.

9. XML-RPC ve REST API’nin Kötüye Kullanımı

XML-RPC, WordPress’in eski mobil istemci ve uzaktan yayın özelliği için kullandığı bir endpoint’tir (/xmlrpc.php). Günümüzde yerini büyük ölçüde REST API’ye bırakmıştır, ancak hâlâ varsayılan olarak aktiftir. Saldırganlar XML-RPC’yi üç şekilde kötüye kullanır:

• Brute force amplification: system.multicall metodu ile tek bir HTTP isteğinde yüzlerce parola denemesi yapılabilir.
• DDoS pingback: pingback.ping metodu, WordPress sitesini başka bir hedefe saldıran bir aracıya dönüştürebilir.
• Bilgi sızdırma: Etkinleştirilmiş metodlardan kullanıcı listesi elde edilebilir.

REST API tarafında ise /wp-json/wp/v2/users endpoint’i, kimlik doğrulaması yapılmamış kullanıcılara dahi kullanıcı adlarını listeleyebilir. Bu, brute force saldırıları için altın değerinde bir bilgidir.

Korunma adımları:

• XML-RPC’ye ihtiyacınız yoksa tamamen kapatın. .htaccess ile:

  <Files xmlrpc.php>
    Require all denied
  </Files>

• Disable XML-RPC veya Wordfence gibi eklentilerle de kapatılabilir.
• REST API’de users endpoint’ini anonim kullanıcılara kapatın; bunu yapan birçok güvenlik eklentisi vardır.
• Yazar arşiv sayfası ?author=1 sorgusunu engelleyin; bu sorgu kullanıcı slug‘ını ifşa eder.

10. Tedarik Zinciri Açıkları: Nulled, Pirated ve Terk Edilmiş Eklentiler

“Nulled” yani lisansı kırılmış premium eklenti ve temalar, WordPress dünyasındaki en yaygın arka kapı (backdoor) kaynaklarından biridir. Ücretsiz olarak dağıtılan bu paketlerin büyük çoğunluğu, içine yerleştirilmiş kötü amaçlı kod ile birlikte gelir: site sahibine fark ettirmeden saldırgana uzaktan erişim sağlar, spam içerik enjekte eder veya siteyi botnet’in parçası hâline getirir.

Benzer şekilde, GitHub veya küçük geliştirici sitelerinden indirilen kod, geliştiricinin kendi hesabı ele geçirildiğinde supply chain saldırısının taşıyıcısı olabilir. Geçmişte birden fazla popüler eklenti, yeni sahibine devredildikten sonra zararlı kod ile güncellenmiştir.

Korunma adımları:

• Eklenti ve temaları yalnızca WordPress.org, geliştiricinin resmi sitesi veya CodeCanyon gibi denetlenen pazaryerlerinden temin edin.
• Nulled yazılım kullanmayın; ekonomik kazancın bedeli neredeyse her zaman site ele geçirmedir.
• El değiştiren veya uzun süredir güncellenmeyen eklentileri yakın takibe alın; Patchstack “abandoned plugin” uyarılarını izleyin.
• Sitede dosya bütünlüğü taraması yapın: Wordfence “scan”, Sucuri SiteCheck veya MalCare ile çekirdek ve eklenti dosyalarının orijinal sürümleriyle karşılaştırın.
• Şüpheli durumlarda wp-content/plugins, wp-content/themes ve wp-content/uploads içinde olağandışı PHP dosyalarını, eval(base64_decode(...)) kalıplarını arayın.

Bonus: Eksikliği Açık Kadar Tehlikeli 5 Önlem

Yukarıdaki on açığa ek olarak, bir WordPress sitesinde bulunması gereken temel savunma katmanlarını da hatırlatmakta fayda var:

• SSL/TLS (HTTPS): Let’s Encrypt ile ücretsiz sertifika alın; HTTP’den HTTPS’e 301 yönlendirme yapın; HSTS başlığı ekleyin.
• Düzenli yedekleme: UpdraftPlus, Jetpack VaultPress veya sunucu seviyesinde JetBackup ile günlük yedek alın ve yedeği siteyle aynı sunucuda tutmayın.
• Web Application Firewall: Cloudflare, Sucuri veya Wordfence ile uygulama katmanı koruması.
• Log izleme: Başarısız giriş denemeleri, 404 patlamaları ve xmlrpc.php trafiği için uyarı kurun.
• En az yetki prensibi: Her kullanıcıya yalnızca işini yapması için gereken rol verin; günlük çalışma için Administrator hesabı kullanmayın.

Olası Bir İhlal Sonrası Yapılacaklar

Her şeye rağmen siteniz ele geçirilirse, panik yapmadan şu adımları izleyin:

1. Siteyi geçici olarak bakım moduna alın veya sunucudan izole edin.
2. Tüm kullanıcıların parolalarını ve cPanel/FTP/SSH erişim bilgilerini sıfırlayın.
3. wp-config.php içindeki SALT anahtarlarını yenileyin; bu, mevcut tüm oturumları geçersiz kılar.
4. Wordfence, Sucuri veya MalCare ile tam tarama yapın; dosya bütünlüğünü çekirdek kaynağıyla karşılaştırın.
5. Şüpheli kullanıcıları, planlanmış görevleri (wp_cron) ve zamanlanmış SQL kayıtlarını inceleyin.
6. Temiz bir yedeğe dönmek en hızlı çözümdür; ancak yedeğin de zararlı kod içerebileceğini unutmayın.
7. Olayın kök nedenini bulmadan siteyi tekrar yayına almayın; aksi takdirde aynı yoldan tekrar girilir.

Sonuç

WordPress güvenliğinin sırrı, sihirli bir eklenti veya pahalı bir hizmet değil; disiplinli bakımdır. Bu rehberde ele aldığımız on açığın neredeyse tamamı, düzenli güncelleme, güçlü parolalar, iki adımlı doğrulama, doğru dosya izinleri ve önünüze koyacağınız bir WAF ile büyük ölçüde kapatılabilir. Sitenizi yılda bir kez değil, ayda bir kez gözden geçirin; eklenti envanterinizi sade tutun; yedeklerinizi test edin. Bu küçük rutin, sizi olası bir hack vakasının maliyetli kurtarma sürecinden koruyacaktır.

Sitenizin güvenliğine adım atmak için bugünden başlayabileceğiniz en somut üç şey: tüm yazılımı güncelleyin, iki adımlı doğrulamayı açın ve tam bir yedek alarak güvenli bir konuma yedekleyin. Gerisi zaman içinde inşa edilir.