Geçtiğimiz günlerde (28 Nisan) yayınlanan CVE-2026-41940 duyurusu, cPanel & WHM kullanan herkes için bir kabus oldu. Mevzu basit bir kod hatasından öte; sistemin “şifre yanlış” dediği noktada kapıyı aralık bırakmasıyla alakalı bir mantık hatası. Eğer v11.40 üstü bir sürümdeyseniz ve hala update geçmediyseniz, sunucunuz şu an dış dünyaya oldukça misafirperver davranıyor olabilir. Bu yazıyı yazdığım tarihler de cPanel bazı güncellemeler yayınlamış olsa dahi duyuruları takip etmekte yarar var.

>> https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026

Adım Adım Atak Vektörü

CVE-2026-41940 zafiyetinin sömürülmesi, protokoller arasındaki mantıksal boşlukları ve cpsrvd servisinin geçici oturum dosyalarını (session files) işleme biçimindeki hatayı temel alır. Bir saldırganın bu yetkisiz erişimi nasıl gerçekleştirdiğini adım adım inceleyelim:

1. Adım: Başlangıç Oturumu ve “Race Condition” Hazırlığı

Saldırgan, hedef cPanel veya WHM giriş arayüzüne (Port 2083/2087) standart bir HTTP isteği gönderir. Bu aşamada sistem, kullanıcıyı tanımlamak için /var/cpanel/sessions/ dizini altında geçici bir oturum dosyası oluşturur. Henüz kimlik doğrulanmadığı için bu dosya “pre-auth” statüsündedir.

2. Adım: “badpass” Metodunun Manipülasyonu

Normal bir “Kötü Şifre” denemesinde cPanel, oturum dosyasına method=badpass flag’ini ekler. Ancak zafiyet, saldırganın giriş isteği sırasında özel olarak yapılandırılmış bir veri paketi göndererek, oturum dosyasının içeriğine doğrudan müdahale etmesine (Session Injection) olanak tanır.

Saldırgan, sunucuya gönderdiği POST isteğinde parametre kirliliği (Parameter Pollution) veya özel karakter dizileri kullanarak sunucuyu şu yanılsamaya iter:

• Sunucu oturumu “başarısız” olarak işaretlemeye çalışırken, saldırganın enjekte ettiği auth_status=1 veya benzeri bir “başarılı” flag’i aynı dosya satırına yazılır.

3. Adım: Token Injection (Güvenlik Token’ı Üretimi)

cPanel’in güvenlik mimarisi her oturum için bir cp_security_token gerektirir. Zafiyet noktasında, cpsrvd servisi oturumu “hatalı giriş” olarak işaretlemesine rağmen, mantıksal bir hata nedeniyle oturuma geçerli bir security_token atamaya devam eder. Saldırgan, sunucunun yanıtından bu token değerini capture eder.

4. Adım: Kontrol Mekanizmalarının Atlatılması (Bypass)

Saldırgan, elindeki manipüle edilmiş oturum ID’si ve yeni üretilen security_token ile doğrudan bir yönetim URL’sine (örneğin: https://server:2087/cpsessXXXXXXXXXX/main.html) istek atar.

Buradaki kritik hata şudur: Cpanel::Server modülü, oturum dosyasında badpass ifadesini görse bile, eğer dosya içinde geçerli bir token ve kullanıcı eşleşmesi enjekte edilmişse, “token denied” kontrolünü atlayarak kullanıcıyı içerideki yetkili sayfaya yönlendirir.

5. Adım: Tam Yetki ve Kalıcılık (Post-Exploitation)

Kimlik doğrulama duvarı aşıldıktan sonra saldırgan, sistemde root veya kullanıcı yetkileriyle hareket edebilir. Bu noktadan sonra genellikle şunlar yapılır:

• Yeni bir API Token oluşturulur (kalıcılık için).
• Sistem logları manipüle edilerek giriş izleri gizlenmeye çalışılır.
• Zayıf izinli dosyalara webshell enjekte edilir.

CVE-2026-41940 için ne yapılmalı?

cPanel’in resmi destek sayfasında da belirtildiği üzere, bu zafiyetin tek kalıcı çözümü sistemlerin vakit kaybedilmeden yamalanmasıdır. Eğer sunucunuzda otomatik güncellemeler kapalıysa, aşağıdaki adımları manuel olarak uygulamanız hayati önem taşıyor.

1. Güncel Versiyon Kontrolü

Öncelikle sunucunuzun şu güvenli sürümlerden birine (veya daha üstüne) sahip olduğundan emin olun:

• 11.136.0.5
• 11.134.0.20
• 11.110.0.97 (LTS/ESR kullanıcıları için)

2. Güncelleme Komutları

Sunucunuza SSH üzerinden bağlanarak aşağıdaki komutlarla zorunlu güncellemeyi başlatabilirsiniz:

# cPanel & WHM sistemini en son yamalı sürüme yükseltir
/scripts/upcp --force

# Güncelleme sonrası servislerin yeni binary'leri kullandığından emin olmak için cpsrvd'yi yeniden başlatın
/scripts/restartsrv_cpsrvd --hard

3. Yapılandırma ve İzleme (Post-Update)

Güncelleme sonrasında sistemde herhangi bir anomali olup olmadığını anlamak için şu ek adımları izlemeniz önerilir:

• Session Temizliği: Şüpheli oturumları sonlandırmak için /var/cpanel/sessions dizinindeki eski dosyaları temizlemeyi düşünebilirsiniz.
• cPhulk Kontrolü: cPhulk servisinin aktif olduğunu ve kaba kuvvet saldırılarına karşı doğru yapılandırıldığını teyit edin. Zira bu zafiyet, cPhulk’ın bazı engelleme mantıklarını da bypass edebiliyordu.
• Log Analizi: /usr/local/cpanel/logs/access_log dosyasını, özellikle 28 Nisan öncesine dönük “anormal” başarılı girişler (normalde başarısız olması gereken IP’lerden gelen başarı kayıtları) için tarayın.

Bu tarz kritik bir açıkla karşılaştığımızda panikle hemen upcp komutuna sarılıyoruz ancak şu kuralı unutmamak gerek: Yedek almadığın sistem senin değildir.

CVE-2026-41940 gibi derinlikli açıklar yamalanırken, cPanel bazen paket bağımlılıklarını veya kernel seviyesindeki yapılandırmaları da güncelleyebiliyor. Güncelleme sırasında yaşanacak bir kesinti veya sürüm uyuşmazlığı, sunucuyu tamamen erişilemez hale getirebilir.

Süreci başlatmadan önce şu üçlü koruma kalkanını uygulamanızı öneririm:

1. Snapshot Alın: Eğer bulut tabanlı bir altyapı kullanıyorsanız, güncellemeye başlamadan önce mutlaka bir “Snapshot” alın.
2. Konfigürasyon Yedekleri: /etc/ dizini altındaki kritik yapılandırmalarınızı ve özellikle /var/cpanel/ altındaki lisans/oturum verilerini ayrı bir yere kopyalayın.
3. Dışarıya Yedekleme: Yedeklerinizin sunucuyla aynı diskte kalmadığından emin olun. Saldırganın içeri sızma ihtimaline karşı “Offsite Backup” her zaman hayat kurtarır.

Unutmayın; bir sistemi geri yüklemek, çökmüş bir sistemi tamir etmeye çalışmaktan her zaman daha hızlıdır.