Das PHP-Sicherheitsteam kündigte am Dienstagabend, dem 20. Oktober, vorab an, dass am nächsten Tag ein dringender Sicherheitsupdate zur Behebung zweier kritischer Fehler erscheinen werde. Da Details zu den Fehlern bereits vor der offiziellen Veröffentlichung durchgesickert waren, wurde die Veröffentlichung um einen Tag vorverlegt. Am 21. Oktober um 16:00 Uhr (ungarische Zeit) veröffentlichte das Team von php.net die korrigierten Versionen selbst.

Aufgrund der Sicherheitslücke reagierten auch die Angreifer schnell: Mehrere Sicherheitsunternehmen (darunter watchTowr, Hadrian und Patchstack) stellten aktive Ausnutzungsversuche fest, und Cloudflare meldete bereits vor der Behebung des Problems die ersten Angriffe. Laut einem Bericht von Amazon Threat Intelligence begannen die ersten Versuche bereits am 17. Oktober.

Warum ist dies von entscheidender Bedeutung?

Die beiden Fehler liegen in der Speicherverwaltung von PHP:

• CVE-2026-109618: Wenn während der Verarbeitung einer Anfrage der Speicher knapp wird, führt PHP eine Bereinigung mit teilweise vorbereiteten Daten durch, was zu einer Speicherbeschädigung führt.
• CVE-2026-109619: Ein späterer Aufruf im selben PHP-Prozess kann einen Status nutzen, der auf bereits freigegebenen Speicher verweist, der aus einem früheren Aufruf übrig geblieben ist.

Beide weisen einen CVSS-Wert von 9,2 (kritisch) auf. Mit einer speziell gestalteten Webanfrage kann ein Angreifer Code auf dem Server ausführen, und zwar mit den Berechtigungen des PHP-Prozesses. Forscher haben zudem gezeigt, dass der Inhalt des Speichers des PHP-Prozesses offengelegt werden kann, der Passwörter, Tokens oder API-Schlüssel enthalten kann.

Da PHP die Anfrage vor dem Anwendungscode verarbeitet, bietet auch der Anmeldeschutz des CMS keinen Schutz. Das größte Risiko geht von Apache mod_php aus, doch auch PHP-FPM, LiteSpeed und FrankenPHP sind bei bestimmten Einstellungen betroffen.

Betroffene Versionen und Korrekturen

Die Fehler betreffen PHP 5.4 und neuere Versionen.

Wichtig: Die folgende Tabelle zeigt ausschließlich, für welche Zweige das PHP.net-Team (das PHP-Projekt selbst) offizielle Patches veröffentlicht hat. Dies bedeutet nicht, dass die übrigen Versionen tatsächlich ungeschützt bleiben: Die Wartungsteams der Betriebssysteme und Softwarehersteller (wie beispielsweise CloudLinux, cPanel, TuxCare, Debian, Ubuntu oder AlmaLinux) können den Patch auch auf andere, ältere PHP-Versionen zurückportieren (Backport), was in der Praxis häufig auch geschieht. Wie die Situation auf einem bestimmten Server aussieht, hängt vom Status des dort verwendeten Pakets ab, nicht von der PHP-Versionsnummer.

PHP-Zweig	Korrigierte Version von PHP.net	Anmerkung
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	Der Support für PHP.net läuft am 31. Dezember 2026 aus
8.1 und älter	PHP.net veröffentlicht keine offiziellen Versionen	Das PHP-Team hat einen Patch auf Quellcode-Ebene für die Zweige 7.4, 8.0 und 8.1 veröffentlicht; Distributionen und Hersteller können auch für diese (und noch ältere Zweige) eigene, rückportierte Patches herausgeben

Die Tabelle gibt also die offizielle Unterstützung durch PHP.net wieder und nicht, welche Version auf einem bestimmten Server sicher ist. Bei uns enthalten beispielsweise die CloudLinux- und cPanel-Pakete (EasyApache) auch für ältere PHP-Zweige die entsprechenden Patches, sodass auf diesen Servern auch die älteren Versionen geschützt sind.

Warum bleibt die Versionsnummer unverändert?

Einige Hersteller (wie beispielsweise CloudLinux) portieren den Patch rückwärts (Backport) in ihre Pakete mit älteren Versionsnummern. In diesem Fall ändert sich die PHP-Versionsnummer nicht (sie bleibt beispielsweise 8.5.11), sondern lediglich die Build-Nummer des Pakets; die Build-Nummer ist jedoch in der Versionsangabe nicht sichtbar. Das Changelog des Pakets bestätigt, dass der Patch enthalten ist.

Aus diesem Grund können Prüfprogramme, die lediglich die PHP-Versionsnummer berücksichtigen, falsche Ergebnisse anzeigen. Wenn ein WordPress-Plugin (z. B. HelloPack) anzeigt, dass die Website PHP 8.5.11 verwendet und aktualisiert werden muss, bedeutet dies nicht automatisch, dass der Patch fehlt. Sollten Sie eine solche Warnmeldung erhalten, schreiben Sie uns bitte, damit wir den Status überprüfen können.

Auch das „Build Date“ in der Ausgabe von „phpinfo()“ ist hilfreich: Liegt das Datum nach dem 21. Oktober 2026, wurde das Paket wahrscheinlich nach dem Patch neu kompiliert. Eine sichere Überprüfung bietet das Changelog des Pakets.

Was haben wir getan?

• Bereits vor der Veröffentlichung des Patches haben wir ModSecurity-Regeln auf unseren Servern angewendet, um bis dahin einen gewissen Schutz zu gewährleisten. Dies ist ein zusätzlicher Schutz, der das PHP-Update nicht ersetzt.
• Auf unseren Servern: Sobald die Patches verfügbar waren, haben wir diese innerhalb von 5 bis 15 Minuten installiert. Es wurden kontinuierlich Patches für die verschiedenen PHP-Versionen veröffentlicht, und aufgrund der hohen Auslastung der Repositories dauerte deren Download zudem länger als gewöhnlich.
• Neustart: Die Korrektur wird erst nach dem Neustart der betroffenen Dienste wirksam; daher haben wir Apache und PHP mehrmals neu gestartet (nicht den gesamten Server). Dies führte insgesamt nur zu einer Unterbrechung von wenigen Minuten.
• Falls Ihre Website über Cloudflare betrieben wird, hat Cloudflare ebenfalls eigene Sicherheitsregeln eingeführt: Diese traten am 21. Oktober 2026 um 05:02 Uhr (ungarische Zeit) standardmäßig über die WAF-Regeln in Kraft. Dies gilt auch für kostenlose Cloudflare-Abonnements.

Was können Sie tun?

1. Sie müssen nichts unternehmen, um das PHP-Problem zu beheben. Das Update muss vom Serverbetreiber bzw. -wartungsbeauftragten installiert werden; es kann nicht direkt aus der Webanwendung heraus durchgeführt werden.
2. Bitte überprüfen Sie Ihre Website. Zu den verdächtigen Anzeichen zählen unbekannte oder kürzlich geänderte .php-Dateien, unbekannte Benutzer oder Administratoren im CMS, unbekannte zeitgesteuerte Aufgaben (Cron) in Ihrem Hosting-Konto sowie unerwartete Weiterleitungen, Spam oder fremde Inhalte. Sollten Sie derartige Auffälligkeiten feststellen, melden Sie uns diese bitte und löschen Sie nichts, bevor wir uns mit Ihnen abgestimmt haben.
3. Erwägen Sie, Ihre Passwörter zu ändern. Ohne verdächtige Anzeichen ist dies nicht zwingend erforderlich, doch aus Vorsichtsgründen – insbesondere, wenn die Website Anmelde- oder Zahlungsvorgänge abwickelt – empfiehlt es sich, die Passwörter für das Control Panel, FTP, die Datenbank sowie die CMS-Administratorrechte zu ändern. Der Fehler kann auch den Inhalt des PHP-Prozessspeichers offenlegen. Das Ändern des cPanel-Passworts wird in einem separaten Artikel erläutert.
4. Halten Sie Ihr CMS und Ihre Plugins auf dem neuesten Stand. Dies ersetzt zwar nicht die PHP-Aktualisierung, verringert jedoch die Angriffsfläche.
5. Seien Sie vorsichtig bei Phishing-E-Mails. Aufgrund dieser Meldung könnte es vermehrt zu gefälschten E-Mails kommen, die auf ein „dringendes Sicherheitsupdate“ verweisen. Wir werden Sie niemals per E-Mail nach Ihrem Passwort fragen.

Wer seine eigene Website überprüfen möchte, kann beispielsweise das Open-Source-Tool „php2shell-scanner“ von Searchlight Cyber oder den kostenlosen URL-Checker von Aikido nutzen. Bitte verwenden Sie diese Tools ausschließlich zum Testen Ihres eigenen Servers und Ihrer eigenen Website!

Zeitleiste

Die Zeitangaben beziehen sich auf die ungarische Zeit (MESZ) und sind im Format JJJJ-HH-NN Uhr:PP angegeben.

Datum	Veranstaltung
2026-10-17	Laut dem Bericht von Amazon Threat Intelligence begannen zu diesem Zeitpunkt die ersten Ausnutzungsversuche, noch bevor die Schwachstelle öffentlich bekannt gegeben wurde.
2026-10-20 21:33	Das PHP-Sicherheitsteam kündigt vorab die dringende Veröffentlichung eines Updates für zwei kritische Sicherheitslücken an. Die Details sickern bereits vor der offiziellen Veröffentlichung durch, und auch CERT-EU gibt eine Warnung heraus.
2026-10-21 05:02	Cloudflare aktiviert standardmäßig seine Schutzregeln für WAF-Pakete.
2026-10-21 09:43	Cloudflare meldet die ersten Angriffe.
2026-10-21 11:08	Der erste Regelsatz von Imunify360 WAF blockiert öffentlich bekannte Angriffsmuster.
2026-10-21 13:35	Hadrian ermöglicht eine Nutzung in großem Maßstab, insbesondere durch den Fortschritt beim Hochladen von Sitzungen (Session Upload Progress).
2026-10-21 16:00	Das Team von php.net veröffentlicht die folgenden korrigierten Versionen: 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
2026-10-21 16:19	watchTowr bestätigt, dass es aktive Ausnutzungsversuche für beide Schwachstellen feststellt. Sowohl die CISA als auch das britische NCSC haben Warnungen herausgegeben.
21.10.2026 fortlaufend	Auch cPanel veröffentlicht eine Mitteilung zu den aktualisierten cPanel- und EasyApache 4-Paketen.
2026-10-21 19:50	AlmaLinux stellt die korrigierten PHP-Pakete zur Testphase bereit (sie werden ab dem 21.10.2026 um 23:15 Uhr in die Produktions-Repositories übernommen).
2026-10-21 22:55	CloudLinux veröffentlicht die korrigierten ea-php-Pakete (ea-php52–ea-php85).
2026-10-21	Ubuntu veröffentlicht die Mitteilung USN-8948-1: korrigierte PHP-Pakete für Ubuntu 22.04 LTS (php8.1, 8.1.2-1ubuntu2.28), 24.04 LTS (php8.3, 8.3.6-0ubuntu0.24.04.13), 26.04 LTS (php8.5, 8.5.4-0ubuntu1.5) und 26.10 (php8.5, 8.5.9-0ubuntu2.1) veröffentlicht.
2026-10-21	Ubuntu veröffentlicht die Mitteilung USN-8948-2 für ältere Versionen: 20.04 LTS (PHP 7.4, 7.4.3-4ubuntu2.29+esm5) und 18.04 LTS (PHP 7.2, 7.2.24-0ubuntu0.18.04.17+esm14) über das ESM; für die Updates von 16.04 und 14.04 ist ein Ubuntu Pro Legacy Support-Abonnement erforderlich.
2026-10-21	Auch Debian veröffentlicht korrigierte Pakete: trixie (Debian 13) php8.4 8.4.27-1~deb13u1 (DSA-6574-1) und bookworm (Debian 12) php8.2 8.2.35-1~deb12u1 (DLA-4848-1). Im instabilen (sid) Zweig war der Fix noch nicht im Debian-Tracker aufgeführt.
2026-10-22 02:07	Die aktualisierten alt-php-Pakete von CloudLinux werden in den stabilen Repositories veröffentlicht (CloudLinux 7, 8, 9: PHP 5.2–8.5).
2026-10-22 03:19	TuxCare hat alle korrigierten Pakete veröffentlicht (alt-php, die distributionsspezifischen PHP-Pakete sowie PHP für Windows).
2026-10-22 14:05	Ein Open-Source-Scan-Tool (Searchlight Cyber php2shell-scanner) wird veröffentlicht.

Häufig gestellte Fragen

Ist meine WordPress-Seite oder mein Online-Shop davon betroffen? Ja, dies kann jede PHP-basierte Website betreffen, da der Fehler in PHP liegt. Die Behebung erfolgt auf dem Server.

Reicht es aus, WordPress oder die Plugins zu aktualisieren? Nein. Der Fehler wird durch ein PHP-Patch behoben, nicht allein durch die Aktualisierung des CMS.

Ist meine Website ausgefallen? Für kurze Zeit ja: Die Neustarts von Apache und PHP führten insgesamt nur zu einer Unterbrechung von wenigen Minuten.

Kann ich weiterhin PHP 8.1 oder eine ältere Version verwenden? PHP.net hat für diese Zweige keine offizielle Version veröffentlicht, jedoch können Betriebssysteme und Hersteller (wie beispielsweise CloudLinux, cPanel und TuxCare) rückportierte Patches dafür bereitstellen, sodass auch ältere Versionen auf den betroffenen Servern geschützt sein können. Langfristig empfehlen wir den Wechsel auf die unterstützte Version (8.3 oder 8.4), sofern Ihre Website damit kompatibel ist. Erstellen Sie vor dem Wechsel eine Sicherungskopie und testen Sie anschließend die Website. Die Umstellung der PHP-Version in cPanel wird in einem separaten Artikel erläutert.

• Cybersicherheit
• PHP
• CloudLinux
• cPanel
• Neuigkeiten