PHP plant Notfall-Fix für zwei kritische Lücken mit Wert 9.2
PHP veröffentlicht am 21. Oktober um 14:00 UTC Korrekturen für zwei kritische Lücken mit Wert 9.2. Nur 8.2 bis 8.5 erhalten Patches, und Details sickerten einen Tag zu früh durch.
4 Min. Lesezeit

Die Zahlen
- CVSS v4.0 score PHP gave each flaw
- 9.2
- release time on October 21, 2026
- 14:00 UTC
- hosts showing PHP 8.1 or older in a Shodan count
- 884,000
Das PHP-Sicherheitsteam veröffentlicht am 21. Oktober 2026 um 14:00 UTC ein außerplanmäßiges Sicherheitsrelease für zwei Lücken, die es als kritisch einstuft. Forschern zufolge ermöglichen die Fehler Remote-Codeausführung, und Details sind einen Tag zu früh durchgesickert. Wer PHP betreibt, sollte bereit sein, sofort zu patchen, sobald das Release erscheint.
PHP ist die Sprache hinter WordPress, Drupal und einem großen Teil des serverseitigen Codes im Web. Ein außerplanmäßiges Release erscheint außerhalb des normalen Release-Kalenders des Projekts. PHP reserviert diesen Weg für dringende Korrekturen.
Was das PHP-Sicherheitsteam angekündigt hat
Die Mitteilung auf PHP.net, veröffentlicht am 20. Oktober, sagt absichtlich wenig. Sie nennt zwei Schwachstellen und bewertet jede mit 9.2 nach CVSS v4.0, der gängigen Schweregradskala von 0 bis 10. Sie nennt keine CVE-Nummern, keine Beschreibung und keine Versionsnummern. Die betroffenen und korrigierten Versionen "werden mit dem Release veröffentlicht", heißt es in der Mitteilung.
Das Team hat sich außerdem Spielraum gelassen, schneller zu handeln. Es könne früher veröffentlichen, wenn die Details öffentlich werden oder Angriffe beginnen. "Alle PHP-Nutzer sind angehalten, sich jetzt vorzubereiten, damit sie aktualisieren können, sobald das Release verfügbar ist", heißt es in der Mitteilung.
LWN, eine langjährige Nachrichtenseite zu Linux und Open Source, gab die Warnung noch am selben Tag weiter. Sie riet allen, die eine PHP-Website betreiben, sich auf das Update vorzubereiten.
Was durchgesickert ist und was noch unbestätigt ist
The Hacker News berichtet, dass Forscher das Paar "php2shell" nennen, ein Name, den PHP nicht verwendet hat. Die Sicherheitsfirma watchTowr sagt, die Lücken ermöglichen Remote-Codeausführung. Ein Angreifer könnte also Befehle auf dem Server ausführen. Am 20. Oktober erklärte watchTowr auf X, ein Leak zu den Lücken sei echt. Die Firma fügte hinzu, dass die Lücken unter Embargo standen, also in einer Phase, in der Details bis zum Erscheinen einer Korrektur vertraulich bleiben.
Dieses Leak war ein Beitrag auf Hacker News, dem Tech-Forum. Darin hieß es, die Offenlegung sei für Donnerstag, den 22. Oktober, geplant, und der Beitrag behauptete, jede Version ab PHP 5 sei betroffen. Dieser Umfang ist unbestätigt. In den Worten der FAQ von watchTowr wurde er "nicht durch eine offizielle Sicherheitsmeldung des Herstellers bestätigt".
Forscher ordnen den Lücken zwei Kennungen zu: CVE-2026-109618 und CVE-2026-109619. Die Mitteilung von PHP nennt keine davon.
Ein selbst veröffentlichter Bericht auf jackalsyn.com, verfasst von einem Forscher unter dem Namen J4ck3LSyN, verknüpft diese Kennungen mit einem Use-after-free-Fehler in session.upload_progress. Ein Use-after-free entsteht, wenn ein Programm Speicher weiter nutzt, den es bereits freigegeben hat. Die Funktion selbst verfolgt in der Session eines Nutzers den Fortschritt von Datei-Uploads.
Dieser Bericht bewertet die eigenen Befunde weit niedriger als PHP: 5.3, also Medium, für einen Pfad und 0.0 für einen anderen. Er reproduzierte den Fehler nur unter Apache mit mod_php im Prefork-Modus und zeigte keine Codeausführung. Nichts bestätigt, dass er dieselben Fehler beschreibt, die PHP mit 9.2 bewertet hat.
Welche PHP-Versionen Korrekturen erhalten
Laut The Hacker News erhalten nur die unterstützten Zweige 8.2 bis 8.5 Korrekturen. Alpine Linux und der Sicherheitsforscher Kevin Beaumont verfolgen die erwarteten Versionsnummern, die PHP nicht bestätigt hat.
| Zweig | Aktuelles Release | Supportstatus | Erwartete Korrektur (unbestätigt) |
|---|---|---|---|
| PHP 8.5 | 8.5.11 | Aktiver Support bis zum 31. Dezember 2027 | 8.5.12 |
| PHP 8.4 | 8.4.26 | Aktiver Support bis zum 31. Dezember 2026 | 8.4.27 |
| PHP 8.3 | 8.3.35 | Nur Sicherheitskorrekturen bis zum 31. Dezember 2027 | 8.3.36 |
| PHP 8.2 | 8.2.34 | Nur Sicherheitskorrekturen bis zum 31. Dezember 2026 | 8.2.35 |
| PHP 8.1 und älter | n/a | End of Life | Keine Korrektur von PHP |
Die alten Zweige machen einen großen Teil des Webs aus. Eine Shodan-Zählung von Mallory vom 20. Oktober, zitiert von The Hacker News, fand rund 884.000 aus dem Internet erreichbare Hosts, die PHP 8.1 oder älter melden. Das sind 59 % von rund 1,5 Millionen Hosts, die überhaupt eine Version melden. Weitere rund 740.000 melden PHP ohne Version. Das sind Banner-Zählungen, keine bestätigt angreifbaren Systeme.
Bisher wurden keine Angriffe gemeldet. Huntress, ein Sicherheitsunternehmen, sah bis zum 20. Oktober keine Ausnutzung und wusste von keinem öffentlichen Exploit-Code. Die Lücken stehen nicht auf der CISA-Liste bekannter ausgenutzter Schwachstellen. Dieses Zeitfenster könnte kurz sein: Akamai sah Angriffsversuche innerhalb von 24 Stunden, nachdem CVE-2024-4577, eine frühere PHP-Lücke, im Juni 2024 öffentlich wurde.
Was das für Entwickler bedeutet
Finden Sie zuerst jede PHP-Installation. Huntress und CERT-EU raten beide zu einer Bestandsaufnahme, die auch mitgelieferte Kopien umfasst, etwa PHP in Container-Images, Appliances und Hosting-Panels. Ein Server, den Sie vergessen haben, ist der, der getroffen wird.
Patchen Sie aus dem Internet erreichbare Systeme zuerst, sobald das Release um 14:00 UTC erscheint. Es ist inzwischen als PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erschienen. Wenn Sie PHP aus einer Linux-Distribution oder einem Container-Basis-Image installieren, prüfen Sie, wann diese Quelle ihr neu gebautes Paket veröffentlicht. Das kann später geschehen als auf php.net.
Planen Sie jetzt für die Zweige mit End of Life. PHP 8.1 und älter erhalten keine Korrektur vom Projekt. CERT-EU rät, "in Betracht zu ziehen, aus dem Internet erreichbare Anwendungen von öffentlichen Netzen zu isolieren, bis eine Korrektur verfügbar ist". Die anderen Optionen sind ein Upgrade, ein VPN oder eine Web Application Firewall vor der Website.
Gehen Sie mit dem inoffiziellen Workaround vorsichtig um. Der Bericht auf jackalsyn.com schlägt vor, session.upload_progress.enabled = Off zu setzen. PHP hat keinen Workaround veröffentlicht, und dieser Bericht beschreibt womöglich nicht die Fehler, die PHP behebt. Die meisten Apps brauchen die Einstellung nur, wenn sie Upload-Fortschrittsbalken anzeigen. Sie abzuschalten ist daher eine günstige Notlösung, keine Korrektur.
Achten Sie diese Woche auf Anzeichen einer Kompromittierung. The Hacker News gibt den Rat weiter, Alarm zu schlagen, wenn ein PHP-Prozess eine Shell oder ein Download-Werkzeug startet. PHP-Anwendungen hatten einen arbeitsreichen Monat: Drupal lieferte am 14. Oktober eine Korrektur für eine kritische Lücke in Field UI.
Quellen
Ähnliche Artikel

PHP 8.5.12 und 8.4.27 schließen zwei kritische RCE-Lücken
PHP hat am 21. Oktober 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, um zwei mit 9.2 bewertete Lücken zu schließen. Laut PHP ist ein Update die einzige vollständige Lösung.

Amazon sah PHP2Shell-Angriffsversuche vier Tage vor der Offenlegung
Laut Amazon haben seine MadPot-Honeypots am 17. Oktober 2026 einen Versuch protokolliert, die PHP2Shell-Lücken auszunutzen, vier Tage bevor PHP die Korrekturen veröffentlichte. Die Angriffe gehen inzwischen in die Millionen.

Python 3.15.1, 3.14.9 und 3.13.17 liefern pip 26.2.2
Python 3.15.1, 3.14.9 und 3.13.17 sind am 21. Oktober 2026 erschienen. Sie bringen pip 26.2.2 und certifi 2026.10.19 mit, damit die CA eMudhra nicht mehr vertraut wird.