Julia Wolf 
Eine CRLF-Injection in cPanel und WHM, CVSS-Score 9,8, seit Februar 2026 als Zero-Day aktiv – und rund 44.000 Server bereits kompromittiert. Die „Sorry“-Ransomware macht ihrem Namen alle Ehre: Sie verschlüsselt, fordert Lösegeld, und hinterlässt Backdoors, die niemand sucht. Willkommen im Hosting-Backend, dem neuen Lieblingseingang der organisierten Cyberkriminalität.
Stellen Sie sich vor, Sie wollen in eine Wohnanlage einbrechen. Sie könnten jede Wohnung einzeln aufbrechen. Oder Sie stehlen den Schlüssel des Hausmeisters. cPanel ist dieser Hausmeisterschlüssel – zentralisiert, weit verbreitet, und wenn er fällt, fallen gleich alle Türen dahinter.
cPanel und WHM (Web Host Manager) verwalten weltweit Millionen von Websites und Servern. Jede Instanz ist ein Kontrollzentrum: E-Mails, Datenbanken, DNS-Einträge, FTP-Zugänge, SSL-Zertifikate. Wer Root-Zugriff auf einen cPanel-Server hat, hat de facto die gesamte dort gehostete Infrastruktur in der Hand. Das macht cPanel Hosting zu einem Ziel erster Güte – nicht trotz seiner Verbreitung, sondern genau deswegen.
Die Lücke CVE-2026-41940 trifft den Kern dieser Architektur. Sie sitzt im cpsrvd-Dienst, dem zentralen Daemon, der Anfragen im cPanel-Backend verarbeitet. Konkret handelt es sich um eine CRLF-Injection – eine Schwachstellenklasse, die älter ist als mancher Hosting-Kunde, und die dennoch immer wieder ihren Weg in produktive Software findet. Das Pikante daran: Für einen erfolgreichen Angriff ist keinerlei Authentifizierung notwendig. Unauthentifizierter Root-Zugriff. CVSS 9,8. Höher geht die Skala nicht.
Zum Vergleich: Der Sicherheitsblog BornCity dokumentiert umfangreich, wie schnell sich diese Lücke zur Massenwaffe entwickelte. Und „Massenwaffe“ ist hier keine Übertreibung – die Shadowserver Foundation registrierte bereits 44.000 kompromittierte IP-Adressen. Gleichzeitig gelten laut verschiedenen Recherchen noch rund 1,5 Millionen cPanel- und WHM-Instanzen als ungepacht und damit potenziell verwundbar.
Das ist kein Nischenproblem. Das ist Hosting-Infrastruktur im freien Fall.
Hier beginnt die Geschichte richtig unangenehm zu werden. CVE-2026-41940 wurde nicht erst entdeckt und dann ausgenutzt – die Reihenfolge war umgekehrt.
Seit Februar 2026 nutzten Angreifer die Schwachstelle aktiv als Zero-Day aus. Das bedeutet: Kein Patch existierte, keine CVE-Nummer war veröffentlicht, kein Administrator wusste, wonach er suchen sollte. Der Patch erschien am 28. April 2026. Zwischen erstem bekanntem Exploit und verfügbarem Fix lagen also knapp zwei Monate.
Zwei Monate, in denen automatisierte Exploit-Frameworks die gesamte im Netz exponierte cPanel-Infrastruktur systematisch abscannen und kompromittieren konnten. Zwei Monate ungehinderter Angriffsmöglichkeiten gegen Systeme, die Tausende von Websites hosten. Wenig überraschend, dass die Schadensbilanz entsprechend drastisch ausfällt.
Die CISA – die US-amerikanische Cybersicherheitsbehörde – reagierte mit einer Eilanordnung und setzte bundesbehördlichen Stellen eine Frist zur Implementierung des Patches. Dieser Schritt ist nicht standardmäßig; er signalisiert, dass die Behörde aktive Ausnutzung im kritischen Bereich beobachtet. Wer die CISA-Frist kennt, weiß: Wenn dort jemand eine Deadline setzt, brennt es bereits.
Geografisch trifft es keine bestimmte Region besonders – unter den gefährdetsten Systemen befinden sich Server in den USA, Frankreich, Deutschland und Großbritannien. Das entspricht schlicht der globalen Verteilung von cPanel-Hosting-Providern. Hosting ist ein internationales Geschäft; Ransomware kennt keine Grenzen. Mehr Kontext liefert Cybersecurity 2024 Trends: BEC und Ransomware im Fokus.
CRLF-Injection klingt harmlos. Carriage Return, Line Feed – das sind Steuerzeichen aus der Frühzeit der Computerei. In der Webentwicklung bedeutet eine CRLF-Injection, dass Angreifer diese Steuerzeichen in HTTP-Antworten oder Log-Einträge einschleusen können, um Header zu manipulieren oder Protokolleinträge zu fälschen. Wenn das im falschen Kontext passiert, kann es zur vollständigen Authentifizierungsumgehung führen.
Im Fall von cPanel läuft der Angriff laut verfügbaren Analysen in mehreren Stufen ab. Zuerst identifizieren Angreifer verwundbare Instanzen – Shodan und ähnliche Reconnaissance-Tools machen cPanel-Server im Netz sichtbar wie bunte Weihnachtsbaumkugeln. Danach erfolgt Session-Minting und Cache-Propagation, um die Authentifizierung zu umgehen und Root-Zugriff zu erlangen. Ist der Zugriff einmal da, werden 4096-Bit-RSA-Schlüssel in die authorized_keys-Datei eingetragen. Persistenz. Solide, langfristige Persistenz.
Ab diesem Punkt hat der Angreifer die Wahl: Account-Übernahme, Remote-Code-Ausführung, oder beides. Für die Sorry-Ransomware-Kampagne bedeutet das konkret: Alle erreichbaren Dateien verschlüsseln, Lösegeldforderung hinterlassen, und still die Hintertür für spätere Besuche offenlassen.
Das Python-basierte Exploit-Framework namens „cPanelSniper“ automatisiert diesen Prozess vollständig. Identifikation verwundbarer Systeme, Exploit-Ausführung, Kontrollübernahme – weitgehend ohne manuellen Aufwand. Wer das Framework bedient, muss kein Experte sein. Er muss nur wissen, wo er es herbekommt. Das senkt die Einstiegshürde für Angreifer auf ein erschreckendes Minimum.
Honeypot-Daten zeigen, dass einzelne Sensoren innerhalb von 48 Stunden Hunderte Exploit-Versuche registrierten. Der Ansturm auf verwundbare cPanel-Instanzen war also nicht sporadisch – er war industriell.
Der Name ist Programm, oder besser: Der Name ist Hohn. „Sorry“ – das ist die Nachricht, die Opfer auf ihren kompromittierten Systemen vorfinden, bevor sie die Lösegeldforderung lesen.
Sorry ist in der Programmiersprache Go geschrieben. Das ist mittlerweile eine Art Industriestandard bei moderner Ransomware – Go-basierte Malware ist plattformübergreifend kompilierbar, schwerer zu analysieren als C-basierter Code, und lässt sich schnell aktualisieren. Die Verschlüsselungskombination aus ChaCha20 für symmetrische Datenverschlüsselung und RSA-2048 für die Schlüsselübertragung ist technisch robust. Ohne den privaten Schlüssel der Angreifer ist eine Entschlüsselung ohne erheblichen Aufwand nicht realistisch.
Verschlüsselte Dateien erhalten die Endung .sorry – damit sind sie auf einen Blick identifizierbar. Die Lösegeldforderungen bewegen sich laut verfügbaren Berichten zwischen 6.500 und 7.000 Euro, was etwa 0,3 Bitcoin entspricht – wobei der genaue Betrag naturgemäß von Kurs und individuellem Opfer abhängen kann. Kommuniziert wird über Tox, eine dezentrale Messaging-Plattform, die keine zentralen Server benötigt und damit Strafverfolgern wenig Angriffsfläche bietet.
Plot Twist: Der eigentliche Schaden liegt nicht in der Verschlüsselung. Er liegt in dem, was nach der Verschlüsselung noch im System steckt. Wie erwähnt hinterlassen die Angreifer persistente SSH-Schlüssel. Wer also das Lösegeld zahlt und glaubt, das Problem sei damit erledigt, irrt. Die Backdoor bleibt. Ein vollständiger System-Audit, im Zweifelsfall ein komplettes Redeployment, ist das Minimum an Reaktion, das sinnvoll ist.
Ehrlich gesagt ist die Lösegeldhöhe von rund 6.500 bis 7.000 Euro eine Art bewusste Kalibrierung: niedrig genug, dass viele Opfer – insbesondere kleinere Hosting-Anbieter oder Reseller – die Zahlung als günstigere Option gegenüber wochenlangem Ausfall betrachten. Klassisches Erpressungsdesign, perfektioniert über Jahre von Ransomware-Gruppen weltweit.
Die Sorry-Ransomware-Kampagne ist das Hauptkapitel dieser Geschichte – aber nicht das einzige. Die cPanel-Krise hat eine Welle von Begleitangriffen ausgelöst, die zeigt, wie Angreifer kompromittierte Hosting-Infrastruktur als Sprungbrett nutzen.
Am 1. Mai 2026 traf eine massive DDoS-Attacke die Ubuntu-Archive. Über 3,5 Terabit Traffic pro Sekunde, rund 23 Stunden Dauer. Zur Einordnung: Das ist kein kleines Botnet. Das setzt Infrastruktur voraus, die bereits kompromittiert ist und als verteiltes Angriffsnetz funktioniert. Ob diese Attacke direkt den cPanel-Angriffen zuzurechnen ist, ist laut verfügbaren Quellen nicht eindeutig belegt – aber zeitlich und kontextuell fällt sie in dieselbe Kampagnenwelle. Mirai-basierte Botnet-Varianten wurden im Zusammenhang mit cPanel-Angriffen dokumentiert.
Parallel dazu lief eine Lieferketten-Attacke über npm-Pakete. Die Gruppe, die unter dem Namen TeamPCP firmiert, soll dabei über 1.100 Repositories kompromittiert haben – ein Angriff, der als „Mini Shai-Hulud“ bezeichnet wird. Kompromittierte Hosting-Server als Sprungbrett für Paket-Poisoning in der Entwickler-Infrastruktur: Das ist Supply-Chain-Angriff in seiner modernsten Form. BornCity hat die technischen Details der begleitenden Angriffskampagnen umfassend aufgezeichnet.
Dazu kommen AWS S3-Angriffe mit 1.229 gestohlenen Zugangsschlüsseln und Lösegeldforderungen von rund 25.000 Euro. Und ein Datenschutzvorfall beim Cookeville Regional Medical Center, bei dem 337.917 Patientendatensätze betroffen sein sollen, mit einer Forderung von 10 Bitcoin – zum Zeitpunkt der Berichte etwa 1,15 Millionen Euro. Ob jeder dieser Vorfälle direkt auf cPanel zurückzuführen ist, ist nicht für alle abschließend belegt. Aber sie zeigen das Ökosystem: Wer Hosting-Infrastruktur kontrolliert, kontrolliert ein Sprungbrett in viele weitere Systeme.
Nicht alle Angreifer wollen Geld. Einige wollen Daten. Einige wollen beides. Und einige nutzen Ransomware als Cover für etwas Brisanteres.
Dokumentiert sind Fälle, in denen Advanced Persistent Threat-Gruppen die cPanel-Lücke mit weiteren Zero-Days kombinieren, um gezielt Regierungs- und Militäreinrichtungen in Südostasien anzugreifen. In einem dokumentierten Fall wurde neben CVE-2026-41940 auch eine SQL-Injection-Schwachstelle gegen ein indonesisches Verteidigungsportal eingesetzt. Erbeutet wurden dabei laut Berichten 4,37 Gigabyte Daten, darunter sensible Infrastruktur- und Bahndaten.
Das ist kein opportunistisches Ransomware-Deployment. Das ist gezielte Spionage-Operation, die eine weit verbreitete Schwachstelle als initialen Zugangspfad nutzt. Der Clou dabei: Wer als Opfer nur „Sorry“-Dateien auf dem Server sieht, denkt an Ransomware-Kriminelle. Dass parallel Daten exfiltriert wurden, fällt oft erst im Nachhinein auf – wenn überhaupt.
Diese Vermischung von finanziell motivierten Angriffen und staatlich gesponserter Spionage ist eines der zentralen Merkmale moderner Bedrohungslandschaften. Es macht Attribution schwerer und Verteidigung komplexer. Der Ransomware-Angriff ist sichtbar. Die Datenexfiltration darunter bleibt oft unsichtbar.
Für Unternehmen, die kritische Daten auf cPanel-basierter Hosting-Infrastruktur lagern, stellt sich damit eine unbequeme Frage: Wissen Sie eigentlich, was in den letzten Monaten auf Ihren Servern passiert ist? Nicht was jetzt passiert – was damals passiert ist, als der Zero-Day noch kein Zero-Day war, weil niemand davon wusste?
Die cPanel-Krise trifft nicht nur große Hosting-Provider. Sie trifft auch jeden, der cPanel oder WHM selbst betreibt – als VPS-Lösung, als Managed Server oder als Teil eigener Hosting-Infrastruktur. Self-Hosting-Security war noch nie ein Selbstläufer, aber CVE-2026-41940 macht das Thema akut.
Der erste Schritt ist simpel, aber offenbar für viele Betreiber noch nicht erfolgt: den Patch vom 28. April 2026 einspielen. Das klingt banal. Aber wenn 1,5 Millionen Instanzen noch immer ungepacht sind – Wochen nach Veröffentlichung des Patches – dann ist „Patchen ist selbstverständlich“ leider kein realistisches Bild der Praxis.
Was muss nach einem möglichen Angriff passieren? Hier eine Mindest-Checkliste:
Das ist kein übertriebener Aufwand. Das ist das Minimum, wenn man die Persistenz-Mechanismen ernst nimmt, die im Rahmen dieser Angriffskampagne dokumentiert wurden.
Wenn Sie Ihre Website oder Anwendung bei einem Hosting-Provider betreiben, der cPanel oder WHM einsetzt, dann sind Sie potenziell betroffen – auch wenn Sie selbst nichts falsch gemacht haben. Die Verantwortung für das Patching liegt beim Provider. Aber das entbindet Sie nicht von der Pflicht zu fragen.
Konkrete Fragen, die Sie Ihrem cPanel Hosting-Anbieter stellen sollten:
Provider, die auf diese Fragen mit Ausweichen, Generalberuhigungen oder Schweigen reagieren, sagen damit eigentlich alles, was man wissen muss. Wenig überraschend: Hosting ist ein hartumkämpfter Markt mit engen Margen, und Sicherheits-Investitionen werden dort nicht selten als Kostenstelle wahrgenommen. Das ändert sich dann, wenn Ransomware zum Kostenfaktor wird – leider oft zu spät.
Ein ISO 27001-Zertifikat beim Hosting-Provider ist kein Allheilmittel, aber es ist ein Indikator dafür, dass Sicherheitsprozesse strukturiert vorhanden sind. Hosting ISO 27001-Zertifizierungen umfassen typischerweise Patch-Management-Prozesse, die genau solche Szenarien adressieren sollen. Wer Hosting ISO 27001-Standards einhält, hat zumindest theoretisch einen Prozess, der das zeitnahe Einspielen kritischer Patches vorschreibt. In der Praxis ist die Umsetzungsqualität variabel – aber es ist ein Ausgangspunkt für Gespräche.
Die Verbindung zwischen kompromittiertem Hosting und Supply-Chain-Angriffen ist kein Zufall. Sie ist Strategie.
Wer einen Hosting-Server kontrolliert, auf dem Entwickler-Tools, CI/CD-Systeme oder Package-Registries betrieben werden, kontrolliert potenziell die gesamte Software-Lieferkette dahinter. Die npm-Kampagne im Zusammenhang mit dem cPanel-Vorfall zeigt, wie das in der Praxis aussieht: Kompromittierte Server werden zum Startpunkt für Package-Poisoning, bei dem legitime Pakete mit Malware verseucht und an ahnungslose Entwickler verteilt werden.
Das ist der Albtraum jedes Security-Teams: Nicht der direkte Angriff auf die eigene Infrastruktur, sondern der Angriff auf die Infrastruktur, der man vertraut. Eine Dependency in einem npm-Paket, die plötzlich Schadcode enthält – eingebettet von Angreifern, die Monate zuvor einen cPanel-Server geentert haben.
Für Entwickler und DevOps-Teams bedeutet das: Die Sicherheitskette reicht über die eigene Infrastruktur hinaus. Software Composition Analysis (SCA), das systematische Überprüfen von Abhängigkeiten auf bekannte Schwachstellen oder unerwartete Änderungen, ist kein optionales Nice-to-have. Es ist Teil der Grundhygiene.
Und für alle, die Hosting als rein passiven Infrastruktur-Layer betrachten: Das war einmal. Hosting ist heute aktive Angriffsfläche – sowohl als direktes Ziel als auch als Sprungbrett in andere Systeme. Die Zeiten, in denen man dem Provider vertraute und sich nicht weiter darum kümmerte, sind endgültig vorbei.
Ein beträchtlicher Teil der auf cPanel gehosteten Websites läuft unter WordPress oder anderen Content-Management-Systemen. Das ist insofern relevant, als cPanel-Zugriff nicht nur den Server selbst öffnet – er öffnet auch alle Datenbanken, alle Dateiverzeichnisse, alle Konfigurationsdateien der dort betriebenen Websites.
Sicheres WordPress Hosting ist deshalb mehr als die Frage, ob WordPress selbst aktuell gehalten wird. Es beginnt bei der Frage, auf welcher Infrastruktur WordPress läuft. Ein perfekt gepatchtes WordPress auf einem kompromittierten cPanel-Server ist so sicher wie ein gepanzertes Fahrzeug mit offener Heckklappe.
Konkret bedeutet das für WordPress-Betreiber: Prüfen Sie, ob Ihr Hosting-Provider cPanel einsetzt. Wenn ja, stellen Sie die oben genannten Fragen. Prüfen Sie, ob Ihre WordPress-Datenbank-Passwörter, Ihre wp-config.php-Dateien oder andere sensible Konfigurationsdaten kompromittiert sein könnten. Bei einem bestätigten cPanel-Vorfall reicht es nicht, das CMS zu sichern – die gesamte Hosting-Umgebung muss als potenziell kompromittiert betrachtet werden.
WordPress-Security-Plugins können vieles leisten. Sie können einen kompromittierten Hosting-Layer nicht kompensieren. Das ist eine strukturelle Grenze, die kein Plugin überwindet.
VPS-Hosting wird oft als sicherere Alternative zu Shared Hosting vermarktet – mehr Kontrolle, isolierte Umgebung, eigene Ressourcen. Das stimmt, soweit es geht. Aber CVE-2026-41940 zeigt, wo die Grenzen dieser Kontrolle liegen.
Wer einen VPS mit cPanel betreibt, ist direkt betroffen. Der VPS bietet Isolation auf Ressourcenebene – aber wenn das Management-Interface selbst die Schwachstelle ist, hilft die beste Virtualisierung nicht weiter. Root-Zugriff über eine Lücke im Management-Tool überwindet Isolation vollständig.
Das gilt auch für Managed-VPS-Angebote, bei denen der Provider cPanel oder WHM als Verwaltungsoberfläche bereitstellt. Hier liegt die Patch-Verantwortung beim Provider. Der Kunde sieht die Verwaltungsoberfläche, aber nicht die darunterliegende Infrastruktur. Vertrauen ist gut. Vertrauen plus konkrete Fragen ist besser.
Wer maximale Kontrolle über seine Hosting-Sicherheit haben möchte, kommt nicht umhin, sich mit den technischen Details seiner Infrastruktur auseinanderzusetzen – oder einen Provider zu wählen, der das transparent kommuniziert und belegbar umsetzt. Die Idee, dass „Managed“ automatisch „sicher“ bedeutet, hat CVE-2026-41940 eindrücklich widerlegt. Mehr Kontext liefert Aktive Cyberabwehr: Was das neue Gesetz technisch bedeutet.
Was diese cPanel-Krise von früheren Schwachstellen-Ausnutzungen unterscheidet, ist der Grad der Automatisierung auf Angreifer-Seite. Das Exploit-Framework „cPanelSniper“ ist nicht das erste seiner Art – aber es illustriert einen Trend, der die gesamte Cybersecurity-Branche seit Jahren beschäftigt: Angriffe, die früher spezialisiertes Know-how erforderten, werden zur Commodity.
Ein automatisiertes Framework, das verwundbare cPanel-Instanzen identifiziert, den Exploit ausführt, Persistenz einrichtet und Ransomware deployed – das ist kein Angriff einer hochspezialisierten Gruppe mehr. Das ist ein Werkzeug, das potenziell von jedem mit den richtigen Verbindungen eingesetzt werden kann. Oder, um im Bild zu bleiben: Das ist kein Meisterdieb, der Schlösser knackt. Das ist ein industrieller Schlüsselduplizierer, der Tausende Kopien macht.
Diese Demokratisierung von Angriffswerkzeugen ist einer der Gründe, warum Patch-Management keine akademische Disziplin ist, sondern operativer Überlebensfaktor. Wenn ein Framework innerhalb von 48 Stunden Hunderte Exploit-Versuche gegen einzelne Honeypots schickt, dann ist die Zeitspanne zwischen Patch-Veröffentlichung und erfolgreicher Ausnutzung ungepatchter Systeme keine Frage von Wochen mehr – sie ist eine Frage von Stunden.
Das verändert das Kalkül. „Wir patchen im nächsten Maintenance-Window“ war schon früher keine optimale Strategie. Bei CVSS 9,8 und laufender aktiver Ausnutzung ist es eine Einladung.
Je nach Position in der Hosting-Wertschöpfungskette sind unterschiedliche Maßnahmen relevant. Hier eine strukturierte Übersicht:
Für Unternehmen, die personenbezogene Daten auf cPanel-Hosting-Infrastruktur verarbeiten, ist CVE-2026-41940 nicht nur ein technisches Problem – es ist möglicherweise ein Datenschutzvorfall im Sinne der DSGVO.
Artikel 33 DSGVO verpflichtet Verantwortliche, Datenschutzverletzungen innerhalb von 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde zu melden, sofern die Verletzung voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen darstellt. Eine erfolgreiche Kompromittierung eines Servers, auf dem Kundendaten liegen, fällt typischerweise unter diese Definition.
Das bedeutet konkret: Wer durch forensische Analyse oder Provider-Kommunikation erfährt, dass sein cPanel-Server möglicherweise im Februar-Mai 2026 kompromittiert wurde, hat eine Meldepflicht zu prüfen. Das ist keine Frage von „ob das schlimm genug war“ – das ist eine gesetzliche Anforderung, die Fristen hat und bei Nichterfüllung eigene Bußgeldrisiken mit sich bringt.
Hosting-Provider selbst agieren in dieser Konstellation typischerweise als Auftragsverarbeiter. Ihre vertragliche Verpflichtung, Kunden bei Datenschutzverletzungen zu unterstützen, ist in der DSGVO und in Auftragsverarbeitungsverträgen geregelt. Wer als Provider jetzt schweigt, riskiert nicht nur Reputationsschaden, sondern potenziell auch Vertragsbruch und Haftungsfragen.
Der Hinweis sei deutlich gegeben: Die konkrete rechtliche Einschätzung für den eigenen Fall gehört in die Hände von Datenschutzbeauftragten oder Rechtsberatern, nicht in einen Magazinartikel. Aber die Sensibilität für das Thema sollte spätestens jetzt vorhanden sein.
CVE-2026-41940 ist kein Einzelfall. Es ist ein Symptom einer strukturellen Herausforderung: Hosting-Backend-Software ist hochkomplex, weit verbreitet und oft nicht im Fokus von Sicherheitsaudits, die sich auf Applikationsschicht und Perimeter konzentrieren.
cPanel verwaltet weltweit Millionen von Servern. Plesk tut es. DirectAdmin tut es. Und jede dieser Verwaltungsplattformen ist ein potenzielles Single Point of Failure, das bei einer kritischen Schwachstelle Massenangriffe ermöglicht. Das ist keine Kritik an den Produkten per se – Komplexität erzeugt Schwachstellen, das ist unvermeidlich. Aber es ist ein Argument dafür, Hosting-Backend-Software mit derselben Security-Sorgfalt zu behandeln wie produktive Applikationen.
Patch-Management muss für diese Systeme priorisiert und automatisiert sein. Monitoring muss auch auf der Infrastrukturebene stattfinden, nicht nur auf Applikationsebene. Und Incident-Response-Pläne müssen den Fall eines kompromittierten Management-Interfaces explizit adressieren.
Die Realität der meisten mittelgroßen Hosting-Umgebungen sieht anders aus. Patches werden manuell eingespielt. Monitoring ist auf Verfügbarkeit, nicht auf Sicherheit ausgerichtet. Und Incident Response beginnt erst, wenn Kunden Beschwerden einreichen. Das ist das Einfallstor. Nicht die Schwachstelle selbst – sondern die Reaktionsgeschwindigkeit darunter.
Die cPanel-Krise ist insofern auch ein Weckruf für die Hosting-Branche insgesamt. Wer Hosting-Services anbietet, übernimmt Verantwortung für die Sicherheit der darauf aufbauenden Infrastruktur. Diese Verantwortung endet nicht mit der Bereitstellung von Server-Ressourcen. Sie umfasst Security-Monitoring, schnelles Patch-Management und transparente Kommunikation im Ereignisfall. Einen guten Überblick über die Schwachstelle und ihre Auswirkungen bietet auch Dr. Web.
Der Patch für CVE-2026-41940 ist draußen. Das ist gut. Es löst das Problem für alle, die ihn eingespielt haben. Für die rund 1,5 Millionen Instanzen, die das noch nicht getan haben, ist der Patch ein theoretisches Sicherheitsupdate, das in der Praxis noch nicht existiert.
Und selbst wer gepatcht hat: Wer kann mit Sicherheit sagen, dass sein System im Zeitraum Februar bis April 2026 nicht kompromittiert wurde? Wer hat die Logs durchgesehen? Wer hat die authorized_keys geprüft? Wer weiß, ob ein stiller SSH-Schlüssel in der Infrastruktur sitzt und auf seinen nächsten Einsatz wartet?
Sorry-Ransomware ist sichtbar – verschlüsselte Dateien, Lösegeldforderung, .sorry-Endungen. Die Backdoors dahinter sind unsichtbar, bis jemand aktiv sucht. Und die meisten tun das erst, wenn es zu spät ist.
Die Frage, die sich nach dieser Krise stellt, ist nicht nur „Hat mein Provider gepatcht?“. Die Frage ist: Wie viele weitere Hosting-Backend-Systeme haben ähnliche Schwachstellen, die noch niemand entdeckt hat – oder die bereits ausgenutzt werden, während Sie das gerade lesen? Mehr Kontext liefert CISA erweitert KEV-Katalog: 8 neue Schwachstellen gefährden kritische Infrastrukturen sofort.
Was meinen Sie: Haben Sie Ihren Hosting-Provider bereits auf den Patch-Status angesprochen – und wenn ja, wie war die Antwort?
