Genel

CVE-2026-41940: cPanel Kritik Güvenlik Açığı ve WordPress Site Sahipleri İçin Tam Rehber

4 Mayıs 2026 No comments yet
Kritik cPanel CVE-2026-41940 açığı için WordPress site sahibi rehberi kapak görseli

Kısa Özet

28 Nisan 2026’da cPanel & WHM için CVE-2026-41940 kimliğiyle açıklanan kritik bir kimlik doğrulama atlatma açığı yamandı; ancak güvenlik araştırmacıları açığın yaklaşık iki aydır vahşi doğada (in-the-wild) sömürüldüğünü, dolayısıyla saldırganların yamanmamış sunucularda root düzeyinde WHM erişimi elde edebildiğini doğruladı. Açığın CVSS skoru 9.8 ve dünya genelinde 1,5 milyondan fazla sunucuyu, 70 milyondan fazla domaini etkilediği tahmin ediliyor. WordPress site sahibiyseniz ve sitenizi cPanel/WHM çalıştıran bir hostingde tutuyorsanız, bu rehber sizin için: hostinginizin yamayı aldığını nasıl doğrularsınız, sızıldığınızı nasıl anlarsınız, sızıldıysa hangi sırayla ne yapmalısınız ve bir daha aynı tip olaylara karşı sitenizi nasıl güçlendirirsiniz.

CVE-2026-41940 Nedir? Neden Bu Kadar Büyük Bir Olay?

CVE-2026-41940, cPanel & WHM’in oturum (session) yönetimindeki bir CRLF injection hatasından doğan, kimlik doğrulama gerektirmeyen (pre-auth) bir uzaktan kullanıcı yetki yükseltme açığıdır. Pratik anlamı şudur: saldırgan, kullanıcı adı ve şifre bilmeden, internet üzerinden WHM yönetim arayüzüne root düzeyinde giriş yapabilir. Root, hosting sunucusunun en yüksek yetkili kullanıcısıdır; bir saldırgan bu yetkiyi eline geçirdiğinde sunucudaki tüm cPanel hesaplarına, dosyalara, veritabanlarına, e-posta kutularına ve yedeklere müdahale edebilir.

Açığın CVSS (Common Vulnerability Scoring System) skoru 9.8/10; bu, “kritik” sınıfının en üst kademesidir. Açığın etkilediği versiyon yelpazesi çok geniştir: cPanel’in 11.40 sonrası tüm desteklenen sürümleri savunmasızdı. Resmi yama, cPanel’i geliştiren WebPros tarafından 28 Nisan 2026 tarihinde yayınlandı. Yama öncesi en az iki ay boyunca açık aktif olarak sömürüldü; yani bu açık tipik bir sıfır gün (zero-day) idi ve siber güvenlik camiası olayı “yılın hosting felaketi” olarak değerlendirdi. CISA, açığı bilinen istismar edilen güvenlik açıkları (KEV) kataloğuna ekleyerek federal kurumlara öncelikli yama uygulanması talimatı verdi.

Açığın Mekaniği — Yüzeysel Bakış

Bu rehber site sahibinin perspektifinden yazıldığı için açığın istismar detaylarını paylaşmıyoruz; ancak temel mekanizmayı anlamak savunma adımlarını tasarlamak için faydalıdır. Saldırgan, WHM’e gönderdiği özel olarak hazırlanmış bir HTTP isteğiyle, oturum dosyasına yazılan değerleri manipüle eder. Sunucu, oturum dosyasındaki “kullanıcı kimdir?” alanını ham metin olarak yeniden okurken saldırganın eklediği user=root tarzı bir satıra inanarak ona root oturumu tanır. Tüm bunlar saniyeler içinde, hiçbir şifre veya iki faktörlü kod istenmeden gerçekleşir. Sömürü tipi olarak adlandırılan teknik CRLF injection‘dur; CRLF, satır başı (\r) ve satır sonu (\n) karakterlerinin kısaltmasıdır.

Hangi Sürümler Etkilendi?

cPanel’in 28 Nisan 2026 güvenlik bültenine göre yamalı sürümler şunlardır: 11.136.0.5, 11.134.0.20, 11.132.0.29, 11.130.0.19, 11.126.0.54, 11.118.0.63, 11.110.0.97 ve 11.86.0.41. Ek olarak WP Squared sürümlerinde 136.1.7 yamalı sürümdür. Sunucunuzun kullandığı sürüm bu listenin altındaysa (yani küçük versiyonu daha düşükse) sunucu hâlâ savunmasızdır. Sürümünüzü /usr/local/cpanel/cpanel -V komutuyla görebilirsiniz; ancak çoğu paylaşımlı hosting müşterisi bu komutu çalıştıramayacağından, hostinginizden yazılı bir teyit almak en kestirme yoldur.

Bir WordPress Site Sahibi Olarak Beni Nasıl Etkiler?

Açık doğrudan WordPress’i hedef almıyor; cPanel/WHM yönetim katmanını hedefliyor. Ancak WordPress siteniz cPanel kullanan bir sunucuda çalışıyorsa, sunucu seviyesinde bir kompromittasyon WordPress’inizin de tehlikeye girmesi anlamına gelir. Tipik etkiler şunlardır:

Tüm Dosyalarınız Okunabilir/Değiştirilebilir Olur

Saldırgan root düzeyinde sunucuya geçtiğinde, sitenizin wp-config.php dosyasını okuyup veritabanı kullanıcı adı, şifresi, AUTH_KEY sabitleri ve diğer hassas bilgileri ele geçirebilir. wp-config.php içinde okunabilir hâlde duran tek bir veritabanı şifresi, saldırgan için sitenize sınırsız erişim demektir.

Veritabanınız İndirilir veya Silinir

WordPress veritabanında üyelik bilgileri, sipariş geçmişi, müşteri e-postaları, hashed parolalar ve özel veriler bulunur. WooCommerce çalıştırıyorsanız risk daha da büyüktür: müşteri kart bilgileri saklanmasa bile sipariş geçmişi, fatura adresleri ve iletişim bilgileri sızdırılabilir.

Kalıcı Arka Kapılar (Backdoor) Yerleştirilir

Saldırgan kompromittasyon sonrası genellikle bir “geri dönmek için kapı” bırakır: temaya gizli bir admin kullanıcısı oluşturmak, functions.php içine zararlı PHP eklemek, eklenti dizinine sahte bir eklenti koymak, veya cron job ekleyip her saat başı yeni bir backdoor yaratan bir script yerleştirmek. cPanel seviyesinde de SSH anahtarı, WHM hook’u veya gizli bir cron job bırakabilir.

Spam, Kimlik Avı ve SEO Sahtekarlığı

Sunucularda en sık karşılaşılan ikincil etki; sitenin spam e-posta gönderme makinesine ya da kimlik avı (phishing) sayfalarına ev sahibi yapılmasıdır. Google Search Console aniden “kötü amaçlı içerik” uyarısı vermeye, hosting sağlayıcısı IP’nizi e-posta bloklisteme almaya başlar. Trafiğiniz ve itibarınız hızla erir.

Hosting Hesabınız Askıya Alınır

Hosting sağlayıcıları kompromittasyon tespit ettiğinde genellikle önce sitenizi askıya alır, sonra sizi bilgilendirir. Bu süreçte hem sitenize erişim kaybedersiniz hem de itibar zedelenir. Olayın yönetimi sizin hızınıza bağlıdır.

Hostingim Yamayı Aldı mı? Nasıl Kontrol Ederim?

İlk yapılması gereken şey, sunucunun yamalı bir sürüme geçtiğinden emin olmaktır. Site sahibi olarak elinizde aşağıdaki üç yol vardır.

Yöntem 1: Hosting Sağlayıcısına Doğrudan Sormak (Önerilen)

Hosting destek paneline aşağıdaki gibi açık ve net bir talep iletin:

Merhaba, 28 Nisan 2026’da yayınlanan CVE-2026-41940 cPanel/WHM kimlik doğrulama atlatma açığı hakkında bilgi almak istiyorum. Sitemin barındırıldığı sunucuda hangi cPanel sürümü çalışıyor ve bu sürüm yamalı sürümler arasında mı (11.86.0.41, 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20, 11.136.0.5)? Yama uygulandı mı, uygulandıysa hangi tarihte? Ayrıca sunucu üzerinde IOC (kompromittasyon belirtisi) taraması çalıştırıldı mı, sonucu nedir?

Bu mesaj, hosting sağlayıcısının size somut, denetlenebilir bir cevap vermesini sağlar. Cevap “patch’lendi, sorun yok” gibi muğlak bir ifade ise, sürüm numarasını ve tarama sonucunu yazılı olarak isteyin. Ciddi bir hosting sağlayıcısı bu bilgileri paylaşmaktan çekinmez.

Yöntem 2: cPanel Arayüzünden Sürüm Bilgisini Görmek

cPanel’e giriş yapın. Sağ üstteki kullanıcı menüsünün altında veya soldaki “Server Information” başlığı altında genellikle çalışan cPanel sürüm numarası gösterilir. Bu numara yukarıdaki yamalı sürüm listesinin altındaysa, hosting yamayı henüz almamış demektir. Hostinginizle hemen iletişime geçin.

Yöntem 3: SSH Erişiminiz Varsa Komutla Doğrulamak

VPS, dedicated veya yönetilen WordPress hostingde SSH erişiminiz varsa şu komutla sürümü görebilirsiniz:

/usr/local/cpanel/cpanel -V

Çıktı örneğin 11.136.0.5 (build 1) ise sunucu yamalanmıştır. Daha düşük bir alt sürüm görüyorsanız hosting tarafının güncellemesini istemeniz gerekir. Yöneticisi olduğunuz bir VPS’de güncellemeyi tetiklemek için cPanel’in resmi script’i kullanılır:

/scripts/upcp --force

Komut tamamlandığında sürümü tekrar doğrulayın ve cpsrvd servisini yeniden başlatın:

/scripts/restartsrv_cpsrvd

Sızılmış Olabilir miyim? Uyarı İşaretleri ve Kontrol Listesi

Hosting sağlayıcınız sunucuyu yamadığını teyit etse bile, yama öncesi iki aylık pencere boyunca sızılmış olabilir. Bu yüzden bir kompromittasyon kontrol etmek de gereklidir. Site sahibi olarak göz atmanız gereken sinyaller şunlardır:

1. WordPress Tarafı

WordPress yönetici paneline girip aşağıdaki noktaları kontrol edin:

  • Yeni admin kullanıcılar: Kullanıcılar → Tüm Kullanıcılar → Yönetici filtresinde tanımadığınız bir hesap var mı? Özellikle e-posta alanı şüpheli, kullanıcı adı rastgele harflerden oluşuyorsa.
  • Şüpheli eklentiler: Aktif eklentiler arasında sizin yüklemediğiniz, açıklaması boş veya isimsiz olanlar var mı?
  • Tema dosyalarında değişiklik: functions.php, header.php, footer.php dosyalarında base64_decode, eval(, gzinflate(, str_rot13 gibi fonksiyonlar veya tek satıra sıkıştırılmış uzun karakter dizileri.
  • Yeni cron işleri: WP-Crontrol eklentisi veya hosting cron paneli üzerinden listeleyin; tanımadığınız işler ekli mi?

2. Sunucu Tarafı (cPanel paneli üzerinden)

  • Son giriş kayıtları: cPanel ana sayfasında “Last Login” / “Son Giriş” alanına bakın. Sizin oturumunuzdan başka, tanımadığınız bir IP varsa kayda alın.
  • Yeni cPanel hesapları: Reseller veya VPS yönetimindeyseniz WHM’deki hesap listesi son 60 gün içinde size ait olmayan bir hesap içeriyor mu?
  • SSH anahtarları: cPanel “SSH Access” bölümünde tanımadığınız bir public key eklenmiş olabilir. Tüm anahtarları gözden geçirin.
  • FTP hesapları: “FTP Accounts” bölümünde sizin oluşturmadığınız bir hesap var mı?
  • Cron işleri: “Cron Jobs” altında günde bir kez çalışıp wget, curl, base64, php -r gibi komutları içeren satırlar tehlike sinyalidir.
  • E-posta kuyruğu: “Email Disk Usage” veya “Mail Queue” şişmişse, sunucunuz spam göndermek için kullanılıyor olabilir.

3. Dış Sinyaller

  • Google Search Console: Güvenlik Sorunları (Security Issues) sekmesi temiz mi? Manuel cezalar, “kötü amaçlı yazılım” veya “zararlı yönlendirme” uyarısı varsa müdahale gerekir.
  • Sucuri SiteCheck / VirusTotal URL tarama: Domain’inizi sitecheck.sucuri.net veya virustotal.com üzerinden ücretsiz tarayın.
  • E-posta blok listesi: mxtoolbox.com/blacklists.aspx üzerinden domain ve IP’nizi sorgulayın.
  • Hosting kullanım grafikleri: Bant genişliği veya CPU tüketiminde ani sıçrama; spam veya kripto madenciliği için kullanılma sinyalidir.

4. Sunucu Yöneticisinden İsteyebileceğiniz IOC Taraması

cPanel resmi olarak ioc_checksessions_files.sh isimli bir kompromittasyon taraması script’i yayınladı. Bu script /var/cpanel/sessions/raw/ dizini altındaki oturum dosyalarını CRLF injection izleri için tarar; CRITICAL veya WARNING sonucu çıkması, açığın bu sunucuda istismar edildiği anlamına gelir. Hosting sağlayıcınızdan bu script’i sunucuda çalıştırmasını ve sonucu sizinle paylaşmasını talep edebilirsiniz; standart bir destek talebidir ve ciddi sağlayıcılar bu taramayı zaten kendi inisiyatifleriyle yapmış olur.

Sızıldıysa Ne Yapmalı? Acil Eylem Sıralaması

Eğer yukarıdaki kontrollerden bir veya birkaçı kırmızı işaret veriyorsa, paniklemeden ama hızla harekete geçmek gerekir. Aşağıdaki sıra önemlidir.

1. Siteyi Geçici Olarak Kapatın

Sitenizi temizlemeden online tutmak hem ziyaretçilere zarar verir hem de hosting sağlayıcınızın askıya almasına sebep olur. Geçici bir bakım sayfasıyla siteyi devre dışı bırakın. .htaccess üzerinde tüm trafiği bir bakım sayfasına yönlendirebilirsiniz:

# .htaccess
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123\.45\.67\.89$   # Kendi IP'niz buraya
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REQUEST_URI} !\.(jpg|png|gif|css)$ [NC]
RewriteRule .* /maintenance.html [R=503,L]

Bu blok ziyaretçileri 503 durum koduyla bakım sayfasına yönlendirirken size kendi IP’nizden tam erişim bırakır.

2. Tam Yedek Alın (Ama Mevcut Yedeğinizi Bozmayın)

Olay anındaki dosya ve veritabanı durumunu, ileride forensic analiz için bir kenara kopyalayın. Bu yedeği geri yükleme amaçlı kullanmayacaksınız; sadece kanıt amaçlı saklayacaksınız. Yeni bir klasörde, sıkıştırılmış bir incident-2026-05-02.tar.gz arşivi olarak saklayın. WP-CLI ile veritabanı dökümü için:

wp db export incident-2026-05-02.sql
tar -czf incident-2026-05-02.tar.gz wp-content/ wp-config.php incident-2026-05-02.sql

3. Tüm Şifreleri Değiştirin

Sızılmış olduğu varsayımıyla aşağıdaki şifrelerin hepsini güncelleyin:

  • cPanel ana hesap şifresi
  • FTP/SFTP hesap şifreleri
  • Veritabanı kullanıcı şifreleri (sonra wp-config.php‘yi de güncelleyin)
  • WordPress yönetici hesabı şifreleri
  • WordPress salt değerleri (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY ve _SALT karşılıkları)
  • E-posta hesap şifreleri

Yeni WordPress salt değerleri için https://api.wordpress.org/secret-key/1.1/salt/ adresinden taze bir set alıp wp-config.php içinde değiştirebilirsiniz. Bu işlem mevcut tüm oturumları geçersiz kılar; saldırganın açık bir oturumu varsa kapanır.

4. Şüpheli Kullanıcıları Silin

WordPress’te tanımadığınız admin hesaplarını silin. cPanel ve WHM seviyesinde de yetkisiz oluşturulmuş hesapları kaldırın. SSH yetkili anahtarlar dosyasını (~/.ssh/authorized_keys) gözden geçirip yabancı her satırı silin.

5. Yeni Cron İşlerini ve Backdoor’ları Temizleyin

cPanel “Cron Jobs” listesini sıfırdan denetleyin; wget, curl, php -r, base64 -d içeren her satırı şüpheli kabul edin. WordPress içinde de functions.php ve eklenti dizinlerinde aynı şüpheli desenleri arayın.

6. Çekirdek, Tema ve Eklentileri Yeniden Yükleyin

Saldırgan WordPress çekirdek dosyalarına bile bir .php backdoor sızdırmış olabilir. Çekirdeği WordPress.org’dan indirip wp-content hariç üzerine yazmak en güvenli adımdır. WP-CLI ile:

wp core download --force --skip-content
wp plugin install --force $(wp plugin list --field=name --status=active)
wp theme install --force $(wp theme list --field=name --status=active)

Bu üç komut çekirdeği, aktif eklentileri ve aktif temaları en güncel sürümleriyle dosya bazlı olarak değiştirir. wp-content/uploads dizinini ayrıca tarayıp PHP dosyalarını silin (uploads içinde PHP dosyası olmaması gerekir).

7. Veritabanını Tarayın

Backdoor’lar bazen veritabanına da yerleşir; özellikle wp_options tablosundaki active_plugins ve siteurl alanlarına. Şu basit SQL ile gözden geçirin:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home', 'active_plugins', 'template', 'stylesheet')
   OR option_value LIKE '%base64%'
   OR option_value LIKE '%eval(%';

Sonuçlarda yabancı bir URL veya base64 string görüyorsanız temizlemek gerekir.

8. Güvenlik Eklentisi ile Tam Tarama

Wordfence (ücretsiz sürüm), Sucuri Security veya iThemes Security gibi güvenlik eklentilerini kurup tam dosya taraması başlatın. Bu eklentiler bilinen backdoor imzalarını ve değiştirilmiş çekirdek dosyalarını saatler içinde tespit eder. Wordfence’in “scan options” ekranında “Scan files outside WordPress installation” seçeneğini de aktif edin.

9. .htaccess ve wp-config.php Dosyalarını Sıfırdan Yazın

İki kritik dosya da saldırganın hedef tahtasındadır. .htaccess içinde tanımadığınız RewriteRule, Redirect, SetEnv satırları varsa bütünüyle silip WordPress varsayılan içeriğiyle değiştirin. wp-config.php‘yi de örnek dosyadan yeniden oluşturup yalnızca veritabanı bilgileri ve salt değerlerini doldurun.

Site Sahibi İçin Uzun Vadeli Güçlendirme

Bir sızma olayını atlatmak yetmez; aynı seviyede başka bir olayı bir daha yaşamamak için bazı disiplinler kurmak gerekir.

1. WHM/cPanel İki Faktörlü Doğrulama

cPanel paneline iki faktörlü doğrulama (2FA) eklemek temel hijyendir. cPanel arayüzünde “Security” → “Two-Factor Authentication” yolundan QR kod ile Google Authenticator veya Authy bağlayabilirsiniz. Bu açıkta 2FA bypass edildi; yine de saldırganlar genellikle 2FA aktif hesapları öncelikli hedef yapmaz.

2. WordPress Tarafında 2FA

WordPress yönetici hesaplarınız için “Wordfence Login Security”, “Two Factor”, “miniOrange 2FA” gibi eklentilerden birini kurun. 2FA’yı tüm admin/editor seviye kullanıcılar için zorunlu hâle getirin.

3. wp-config.php Sertleştirmesi

Aşağıdaki sabitleri wp-config.php içine ekleyin:

// Dosya editörünü kapat
define( 'DISALLOW_FILE_EDIT', true );

// Yönetici panelinden eklenti/tema kurulumunu kapat (gelişmiş kullanıcılar için)
define( 'DISALLOW_FILE_MODS', true );

// Otomatik minor güncelleme
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Direkt dosya erişimi
define( 'FS_METHOD', 'direct' );

// Debug üretimde kapalı
define( 'WP_DEBUG', false );

DISALLOW_FILE_EDIT sayesinde kompromittasyon olsa bile saldırgan yönetici panelinden tema/eklenti dosyası düzenleyemez; backdoor enjekte etmek için sunucu seviyesinde yetki gerekir.

4. Doğru Dosya İzinleri

Standart WordPress kurulumları için izin değerleri şöyle olmalıdır: dizinler 755, dosyalar 644, wp-config.php ise 440 veya 400. Toplu uygulamak için:

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

5. Düzenli ve Çoklu Yedek Stratejisi

Bir kopya hosting içinde, bir kopya harici (Google Drive/Dropbox/S3/Backblaze B2) olacak şekilde 3-2-1 stratejisi uygulayın. UpdraftPlus, BackWPup veya BlogVault gibi eklentiler bunu otomatize eder. Yedek almak yetmez; ayda bir kez yedeği staging ortamına geri yükleyerek bütünlüğünü test edin. Kapsamlı bir yedekleme rehberi için WordPress yedekleme rehberi içeriğimize göz atabilirsiniz.

6. Wordfence / Sucuri / iThemes Security Aktif

Bu üç eklentiden birini siteye kurun ve şu özellikleri etkinleştirin: gerçek zamanlı dosya değişikliği taraması, brute-force koruması, login captcha, ülke bazlı filtreleme (gerekirse), 2FA. Bu eklentiler kompromittasyonu engellemese bile sızmadan dakikalar içinde haberdar etmenizi sağlar.

7. Güçlü Şifre + Şifre Yöneticisi

cPanel, WP admin, FTP ve veritabanı şifrelerinin hepsini en az 16 karakterli, büyük-küçük harf, sayı ve sembol içeren rastgele dizilerden seçin. Bitwarden, 1Password veya KeePassXC gibi bir şifre yöneticisi şart. Tek bir şifrenin sızması, diğer hesapları doğrudan tehlikeye atmamalıdır.

8. Hosting Seçimi ve Güncellik

Aynı IP üzerinde 500+ siteyi tutan ucuz paylaşımlı paketlerde, bir cPanel açığı tüm sunucuyu etkiler. Yönetilen WordPress hosting’leri (SiteGround, Kinsta, WP Engine, Hostinger Premium, Cloudways) kritik açıkları otomatik ve hızlı yamalama konusunda paylaşımlı plan sağlayıcılarından genellikle daha disiplinlidir. Hosting seçimi konusunda detaylı yönlendirme için WordPress için en uygun hosting seçimi nasıl yapılır içeriğimizi okuyabilirsiniz.

9. WAF ve CDN Katmanı

Cloudflare, Sucuri Firewall, BunkerWeb veya BulletProof Security gibi bir Web Application Firewall (WAF) kullanmak, bilinen istismar imzalarını sunucuya ulaşmadan engeller. Cloudflare’in ücretsiz planı bile temel bir koruma sağlar; “Managed Rules” → “WordPress” rule set’ini etkinleştirmek pratik bir başlangıçtır.

10. Düzenli Güvenlik Gözden Geçirme Rutini

Ayda bir kez 30 dakikalık bir gözden geçirme yapın: yöneticiler listesi, eklentiler, cron işleri, son giriş kayıtları, hosting kaynak grafikleri, Search Console güvenlik sorunları. Bir Excel veya Notion sayfasında işaretleyerek ilerlemek bu disiplini kalıcı kılar.

WordPress’e Özel Hızlı Aksiyon Listesi

  1. Hostinginizden CVE-2026-41940 yamasının uygulandığını yazılı olarak isteyin.
  2. cPanel ve WordPress admin şifrelerinizi değiştirin, 2FA’yı açın.
  3. wp-config.php içindeki tüm salt değerlerini taze bir set ile değiştirin.
  4. Aktif olmayan eski eklentileri ve temaları silin (sadece “deactivate” değil, “delete”).
  5. Wordfence ücretsiz sürümünü kurup tam tarama başlatın.
  6. UpdraftPlus veya BackWPup ile harici hedefe (Drive/S3) tam yedek alın.
  7. Cloudflare ücretsiz plan bağlayıp DNS’inizi geçirin; “Under Attack Mode”u biliyor olun.
  8. Google Search Console “Security Issues” sekmesini kontrol edin; uyarı varsa “Request Review” gönderin.
  9. Hosting destek ile yazışmalarınızı arşivleyin (ileride lazım olabilir).
  10. Aynı sunucuda birden fazla siteniz varsa, hepsini aynı sıkı taramadan geçirin; saldırgan bir kullanıcının dizininden diğerine atlayabilir.

Hosting Sağlayıcınızla Konuşma Şablonu

Çoğu site sahibi, hosting destek ekibiyle güvenlik konusunu konuşurken yetersiz cevap aldığını düşünür. Aşağıdaki şablon ciddi bir cevap almanızı kolaylaştırır:

Konu: CVE-2026-41940 hakkında bilgi talebi
Merhaba,
Sitemin barındırıldığı sunucuda CVE-2026-41940 (cPanel/WHM kimlik doğrulama atlatma) açığının yamalı olduğunu doğrulamanızı rica ediyorum. Aşağıdaki üç soruya somut cevap istiyorum:
1. Şu an çalışan cPanel sürümü nedir? (Yamalı sürümler: 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20, 11.136.0.5)
2. Yama hangi tarihte uygulandı?
3. cPanel’in yayınladığı IOC tarama script’i (ioc_checksessions_files.sh) bu sunucuda çalıştırıldı mı? Sonucu nedir?
Yanıtınızı bekliyorum. Teşekkürler.

Yanıt 24 saat içinde gelmiyorsa veya cevaplar muğlak ise hosting değişimini ciddi şekilde değerlendirmek gerekir. Güvenlik açıklarına hızlı ve şeffaf cevap, sağlıklı bir hosting sağlayıcısının en temel göstergelerinden biridir.

Sıkça Sorulan Sorular

cPanel kullanmıyorum, Plesk veya DirectAdmin kullanıyorum. Etkileniyor muyum?

CVE-2026-41940 yalnızca cPanel & WHM ürününü etkiler. Plesk, DirectAdmin, ISPConfig, CyberPanel gibi başka kontrol panellerinin kendi güvenlik açıkları olabilir; ancak bu CVE doğrudan onları kapsamaz. Yine de hosting sağlayıcınızın hangi panel ve sürümü kullandığını ve son güvenlik yamalarının uygulanıp uygulanmadığını sormak iyi bir alışkanlıktır.

Şifremi sıkça değiştirmek bu açığı engeller mi?

Hayır; CVE-2026-41940’ın doğası, saldırganın hiç şifre bilmemesidir. Şifreniz dünyanın en karmaşık şifresi olsa bile yamasız sunucuda korunmuyordunuz. Ancak yama sonrası şifreyi değiştirmek, eğer açık döneminde sızılmışsa saldırganın elindeki bilgileri geçersiz kılar.

Cloudflare arkasındaki sitem koruma altında mıydı?

Cloudflare WAF, eğer “Managed Rules” → cPanel/WHM kuralları aktif idiyse istismar denemelerini engelleyebildi. Ancak çoğu kullanıcı bu kural setlerini aktif etmediğinden sömürü trafiği doğrudan sunucuya ulaşıyordu. Cloudflare’in arkasında olmak da hostinginizin yamalanmamış olması gerçeğini değiştirmez.

Sızıldığımı nasıl kesin olarak kanıtlarım?

Kesin kanıt için iki kaynağa bakılır: (1) cPanel oturum dosyaları üzerinde resmi IOC script’inin sonucu, (2) Apache/Nginx erişim logları. Loglarda 28 Şubat – 28 Nisan 2026 arasında WHM’e (port 2087/2086) yapılan, bilinmeyen IP’lerden gelen, başarılı 200 yanıt alan istekler şüpheli olabilir. Hosting sağlayıcınızdan bu logları talep edebilirsiniz.

WP-CLI bilmiyorum, bu komutları nasıl çalıştırırım?

WP-CLI olmadan da çoğu adımı yönetici panelinden yapabilirsiniz: kullanıcı silme, eklenti yeniden yükleme, salt değerlerini güncelleme (FTP ile wp-config.php düzenleyerek). WP-CLI yalnızca işlemleri hızlandırır; sahip olmamak engel değildir. Hosting sağlayıcınız SSH erişimi sunmuyorsa cPanel “Terminal” özelliğini kontrol edin; çoğu modern hosting bu özelliği panelden veriyor.

Sızılmamış görünüyorum; yine de şifre değiştirmeli miyim?

Evet. Açığın iki ay aktif sömürüldüğü ve tespit edilemeyen sızmaların büyük olasılıkla mevcut olduğu düşünülürse, “ihtiyat tedbiri” olarak şifre rotasyonu makul bir karardır. Bu, gelecekteki olası bir kullanım durumunu engeller; “şu an temiz görünüyorum” çıktısı sonsuza kadar geçerli değildir.

WooCommerce mağazam var, müşterilere bilgi vermeli miyim?

Sızma kanıtınız varsa evet — KVKK ve GDPR yükümlülükleri açısından gereklidir. Sızma kanıtı yoksa zorunluluk değildir; ancak bir blog yazısı veya sosyal medya açıklamasıyla müşterilerinize “sektörde olan bu açığı sunucumuzda doğruladık ve önlemler aldık” demek güven artırır.

Hosting sağlayıcım yamalandığını söylüyor ama doğrulamak istiyorum.

Sağlayıcının size verdiği sürüm numarasını yamalı sürüm listesiyle (yukarıda) karşılaştırın. cPanel’e giriş yapıp sağ üstteki sürüm bilgisini de kontrol edebilirsiniz. SSH erişiminiz varsa /usr/local/cpanel/cpanel -V en kesin yöntemdir.

Kaynak Önerileri ve İlgili Rehberler

Aynı konunun başka cephelerine ve genel WordPress güvenliği disiplinine ilişkin WordPress sitem hacklendi: temizlemek için acil 7 adım, WordPress yedekleme rehberi, WordPress için en uygun hosting seçimi ve WordPress bellek limiti artırma rehberi içeriklerimize göz atabilirsiniz. Resmi kaynaklar olarak NVD CVE-2026-41940 detay sayfası, cPanel resmi blog ve CISA Known Exploited Vulnerabilities kataloğunu takip etmek hayatî güncellemeleri kaçırmamanızı sağlar.

Kapanış

CVE-2026-41940 olayı, güvenliğin tek birkatmanda değil, hosting tedarikçisinden site sahibinin günlük disiplinine kadar uzanan bir zincirde inşa edildiğini bir kez daha gösterdi. Bir WordPress site sahibi olarak elinizdeki en güçlü silahlar; hostinginizden hesap sorabilmek, her şeyin yedeğini tutmak, şifre yönetimini ciddiye almak, 2FA kullanmak ve kompromittasyon belirtilerini erken yakalayabilmektir. Yamasını uygulamayan veya size sürüm bilgisini paylaşmayan bir hosting sağlayıcısıyla devam etmek artık tartışılır bir karardır. Bu rehberi bir kontrol listesi olarak elinizin altında tutun ve en az ayda bir gözden geçirin; çünkü internetin altyapısında benzer büyüklükte yeni açıkların çıkması bir mesele değil, bir zaman meselesidir.