Kritische Sicherheitslücke beim cPanel: Ist Ihre Website betroffen?

Wussten Sie, dass die cPanel-Sicherheitslücke CVE-2026-41940 bereits seit dem 23. Februar 2026 aktiv ausgenutzt wird, fast zwei Monate bevor cPanel überhaupt einen Patch veröffentlichte? Potenziell 1,5 Millionen Server waren in diesem Zeitraum ungeschützt.

Sie wachen morgens auf, öffnen Ihre Website und sehen eine Erpresserbotschaft. Kein Einzelfall mehr. Tausende Webmaster erlebten genau das in den vergangenen Tagen. Und das Erschreckende: Viele von ihnen hatten ihr WordPress aktuell gehalten, starke Passwörter gesetzt und alle Sicherheitsregeln befolgt.

Das Wichtigste in Kürze

• CVE-2026-41940 ist eine kritische Sicherheitslücke in cPanel & WHM mit CVSS-Score 9,8 von 10, der höchsten praktisch relevanten Einstufung.
• Angreifer nutzten die Lücke seit dem 23. Februar 2026 als Zero-Day, fast zwei Monate vor dem Patch am 28. April 2026.
• Betroffen sind alle cPanel & WHM-Versionen ab 11.40, das entspricht potenziell 1,5 Millionen im Internet exponierten Instanzen.
• Führen Sie keine WordPress-Bereinigung durch, solange Ihr Hoster nicht nachweislich gepatcht hat. Der Server ist das Einfallstor, nicht Ihre Website.

Was steckt hinter dem Massen-Hack vom April 2026?

Die cPanel-Sicherheitslücke trägt den offiziellen Bezeichner CVE-2026-41940 und einen CVSS-Score von 9,8. Das ist kein theoretisches Risiko auf einer Risikoliste, sondern der höchste Wert, den eine Schwachstelle in der Praxis nahezu erreichen kann.

Der Fehler steckt im Anmelde- und Session-Handling-Prozess von cPanel & WHM. Der Daemon cpsrvd schreibt noch vor der eigentlichen Authentifizierung eine Session-Datei auf die Festplatte. Ein Angreifer manipuliert dabei den whostmgrsession-Cookie so, dass die Verschlüsselung umgangen wird. Über einen manipulierten Authorization-Header schleust er rohe Zeilenumbruchzeichen (CRLF) ein. Das System schreibt daraufhin die Session-Datei ohne Prüfung, sodass der Angreifer beliebige Eigenschaften einfügen kann, darunter user=root. Das Ergebnis: Root-Zugriff auf den gesamten Server, ohne ein einziges gültiges Passwort zu kennen.

Das Sicherheitsunternehmen watchTowr veröffentlichte am 29. April 2026 eine vollständige technische Analyse inklusive Proof-of-Concept-Exploit. Ab diesem Zeitpunkt war der Angriff auch für weniger erfahrene Akteure reproduzierbar.

Besonders bitter: Die Ausnutzung begann nicht erst mit dem Patch-Datum. Nach Angaben des Hosting-Anbieters KnownHost wurde die Lücke nachweislich bereits seit dem 23. Februar 2026 aktiv angegriffen. cPanel erhielt laut HelpNetSecurity rund zwei Wochen vor dem öffentlichen Advisory eine Meldung und antwortete zunächst, dass kein Problem vorliege.

Warum trifft es Shared-Hosting-Kunden, die nichts falsch gemacht haben?

Das Missverständnis ist verbreitet: Viele Webmaster suchen nach dem fehlerhaften Plugin oder dem schwachen Passwort in der eigenen WordPress-Installation. Im Fall von CVE-2026-41940 ist das der falsche Ansatz.

Auf einem Shared-Hosting-Server teilen sich dutzende bis hunderte Kunden-Accounts eine einzige cPanel/WHM-Instanz. Erhält ein Angreifer Root-Zugriff auf WHM, kontrolliert er nicht nur den Account des angegriffenen Kunden, sondern den gesamten Server. Alle Datenbanken, alle FTP-Zugänge, alle Dateisysteme aller Kunden sind in diesem Moment kompromittiert. Häufig sucht der Angreifer den technisch schwächsten Account auf dem Server als Einstiegspunkt und dringt von dort auf die gesamte Infrastruktur vor.

Das bedeutet für Sie konkret: Ihre WordPress-Installation kann makellos sein und trotzdem steht heute eine Erpresserbotschaft auf Ihrer Startseite. Der Grund liegt nicht in Ihrer Website, sondern in der Hosting-Infrastruktur Ihres Providers. Mehr zur grundsätzlichen WordPress-Sicherheitsstrategie lesen Sie in unserem Leitfaden zur WordPress-Sicherheit.

Ein weiteres Problem betrifft Backups. Viele Hoster legen ihre Backup-Dateien auf demselben Server ab, auf dem auch die Kundendaten liegen. Sobald ein Angreifer Root-Zugriff hat, sind auch diese Backups verschlüsselt oder vergiftet. Ein Backup auf demselben kompromittierten System ist im Ernstfall wertlos.

Was tun Sie jetzt, wenn Ihre Website betroffen ist?

Ruhe bewahren ist keine Floskel, sondern die wichtigste erste Maßnahme. Panikmaßnahmen wie das Bezahlen des Lösegelds oder das sofortige Überschreiben aller Daten zerstören im schlimmsten Fall die einzige Chance auf Wiederherstellung.

Folgen Sie dieser Schritt-für-Schritt-Reihenfolge:

Schritt 1: Ransom nicht zahlen

Koordinierte Ransomware-Kampagnen dieser Art halten Entschlüsselungsversprechen in der Mehrheit der Fälle nicht ein. Jede Zahlung finanziert die nächste Angriffswelle.

Schritt 2: Website sofort offline nehmen

Nehmen Sie die Website vom Netz oder sperren Sie den öffentlichen Zugriff. Solange die Site erreichbar ist, verteilen Sie möglicherweise Schadsoftware an Ihre Besucher.

Schritt 3: Snapshot sichern

Erstellen Sie einen Snapshot des kompromittierten Zustands, nicht zur Wiederherstellung, sondern zur Analyse. Daraus lassen sich Angriffszeitpunkt und Ausmaß rekonstruieren.

Schritt 4: Off-Site-Backup identifizieren

Prüfen Sie, ob Sie ein Backup außerhalb des kompromittierten Servers haben. Backups auf demselben cPanel-Server sind mit hoher Wahrscheinlichkeit ebenfalls verschlüsselt oder verseucht.

Schritt 5: Saubere Hosting-Umgebung aufbauen

Stellen Sie die Website erst auf einem frischen, vollständig gepatchten Server wieder her. Ein cPanel-Update auf dem alten Server reicht nicht, sofern Root-Zugriff bestand. Wie Sie eine saubere WordPress-Installation nach einem Angriff aufbauen, beschreiben wir detailliert in diesem Beitrag.

Schritt 6: Alle Zugangsdaten rotieren

Behandeln Sie sämtliche Zugangsdaten des kompromittierten Servers als verbrannt: cPanel/WHM-Passwörter, SSH-Schlüssel, FTP/SFTP-Zugänge, Datenbanknutzer, WordPress-Admin-Accounts, API-Schlüssel und SMTP-Credentials.

Schritt 7: Nachkontrolle

Prüfen Sie nach der Wiederherstellung auf unbekannte Admin-Accounts, fremde Cron-Jobs, manipulierte .htaccess-Dateien, PHP-Dateien im Upload-Verzeichnis und außergewöhnlich geänderte Dateien außerhalb der normalen WordPress-Pfade.

Wie prüfen Sie, ob Ihr Hoster bereits gepatcht hat?

Die direkte Frage ist die effizienteste Methode. Kontaktieren Sie den Support Ihres Hosters und fragen Sie konkret nach CVE-2026-41940 und dem Patch-Status. Seriöse Provider geben Ihnen innerhalb weniger Stunden Auskunft.

Betreiben Sie einen eigenen Server mit cPanel & WHM, prüfen Sie die installierte Version selbst. Alle Releases unterhalb dieser Grenzwerte sind weiterhin verwundbar:

• cPanel & WHM 11.136.x: sicher ab 11.136.0.5
• cPanel & WHM 11.134.x: sicher ab 11.134.0.20
• cPanel & WHM 11.132.x: sicher ab 11.132.0.29
• cPanel & WHM 11.130.x: sicher ab 11.130.0.19
• cPanel & WHM 11.126.x: sicher ab 11.126.0.54
• WP Squared: sicher ab 136.1.7

Das Update erzwingen Sie über die cPanel-Kommandozeile. Mehrere Hoster sperrten in der Akutphase alternativ die Ports 2083 und 2087 per TCP-Block. Das ist ein Workaround, kein Ersatz für den Patch. Ist Ihr Hoster nicht gepatcht und gibt es keine kurzfristige Perspektive, wechseln Sie zu einem gepatchten Anbieter, bevor Sie Ihre Website wiederherstellen.

Wie schützen Sie Ihre WordPress-Website vor der nächsten Angriffswelle?

CVE-2026-41940 wird nicht die letzte kritische Schwachstelle in Hosting-Infrastruktur sein. Die eigentliche Lehre aus diesem Vorfall ist struktureller Natur.

Off-Site-Backups sind keine Option, sondern Grundvoraussetzung. Backups, die auf demselben Server liegen wie die Produktivdaten, sind bei einem Server-Angriff wertlos. Dienste wie UpdraftPlus mit externem Cloud-Speicher oder managed Backup-Lösungen sichern Ihre Daten physisch getrennt vom Webserver.

Prüfen Sie bei der Hosting-Wahl, ob der Anbieter einen nachvollziehbaren Patching-Prozess kommuniziert. Wie schnell hat der Hoster CVE-2026-41940 gepatcht? Gab es proaktive Kundenkommunikation? Anbieter, die diese Fragen nicht beantworten können oder wollen, gehören nicht in Ihren Infrastruktur-Stack.

Zwei-Faktor-Authentifizierung schützt Ihren cPanel-Account auf Login-Ebene zuverlässig vor Brute-Force-Angriffen, sofern der Server selbst sauber ist. Die Einrichtung dauert wenige Minuten. Warum schwache Login-Daten nach wie vor der häufigste WordPress-Fehler sind und wie Sie das abstellen, lesen Sie hier.

Betreiben Sie einen eigenen Server, schränken Sie den Netzwerkzugang auf die Ports 2083 und 2087 per Firewall-Allowlist auf bekannte IP-Adressen ein. Niemand außerhalb Ihres Teams braucht Zugriff auf das WHM-Interface.

Glossar: 12 wichtige Fachbegriffe zur cPanel-Sicherheitslücke

Authentication Bypass

Authentication Bypass (Authentifizierungsumgehung) bezeichnet eine Schwachstelle, bei der ein Angreifer die Anmeldehürde eines Systems überspringt, ohne gültige Zugangsdaten zu besitzen. Im Fall von CVE-2026-41940 gelingt das durch manipulierte Session-Dateien, die dem System vortäuschen, die Identität root zu tragen.

CRLF-Injection

CRLF-Injection ist ein Angriff, bei dem ein Angreifer Zeilenumbruchzeichen (Carriage Return \r und Line Feed \n) in Datenströme einschleust, die das System ohne Validierung verarbeitet. Dadurch lassen sich Dateiinhalte oder Header-Strukturen nach Belieben manipulieren.

cPanel

cPanel ist ein webbasiertes Verwaltungspanel für Webhosting-Accounts. Nutzer verwalten darüber Domains, Datenbanken, E-Mail-Adressen und Dateien. Technisch läuft cPanel auf demselben Server wie die gehosteten Websites, was Sicherheitslücken im Panel direkt alle gehosteten Seiten betrifft.

CVSS-Score

CVSS (Common Vulnerability Scoring System) ist ein standardisiertes Bewertungssystem für Sicherheitslücken. Werte reichen von 0 bis 10, wobei ab 9,0 von „kritisch“ gesprochen wird. CVE-2026-41940 erhielt einen Score von 9,8 und begründet damit die Einstufung als unmittelbar handlungsrelevant.

CVE

CVE (Common Vulnerabilities and Exposures) ist ein öffentliches Register für bekannte Sicherheitslücken in Software. Jede Schwachstelle erhält eine eindeutige ID im Format CVE-JJJJ-NNNNN. Die ID erleichtert die eindeutige Kommunikation zwischen Herstellern, Sicherheitsforschern und Administratoren.

Off-Site-Backup

Off-Site-Backup bezeichnet eine Datensicherung, die physisch getrennt vom Produktivsystem aufbewahrt wird, also nicht auf demselben Server oder im selben Rechenzentrum. Im Kontext eines Server-Angriffs ist das Off-Site-Backup die einzige Backup-Variante, die zuverlässig vor Datenverlust schützt.

Proof-of-Concept-Exploit

Proof-of-Concept-Exploit (PoC) ist ein funktionierender Angriffscode, der beweist, dass eine Sicherheitslücke tatsächlich ausnutzbar ist. Die Veröffentlichung eines PoC durch watchTowr am 29. April 2026 erhöhte das Risiko für ungepatchte Systeme schlagartig, da der Angriff nun für ein breiteres Spektrum an Angreifern reproduzierbar wurde.

Ransomware

Ransomware ist Schadsoftware, die Dateien auf einem kompromittierten System verschlüsselt und anschließend Lösegeld für die Entschlüsselung fordert. Bei CVE-2026-41940 nutzten Angreifer den Root-Zugriff auf cPanel-Server, um ganze Server-Partitionen zu verschlüsseln.

Root-Zugriff

Root-Zugriff bezeichnet die höchste Berechtigungsstufe auf einem Linux-Server. Mit Root-Rechten kann ein Angreifer sämtliche Dateien lesen, verändern und löschen, neue Nutzer anlegen und beliebige Software installieren. CVE-2026-41940 ermöglicht genau diesen Zugriff ohne Passwort.

Session-Hijacking

Session-Hijacking ist ein Angriff, bei dem ein Angreifer eine legitime Nutzersitzung übernimmt oder fälscht. Im Fall von CVE-2026-41940 wird keine bestehende Session gekapert, sondern eine neue Session-Datei mit Root-Rechten direkt auf den Server geschrieben.

Shared Hosting

Shared Hosting ist ein Hosting-Modell, bei dem mehrere Kunden-Accounts auf demselben physischen Server betrieben werden. Ein einziges kompromittiertes WHM gibt einem Angreifer Zugriff auf alle Accounts des Servers, unabhängig davon, welcher Account der ursprüngliche Angriffsvektor war.

WHM

WHM (Web Host Manager) ist die administrative Oberfläche über cPanel mit Root-Zugriff auf einen Server. Während cPanel der nutzerseitigen Verwaltung einzelner Accounts dient, steuert WHM die gesamte Serverumgebung inklusive aller cPanel-Accounts darauf.

FAQ: cPanel-Sicherheitslücke: Ist Ihre Website betroffen?

Quellen

• Rapid7 | CVE-2026-41940: cPanel & WHM Authentication Bypass | https://www.rapid7.com/blog/post/etr-cve-2026-41940-cpanel-whm-authentication-bypass/ | besucht am 01.05.2026
• Help Net Security | cPanel zero-day exploited for months before patch release | https://www.helpnetsecurity.com/2026/04/30/cpanel-zero-day-vulnerability-cve-2026-41940-exploited/ | besucht am 01.05.2026
• watchTowr Labs | The Internet Is Falling Down (cPanel & WHM Authentication Bypass CVE-2026-41940) | https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/ | besucht am 01.05.2026
• cPanel | Security Update 04-28-2026 | https://support.cpanel.net/hc/en-us/articles/40073787579671-cPanel-WHM-Security-Update-04-28-2026 | besucht am 01.05.2026
• BleepingComputer | Critical cPanel and WHM bug exploited as a zero-day, PoC now available | https://www.bleepingcomputer.com/news/security/critical-cpanel-and-whm-bug-exploited-as-a-zero-day-poc-now-available/ | besucht am 01.05.2026