PHP2Shell: Was die PHP-Lücken vom 21. Oktober 2026 für Ihre Website bedeuten

Was am 20. und 21. Oktober 2026 passiert ist

Am 20. Oktober 2026 kündigte das Sicherheitsteam von PHP eine Sicherheitsveröffentlichung für den nächsten Tag an, 14:00 Uhr UTC, also 16 Uhr in Österreich, Deutschland und der Schweiz. Sie sollte zwei kritische Lücken schließen, beide mit 9,2 von 10 Punkten bewertet (CVSS 4.0, ein verbreitetes Bewertungsschema für Schweregrade).

Am 21. Oktober 2026 erschienen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das Projekt schreibt dazu, alle PHP-Nutzer sollten umgehend aktualisieren. Die beiden Lücken tragen die Nummern CVE-2026-109618 und CVE-2026-109619. Vereinfacht beschrieben:

• CVE-2026-109618: Wird der Arbeitsspeicher knapp, kann PHP mitten in der Vorbereitung einer Anfrage unterbrochen werden. Beim anschließenden Aufräumen behandelt PHP die halb vorbereiteten Daten dann als gültig.
• CVE-2026-109619: Daten einer Anfrage können im Speicher weiter verwendet werden, obwohl dieser Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Arbeitsprozess kann sie aufgreifen, bevor sie zurückgesetzt werden.

Beides sind Fehler im Kern von PHP, nicht in WordPress, einem Plugin oder einer bestimmten Anwendung. Am 23. Oktober 2026 ergänzte das Projekt einen Hinweis zu einer dritten, nach eigener Einschätzung unwahrscheinlichen Variante (CVE-2026-115560), die nur bei einer ungewöhnlichen Kombination von Einstellungen auftritt; die vollständige Meldung soll mit der nächsten regulären Version folgen.

Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 21. Oktober eine Cybersicherheitswarnung veröffentlicht und am 22. Oktober in Version 1.2 aktualisiert. Es empfiehlt, das Update unverzüglich einzuspielen.

Wer betroffen ist

Laut php.net ist jede PHP-Installation betroffen, die Webanfragen beantwortet, ausdrücklich auch PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Damit sind die üblichen Arten abgedeckt, wie Hoster PHP betreiben. Das höchste Risiko sieht das Projekt bei mod_php: Dort sei gezeigt, dass eine Anfrage ohne Anmeldung den Angriff auslösen kann, noch bevor der Programmcode der Website läuft.

Für Sie als Betreiber heißt das: Ob Ihre Website betroffen ist, hängt nicht davon ab, wie sorgfältig sie gebaut ist oder welche Plugins sie nutzt. Es hängt davon ab, welche PHP-Version auf dem Server läuft.

Wie viele Websites das betrifft, lässt sich nur schätzen. W3Techs, ein Dienst, der Technologien auf Websites zählt, gibt an, dass 69,2 % der Websites, deren Programmiersprache auf dem Server bekannt ist, PHP einsetzen. Von diesen Websites laufen laut W3Techs 65,5 % auf PHP 8 und 26,8 % auf PHP 7 (Stand 25. Oktober 2026). Für PHP 7 und für PHP 8.1 und älter liefert das PHP-Projekt keine Updates mehr. Wegen der Schwere der Lücken hat das Sicherheitsteam trotzdem minimale Korrekturen im Quelltext für PHP 7.4, 8.0 und 8.1 bereitgestellt, für alle, die PHP selbst übersetzen. Einige Linux-Distributionen und Anbieter mit Langzeitpflege liefern ebenfalls Korrekturen für ältere Versionen.

PHP 8.2 bekommt nach Angaben des Projekts nur noch bis 31. Dezember 2026 Sicherheitskorrekturen.

So erkennen Sie Ihre PHP-Version

Entscheidend ist die vollständige Versionsnummer mit drei Teilen, etwa 8.3.34. Behoben sind die Lücken ab 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Diese Wege führen zur Nummer:

1. In der Verwaltung Ihres Hostings. Die meisten Hoster zeigen die PHP-Version je Website in ihrer Oberfläche an und lassen dort auch umstellen.
2. In WordPress. Unter „Werkzeuge“, „Website-Zustand“, Reiter „Bericht“, Abschnitt „Server“ steht die PHP-Version.
3. Bei Ihrer Agentur oder Ihrem Hoster nachfragen. Fragen Sie nach der vollständigen Nummer und danach, ob das Update vom 21. Oktober 2026 eingespielt ist, auf allen Servern, auch für Test- und Nebenseiten.
4. Von außen, mit Einschränkung. Manche Server nennen die Version in der Antwort an den Browser, im Feld „X-Powered-By“, etwa „PHP/8.3.34“. Viele Server senden diese Angabe nicht. Fehlt sie, heißt das nicht, dass kein PHP läuft.

Eine Besonderheit: Linux-Distributionen spielen Korrekturen oft in ihre eigenen Pakete ein, ohne die Versionsnummer von PHP zu ändern. Dann kann eine niedrigere Nummer trotzdem korrigiert sein. Maßgeblich ist in diesem Fall die Sicherheitsmeldung der Distribution. php.net weist ausdrücklich darauf hin, dass Distributionen und Anbieter mit Langzeitpflege die Korrekturen vorab erhalten haben.

Was Betreiber jetzt tun

1. Version feststellen, wie oben beschrieben.
2. Aktualisieren lassen auf PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder ein korrigiertes Paket der Distribution. Das erledigt in der Regel Ihr Hoster oder Ihre Agentur. Wenn Sie in der Hosting-Verwaltung selbst einen PHP-Zweig gewählt haben, etwa 7.4, prüfen Sie, ob für diesen Zweig überhaupt noch Korrekturen kommen.
3. Bestätigung einholen, schriftlich und mit Versionsnummer. „Wir halten alles aktuell“ ist keine Versionsnummer.
4. Wenn das Update nicht gleich möglich ist: php.net beschreibt Einstellungen, die einzelne Angriffswege einschränken, etwa Grenzen für die Größe von Anfragen und das Abschalten des Upload-Fortschritts für Sitzungen (session.upload_progress.enabled=0). Das Projekt schreibt selbst, dass diese Maßnahmen eine Installation nicht absichern und nur ein Update vollständig abhilft. Diese Einstellungen gehören in die Hände Ihres Hosters.
5. PHP 8.1 oder älter: Planen Sie den Umstieg auf eine gepflegte Version. Bis dahin hängt die Korrektur davon ab, ob Ihr Anbieter einen Rückport liefert.
6. PHP 8.2: Planen Sie den Umstieg vor dem 31. Dezember 2026.

Was über Angriffe bekannt ist, Stand 25. Oktober 2026

Ob und wo die Lücken bereits ausgenutzt werden, war am 25. Oktober 2026 nicht bestätigt. Das BSI schrieb in Version 1.2 seiner Warnung vom 22. Oktober, ihm sei noch keine erfolgreiche Ausnutzung in der Breite bekannt; es gebe unbestätigte Berichte über existierende Angriffswerkzeuge. Unit 42, die Forschungsabteilung von Palo Alto Networks, hatte am 23. Oktober eine Verbindung zu einem Angriff auf eine europäische Behörde gemeldet und diese Meldung am 25. Oktober zurückgezogen. Im Katalog ausgenutzter Lücken der US-Behörde CISA standen die beiden Nummern in der Fassung vom 23. Oktober 2026 nicht.

Unit 42 nennt nach eigener Messung über 22,6 Millionen aus dem Internet erreichbare Installationen, die möglicherweise verwundbar sind. Die Zahl steht hier laut Unit 42, unabhängig nicht überprüft.

Wie schnell eine PHP-Lücke in diesem Katalog landen kann, zeigt ein älterer Fall: Die Lücke CVE-2024-4577 in PHP-CGI hat das PHP-Projekt mit Version 8.3.8 am 6. Juni 2024 behoben. Am 12. Juni 2024 nahm CISA sie in den Katalog ausgenutzter Lücken auf, mit dem Vermerk, dass sie in Erpressungskampagnen genutzt wurde.

Was wir in der Sicherheits-Automation daraus machen

Für Websites in unserer Sicherheits-Automation führen wir ein Software-Inventar: welche Komponente in welcher Version läuft, PHP eingeschlossen. Erscheint eine Meldung wie die vom 21. Oktober 2026, gleicht der Prüfablauf sie mit diesem Inventar ab. Die Frage „Läuft hier eine PHP-Version vor 8.3.36?“ ist dann mit einem Blick in das Inventar beantwortet, nicht mit einer Suche.

Trifft eine Lücke zu, melden wir Ihnen das mit Befund und Vorschlag, spielen das Update im vereinbarten Rahmen ein und messen danach die Version nach. Wo nur der Hoster aktualisieren kann, sagen wir Ihnen das und richten bis dahin die Einstellungen ein, die das PHP-Projekt als Zwischenmaßnahme nennt. Im Monatsbericht steht, wann welche Version auf welchem Server lief.

Und diese Website?

plusento.com setzt kein PHP ein. Die Seiten sind fertige HTML-Dateien, nginx liefert sie aus, das Formular nimmt ein eigener Dienst in Node entgegen. Das ist kein Freibrief: Node, nginx und der Seitengenerator Astro haben eigene Sicherheitsmeldungen, die wir genauso verfolgen.