Am 28. April 2026 hat cPanel einen Notfall-Patch veröffentlicht. Einen Tag später bekam die Lücke eine Nummer: CVE-2026-41940, CVSS-Score 9,8 von 10 — das ist die Stufe, ab der Sicherheitsforscher von einer „kritischen" Schwachstelle sprechen. Sicherheitsfirma watchTowr veröffentlichte am selben Tag einen funktionierenden Exploit-Code. Und der KnownHost-CEO bestätigte gegenüber The Hacker News, dass die Lücke schon seit mindestens 30 Tagen aktiv ausgenutzt wurde — bevor irgendjemand öffentlich davon wusste.
Wenn Ihre Website auf einem klassischen Hosting-Paket liegt, ist die Wahrscheinlichkeit hoch, dass irgendwo im Hintergrund cPanel läuft. Anbieter wie dogado, ALL-INKL, Hosteurope-Reseller und viele kleinere deutsche Hoster setzen darauf. Sie müssen kein Server-Admin sein, um betroffen zu sein. Sie müssen nur wissen, welche Frage Sie Ihrem Hoster stellen sollten.
Ein Angreifer kann die Authentifizierung von cPanel und WHM komplett umgehen — ohne Passwort, ohne Zwei-Faktor. Über eine manipulierte HTTP-Anfrage schreibt er sich selbst eine Admin-Session in die Server-Dateien. Danach ist er Root.
Wie der Angriff technisch funktioniert
Der Fehler steckt in cpsrvd, dem zentralen Daemon, der alle Web-Oberflächen von cPanel bedient. Bevor ein Login fertig geprüft wird, schreibt cpsrvd schon eine Session-Datei auf die Festplatte. Ein Angreifer schickt einen Login-Versuch mit eingeschleusten Zeilenumbrüchen im Passwort-Feld — und cpsrvd speichert diese Zeilen unbearbeitet ab. Beim nächsten Laden interpretiert das System die Zeilen als zusätzliche Session-Einträge: user=root, tfa_verified=1, fertig. Ein fehlgeschlagener Login wird so zu einer voll authentifizierten Root-Sitzung.
Wichtig zu verstehen: Zwei-Faktor-Authentifizierung schützt hier nicht. Der Angreifer setzt den 2FA-Status einfach selbst auf „erledigt". Auch starke Passwörter, IP-Limits am Login-Formular oder Captchas helfen nicht — der Angriff hängt sich an die Session-Verwaltung, nicht an das Login.
Wer ist betroffen?
Alle cPanel-Versionen ab 11.40 — also praktisch jede aktive cPanel-Installation. Die Lücke betrifft die direkt erreichbaren Ports 2082, 2083, 2086, 2087, 2095 und 2096. Wenn Ihr Hoster diese Ports öffentlich offen hat (was der Standard ist), war Ihre Seite bis zum Patch verwundbar.
Was nicht direkt betroffen ist: WordPress selbst, Plesk-basierte Hostings (z.B. STRATO, IONOS, Hetzner-Plesk), Static-Site-Setups und Cloud-Hoster ohne klassisches Web-Panel. Wenn Sie nicht wissen, was Ihr Hoster nutzt — eine kurze Mail genügt.
Was Sie jetzt tun sollten
Wir haben das Vorgehen für unsere eigenen Kunden in vier Schritte zusammengefasst. Auch wenn Sie kein Admin sind, können Sie alle vier durchgehen:
- Hoster anschreiben. Eine direkte Frage genügt: „Läuft auf unserem Hosting-Paket cPanel — und wenn ja, ist CVE-2026-41940 gepatcht? Welche Version läuft jetzt?" Seriöse Hoster antworten innerhalb eines Tages.
- Version prüfen lassen. Sicher sind die Builds 11.136.0.5 (aktuell), 11.134.0.20, 11.132.0.29, 11.130.0.19, 11.126.0.54, 11.118.0.63, 11.110.0.97 (LTS) und 11.86.0.41 (Legacy). Alles darunter — oder älter als 11.86 — sollten Sie als Risiko behandeln.
- Logs einsehen lassen. Wenn Ihr Hoster gepatcht hat, fragen Sie nach: „Gab es zwischen Anfang April und 28. April auffällige Login-Aktivität auf unserem Account?" Die 30 Tage Vorlauf als 0-Day bedeuten: einige Server wurden bereits kompromittiert, bevor der Patch da war.
- Backups verifizieren. Nicht „haben wir Backups", sondern: „Wann zuletzt ein Restore getestet wurde". Wenn doch etwas kompromittiert ist, brauchen Sie eine Wiederherstellungspunkt vor dem 1. April 2026.
Wenn Ihr Hoster nicht antwortet
Das ist seltener das Problem als gedacht — die meisten cPanel-Hoster haben innerhalb von 24 bis 72 Stunden gepatcht und ihre Kunden informiert. Namecheap und KnownHost zum Beispiel hatten die Updates schon am 29. April durchgezogen. Wenn nach drei Werktagen aber niemand reagiert, ist das selbst ein Signal: ein Anbieter, der bei einem CVSS-9,8-Vorfall keine Kommunikation hinbekommt, ist auch für die nächste Lücke kein guter Partner.
In dem Fall ist der pragmatische Schritt nicht Panik, sondern Planung: ein Umzug zu einem Hoster mit klarem Patch-Prozess. Bei uns sind das typischerweise Anbieter, die Plesk fahren (zentralisierter Patch-Rollout) oder die ihre Server selbst betreiben und CVE-Tracking als Standard-Service liefern.
Was wir aus dem Vorfall mitnehmen
Drei Dinge bleiben hängen, unabhängig von dieser konkreten Lücke:
- Web-Panels sind ein lohnendes Ziel. Wer cPanel knackt, hat nicht eine Seite, sondern hunderte. Das macht jede Lücke im Panel-Code dramatisch wertvoll für Angreifer — und 0-Day-Fenster von 30 Tagen werden eher länger als kürzer.
- 2FA ist kein Allheilmittel. Die Annahme „mit Zwei-Faktor sind wir sicher" hat hier nicht gehalten. Sicherheits-Reviews müssen die Session-Schicht mit einschließen, nicht nur die Login-Schicht.
- Patch-Geschwindigkeit ist ein Auswahlkriterium für Hoster. Wir bewerten Anbieter inzwischen nicht mehr nur nach Preis und Performance, sondern danach, wie schnell sie auf CVE-Alerts reagieren. Wer 72 Stunden braucht, ist langsam. Wer eine Woche braucht, fällt durch.
Setzen Sie sich einen Erinnerungs-Termin: einmal im Quartal eine kurze Mail an den Hoster mit der Frage „Welche CVEs wurden im letzten Quartal auf unserem Server gepatcht?" Allein die Tatsache, dass Sie fragen, verändert oft schon den Service.
Wenn Sie nicht sicher sind, ob Ihr Hosting betroffen ist, oder eine zweite Meinung zur Patch-Antwort Ihres Anbieters brauchen — schreiben Sie uns kurz. Wir schauen drauf.
Lass uns über dein Projekt sprechen.
30 Minuten Erstgespräch, kostenlos und unverbindlich. Konkrete Antworten statt Sales-Pitch.
→ Kontakt aufnehmen