cPanel CVE-2026-41940: 44.000 Server kompromittiert — was Unternehmen mit Shared-Hosting jetzt tun müssen

Managed Hosting ohne cPanel-Lock-in — souverän in Deutschland — WZ-IT übernimmt Konzeption, Migration und Betrieb auf eigener Infrastruktur. Open-Source-Stacks (NGINX, Caddy, WordPress), Private Cloud auf Hetzner, CVE-Monitoring inklusive — Patches in Stunden statt Wochen, NIS2-konform dokumentiert. Erstgespräch buchen · CVE-Monitoring · High-Scale Webhosting

Eine cPanel-Lücke, die seit dem 23. Februar 2026 aktiv ausgenutzt wird, wird am 28. April 2026 offiziell disclosed. Bis zum 5. Mai sind über 44.000 Server kompromittiert; rund 1,5 Millionen WHM-Instanzen sind weiterhin internet-exponiert. Eine seit 2020 aktive Threat-Actor-Gruppe namens Mr_Rot13 nutzt die Lücke, um eine sechs Jahre alte, in Go geschriebene Backdoor namens Filemanager zu deployen. Parallel verschlüsselt die .sorry-Ransomware nach Censys-Daten 8.859 Hosts; 7.135 davon sind cPanel/WHM-Systeme. Das deutsche CERT-Bund warnt offiziell. Zehn Tage später, am 7. Mai 2026, kündigt cPanel die zweite Notfall-TSR mit drei weiteren CVEs an — Patches seit 8. Mai verfügbar.

Das ist nicht der erste cPanel-Vorfall dieser Art, und es wird nicht der letzte sein. Die strukturelle Frage hinter zwei Notfall-Disclosures in zehn Tagen lautet: Wie lange läuft monolithische Hosting-Panel-Software mit Root-Privilegien als Internet-exponierter Daemon noch tragfähig? Die großen US-Hoster — hosting.com, Namecheap, KnownHost, HostPapa, InMotion — haben am 28. und 29. April mit dem Schlimmsten gerechnet und proaktiv die WHM-Ports per Firewall geschlossen. watchTowr-CEO Benjamin Harris fasst es so zusammen: "the alternative was watching their entire customer base get owned in real-time".

Dieser Beitrag ordnet ein, was passiert ist, wie der Angriff technisch funktioniert, was sofort zu tun ist und welche Alternativen es für Unternehmen gibt, die ihre Web-Präsenz nicht mehr in einem cPanel-Shared-Setup wissen wollen.

Inhaltsverzeichnis

• CVE-2026-41940 — der konkrete Anlass
• Wie der Angriff technisch funktioniert
• Zwei Monate Zero-Day — die Chronologie
• Mr_Rot13 und die parallelen Akteure
• 8. Mai — drei weitere CVEs in zehn Tagen
• Die strukturelle Frage: monolithische Legacy-Hosting-Software
• Sofortmaßnahmen für Server-Betreiber
• Welche Alternativen gibt es?
• NIS2 und persönliche Geschäftsführer-Haftung
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

CVE-2026-41940 — der konkrete Anlass

Am 28. April 2026 um 12:05 CST veröffentlicht cPanel das Advisory zu CVE-2026-41940. CVSS 9.8 nach NVD-v3.1, CVSS 9.3 nach v4. Klasse: CWE-306 (Missing Authentication for Critical Function). Konkret ein Authentifizierungs-Bypass im Session-Handling des cpsrvd-Daemons — des zentralen Web-Daemons, der auf den Ports 2082 bis 2096 sowohl die Kunden- als auch die Admin-Oberflächen aller cPanel/WHM-Server bedient.

Die Lücke ist nicht subtil. Ein einzelner manipulierter Basic-Authentication-Header mit eingeschleusten CRLF-Sequenzen reicht, um eine Session-Datei mit beliebigen Inhalten zu schreiben — inklusive user=root und tfa_verified=1. Mit anderen Worten: jeder kann sich als Root auf einem ungepatchten WHM-Server anmelden, ohne irgendeine Form von Zugangsdaten zu kennen, und die Zwei-Faktor-Authentifizierung wird im selben Schritt aushebelt.

Die watchTowr-Labs-Analyse vom 29. April formuliert die Reichweite trocken: "tens of thousands of servers managing a meaningful chunk of the internet". Rapid7- und Shodan-Daten beziffern die Zahl internet-exponierter cPanel-Instanzen weltweit auf rund 1,5 Millionen — bei rund 70 Millionen verwalteten Domains und einem Marktanteil von 22 bis 23 Prozent unter kommerziellen Hosting-Panels (Datanyze) ist die Lücke kein Nischenproblem.

CISA reagiert noch am Disclosure-Tag mit Aufnahme in den Known-Exploited-Vulnerabilities-Katalog und setzt für US-Bundesbehörden eine Patch-Deadline auf den 3. Mai 2026 — fünf Tage. Das deutsche CERT-Bund schließt sich mit einer eigenen Warnung an. Damit gilt die Schwachstelle für jeden NIS2-Pflichtigen im Geltungsbereich als "Stand der Technik bekannt" — was die Reaktionsfrist nicht erst mit dem Patch beginnt, sondern mit der Bekanntmachung in den Behörden-Feeds.

Wie der Angriff technisch funktioniert

Der Kern der Lücke ist eine ungewöhnlich elegante Verkettung von zwei Konstruktionsfehlern in cpsrvd.

Erstens — Pre-Auth-Session-File. Der Daemon schreibt die Session-Datei vor der Authentifizierung, nicht erst danach. Das ist historisch gewachsen: cPanel arbeitet seit jeher mit dateibasierten Sessions, und für bestimmte interne Routinen (Captcha-Tracking, Brute-Force-Schutz) braucht der Server eine Session-Hülse, bevor er weiß, wer der Aufrufer ist. Im Normalfall wird diese Hülse später durch die echten Auth-Daten überschrieben.

Zweitens — Caller-seitige Sanitization statt zentraler Bereinigung. Die CRLF-Filterung der Eingaben war nicht in der saveSession()-Funktion selbst implementiert, sondern wurde von jedem Caller individuell aufgerufen. Genau einer dieser Caller hat es vergessen. Genau dieser eine Pfad lässt sich von außen — vor Authentifizierung — über einen manipulierten Basic-Auth-Header erreichen.

Der Exploit besteht damit aus diesen Schritten, in dieser Reihenfolge:

1. CRLF-Injection in einen Authorization: Basic …-Header. Der Wert wird base64-dekodiert, in username:password zerlegt und teilweise in die Session-Datei geschrieben. Wer hier \r\n eingeschleust hat, schreibt eigene Zeilen in die Session-Datei — Schlüssel-Wert-Paare nach Wahl.
2. Cookie-Trick zur Bypass-Verschlüsselung. cPanel-Session-Cookies werden normalerweise verschlüsselt; der Daemon überspringt die Entschlüsselung jedoch bei malformed Cookies. Ein gezielt malformed Cookie liefert die unverschlüsselte Session-ID, die zur eben geschriebenen Datei gehört.
3. Promotion auf Root. In die Session-Datei werden user=root und tfa_verified=1 eingeschleust. Beim nächsten Request über denselben Cookie liest der Daemon die Datei, erkennt eine "gültige" Root-Session mit "abgeschlossener" 2FA — und behandelt den Aufrufer entsprechend.
4. Unauth Remote Root. Ab hier hat der Angreifer Zugriff auf das gesamte WHM-API mit Root-Rechten: anlegen von Hosting-Accounts, Manipulation aller Kunden-Sites, Shell-Zugriff über cPanel-Terminal, Lese-Zugriff auf jede gehostete Datenbank und jeden Mailspool.

Die saveSession()-Routine wurde in den gepatchten Versionen zentralisiert; die CRLF-Bereinigung ist jetzt Teil der Funktion selbst. Architektonisch löst das den unmittelbaren Fall, ändert aber nicht das Grundmuster — ein einziger Daemon-Prozess mit Root-Rechten auf Ports 2082 bis 2096, der seit 1996 wächst.

Zwei Monate Zero-Day — die Chronologie

Die Lücke ist nicht erst am 28. April brandgefährlich geworden. Die Telemetrie mehrerer Anbieter zeigt ein konsistentes Bild:

• 23. Februar 2026 (geschätzt): Erste Ausnutzung in freier Wildbahn. Mehrere unabhängige Telemetrie-Quellen — XLab/QiAnXin und Help Net Security zitieren denselben Zeitpunkt — datieren die früheste bestätigte Exploitation auf den 23. Februar.
• 28. April 2026, 12:05 CST: cPanel veröffentlicht das offizielle Advisory mit Patches für alle unterstützten Branches. Der Patch ist auf den meisten Servern mit aktiviertem Auto-Update binnen Stunden ausgerollt — auf Systemen mit manueller Update-Strategie nicht.
• 28. April 2026, später am Tag: Hosting-Provider hosting.com, Namecheap, KnownHost, HostPapa und InMotion blockieren proaktiv die WHM-Ports 2083 und 2087 in ihrer Edge-Firewall. watchTowr-CEO Benjamin Harris kommentiert die Reaktion so: "the alternative was watching their entire customer base get owned in real-time."
• 29. April 2026: watchTowr Labs veröffentlicht eine vollständige Root-Cause-Analyse mit Proof-of-Concept. CISA nimmt CVE-2026-41940 in den KEV-Katalog auf. CERT-Bund-Warnung erscheint.
• 3. Mai 2026: Federal-Agency-Patch-Deadline der CISA-Direktive läuft ab.
• 5. Mai 2026: Censys zählt 44.000 cPanel-Server mit Indikatoren der Mr_Rot13-Backdoor "Filemanager". Auf 7.135 Hosts liegt zusätzlich die .sorry-Ransomware-Extension.
• 7. Mai 2026: Zweite TSR-Pre-Disclosure mit drei weiteren CVEs (CVE-2026-29201/29202/29203).
• 8. Mai 2026, 12:00 EST: Patches für die zweite TSR-Serie veröffentlicht (cPanel/WHM 11.136.0.9 und Backports auf ältere Branches).

Das Zero-Day-Fenster beträgt damit etwa zwei Monate. Wer den eigenen WHM-Server in diesem Zeitraum mit offenen Ports 2083/2087 betrieben hat, muss von potenzieller Kompromittierung ausgehen — nicht von Schuld, aber von der Notwendigkeit forensischer Prüfung und Credential-Rotation.

Mr_Rot13 und die parallelen Akteure

Die mit Abstand interessanteste Threat-Actor-Geschichte hinter dem Massenhack ist Mr_Rot13. Die Gruppe wurde von Sicherheitsforschern bei XLab/QiAnXin namentlich ausgegraben und ist nach deren Einschätzung seit mindestens 2020 aktiv — also rund sechs Jahre. Die Detection-Rate über diesen Zeitraum stuft XLab als "extrem niedrig" ein. Sprachlich vorsichtig formulieren sie: "highly disciplined cyber espionage or organized cybercrime group".

Was die Gruppe nach CVE-2026-41940 deployt, ist eine cross-plattformige Backdoor namens Filemanager. Geschrieben in Go, statisch gelinkt, lauffähig auf Linux, Windows und macOS — und auf allen üblichen Architekturen. Drei Eigenschaften sind aus operativer Sicht bemerkenswert:

• Web-GUI für File-Management und Remote-Command-Execution. Die Backdoor exponiert eine eigene Web-Oberfläche auf einem konfigurierbaren Port, von der aus der Angreifer remote auf das Dateisystem zugreift und Befehle ausführt.
• bcrypt-basierte Auth. Die Backdoor selbst ist gegen unbefugte Drittnutzung abgesichert — kein Plaintext-Passwort im Netzwerk-Traffic, sondern bcrypt-Hashes. Operationale Security auf einem Niveau, das man im Massenhack-Umfeld selten sieht.
• Strukturierte Datenexfiltration. Bash-History, SSH-Keys, Geräteinformationen, Datenbank-Passwörter, cPanel-virtual-aliases (Mail-Forwarding-Konfigurationen, die Mail-Adressen und Empfänger zuordnen).

Die C2-Domain heißt wrned[.]com — eine bewusst an "warned" angelehnte, irreführende Schreibweise. Die Payload wird in Teilen von wpsock[.]com nachgeladen. XLab hat zudem einen Telegram-Kanal namens "0xWR" identifiziert, über den die Gruppe (laut Telemetrie eine Drei-Personen-Operation) Daten abzieht.

Mr_Rot13 ist aber nicht der einzige Akteur. Help Net Security hat aufgedeckt, dass mindestens fünf parallel laufende Operationen die Lücke ausnutzen:

• "Sorry"-Ransomware — ein in Go geschriebener Linux-Encryptor mit .sorry-Datei-Extension und Tox-Kontakt für die Lösegeldverhandlung. Censys-Scans zählen 8.859 Hosts mit .sorry-Dateien, davon 7.135 cPanel/WHM-Systeme.
• cPanelSniper — ein als Proof-of-Concept verteiltes Massen-Exploit-Tool, das die Lücke automatisiert sucht und ausnutzt.
• Mirai-Varianten — klassische Botnet-Recruiting-Operationen, die kompromittierte Server in DDoS-Schwärme einbinden.
• Cryptocurrency-Miner — opportunistische Monero-XMR-Miner als Zweitlast nach erfolgreichem Initialzugriff.
• Ctrl-Alt-Intel-Spionageakteur — Bezug zu indonesischen Verteidigungs-Trainings-Portalen und chinesischen Bahn-Daten; geographische Streuung der Ziele lässt staatsnahe Motivation vermuten.

Die Angreifer-IPs verteilen sich laut IT-Boltwise schwerpunktmäßig auf Deutschland, USA, Brasilien und Niederlande — Deutschland ist hier sowohl Quell- als auch Zielregion auffällig stark vertreten.

8. Mai — drei weitere CVEs in zehn Tagen

Am 7. Mai 2026 verschickt cPanel die zweite Notfall-TSR-Pre-Disclosure innerhalb von zehn Tagen. Drei weitere CVEs werden am 8. Mai um 12:00 EST publik gemacht:

Patch: cPanel/WHM ab 11.136.0.9 (plus Backports auf ältere Branches). Aktive Ausnutzung der drei neuen Lücken ist zum Disclosure-Zeitpunkt nicht bestätigt — bei einer Plattform, deren Authentifizierungs-Bypass aus April noch nicht überall geschlossen ist, ist das eine Frage von Tagen, nicht von Wochen.

Die Panelica-Analyse zur zweiten TSR formuliert das Strukturproblem trocken: "Two emergency TSRs in ten days is not a statistical anomaly. It reflects the ongoing security cost of running monolithic, legacy-architecture hosting software on internet-facing infrastructure at scale."

Genau das ist der Punkt, den die Hosting-Industrie aktuell intern diskutiert — und über den die meisten Endkunden bisher nichts gehört haben.

Die strukturelle Frage: monolithische Legacy-Hosting-Software

cPanel ist 1996 gestartet. Die Codebasis ist seitdem gewachsen — Perl, PHP, Shell-Scripts, später C-Anteile, eine Web-Oberfläche im Web-1.0-Stil, eine REST-API darüber, ein Reseller-Modell, virtuelle Mail-Server, DNS-Management, Backup-Integration, WordPress-Toolkit. Alles in einem Daemon-Prozess (cpsrvd) mit Root-Privilegien, der direkt auf öffentlichen Ports lauscht. Die Architektur ist nicht "schlecht designed" — sie ist organisch über drei Jahrzehnte gewachsen und trägt die Lasten dieser Geschichte.

Drei strukturelle Konsequenzen dieser Geschichte zeigen sich im aktuellen Vorfall:

Erstens — Pre-Auth-Code-Pfade haben Root. Der cpsrvd-Daemon muss jeden eingehenden Request zunächst lesen, Session-Hülsen schreiben, Captcha-Counter erhöhen, Rate-Limits verwalten — alles bevor klar ist, wer der Aufrufer eigentlich ist. Jeder Code-Pfad in diesem Pre-Auth-Bereich läuft mit Root-Rechten. Eine einzige vergessene Sanitization, wie bei CVE-2026-41940, reicht für Vollkompromittierung.

Zweitens — Service-Mesh ohne Privilege-Separation. Eine moderne Architektur würde Auth, Session-Management, Backup, Mail, DNS und WordPress in separate Prozesse mit minimalen Rechten zerlegen und über lokale Sockets oder einen Service-Mesh verbinden. Bei cPanel und ähnlichen Legacy-Panels (Plesk hat strukturell vergleichbare Probleme) sitzt all das im selben Prozess oder unter derselben uid.

Drittens — Mindshare-Verlust beschleunigt sich. PeerSpot-Daten zeigen einen Rückgang des cPanel-Mindshare unter Hosting-Käufern von 19,9 Prozent im Oktober 2024 auf 12,1 Prozent im Januar 2026 — ein Verlust von rund 40 Prozent in 15 Monaten. Die Plattform bleibt mit rund 23 Prozent installed base unter kommerziellen Panels weiterhin dominant, aber die Wachstumskurve hat sich gedreht. Wer heute eine Hosting-Architektur neu plant, plant in der Regel ohne cPanel.

Das ist der eigentliche Kontext der jüngsten Vorfälle. Eine Lücke wäre verschmerzbar; zwei in zehn Tagen werden zum Muster.

Sofortmaßnahmen für Server-Betreiber

Wer einen eigenen cPanel- oder WHM-Server betreibt — als Hoster, als Reseller, als Unternehmen mit eigener Plattform — sollte in dieser Reihenfolge handeln:

1. Patch-Stand prüfen.

/usr/local/cpanel/cpanel -V

Gepatchte Versionen pro Branch:

2. Force-Update einspielen.

/scripts/upcp --force
/scripts/restartsrv_cpsrvd

Bei aktivem Auto-Update ist der Patch in der Regel schon eingespielt — Prüfung trotzdem zwingend, weil Auto-Update bei Lizenzproblemen oder I/O-Engpässen still kippen kann.

3. Wenn Patch nicht sofort möglich.

# Firewall — Ports blocken (nftables-Beispiel)
nft add rule inet filter input tcp dport { 2082, 2083, 2086, 2087, 2095, 2096 } drop

# Oder Services stoppen
/scripts/restartsrv_cpsrvd --stop
/scripts/restartsrv_cpdavd --stop

Konkret blockieren sollte man die kompletten cPanel-Daemon-Ports (2082/2083 = User-cPanel, 2086/2087 = WHM, 2095/2096 = Webmail). Bei reinem Web-Hosting bleibt Apache/LiteSpeed auf 80/443 erreichbar.

4. Indikatoren für Kompromittierung prüfen.

• cPanel-eigenes Detection-Script (aus dem offiziellen Advisory verlinkt) ausführen — sucht nach bekannten Persistenz-Mechanismen.
• watchTowr-Detection-Tool (GitHub) — testet die Verwundbarkeit nicht-destruktiv von außen.
• Auf Mr_Rot13-Backdoor prüfen: ungewöhnliche Prozesse aus /tmp oder /var/tmp mit Go-Binary-Signatur, ungewöhnliche Listening-Ports, persistente Cron-Jobs mit Verweis auf wrned.com oder wpsock.com.
• Bash-History-Manipulation und neue SSH-Keys in /root/.ssh/authorized_keys prüfen.

5. Bei Verdacht auf Kompromittierung.

• Saubere Neuinstallation aus Pre-Februar-Backup ist der einzige sichere Pfad, da die Backdoor in unbekannten Pfaden persistieren kann.
• Alle Credentials rotieren: Root-Passwort, alle Kunden-cPanel-Passwörter, alle Datenbank-Passwörter, SSH-Keys, API-Keys, FTP-Passwörter.
• DSGVO-Meldung an die zuständige Aufsichtsbehörde innerhalb von 72 Stunden, sobald personenbezogene Daten potenziell betroffen sind (Art. 33 DSGVO). Bei NIS2-pflichtigen Einrichtungen zusätzlich BSI-Meldung.
• Forensik: Logs sichern, Memory-Dump anfertigen, externen Incident-Responder einbeziehen, wenn die eigene Kapazität nicht reicht.

Welche Alternativen gibt es?

Die Diskussion "Alternative zu cPanel" hat zwei Ebenen: die taktische (anderes Panel) und die strategische (anderes Hosting-Modell).

Taktisch — alternative Hosting-Panels

• Hestia Control Panel — Open-Source-Fork von VestaCP, aktiv gepflegt, deutlich schlankere Codebasis, Mail/DNS/Backup integriert. Realistische Alternative für Reseller, die das Panel-Modell behalten wollen.
• ISPConfig — etabliertes deutsches Open-Source-Panel, häufig bei Webagenturen mit eigenem Server-Park.
• Froxlor — Open Source, vergleichsweise schlank, gut für kleine Setups.
• CloudPanel — aus Deutschland, fokussiert auf Performance (NGINX statt Apache), kostenfrei nutzbar, klare Architektur.
• Plesk — proprietäre Alternative, dieselbe Architektur-Familie wie cPanel, ebenfalls mit Schwachstellen-Historie, aber kommerziell besser supportet.

Wer Plesk produktiv betreibt und hohe Last-Anforderungen oder Agentur-Workflows hat, ist mit unserem High-Scale Webhosting auf dedizierter Hardware und mit verwaltetem Plesk-Stack gut bedient — wir übernehmen Plesk-Wartung, CVE-Monitoring und Hardening als Standard.

Strategisch — Hosting-Modelle ohne Panel

Für viele Unternehmen ist die wahre Antwort auf cPanel-Vorfälle nicht "anderes Panel", sondern "kein Panel". Das geht in mehreren Spielarten:

• Direkt verwalteter LAMP- oder LEMP-Stack auf einer eigenen VM bei einem EU-Hoster. NGINX oder Caddy als Web-Server, Let's-Encrypt-Zertifikate vollautomatisch, WordPress oder ein anderes CMS direkt installiert. Keine Internet-exponierte Panel-Software. Wartung über Ansible-Playbooks oder einen Managed-Service.
• Container-Hosting auf Coolify — Open-Source-PaaS, Self-Hostable, deployt einzelne Anwendungen in Docker-Containern, Web-UI für Deploy-Management. Architektur-Vorteil: Coolify-Daemon und WordPress-Container sind getrennt; ein Bug im Panel kompromittiert nicht automatisch alle Sites.
• Statische Sites mit Headless-CMS — Gatsby, Astro, Hugo oder Next.js als Generator, Inhalte aus einem entkoppelten CMS, ausgeliefert über CDN oder einfache NGINX-Instanz. Geringste Angriffsfläche, ideale Performance.
• Private Cloud auf Proxmox bei Hetzner oder netcup — eigene VM pro Workload, klare Privilege-Separation, keine Shared-Tenancy zwischen Kunden, voller Root-Zugriff für Audit und Forensik.

Für reine WordPress-Hosting-Anforderungen lohnt sich häufig der direkte Sprung auf Managed WordPress mit klar getrennten Containern statt eines Panel-Setups. Die Migration aus einem cPanel-Shared-Hoster zu einem solchen Setup ist mit DNS-Schwenk und Mail-Migration in der Regel ein Wochenend-Projekt — vorausgesetzt, jemand übernimmt die Choreografie.

NIS2 und persönliche Geschäftsführer-Haftung

Das deutsche NIS2-Umsetzungsgesetz wirkt im konkreten cPanel-Fall an drei Stellen:

Artikel 21 — Cybersicherheits-Risikomanagement. Patch-Management, Reaktion auf bekannte Schwachstellen, dokumentierte Reaktionsprozesse, Lieferanten-Risikomanagement (auch in Bezug auf den Hosting-Anbieter). Wer einen kompromittierbaren cPanel-Server im Geltungsbereich betreibt, ohne dokumentierten Patch-Workflow und ohne nachweisliche Reaktion auf die CERT-Bund-Warnung vom 29. April, hat im Audit ein Problem.

Artikel 23 — Meldepflichten. Bei "erheblichem" Sicherheitsvorfall ist eine Frühwarnung binnen 24 Stunden zu erstatten, ein vollständiger Bericht binnen 72 Stunden. Massenkompromittierung über CVE-2026-41940 mit Datenabfluss erfüllt das Kriterium spätestens, wenn Kundenmail-Vaults oder Datenbankinhalte abgegriffen wurden.

Haftung. Bußgelder bis 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes. Persönliche Haftung der Geschäftsleitung gegenüber dem Unternehmen — eine zivilrechtliche Innenhaftung, die nicht durch D&O-Versicherungen abgedeckt werden muss. Wer nachweisen kann, dass ein dokumentierter Patch-Workflow existierte und im konkreten Fall fristgerecht ausgelöst wurde, steht im Audit gut da. Wer das nicht kann, hat ein Problem.

Praktisch heißt das: Ein Pre-Audit-Befund "CVE-2026-41940 ungepatcht zwei Wochen nach CERT-Bund-Warnung" wird in NIS2-Compliance-Reviews dieses Jahres zu einem Standardpunkt. Vorbeugen ist deutlich billiger als die Korrektur unter Auditor-Beobachtung.

Parallel zu NIS2 wirken DSGVO-Meldepflichten bei Datenabfluss. Eine kompromittierte cPanel-Instanz, die personenbezogene Daten gehostet hat — Kundendaten von Mandantensystemen, Mail-Konten mit Klartext-Passwörtern, Webshop-Datenbanken — löst die 72-Stunden-Frist nach Art. 33 DSGVO aus. Die Aufsichtsbehörden gehen mit unklaren Sachverhalten zunehmend strenger um.

Unser Vorgehen bei WZ-IT

Wir bieten Managed Hosting ohne cPanel-Lock-in über mehrere Wege an — abhängig davon, was am Ende für Ihren Use Case sinnvoll ist:

Managed Hosting auf eigener Infrastruktur in Deutschland. Open-Source-Stack: NGINX oder Caddy als Web-Server mit automatischer Let's-Encrypt-Erneuerung, WordPress oder anderes CMS direkt auf der VM oder containerisiert, Mail über einen separaten verwalteten Mailserver. Kein Panel-Daemon mit Root als Internet-exponierte Angriffsfläche.

Private Cloud auf Proxmox bei Hetzner oder netcup. Eigene VM pro Workload, klare Privilege-Separation, EU-Hosting für DSGVO-Konformität, Backup-Architektur mit Pull-basierter Offsite-Replikation für Ransomware-Sicherheit. Dokumentierte RTO/RPO, regelmäßige Restore-Tests.

Plesk auf dedizierter Hardware für Agenturen. Über unser High-Scale Webhosting — für Hosting-Setups mit 50 bis 500 verwalteten Domains, bei denen das Panel-Modell weiterhin organisatorisch sinnvoll ist. Plesk-Wartung, CVE-Monitoring, Hardening und WordPress-Toolkit-Verwaltung übernehmen wir vollständig.

CVE-Monitoring als Standard. Tägliche Prüfung gegen NVD, CISA-KEV, BSI-Warnungen und Vendor-Feeds. CVE-2026-41940 wäre bei unseren Kunden innerhalb von Stunden nach Disclosure am 28. April mitigiert gewesen — entweder durch sofortigen Patch oder durch Port-Block bis zur Verifikation. Dokumentation jeder Reaktion als Anlage zur NIS2-Risikomanagement-Doku.

Migration aus cPanel-Shared-Hosting. DNS-Schwenk-Choreografie, Mail-Migration (IMAP-Übernahme oder Mailbox-Sync), parallel laufende Übergangsphase, Cleanup der alten Umgebung. Typische Migration einer KMU-Site mit 5 bis 15 Mailkonten ist in zwei bis fünf Werktagen abgeschlossen, ohne nennenswerte Downtime.

Konkret im Bleeding-Edge-Fall. Wer aktuell auf einem cPanel-Server mit Verdacht auf Kompromittierung sitzt, sollte den Server nicht einfach patchen, sondern aus dem produktiven Verkehr nehmen, Backup aus Pre-Februar-2026 zurückspielen und parallel die Migration auf eine moderne Hosting-Umgebung aufsetzen. Wir übernehmen die Cutover-Logistik so, dass keine durchgehende Downtime entsteht.

Weiterführende Guides

• Managed Services auf eigener Infrastruktur (BYOI) — Hosting-Betrieb ohne Vendor-Lock-in, auf Ihrer Hardware oder unserer
• High-Scale Webhosting mit Plesk — wenn Panel-Modell organisatorisch nötig bleibt
• CVE-Monitoring als Managed Service — automatisierte Reaktion auf NVD, CISA-KEV und BSI-Feeds
• Private Cloud auf Proxmox — Alternative zum Shared-Hosting mit klarer VM-Separation
• Proxmox auf Hetzner — souveräne EU-Hosting-Basis mit kalkulierbarer Kosten-Struktur
• Hetzner Server-Wartung auslagern — was Managed-Operations konkret leistet
• Cisco ASA, ArcaneDoor & CVE-2025-20362 — moderner VPN-Stack — gleiches Muster bei Edge-Appliances
• Bleeding Llama (CVE-2026-7482) — gleiches Muster bei Self-Hosted-AI
• Linux-Kernel-Schwachstellen 2026 — Patch-Management Chefsache — NIS2-Kontext und Geschäftsführer-Haftung
• Coolify CVE-Sicherheitslücken Update 2025/2026 — wie sicheres Container-PaaS funktioniert

Sie betreiben eine Website oder einen Server unter cPanel oder Plesk — und sind sich nach den letzten zwei Wochen unsicher, ob das mit Patches und Hoster-Vertrauen weitergeführt werden kann? Wir prüfen Ihre aktuelle Architektur kostenfrei und liefern eine konkrete Migrations-Empfehlung mit Aufwandsschätzung und Compliance-Bewertung — pauschal pro Site oder pro Server, mit oder ohne Übergangs-Parallelbetrieb.

Kostenloses Hosting-Architektur-Review buchen · Zu Managed Services BYOI · CVE-Monitoring