Es gibt Schwachstellen, die Administratoren zum Stirnrunzeln bringen. Und es gibt Schwachstellen, bei denen ganze Hosting-Provider innerhalb weniger Stunden Wartungsfenster ankündigen, Imperva-Regeln ausrollen und CISA in der Nacht eine neue Eintragung in den Known Exploited Vulnerabilities-Katalog vornimmt. CVE-2026-41940 gehört eindeutig in die zweite Kategorie. Mit einem CVSS-Score von 9,8, rund 1,5 Millionen exponierten Instanzen und Hinweisen darauf, dass die Lücke seit Februar 2026 still in einigen Ecken des Internets ausgenutzt wurde, ist sie eine der gravierendsten Hosting-Schwachstellen der letzten Jahre.
Was genau ist passiert?
Am 29. April 2026 vergab MITRE die Kennung CVE-2026-41940 fuer eine kritische Authentifizierungsumgehung in cPanel & WHM. Einen Tag spaeter, am 30. April, listete die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) die Schwachstelle in ihrem KEV-Katalog. Cloudflare schaltete am selben Abend ein Notfall-WAF-Release scharf, watchTowr titelte zynisch: „The Internet Is Falling Down“. Wenige Stunden spaeter folgte das deutsche Bundesamt fuer Sicherheit in der Informationstechnik mit einer Warnmeldung an Hosting-Provider und Provider-Kunden.
Die Geschichte dahinter ist erstaunlich klassisch und gerade deshalb so erschreckend. Die Entwickler von cPanel, dem mit Abstand am haeufigsten eingesetzten Linux-Hosting-Panel der Welt, haben vor langer Zeit eine pragmatische Designentscheidung getroffen: Damit der Login-Prozess auch bei langen TLS-Handshakes und mehrstufiger 2FA verlaesslich funktioniert, wird der Sitzungszustand bereits vor der eigentlichen Authentifizierung in einer Session-Datei abgelegt. cpsrvd, der Daemon hinter den Ports 2083, 2087, 2095 und 2096, parst diese Datei nach erfolgreichem Login erneut und entscheidet anhand der dort hinterlegten Werte, ob die Sitzung als Root, als Reseller oder als gewoehnlicher Mailbox-Nutzer gilt.
Die technische Mechanik der Luecke
Das Problem: Bestimmte Felder, die ein nicht authentifizierter Client an cpsrvd senden kann, landen ungefiltert in dieser Pre-Auth-Sessiondatei. Wer in diese Felder ein Carriage-Return-Line-Feed (CRLF, also \r\n) einbaut, schreibt damit faktisch zusaetzliche Zeilen in die Session-Datei. Beim spaeteren Re-Parse interpretiert cpsrvd jede Zeile als eigenen Schluessel-Wert-Eintrag.
Genau das nutzen Angreifer aus. Ein Proof-of-Concept, der inzwischen in mehreren Threat-Intelligence-Feeds zirkuliert, injiziert exakt drei Zeilen:
user=root
hasroot=1
tfa_verified=1Damit ist die Sitzung unmittelbar nach dem ersten unauthentifizierten HTTP-Request eine vollstaendig privilegierte Root-Session – ohne Passwort, ohne 2FA, ohne API-Token. Rapid7 beschreibt den Effekt in seinem technischen Advisory unmissverstaendlich: „The injected lines become top-level session entries.“ Aus Sicht von cpsrvd ist die Anfrage ununterscheidbar von einem korrekt durchlaufenen Login.
Wer ist betroffen?
Faktisch alle. Die offiziellen Patch-Notes von cPanel sprechen von allen unterstuetzten Versionen ab 11.40 – und damit von Releases, die seit ueber einem Jahrzehnt im Einsatz sind. Auch WP Squared, das WordPress-Hosting-Panel auf cPanel-Basis, ist verwundbar. Rapid7 hat ueber Shodan rund 1,5 Millionen oeffentlich erreichbare cPanel-Instanzen gefunden; die tatsaechliche Zahl liegt deutlich hoeher, da viele Provider die WHM-Ports nur intern oder per VPN exponieren.
Besonders pikant: Nach Aussagen des Managed-Hosters KnownHost und Telemetriedaten mehrerer EDR-Anbieter wurde die Schwachstelle bereits seit dem 23. Februar 2026 in einer kleinen Zahl gezielter Angriffe ausgenutzt – also rund neun Wochen vor dem oeffentlichen Patch. Wer in dieser Zeit ungewoehnliche Reseller-Anlagen, neue API-Tokens, fremde SSH-Schluessel in /root/.ssh/ oder unerklaerliche Mailweiterleitungen entdeckt, sollte einen Forensik-Vorgang einleiten und nicht einfach den Patch einspielen.
Was die Patches mitbringen
cPanel hat parallel fuer alle Branches geschlossene Versionen veroeffentlicht. Zum Stand 1. Mai 2026 sind das im Wesentlichen 11.110.0.97 (LTS), 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20 und 11.136.0.5. WP Squared erhaelt mit 136.1.7 das entsprechende Update. Wer in der Free-Tier oder in einer EOL-Version unterwegs ist, hat keinen offiziellen Patch und muss zwingend ueber Mitigation und Migration nachdenken.
Sofortmassnahmen, wenn der Patch nicht in den naechsten Stunden eingespielt werden kann
Im Notfall empfiehlt cPanel, eingehenden Traffic auf den Ports 2083, 2087, 2095 und 2096 auf der Firewall zu blockieren oder die Dienste cpsrvd und cpdavd komplett zu stoppen. Beides bedeutet, dass Endkunden voruebergehend nicht ueber die WebUI auf ihre Hosting-Accounts zugreifen koennen – fuer einige Stunden ist das aber das deutlich kleinere Uebel als ein potenziell uebernommener Server, von dem aus weitere Angriffe geritten werden koennen.
Wer einen WAF-Anbieter wie Cloudflare oder Imperva vorgeschaltet hat, sollte zusaetzlich pruefen, ob die jeweiligen virtuellen Patches bereits ausgerollt sind. Cloudflare hat am 30. April ein Emergency-Release veroeffentlicht, das CRLF-Sequenzen in den verdaechtigen Headern blockt. Diese Regel ist aber kein Ersatz fuer den Server-Patch, sondern reine Schadensbegrenzung.
Forensik: Worauf jetzt zu achten ist
Eine Schwachstelle, die seit Februar in der Wildbahn ist, hinterlaesst Spuren – wenn man weiss, wo man hinschaut. Wir empfehlen Hosting-Betreibern und Unternehmen mit Inhouse-cPanel die folgende Kurz-Pruefung:
Erstens: Sessions auswerten. Im Verzeichnis /var/cpanel/sessions liegen alle aktiven und abgelaufenen Sessions. Saemtliche Dateien, deren Inhalt sowohl user=root als auch hasroot=1 enthaelt, ohne dass eine plausible Login-Historie das erklaert, sind verdaechtig. Kombiniert mit dem Zeitstempel der Datei laesst sich eingrenzen, wann ein moeglicher Missbrauch stattgefunden hat.
Zweitens: API-Tokens und Reseller pruefen. Im WHM unter Manage API Tokens und Reseller Center alles loeschen, was nach unbekannten Akteuren aussieht. Angreifer legen typischerweise persistente Tokens an, um auch nach einem Patch noch Zugriff zu haben.
Drittens: Crontabs und Cloud-Backups. Insbesondere /var/spool/cron/root und cPanel-eigene Backup-Konfigurationen koennen versteckte Reverse-Shells oder Exfiltrations-Jobs enthalten. Wer Backup-Buckets in S3 oder Wasabi nutzt, sollte CloudTrail- bzw. Audit-Logs auf neue Buckets oder veraenderte Ziele pruefen.
Viertens: SSH-Schluessel. Klassischer Persistenzmechanismus: ein zusaetzlicher Eintrag in ~/.ssh/authorized_keys beim root-Account oder in den Home-Verzeichnissen der wichtigsten WHM-Reseller.
Warum das gerade jetzt kritisch ist
cPanel ist die Hosting-Plattform fuer einen Grossteil der KMU-Webhoster in Europa. Hinter jeder verwundbaren Instanz haengen typischerweise Hunderte bis Tausende Endkundenwebseiten, oft auch Mailserver mit echten Geschaeftsdaten. Ein erfolgreicher Angreifer hat damit nicht nur einen Server, sondern eine ganze Plattform – inklusive Zertifikate, Admin-Zugaenge zu WordPress-Instanzen und FTP-Logins. Die Verkettungseffekte aehneln dem Kaseya-Vorfall von 2021 oder den ConnectWise-Vorfaellen Anfang 2024, nur in deutlich groesserem Massstab.
Zusaetzlich faellt der Vorfall in eine Zeit, in der die NIS2-Pflichten in Deutschland operativ wirksam geworden sind. Wer Hosting fuer kritische oder wichtige Einrichtungen betreibt, ist verpflichtet, signifikante Sicherheitsvorfaelle innerhalb von 24 Stunden an das BSI zu melden. Eine durch CVE-2026-41940 erfolgte Kompromittierung ist mit hoher Wahrscheinlichkeit meldepflichtig – allein wegen des Umfangs der potenziell betroffenen Drittparteien.
Was Unternehmen jetzt konkret tun sollten
Wir empfehlen Verantwortlichen in der IT, fuer die naechsten 72 Stunden die folgende Reihenfolge einzuhalten:
1. Inventur. Welche Systeme im eigenen oder im providerseitigen Netzwerk laufen mit cPanel oder WP Squared? Auch interne Reseller-Server, Backup-Hosts und Test-Maschinen einbeziehen. Provider-Kunden sollten gezielt beim Hoster nachfragen, ob und wann gepatcht wurde.
2. Patchen oder mitigieren. Spielen Sie das jeweilige Update der eigenen Branch ein und starten Sie cpsrvd einmal sauber durch (service cpsrvd restart). Falls das Update nicht in wenigen Stunden moeglich ist, blockieren Sie die genannten Ports auf der Edge-Firewall oder hinter dem WAF.
3. Auf Kompromittierung pruefen. Mindestens die Sessions, API-Tokens, Reseller-Konten und SSH-Schluessel-Strukturen pruefen. Rotieren Sie alle WHM-Passwoerter und Root-Tokens nach dem Patch zwingend, da man bei einer aktiv ausgenutzten Pre-Auth-Luecke nicht von Nichtwissen ausgehen darf.
4. Meldung pruefen. Wer dem NIS2-Regime unterliegt und Hinweise auf eine Kompromittierung hat, muss ueber eine BSI-Meldung entscheiden. Im Zweifel lieber innerhalb der 24-Stunden-Frist eine Erstmeldung absetzen, die spaeter konkretisiert wird.
5. Lessons Learned. Wer einen Pre-Auth-Bypass in einem extern erreichbaren Admin-Panel ein zweites Mal erleidet, hat ein strukturelles Problem. Hosting-Panels gehoeren grundsaetzlich nicht direkt ins Internet, sondern hinter VPN, Bastion-Host oder zumindest IP-Allowlisting. Wir helfen mittelstaendischen Unternehmen regelmaessig dabei, eine entsprechende Defense-in-Depth-Strategie zu etablieren – siehe unsere Leistungen rund um Informationssicherheit.
Fazit
CVE-2026-41940 ist ein Lehrstueck. Eine Klasse von Schwachstelle (CRLF Injection), die seit den fruehen 2000ern bekannt ist. Ein Designmuster (Pre-Auth-Sessiondateien), das schon damals umstritten war. Ein Service, der in seiner Default-Konfiguration direkt aus dem Internet erreichbar ist. Und eine Codebasis, die seit Version 11.40 die gleiche unsichere Annahme mit sich getragen hat.
Fuer Hosting-Provider und alle Unternehmen, die cPanel im eigenen Rechenzentrum betreiben, ist heute kein normaler Tag, sondern ein Patch-Day mit allen Eskalations- und Forensik-Konsequenzen. Wer beim Patchen, beim NIS2-Meldeweg oder bei der Kompromittierungs-Triage Unterstuetzung braucht, kann uns ueber das Kontaktformular erreichen. Wir begleiten kleine und mittelstaendische Hoster und Inhouse-IT-Abteilungen seit Jahren bei genau solchen Notfaellen.
