Was Ende April als CRLF-Bypass-Lücke begonnen hat, ist seit Anfang Mai 2026 die größte aktive Hosting-Welle des Jahres. Mehrere Threat-Hunter und cPanels eigenes Sicherheits-Team bestätigen: CVE-2026-41940 wird seit Februar — also Monate vor dem Patch — in der Wildbahn ausgenutzt. Etwa 1,5 Millionen exponierte Server sind betroffen. cPanel und WHM bedienen 70 Millionen Domains — das Risiko reicht weit.
UNGLAUBLICH: Lücke seit Februar offen
Der Patch kam am 28. April 2026, geschrieben war die Lücke aber bereits Anfang Februar. Sicherheitsforscher von WatchTowr und Rapid7 haben in den Telemetrie-Daten Angriffe nachweisen können, die zwei Monate vor dem Bug-Disclosure liefen. Heißt: Es gibt eine echte Wahrscheinlichkeit, dass dein cPanel-Server seit Wochen kompromittiert ist, ohne dass du es weißt.
Technisch nutzt der Angreifer Carriage-Return-Line-Feed-Injection in der Login- und Session-Lade-Routine. Damit lässt sich der Auth-Layer komplett umgehen. CVSS-Score: 9.8 ohne Auth, kein User-Interaction nötig, Hauptservice-Port 2083 reicht.
SCHOCK: Der Skalen-Effekt
Cybersecurity-Dive beziffert die Massen-Exploit-Wellen auf rund 1,5 Millionen Server. Das ist nicht das gesamte cPanel-Universum (70 Millionen Domains laufen darunter), aber jeder dritte exponierte Host. Threat-Actors nutzen die Lücke für Defacement, Ransomware-Drops und das Anlegen versteckter Reseller-Accounts. Letzteres ist besonders fies: Du merkst es erst, wenn die Hetzner-Abrechnung für plötzlich aktive Reseller-Pakete kommt.
Auch WP Squared ist betroffen — das ist die Managed-WordPress-Plattform auf cPanel-Basis. Die Version 136.1.7 enthält dieselbe verwundbare Routine. Für Hosting-Provider mit WP-Squared-Lizenz ist das doppelt unangenehm.
SO FLICKST DU DEIN PANEL IN 5 MINUTEN!
Schritt 1: Build-Nummer prüfen. /usr/local/cpanel/cpanel -V auf der Konsole zeigt deine Version. Du brauchst 11.136.0.5 oder ein höheres Branch-Äquivalent. Alles unter 11.136.0.5 ist offen.
Schritt 2: Update-Skript laufen lassen. /scripts/upcp --force spielt die aktuelle Version aus dem cPanel-Repo ein. Auf Reseller-Hosts solltest du den Wartungsmodus für ein paar Minuten setzen.
Schritt 3: Log-Forensik. Schau dir die access_log-Einträge auf Port 2083 ab dem 1. Februar an. Verdächtig sind POST-Requests an /login mit ungewöhnlichen Header-Folgen, insbesondere %0d%0a-Sequenzen. Wer die findet, sollte einen Forensik-Snapshot ziehen, statt blindlings zu rebooten.
NACH DEM PATCH: Account-Audit
Selbst nach dem Update bleibt die Frage: Hat dich jemand schon erwischt? Indikatoren: neue Reseller-Accounts, geänderte Mail-Forwarder mit unbekannten Zielen, neue WHM-API-Tokens, oder ein cron.allow, das du nie geschrieben hast. Lege ein Backup-Image an, prüfe alle Accounts auf Anomalien, und rolle Admin-Passwörter sowie API-Tokens neu aus.
Bei Hosting-Anbietern mit großem Bestand lohnt sich ein automatisiertes Compliance-Tool wie Imunify360 oder ein selbstgeschriebenes WHM-API-Skript, das ungewöhnliche Account-Erstellungen alarmiert.
EXTRA-TIPP: Edge-Schicht vorschalten
Wer einen Cloudflare- oder ähnlichen Edge-Layer vor dem cPanel hat, sollte temporär einen WAF-Custom-Rule-Block für CRLF-Sequenzen in Login-URIs scharf schalten. Das fängt zwar nicht 100 % der Varianten, aber drückt das Hintergrund-Rauschen deutlich runter — und kauft dir Zeit, falls du den Update-Run nicht in einer Stunde durchziehen kannst.
FAZIT: Eine der schwersten Hosting-Wellen
CVE-2026-41940 reiht sich in die Liste der dramatischsten Webhosting-Bugs des Jahrzehnts ein. Wer Hosting für Kunden anbietet, hat keinen Bonus mehr — patchen, Logs durchsuchen und Audit fahren ist Pflichtprogramm. Wer privat nur einen Single-Server betreibt, sollte ebenfalls heute Abend updaten. Die zwei Monate Vorsprung der Angreifer bedeuten: Du bist im Worst Case nicht der Erste, der überlegt, was passiert ist.
Häufige Fragen
Welche Versionen sind betroffen?
Wie merke ich, ob mein System verwundbar ist?
/usr/local/cpanel/cpanel -V deine Build-Nummer. Liegt sie unter 11.136.0.5, bist du betroffen. Zusätzlich gibt es ein Detection-Skript bei WatchTowr Labs, das verdächtige Login-Header in den access_log-Dateien sucht — sehr empfehlenswert, weil die Lücke schon Monate offen war.Wie behebe ich das Problem konkret?
/scripts/upcp --force, danach Reboot der relevanten Dienste. Im Anschluss: Account-Audit, Token-Rotation, Mail-Forwarder-Check, und Reseller-Liste durchgehen. Wer Anzeichen für eine Kompromittierung findet, sollte einen Vollback-Restore aus einem Pre-Februar-Backup erwägen statt nur zu patchen.