Eine harte Woche für Verteidiger: PwnEscape, eMudhra, SafePay und der PHP-Patch

Update, 21. Oktober, 16:30 Uhr Pariser Zeit: PHP veröffentlichte die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 gegen 15:35 Uhr Pariser Zeit, etwas vor den angekündigten 14:00 UTC, und behebt damit beide kritischen Schwachstellen, dazu Quellcode-Backports für 7.4, 8.0 und 8.1. Der PHP-Abschnitt weiter unten wurde aktualisiert.

Wer in der Sicherheit, der Systemadministration oder im Hosting arbeitet, erlebte in den sieben Tagen bis heute die Art von Woche, die Fachleute nüchtern mit einem Datumsbereich beschreiben, weil Adjektive unprofessionell wirken. Ein kritischer Ausbruch aus virtuellen Linux-Maschinen am Donnerstag. Eine Zertifizierungsstelle, deren private Schlüssel sich übers Wochenende als für jeden mit einem Laptop rekonstruierbar erwiesen. Am Dienstag eine gemeinsame Behördenwarnung zu Ransomware, die Backup-Geräte auf Werkseinstellungen zurücksetzt, dazu ein Cloud-Ausfall, der Bankkarten lahmlegte, und die Mitteilung des PHP-Projekts, dass am nächsten Tag zwei kritische Korrekturen erscheinen würden. Dieser nächste Tag ist heute. Die Korrekturen waren für 14:00 UTC angekündigt und erschienen etwas früher, gegen 15:35 Uhr Pariser Zeit.

Eine Richtigstellung ist wichtiger als jede einzelne Schlagzeile. Vielleicht haben Sie gelesen, dass „viele Hosting-Anbieter gehackt wurden”, und zwar über den VM-Ausbruch mit dem Spitznamen PwnEscape. Mit Stand 13:30 Uhr Pariser Zeit am 21. Oktober ist das eine Befürchtung, keine Bestätigung. Nirgendwo wurde eine Ausnutzung in freier Wildbahn gemeldet. Die Angst hat eine rationale Grundlage, die wir erklären werden, aber sie sollte als Angst gekennzeichnet sein. Der Rest dieses Beitrags geht die Woche der Reihe nach durch, trennt Bestätigtes von Prognosen und endet mit der kurzen Liste der Dinge, die ein normaler Leser oder der Betreiber einer kleinen Website tatsächlich tun sollte.

Warum sind Sicherheitsteams so erschöpft?

Beginnen wir mit den Menschen, denn jedes Ereignis dieser Woche landete auf denselben Schreibtischen. Die ISC2 2025 Cybersecurity Workforce Study, veröffentlicht im Dezember 2025 auf Basis einer im Juli und August 2025 durchgeführten Befragung mit 16.029 Teilnehmern, ergab, dass sich 48 % der Sicherheitsfachleute erschöpft fühlen bei dem Versuch, bei Bedrohungen und Technologien auf dem Laufenden zu bleiben, 47 % fühlen sich häufig von ihrer Arbeitslast überwältigt, und 32 % fühlen sich wegen Personalmangels überarbeitet. Das Geld mildert es kaum: 20 % erhielten im vergangenen Jahr keine Gehaltserhöhung, und unzureichende Bezahlung war für 31 % eine häufige Quelle der Unzufriedenheit.

Der schärfere Befund betrifft die Führung. Nur 32 % der Befragten sagen, dass ihre Organisation Cybersicherheit als kritische Geschäftsfunktion behandelt, und 23 % nennen diese Lücke als Grund für Unzufriedenheit. Sicherheitsarbeit ist strukturell unsichtbar: Ein ruhiges Quartal sieht aus der Vorstandsetage genauso aus wie eine unnötige Ausgabe, und die Person, die zehn Vorfälle verhindert hat, steht im Budget neben der Person, die zehn Verkäufe abgeschlossen hat. Dieselbe ISC2-Studie ergab, dass 36 % der Organisationen 2025 ihre Sicherheitsbudgets kürzten und 24 % Entlassungen im Sicherheitsbereich meldeten, während 72 % der Fachleute zustimmen, dass der Abbau von Sicherheitspersonal das Risiko von Sicherheitsverletzungen deutlich erhöht.

Die europäischen Daten sind nicht freundlicher. In ISACAs State of Cybersecurity 2026 (Befragung im Mai 2026; 494 europäische Teilnehmer von weltweit 1.888) sagten 72 %, der Job sei stressiger als vor fünf Jahren, mit der komplexen Bedrohungslage (72 %) und unrealistischen Erwartungen in Kombination mit zu viel Arbeit (57 %) als Hauptursachen. Mehr als die Hälfte der europäischen Organisationen bezeichnete sich als unterbesetzt (56 %) und unterfinanziert (55 %), und 21 % der Unternehmen unternehmen gegen Burnout gar nichts. Behalten Sie diese Zahlen im Kopf, während sich die Woche entfaltet.

Was ist PwnEscape, und wurden Hosting-Anbieter wirklich darüber gehackt?

Am Donnerstag, dem 15. Oktober, veröffentlichte das Linux-Kernel-Projekt CVE-2026-99999, schnell PwnEscape getauft: eine Schwachstelle in der IPv4-Prüfsummenverarbeitung des Kernels, von der Kernel-CNA mit 9,3 (kritisch) bewertet (Red Hat stuft sie als Important ein). Das Szenario: Eine bösartige Mikro-VM füttert die TAP-Schnittstelle des Hosts mit präparierten virtio-net-Prüfsummen-Metadaten. Ein Ausbruch vom Gast zum Host ist der Moment, in dem eine gemietete virtuelle Maschine aufhört, Mieter zu sein, und zum Vermieter wird: Code in der VM eines Kunden gewinnt Einfluss auf den physischen Server, auf dem alle anderen laufen. Deshalb ließ eine 9,3 auf Hosts vom KVM-Typ das Hosting-Personal zum Kaffee greifen.

Hier ist, was tatsächlich feststeht. Die Schwachstelle wurde von Forschern bei pwn.ai im Rahmen der Sandbox-Challenge von Vercel gefunden, am 4. September an den Kernel gemeldet und am 14. Oktober im Mainline-Kernel behoben, wobei sieben Stable-Zweige gepatcht wurden. Das Leck im Host-Speicher wurde gegen die Produktions-Sandboxes des Challenge-Hosts demonstriert, wie Vercels eigener Bericht über die Challenge bestätigt; derselbe Beitrag sagt, dass keine Meldungen zeigten, dass jemand auf Kundendaten in Vercel Sandbox zugegriffen hat. Die Host-Abstürze und die Root-Rechte auf dem Host wurden nur auf den eigenen Maschinen der Forscher gezeigt, und pwn.ai erklärt, seine Arbeit sei keine Behauptung einer Root-Befehlsausführung in der Produktionsumgebung irgendeines Anbieters. Das verwundbare Code-Muster stammt laut der Analyse von TuxCare aus etwa dem Jahr 2008.

Und die Ausnutzung? CISAs Anreicherung des CVE-Eintrags sagt es unverblümt: Exploitation: none. Die Schwachstelle steht mit Stand des Feeds vom 20. Oktober nicht im Katalog der Known Exploited Vulnerabilities (bekannt ausgenutzte Schwachstellen) von CISA. Kein bestätigter Angriff in freier Wildbahn wurde von einem der Medien gemeldet, die das Thema verfolgen. Von CSO und heise zitierte Forscher erwarten funktionierende Exploits gegen schwächere Konfigurationen innerhalb von Wochen, was eine Prognose ist, keine Beobachtung.

Warum also die Beklemmung? Drei Gründe, alle legitim. Erstens gibt es keine veröffentlichten Kompromittierungsindikatoren für diese Schwachstelle, keine bösartigen Hashes oder Angreifer-Infrastruktur, nach der man suchen könnte; SOC Prime merkt an, dass die Erkennung von Host-Telemetrie, Virtualisierungs-Monitoring und Absturzanalyse abhängt, die viele kleinere Hoster schlicht nicht erheben. Das macht die Erkennung schwer. Es macht die Schwachstelle nicht spurlos: Keine Quelle, die wir gefunden haben, sagt, dass die Ausnutzung keine Spuren hinterlässt. Zweitens erfordert die Behebung das Patchen und einen Neustart des Host-Kernels; das Aktualisieren der eigenen VM bewirkt nichts, also steht jeder betroffene Anbieter vor einer Neustart-Kampagne über seine gesamte Flotte. Drittens richtet die Unsicherheit bereits kommerziellen Schaden an: Ein japanischer Hosting-Anbieter fror am 16. Oktober vorsorglich Neuanmeldungen für sein VPS-, Shared- und Dedicated-Hosting ein, ohne dass eine Sicherheitsverletzung gemeldet wurde, und ein deutscher Hoster startet seit dem Wochenende seine Virtualisierungsserver neu. Für Kunden gilt der Rat von heise: Sie müssen nichts tun, außer zu prüfen, dass Ihre VM nach dem Neustart Ihres Hosters wieder hochgefahren ist.

Was ist mit den eMudhra-Zertifikaten passiert?

Der Samstag brachte die Zertifikatsgeschichte, und das Wort „gekapert" begann zu kursieren. Die Realität, dokumentiert in Mozillas Fehlerbericht, ist anders und in mancher Hinsicht seltsamer: Acht Zwischenzertifikate (Intermediate-CA-Zertifikate) von eMudhra, einer indischen Zertifizierungsstelle, hatten so schwache private P-384-Schlüssel, dass sie trivial rekonstruierbar waren. Mozillas eigene Mitarbeiter stellten die Schlüssel innerhalb von Stunden nach der Meldung vom 17. Oktober wieder her. eMudhra führt die Schwäche auf ein fehlerhaftes Schlüsselerzeugungsskript zurück, das bei einer Schlüsselzeremonie im April 2025 verwendet wurde, und nennt menschliche Fehler in mehreren Schritten.

Was folgte, war das Vertrauensökosystem in Hochgeschwindigkeit. Laut BleepingComputer verteilte Firefox am 17. Oktober eine OneCRL-Sperre, gefolgt von den Updates Firefox 158.0.1 und ESR am 20. Oktober für Nutzer, deren Konfiguration das frühere Update blockiert hatte; Chrome sperrte die sechs TLS-fähigen Zwischenzertifikate ebenfalls am 17. Oktober, und Apple folgte am 19. Oktober; eMudhra widerrief alle acht Zertifikate am 18. Oktober. Mozilla kündigte anschließend den notfallmäßigen Vertrauensentzug für das übergeordnete emSign ECC Root CA - G3 an, und Chrome sagte einen ähnlichen Weg zu; eMudhra schätzt laut eigenem Kommentar in Mozillas Fehlerbericht, dass rund 30.000 Zertifikate migriert werden müssen.

Zwei ehrliche Vorbehalte wirken in entgegengesetzte Richtungen. Beruhigend: Es gibt keine Hinweise, dass die schwachen Schlüssel je missbraucht wurden, und eMudhra sagt, aus den betroffenen Serien seien keine Endzertifikate ausgestellt worden. Weniger beruhigend: Einer der privaten Schlüssel wurde von einem Forscher auf GitHub veröffentlicht, und Software mit eigenem Vertrauensspeicher oder ohne Widerrufsprüfungen (Mozillas Vorfalls-Tracker nennt laut BleepingComputer das in macOS eingebaute curl als Beispiel) vertraut den Zertifikaten möglicherweise weiter, bis sie aktualisiert wird. Für Leser besteht die gesamte Handlungsanweisung aus einer Zeile: Aktualisieren Sie Browser und Betriebssystem. Zertifikatsprobleme sind genau die Kategorie, in der ein VPN nichts ändert, wobei man sich merken sollte, dass gefälschte oder fälschlich als vertrauenswürdig eingestufte Zertifikate vor allem für einen Angreifer zählen, der Ihren Datenverkehr bereits abfangen kann, was ein Grund ist, warum die Verschlüsselung Ihrer Verbindung in öffentlichem WLAN (auf Englisch) weiterhin vernünftige Hygiene ist.

Warum war das heutige PHP-Release so wichtig?

Am Dienstagnachmittag veröffentlichte das PHP-Projekt auf php.net eine ungewöhnliche Mitteilung: ein Sicherheitsrelease, angesetzt für Mittwoch, den 21. Oktober um 14:00 UTC, das zwei kritische Schwachstellen behebt, wobei alle Details mit dem Release veröffentlicht werden. Eine kritische Korrektur vorab anzukündigen ist ein bewusster Kompromiss: Es gibt Verteidigern einen Tag, um Wartungsfenster zu planen, um den Preis, Angreifern mitzuteilen, dass etwas Wertvolles kommt. Das Release erschien dann etwas früher: Die GitHub-Advisories tragen den Zeitstempel 13:34 UTC, 15:34 Uhr in Paris, und PHPs Ankündigung mit dem Titel „Kritische Schwachstellen für Remote-Code-Ausführung, jetzt aktualisieren" nennt als korrigierte Releases PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie beheben CVE-2026-109618 und CVE-2026-109619, „zwei kritische Schwachstellen, die eine nicht authentifizierte Remote-Code-Ausführung ermöglichen können", beide mit CVSS v4.0 9,2 bewertet.

Die beiden Schwachstellen sind einfach zu beschreiben. CVE-2026-109618, „RCE über OOM-Korruption": Die Behandlung von Speichermangel (out of memory) kann PHP unterbrechen, während interne Anfragedaten erst teilweise initialisiert sind, und die Anfragebereinigung kann die ungültigen Daten dann als gültig behandeln. CVE-2026-109619, „RCE über veralteten globalen Zustand": Interner Zustand, der zu einer Anfrage gehört, kann überleben, nachdem sein Speicher freigegeben wurde, und eine spätere, vom selben Worker bearbeitete Anfrage kann ihn nutzen, ein Use-after-free. Wer gefährdet ist, laut PHP: „alle PHP-Installationen, die Web-Anfragen bedienen, einschließlich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed". Das Risiko ist am höchsten für mod_php, „mit einem demonstrierten Exploit, bei dem eine nicht authentifizierte Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft". Ein demonstrierter Exploit ist nicht dasselbe wie Ausnutzung in freier Wildbahn; PHPs Advisory meldet keine Angriffe in freier Wildbahn.

Das Embargo war ohnehin durchgesickert. Analysen von Sicherheitsfirmen, darunter die von SecureLayer7, führten die Schwachstellen als CVE-2026-109618 und CVE-2026-109619 und berichteten, dass vor dem Release ein Proof of Concept namens „PHP2Shell" auftauchte; das PHP-Projekt hat ihn nicht verifiziert, auch wenn SecureLayer7 berichtet, dass mindestens eine Sicherheitsfirma angibt, eine der Schwachstellen reproduziert zu haben. PHPs Advisories vom 21. Oktober melden keine Ausnutzung in freier Wildbahn.

Dann sind da alle auf einem alten Zweig. „PHP 8.1 und älter erhalten keine Updates mehr vom PHP-Projekt", merkt die Ankündigung an, auch wenn einige Distributionen und LTS-Anbieter zurückportierte Korrekturen bereitstellen. „Angesichts des Schweregrads" veröffentlichte das PHP-Sicherheitsteam zusätzlich minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1, gedacht für Leute, die aus dem Quellcode bauen oder keinen LTS-Anbieter haben; das sind Patches zum Anwenden, keine fertigen Releases. Das Projekt veröffentlichte keine Backports für PHP 7.3 oder älter, einschließlich PHP 5. Linux-Distributionen und LTS-Anbieter erhielten die Patches vorab, und PHP 8.2 selbst erreicht am 31. Dezember 2026 das Ende seiner Lebensdauer. PHPs Advisory listet Übergangsmaßnahmen für alle, die nicht sofort aktualisieren können, etwa memory_limit auf -1 zu setzen, post_max_size zu senken oder den Session Upload Progress zu deaktivieren, sagt aber, sie „verringern die Angriffsfläche für bestimmte Angriffswege, machen eine Installation aber nicht sicher"; laut den Release Notes ist „das Update die einzige sichere Wahl".

Die Größenordnung ist der Punkt. Laut W3Techs läuft PHP auf 69,3 % der Websites mit bekannter serverseitiger Sprache, und von diesen PHP-Sites laufen 27,0 % noch auf Version 7 und 7,7 % auf Version 5, Zweigen, die vor Jahren das Ende ihrer Lebensdauer erreicht haben. Die Version-7-Sites schließen PHP 7.4 ein, das jetzt immerhin einen Backport auf Quellcode-Ebene hat; Sites auf PHP 5 und auf PHP 7.0 bis 7.3 bekommen vom Projekt keinen Backport. CERT-EUs Advisory 2026-018 warnte, die Schwachstellen könnten alle PHP-Versionen ab PHP 5 betreffen; das bleibt seine Warnung, während GitHubs Advisories nur die unterstützten Zweige unterhalb von 8.2.35, 8.3.36, 8.4.27 und 8.5.12 als betroffen führen und Versionen am Ende ihrer Lebensdauer nicht aufzählen. Für die Sysadmins aus Abschnitt eins ist das die Arbeit von heute Abend und das Migrationsprojekt des nächsten Quartals, angekündigt am selben Dienstag wie alles andere.

Was landete diese Woche noch auf den Schreibtischen der Verteidiger?

Montag und Dienstag legten weiter nach. Das gemeinsame Advisory AA26-293A von CISA und FBI (20. Oktober) beschreibt SafePay, eine Ransomware-Operation, die seit August 2024 mindestens 600 Organisationen getroffen hat. Um Opfer an der Wiederherstellung zu hindern, so das Advisory, stoppt SafePay den Volume Shadow Copy Service und setzt netzgebundene Backup-Speicher auf Werkseinstellungen zurück, in manchen Fällen werden alle netzgebundenen Backups gelöscht. Der Kernrat des Advisorys ist alte Weisheit mit neuer Dringlichkeit: Backups müssen offline, unveränderlich und tatsächlich getestet sein, denn über das Netz erreichbare Kopien sind genau das, was diese Gruppe zerstört.

Auch CISAs Katalog der Known Exploited Vulnerabilities hatte eine schwere Woche: Am 20. Oktober kamen vier verkettbare Schwachstellen in Plex Media Server hinzu, was zählt, weil Plex der seltene KEV-Eintrag ist, der in Wohnzimmern statt in Rechenzentren sitzt. Früher in der Woche kamen BeyondTrust Remote Support und Fortinet (16. Oktober), Atlassian Data Center (15. Oktober) sowie Palo Alto PAN-OS, Cisco Secure Email Gateway und Ahsay (14. Oktober). Jeder Eintrag hat Belege für Ausnutzung in freier Wildbahn.

Zwei weitere Meldungen rahmten die Woche. Eine Reuters-Exklusivmeldung vom 19. Oktober beschrieb einen einzelnen Hacker, der autonome KI-Agenten nutzte, um Einbruchsversuche auf mehr als 1.200 Sites zu unternehmen und in die Sites von mehr als 100 Unternehmen einzudringen, zu Kosten von rund 50 US-Dollar pro Einbruch, laut einem Forscher bei NorForge; Reuters konnte nicht feststellen, welche Daten entwendet wurden. Wie auch immer die endgültige Bilanz ausfällt, die Ökonomie ist die Geschichte: Wenn ein Einbruch etwa 50 US-Dollar kostet, sehen die Budgetkürzungen aus den ISC2-Daten noch schwerer zu rechtfertigen aus. Und am Dienstag fiel ein Google-Cloud-Ausfall in der Region London mit europaweit abgelehnten Revolut-Karten zusammen; Revolut selbst bestätigte die Ursache am Abend des 20. Oktober, verkündete um 19:39 Uhr Pariser Zeit, das Problem sei behoben und die Dienste wiederhergestellt, und nannte einen Google-Cloud-Ausfall als Ursache, Google führt seinen Ausfall auf ein Stromereignis in einer Zone seiner Region London zurück, und nichts verbindet ihn mit PwnEscape. Wir haben das separat in unserem Erklärstück zum Revolut-Ausfall behandelt.

Wie sieht die ganze Woche im Überblick aus?

Was sollten Sie diese Woche tatsächlich tun?

Für die meisten Leser ist die ehrliche Antwort kurz. Aktualisieren Sie Browser und Betriebssystem, was die Zertifikatsgeschichte still erledigt. Wenn Sie zu Hause Plex Media Server betreiben, aktualisieren Sie ihn heute; diese Schwachstellen werden ausgenutzt, nicht nur theoretisiert. Und rechnen Sie mit Phishing, das sich die Schlagzeilen dieser Woche borgt, die Sorte „Ihr Konto war von der PHP-Sicherheitslücke betroffen"; ein DNS-Filter, der bekannte Phishing-Domains blockiert, bevor sie laden, wie Le VPNs Threat Protection, hilft dabei, und wenn eine Mail behauptet, Ihre E-Mail-Adresse sei in einem Datenleck aufgetaucht, prüfen Sie das selbst gegen bekannte Datenlecks, statt auf den Link zu klicken. Unser Hub für Online-Sicherheit (auf Englisch) deckt den Rest der Grundlagen ab.

Wenn Sie eine Website besitzen: Finden Sie heute Abend heraus, welchen PHP-Zweig Sie nutzen. Auf 8.2 bis 8.5 ist das Update da: Spielen Sie jetzt 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 ein, oder fragen Sie Ihren Hoster, ob es eingespielt ist, denn Linux-Distributionen und LTS-Anbieter erhielten die Patches vorab. Auf 7.4, 8.0 oder 8.1 sind die minimalen Quellcode-Backports des PHP-Sicherheitsteams oder die zurückportierte Korrektur eines Anbieters die Optionen. Auf 7.3 oder älter, einschließlich PHP 5, behandeln Sie dies als den Anstoß für das Upgrade, das Sie aufgeschoben haben, und ziehen Sie in der Zwischenzeit CERT-EUs Vorschlag in Betracht, alles mit Internetzugang zu isolieren, was nicht gepatcht werden kann. Wenn Ihre Site auf einem VPS liegt, dürfen Sie Ihrem Anbieter zwei Fragen stellen: Wurden die Host-Kernel für CVE-2026-99999 gepatcht, und wann ist das Neustartfenster. Und prüfen Sie, dass Ihre Backups irgendwo liegen, wo Ransomware nicht hinkommt: SafePay setzt netzgebundene Backups zurück oder löscht sie, gerade weil Opfer auf sie zählen.

Wenn Sie Menschen führen, die diese Arbeit machen, sind die Umfragezahlen am Anfang dieses Beitrags keine HR-Kuriosität, sondern ein Risikoindikator. Proofpoints 2026 Voice of the CISO ergab, dass 77 % der CISOs sagen, an sie würden überzogene Erwartungen gestellt, und die Forschung von IANS/Artico zur Einbindung von Aufsichtsgremien ergab, dass nur 29 % der Gremienmitglieder die Cyber-Updates, die sie erhalten, als sehr effektiv bewerten. Ein Team, das diese Woche Hosts gepatcht, Zertifikate rotiert und um Mitternacht Embargo-Leaks gelesen hat, wird das nächsten Monat wieder tun. Ob es das gut tut oder während es den Lebenslauf aktualisiert, ist teilweise eine Budgetfrage.

Noch ein ehrlicher Absatz. Ein VPN hätte kein einziges Ereignis auf dieser Liste verhindert. Es patcht keine Server, behebt keine Kernel- oder PHP-Fehler auf Sites, die Sie besuchen, stoppt keine Cloud-Ausfälle und ersetzt nicht die Browser-Updates, die die schlechten Zertifikate gesperrt haben. Was es tut, ist enger gefasst und trotzdem nützlich: Es verschlüsselt den Datenverkehr zwischen Ihrem Gerät und dem VPN-Server, sodass jemand im selben Café-WLAN nicht abfangen kann, was Sie senden. Genau zu wissen, was ein Werkzeug tut, und das auch zu sagen, schien der richtige Abschluss für eine Woche, die von der Angst vor dem Unbestätigten lebte.

Die Korrekturen erschienen heute Nachmittag, Pariser Zeit. Irgendwo hat ein müder Administrator ein Terminal offen und ein Wartungsfenster gebucht, und bis Donnerstag wird sich niemand außerhalb des Teams daran erinnern. So sieht Sicherheit aus, wenn sie funktioniert: nach außen hin gar nichts.