CVE-2026-41940: cPanel & WHM Authentication Bypass İçin Acil Aksiyon Planı

cPanel, 28 Nisan 2026'da yayımladığı ve 1 Mayıs 2026'da güncellediği güvenlik duyurusunda CVE-2026-41940 için acil aksiyon gerektiğini belirtti. Sorun, cPanel yazılımında DNSOnly dahil olmak üzere 11.40 sonrası sürümleri etkileyen bir authentication bypass zafiyeti olarak tanımlanıyor.

Bu yazı, hosting sağlayıcıları, ajanslar, sistem yöneticileri ve müşterileri adına cPanel/WHM yöneten ekipler için operasyonel aksiyon planı sunar.

Neden acil?

Authentication bypass sınıfındaki zafiyetler, kimlik doğrulama akışının güven sınırını doğrudan etkiler. cPanel/WHM gibi yönetim panellerinde bu risk yalnızca tek bir kullanıcı hesabıyla sınırlı kalmaz:

• WHM yönetim oturumu ele geçirilebilir.
• Hosting hesapları, domain ayarları ve e-posta yapılandırmaları etkilenebilir.
• Webroot, cron, SSH key, database credential ve backup akışları risk altına girebilir.
• Ajans veya reseller yapılarında çok müşterili etki doğabilir.

cPanel advisory'si, güncelleme yapılandırması kapatılmış veya belirli sürüme pinlenmiş sunucuların manuel olarak ele alınması gerektiğini özellikle belirtiyor. Bu nokta kritik: "auto-update açık sanıyorduk" varsayımı bu olayda yeterli değil.

Etkilenen ve düzeltilen sürümler

cPanel'in duyurusunda patch yayımlanan cPanel & WHM sürümleri şu şekilde listeleniyor:

• 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

WP Squared için düzeltilen sürüm:

• 136.1.7

CentOS 6 veya CloudLinux 6 üzerinde v110.0.50 kullanan eski ortamlar için cPanel ayrıca v110.0.103 yolunu duyuruyor. Bu tür legacy sistemlerde yalnızca patch değil, orta vadede desteklenen platforma geçiş planı da açılmalıdır.

Birinci aksiyon: sürümü yükseltin

Sunucu üzerinde cPanel güncellemesini zorlayın:

/scripts/upcp --force

Güncelleme sonrası sürümü doğrulayın ve cpsrvd servisini hard restart ile yeniden başlatın:

/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard

CentOS 7 veya CloudLinux 7 kullanan ve uygun tier'a geçmesi gereken sistemlerde:

whmapi1 set_tier tier=11.110

CentOS 6 / CloudLinux 6 ve v110.0.50 gibi eski özel durumlarda cPanel duyurusundaki ilgili tier komutu ayrıca değerlendirilmelidir.

Auto-update kapalı mı?

Bu olayda en sık kaçacak nokta, update preference tarafıdır. Aşağıdaki durumlar elle kontrol edilmelidir:

• cPanel update tamamen kapatılmış mı?
• Sunucu belirli bir release tier'a pinlenmiş mi?
• Eski OS nedeniyle güncel sürüme geçemiyor mu?
• WHM panelinden yapılan ayar komut satırındaki gerçek durumu yansıtıyor mu?
• Fleet içindeki tüm sunucular aynı update politikasında mı?

Çok sunuculu hosting ortamında tek tek SSH ile bakmak yerine merkezi inventory çıkarılmalıdır.

Güncelleyemiyorsanız geçici önlem

Patch hemen uygulanamıyorsa cPanel advisory'si yönetim portlarının firewall seviyesinde kapatılmasını veya ilgili servislerin durdurulmasını öneriyor.

Geçici firewall yaklaşımı:

• 2083
• 2087
• 2095
• 2096

Bu portları internete kapatmak müşteri operasyonunu etkileyebilir; fakat authentication bypass riskinde yönetim yüzeyini açık bırakmak daha ağır sonuç doğurabilir.

Servis durdurma yaklaşımı için advisory'de cpsrvd ve cpdavd servislerinin disable/stop edilmesine yönelik komut veriliyor. Bu adım operasyon etkisi yaratacağı için bakım penceresi ve müşteri iletişimiyle uygulanmalıdır.

Session IOC kontrolü

cPanel duyurusunda session dosyaları üzerinde indicators of compromise aramak için bir detection script yayımlandı. Script'in mantığı, /var/cpanel/sessions altındaki session dosyalarında exploitation izine benzeyen alan kombinasyonlarını kontrol eder.

Savunma ekibinin pratik kontrol alanları:

• Pre-auth session dosyalarında beklenmeyen authenticated attribute var mı?
• token_denied ve cp_security_token birlikte görünüyor mu?
• tfa_verified değeri geçerli login origin'i olmadan set edilmiş mi?
• Password alanında newline veya session formatını bozan işaretler var mı?
• WHM access log içinde şüpheli başarılı istek var mı?

Script'i çalıştırmadan önce root yetkisi, log saklama süresi ve incident response süreci hazır olmalıdır. IOC pozitif çıkarsa sadece patch yeterli değildir.

IOC pozitif çıkarsa ne yapılmalı?

Eğer session IOC kontrolü şüpheli veya kritik çıktı verirse aşağıdaki aksiyonlar birlikte planlanmalıdır:

1. Tüm session dosyalarını temizleyin ve kullanıcıları tekrar login olmaya zorlayın.
2. Root ve WHM kullanıcıları için parola reset süreci başlatın.
3. /var/log/wtmp, WHM access log ve cPanel access log kayıtlarını inceleyin.
4. SSH authorized keys, cron, webroot, addon domain ve panel kullanıcılarını kontrol edin.
5. Şüpheli dosya, backdoor, web shell ve yeni açılmış e-posta hesabı arayın.
6. Backup bütünlüğünü ve son restore noktalarını doğrulayın.
7. Root compromise kesinleşirse temiz sunucuya migration veya OS reinstall planını açın.

Hosting sağlayıcıları için fleet aksiyon listesi

Hosting sağlayıcısı veya ajans olarak çok sayıda cPanel sunucusu yönetiyorsanız tek sunucu runbook'u yetmez.

Önerilen sıra:

• Tüm cPanel/WHM host inventory'sini çıkarın.
• Public management port'ları internete açık olanları işaretleyin.
• Sürüm ve OS bilgilerini toplayın.
• Auto-update kapalı veya tier pinli sistemleri ayrı listeleyin.
• Önce internetten erişilen ve çok müşterili sunucuları güncelleyin.
• Her host için update, restart ve sürüm doğrulama çıktısını kaydedin.
• IOC script sonuçlarını merkezi case kaydına bağlayın.
• Müşteri iletişimi için kısa ve net bir duyuru hazırlayın.

Ajanslar için kısa müşteri mesajı

Müşterilere panik yaratmadan şu çerçevede bilgi verilebilir:

cPanel & WHM tarafında kimlik doğrulama akışını etkileyen CVE-2026-41940 güvenlik güncellemesi yayımlandı. Yönetimini yaptığımız sunucularda cPanel sürüm güncellemesi, servis yeniden başlatma ve session IOC kontrolü uygulanıyor. Yönetim portları gerektiğinde geçici olarak sınırlandırılabilir. İşlem tamamlandığında sürüm doğrulama ve varsa ek aksiyon bilgisi paylaşılacaktır.

Eresus bakış açısı

cPanel/WHM olayları "panel güncellemesi" gibi görünür; fakat etki zinciri genelde webroot, e-posta, DNS, cron, SSH ve müşteri verisi tarafına yayılır. Bu nedenle authentication bypass olayında doğru soru sadece "sürüm güncel mi?" değildir.

Sorulması gerekenler:

• Panel yönetim yüzeyi internete açık mı?
• WHM kullanıcıları ve reseller yetkileri doğru sınırlanmış mı?
• Session IOC kontrolü yapıldı mı?
• Şüpheli oturum varsa müşteri hesapları etkilenmiş olabilir mi?
• Backup ve restore zinciri güvenilir mi?
• Aynı sunucuda birden fazla müşteri tenant'ı var mı?

Eresus Security bu tür durumlarda patch doğrulaması, log review, web shell hunting, credential rotation ve müşteri etkisi sınıflandırmasıyla incident response sürecini destekler.

SSS

Sadece /scripts/upcp --force yeterli mi?

Patch uygulanması ilk zorunlu adımdır; fakat şüpheli session veya log izi varsa tek başına yeterli değildir. IOC kontrolü ve erişim incelemesi ayrıca yapılmalıdır.

Yönetim portlarını kapatmak zorunda mıyız?

Sunucu hemen güncellenemiyorsa cPanel'in önerdiği geçici önlemlerden biri yönetim portlarını firewall ile kapatmaktır. Bu operasyonu etkileyebilir; ancak açık authentication bypass riskinde yönetim yüzeyini açık bırakmak daha tehlikelidir.

Auto-update açık olan sunucular güvende mi?

Varsaymayın. Sürüm çıktısını doğrulayın. Güncelleme tamamlandıktan sonra cpsrvd restart ve /usr/local/cpanel/cpanel -V kontrolü yapılmalıdır.

IOC pozitifse ne yapmalıyız?

Session temizleme, parola reset, log inceleme, persistence kontrolü ve gerekirse temiz sunucuya migration planı birlikte yürütülmelidir. Pozitif IOC, olayı sıradan patch işinden incident response sürecine taşır.

Kontrol listesi

• Tüm cPanel/WHM sunucuları listelendi mi?
• Sürüm çıktısı kaydedildi mi?
• /scripts/upcp --force çalıştırıldı mı?
• cpsrvd hard restart yapıldı mı?
• Güncelleme sonrası sürüm tekrar doğrulandı mı?
• Auto-update kapalı/pinli sistemler bulundu mu?
• Yönetim portları için geçici firewall kararı verildi mi?
• Session IOC kontrolü çalıştırıldı mı?
• Şüpheli log ve persistence kontrolleri yapıldı mı?
• Müşteri iletişimi ve olay kaydı açıldı mı?