Kritische cPanel-Schwachstelle von 44.000 IPs ausgenutzt

Am 28. April 2026 veröffentlichte cPanel ein Notfall-Sicherheitsupdate für CVE-2026-41940, eine kritische Schwachstelle in cPanel & WHM, über die sich die Authentifizierung umgehen lässt. Die mit einem CVSS-Score von 9,8 bewertete Lücke erlaubt es nicht authentifizierten Angreifern, aus der Ferne administrativen Root-Zugriff auf die Oberfläche des Web Host Manager (WHM) zu erlangen. Möglich macht das eine CRLF-Injection in Kombination mit einer Race Condition bei Sitzungsdateien. Da Schätzungen zufolge weltweit mehr als 70 Millionen Domains mit cPanel betrieben werden, zählt die Reichweite dieser Schwachstelle zu den größten in der Geschichte der Hosting-Infrastruktur.

Aktive Ausnutzung ist bereits ab dem 23. Februar 2026 belegt, mehr als zwei Monate vor dem offiziellen Patch. Bis zur Veröffentlichung des Sicherheitshinweises hatte die Shadowserver Foundation 44.000 unterschiedliche IP-Adressen beobachtet, die nach verwundbaren cPanel-Installationen suchten, diese sondierten oder aktiv ausnutzten. Ein öffentliches Proof-of-Concept-Framework namens "cPanelSniper" beschleunigte die Entwicklung einsatzfähiger Angriffe: Es ermöglichte automatisierte Massenscans, das Einschleusen von Backdoors und die Installation von Ransomware in Shared-Hosting-Umgebungen.

Was passiert ist

Die Schwachstelle steckt in cpsrvd, dem cPanel-Dienst-Daemon, der für Anmeldung und Sitzungsverwaltung zuständig ist. Konkret ist die Verarbeitung von HTTP-Authorization-Headern im Modul Session.pm anfällig für CRLF-Injection (Carriage Return Line Feed). Ein Angreifer kann beliebige Schlüssel-Wert-Paare wie user=root, hasroot=1 und tfa_verified=1 direkt in den serverseitigen Sitzungsspeicher einschleusen.

Eine zweite Schwachstelle verschärft die erste: cPanel speichert Sitzungsdaten sowohl in einer reinen Textdatei als auch in einem JSON-Cache, und eine Race Condition zwischen diesen beiden Schreibvorgängen sorgt dafür, dass die vom Angreifer eingeschleusten Daten erhalten bleiben und von der Authentifizierungsschicht als vertrauenswürdig behandelt werden. Manipuliert der Angreifer das Cookie whostmgrsession so, dass es auf die präparierte Sitzungsdatei verweist, umgeht er sämtliche Authentifizierungsprüfungen einschließlich der Zwei-Faktor-Authentifizierung und erhält eine vollständig authentifizierte Root-Sitzung. Weder gültige Zugangsdaten noch vorheriger Zugriff noch eine Nutzerinteraktion sind dafür erforderlich.

cPanel veröffentlichte am 28. April 2026 Patches für alle unterstützten Versionen nach 11.40. Die CISA nahm CVE-2026-41940 in ihren KEV-Katalog (Known Exploited Vulnerabilities) auf; US-Bundesbehörden sind damit verpflichtet, die Schwachstelle innerhalb der vorgeschriebenen Frist zu beheben.

Welche Daten entwendet wurden

Kompromittierte Server verschafften den Angreifern die vollständige administrative Kontrolle, sodass alles zugänglich war, was auf dem jeweiligen System gehostet wurde. Incident-Response-Teams, die mit CVE-2026-41940 verbundene Sicherheitsvorfälle untersuchen, berichten von der Exfiltration folgender Daten:

• Website-Datenbanken und Quellcode

  Angreifer kopierten MySQL- und PostgreSQL-Datenbanken mit Kundendatensätzen, Zugangsdaten, Zahlungsinformationen und geschäftskritischen Anwendungsdaten sämtlicher Konten, die auf den kompromittierten Servern gehostet waren.

• E-Mail-Archive und Zugangsdaten

  Vollständige Postfachinhalte, SMTP-Zugangsdaten und Adressbücher wurden abgegriffen. Mehrere bestätigte Phishing-Kampagnen ließen sich auf Zugangsdaten zurückführen, die über diese Schwachstelle gestohlen wurden.

• Private SSL/TLS-Schlüssel

  Private Zertifikatsschlüssel, die auf kompromittierten Servern gespeichert waren, wurden ausgelesen. Das ermöglicht Man-in-the-Middle-Angriffe auf Domains, deren Zertifikate noch nicht widerrufen und neu ausgestellt wurden.

• Zugangsdaten auf Serverebene und API-Schlüssel

  Root-SSH-Schlüssel, API-Tokens von Cloud-Anbietern, Zugangsdaten für die DNS-Verwaltung und der Zugriff auf Backup-Systeme lagen in Reichweite, sobald Root-Zugriff auf WHM bestand.

In Shared-Hosting-Umgebungen beherbergt ein einzelner kompromittierter Server in der Regel Hunderte bis Tausende voneinander unabhängiger Websites und Konten. Jedes Konto auf einem betroffenen Server muss als vollständig kompromittiert gelten, unabhängig davon, wie gut es für sich genommen abgesichert war.

Wie solche Angriffe ablaufen

Die Angriffskette beginnt mit der Aufklärung. Angreifer suchen nach Servern, die WHM auf Port 2087 oder cPanel auf Port 2083 offen erreichbar machen. Per Service-Fingerprinting bestätigen sie, dass auf dem Ziel eine verwundbare cPanel-Version läuft. Das Framework cPanelSniper automatisiert diese gesamte Phase und verarbeitet Tausende Ziele pro Stunde.

Ist ein Ziel identifiziert, sendet der Angreifer eine präparierte HTTP-Anfrage an den Login-Endpunkt von WHM. Die Anfrage enthält einen bösartigen Authorization-Header mit CRLF-Sequenzen, die Sitzungsattribute in die serverseitige Sitzungsdatei einschleusen. Diese eingeschleusten Attribute gewähren eine Authentifizierung mit Root-Rechten. Anschließend sendet der Angreifer eine Folgeanfrage mit einem Cookie whostmgrsession, das auf die präparierte Sitzung verweist. Der Server validiert die Sitzung, findet die eingeschleusten Root-Zugangsdaten und liefert eine vollständig authentifizierte WHM-Oberfläche aus.

Was nach der Ausnutzung geschieht, hängt vom Motiv der Angreifer ab. Ransomware-Betreiber verschlüsseln sämtliche gehosteten Daten und fordern Lösegeld pro Server oder pro Konto. Akteure mit Spionageabsichten richten dauerhafte Backdoors ein, etwa über Cronjobs, veränderte System-Binärdateien oder Webshells, die sie in den gehosteten Konten platzieren. Cryptojacking-Kampagnen installieren Mining-Software, die die Rechenressourcen des Servers nutzt. In mehreren bestätigten Fällen verketteten Angreifer ihren Zugriff mit dem Metadaten-Endpunkt des Cloud-Anbieters, um von dort in die weitere Infrastruktur des Hosting-Anbieters vorzudringen.

Warum das Führungskräfte betrifft

cPanel ist das dominierende Control Panel für Webhosting und verwaltet schätzungsweise 70 Millionen Domains auf Hunderttausenden Servern weltweit. Anders als Schwachstellen in einzelnen Anwendungen, die nur eine Website betreffen, trifft eine Kompromittierung von cPanel jede Website, jede Datenbank, jedes E-Mail-Konto und jeden Dienst, der auf dem betreffenden Server gehostet wird. Für Hosting-Anbieter kann ein einziger ungepatchter Server bedeuten, dass sämtliche Kunden auf diesem System gleichzeitig von einer Datenpanne betroffen sind.

Das zweimonatige Zeitfenster, in dem die Lücke als Zero-Day-Schwachstelle ausgenutzt wurde, reichte von Ende Februar bis Ende April 2026. Selbst Server, die noch am Tag der Offenlegung gepatcht wurden, können daher bereits kompromittiert gewesen sein. Patchen allein genügt nicht ohne eine parallele forensische Untersuchung, die klärt, ob in der Zeit vor dem Patch auf den Server zugegriffen wurde. Organisationen, die auf externe Hosting-Anbieter setzen, können nicht davon ausgehen, dass ihr Anbieter zeitnah gepatcht oder nach einer früheren Kompromittierung gesucht hat.

Ransomware erhöht zudem den unmittelbaren finanziellen Druck. Die Angreifer fordern Lösegeld pro Server, und im Shared Hosting zählen auch Unternehmen zu den Opfern, die keine direkte Beziehung zur Hosting-Infrastruktur und keinen Einblick in den Patch-Status des zugrunde liegenden Servers haben. Die regulatorischen Risiken nach DSGVO, PCI DSS und branchenspezifischen Regelwerken sind erheblich, wenn die auf kompromittierten Servern gespeicherten Kundendaten personenbezogene Daten, Zahlungsdaten oder Gesundheitsdaten umfassen.

Was jetzt zu tun ist

1. Notfall-Patch sofort einspielen

   Aktualisieren Sie alle Installationen von cPanel & WHM auf die neueste gepatchte Version vom 28. April 2026. Prüfen Sie anhand der cPanel-Versionsangabe in WHM, ob das Update erfolgreich eingespielt wurde. Waren automatische Updates deaktiviert oder verzögert, behandeln Sie den Server als möglicherweise kompromittiert und leiten Sie eine forensische Untersuchung ein.

2. Auf frühere Kompromittierung prüfen

   Ein Patch beseitigt keine bereits bestehende Kompromittierung. Prüfen Sie das Verzeichnis /var/cpanel/sessions/raw auf Sitzungsdateien aus unbekannten Quellen, die eingeschleuste Attribute wie hasroot=1 oder tfa_verified=1 enthalten. Durchsuchen Sie die WHM-Zugriffsprotokolle nach Authentifizierungsereignissen von unerwarteten IP-Adressen. Suchen Sie nach neu angelegten cPanel-Konten sowie in allen gehosteten Konten nach geänderten Cronjobs, unbekannten autorisierten SSH-Schlüsseln und Webshells.

3. Erreichbarkeit der Verwaltungsports einschränken

   Blockieren Sie auf Ebene der Netzwerk-Firewall eingehenden Datenverkehr aus dem öffentlichen Internet zu den Ports 2083, 2087, 2095 und 2096. Lassen Sie administrativen Zugriff auf die Oberflächen von WHM und cPanel nur über VPN oder IP-Allowlisting zu. Diese eine Maßnahme beseitigt den Angriffsvektor aus der Ferne vollständig.

4. Sämtliche Zugangsdaten austauschen

   Gehen Sie davon aus, dass alle Zugangsdaten kompromittiert sind, die auf dem Server gespeichert oder über ihn erreichbar sind. Erneuern Sie Root-Passwörter, Passwörter der cPanel-Konten, Datenbank-Zugangsdaten, E-Mail-Passwörter, SSH-Schlüssel, SSL/TLS-Zertifikate, API-Tokens sowie alle auf dem Server konfigurierten Zugangsdaten für Drittanbieterdienste. Fordern Sie Ihre gehosteten Kunden auf, ihre eigenen Zugangsdaten auf Anwendungsebene ebenfalls zu erneuern.

5. Umfassende Sicherheitsbewertung durchführen

   Beauftragen Sie ein Team für Penetrationstests damit, zu überprüfen, ob der Patch korrekt eingespielt wurde, keine dauerhaften Backdoors zurückgeblieben sind und die Konfiguration des Servers keine zusätzlichen Angriffsflächen bietet. Für Organisationen, die sensible Daten hosten, empfiehlt sich zudem ein Sicherheits-Code-Review der individuellen Anwendungen auf dem Server, um festzustellen, ob vom Angreifer eingeschleuster Code im Quellcode der Anwendungen verblieben ist.

Drängende Fragen

• Wurde mein Server kompromittiert, bevor der Patch erschien?

  Wenn auf Ihrem Server zu irgendeinem Zeitpunkt zwischen dem 23. Februar und dem 28. April 2026 eine ungepatchte Version von cPanel & WHM lief und die Ports 2083 oder 2087 aus dem Internet erreichbar waren, besteht eine erhebliche Wahrscheinlichkeit einer Kompromittierung. In diesem Zeitraum wurde aktive Ausnutzung bestätigt. Ob tatsächlich eine Kompromittierung stattgefunden hat, lässt sich nur durch eine forensische Untersuchung der Sitzungsdateien, Zugriffsprotokolle und Systemintegrität feststellen.

• Schützt die Zwei-Faktor-Authentifizierung vor dieser Schwachstelle?

  Nein. Über die CRLF-Injection können Angreifer tfa_verified=1 direkt in die Sitzungsdatei einschleusen und die Zwei-Faktor-Authentifizierung damit vollständig umgehen. Die Sitzung wird als 2FA-verifiziert markiert, ohne dass die Verifizierung je stattgefunden hat. Das ist keine Schwäche der 2FA selbst, sondern der Sitzungsverwaltung, die ihr vorgelagert ist.

• Ich nutze einen Hosting-Anbieter. Bin ich betroffen?

  Wenn Ihr Hosting-Anbieter Ihr Konto über cPanel verwaltet, können Sie unabhängig von Ihren eigenen Sicherheitsmaßnahmen betroffen sein. Fragen Sie direkt bei Ihrem Hosting-Anbieter nach, ob er den Patch eingespielt und eine forensische Untersuchung für den Zeitraum der Ausnutzung vor dem Patch durchgeführt hat. Kann er nicht beides bestätigen, sollten Sie erwägen, sensible Workloads auf eine Infrastruktur unter Ihrer eigenen Kontrolle zu verlagern.

• Werden verwaltete cPanel-Installationen automatisch gepatcht?

  cPanel-Server mit aktivierten automatischen Updates erhielten den Patch kurz nach der Veröffentlichung am 28. April. Auf vielen Produktivservern sind automatische Updates jedoch bewusst deaktiviert, um die Stabilität zu wahren, sodass dort ein manuelles Eingreifen nötig ist. Prüfen Sie Ihre Update-Konfiguration und die aktuelle Version über die WHM-Oberfläche "Upgrade to Latest Version".

Das Wichtigste in Kürze

CVE-2026-41940 ist ein Worst-Case-Szenario für Shared-Hosting-Infrastruktur: Root-Zugriff ohne Authentifizierung auf die Verwaltungsoberfläche des weltweit am häufigsten eingesetzten Hosting-Control-Panels, zwei Monate lang als Zero-Day-Schwachstelle aktiv ausgenutzt, bevor ein Patch verfügbar war. Die Kombination aus trivialer Ausnutzbarkeit, enormer Angriffsfläche und bestätigtem Ransomware-Einsatz macht sie zu einer der folgenreichsten Schwachstellen in der Hosting-Infrastruktur der letzten Jahre.

Patchen ist notwendig, aber nicht ausreichend. Jede Organisation, die cPanel betreibt, muss den Patch-Status prüfen, nach früheren Kompromittierungen suchen, sämtliche Zugangsdaten austauschen und die Erreichbarkeit der Verwaltungsoberflächen auf vertrauenswürdige Netzwerke beschränken. Organisationen, die auf externes Hosting setzen, müssen die Reaktion ihres Anbieters direkt überprüfen. Die Annahme "Mein Hoster kümmert sich um die Sicherheit" ist keine haltbare Position, wenn das Control Panel des Hosters selbst der Angriffsvektor war.