Für ein Drittel der WordPress-Server baut PHP keine neue Version

Der Rat, den die Agenturmeldung heute „IT-Experten“ zuschreibt, lautet: Sicherheitsupdates ohne jeden Verzug einspielen. Er setzt voraus, dass es eines gibt. Seit dem Nachmittag gibt es eines, für vier Zweige: 8.5.12, 8.4.27, 8.3.36 und 8.2.35¹. Von den WordPress-Installationen, die ihre Version an wordpress.org melden, laufen nach den Rohdaten vom 21. Oktober api.wordpress.org ↗ 36,4 Prozent auf älteren Zweigen. W3Techs, das Websites von außen abfragt, kommt für alle PHP-Websites auf rund 48 Prozent. Für diese Server baut das Projekt keine Version; es legt für 7.4, 8.0 und 8.1 je einen Patch im Quelltext auf GitHub, den man selbst einkompilieren muss. Dass die alten Zweige keine Version bekommen, hatten das BSI und die US-Sicherheitsfirma Huntress vor dem Release geschrieben, die Agenturmeldung nicht.

Seit 14:23 Uhr läuft die dpa-Zeile „Gravierende Sicherheitslücke bedroht weltweit Webseiten“ durch die Presse, ein Dutzend Häuser, zwei Drittel davon wortgleich. Zuvor hatten die Charité und die Stadt Mainz ihre Websites abgeschaltet, wie Potsdam Ende September nach der Citrix-Warnung². Es geht um zwei Lücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, „PHP2Shell“ genannt, beide mit Schweregrad 9,2 von 10 (CVSS).

Nach Darstellung von Huntress huntress.com ↗ erschien am Morgen des 20. Oktober in einem Technikforum ein Beitrag, wonach zwei kritische PHP-Lücken vor der Veröffentlichung stünden; er wurde gelöscht, Screenshots kursierten. Am Abend stellte das PHP-Sicherheitsteam eine Vorankündigung³ auf php.net: Die Sicherheitsversion komme am Mittwoch um 16 Uhr MESZ, laut Huntress einen Tag früher als ursprünglich vereinbart; üblich ist beim Projekt der Donnerstag⁴. Im Newsarchiv von php.net, das bis 2004 zurückreicht, findet sich keine zweite Überschrift, die eine Sicherheitsversion vorab ankündigt.

Um 15:31 Uhr MESZ stand dort noch allein diese Vorankündigung, um 15:36 Uhr die Sicherheitsmitteilung mit den vier Versionen, eine knappe halbe Stunde vor dem angekündigten Termin; die beiden Advisories auf GitHub tragen 13:34 UTC. Das Projekt sieht das Risiko für mod_php, das PHP-Modul des Apache-Webservers, am höchsten; die genannten Konfigurationsänderungen „reduce exposure to specific attack paths but do not make an installation safe“. Das BSI führte um 15:37 Uhr in seiner Übersicht weiter „Behebende Versionen: ausstehend“. Die vier Nummern, die der Sicherheitsforscher Kevin Beaumont am Vorabend auf Mastodon genannt hatte, waren die richtigen.

Für 7.4, 8.0 und 8.1 gibt es einen Patch auf GitHub, keine Version#

Die Regel steht auf php.net: zwei Jahre volle Pflege, zwei weitere Jahre nur Sicherheitsversionen, dann Ende. Für 8.1 kam das Ende am 31. Dezember 2025⁵ mit Version 8.1.34, für 8.0 am 26. November 2023, für 7.4 am 28. November 2022. Heute schreibt das Projekt: „PHP 8.1 and older no longer receive updates from the PHP project.“ Wegen der Schwere habe das Sicherheitsteam „minimal source-backports“ für 7.4, 8.0 und 8.1 bereitgestellt, „to help people building from source or without access to an LTS vendor“: je ein Commit vom 18. Oktober, im Zweig für 8.1 mit 23 geänderten Dateien. Eine Version 8.1.35 führt php.net nicht. Auf Seite 3 seines Hinweises hält das BSI bsi.bund.de ↗ fest: „Dabei haben alle PHP Versionen vor 8.2 bereits ihr End-of-Life erreicht. Auch PHP 8.2 wird nur noch bis zum Jahresende mit Sicherheitsupdates unterstützt.“ WordPress selbst empfiehlt PHP 8.3⁶, läuft aber laut eigener Anforderungsseite weiter „with PHP 7.4+“.

W3Techs⁷ zählt Websites statt Installationen und sieht PHP auf 69,3 Prozent aller Websites mit bekannter Serversprache; 65,2 Prozent davon laufen auf Version 8, und innerhalb von 8 liegen 79,0 Prozent auf den vier gepflegten Zweigen (34,8 + 27,7 + 12,1 + 4,4). Gepflegt sind damit 51,5 Prozent aller PHP-Websites, 48,5 Prozent nicht.

Eine 8.1 in der Statistik ist nicht automatisch ungeschützt#

Beide Anteile sind Obergrenzen. Debian, Ubuntu und Red Hat flicken Lücken teils in ältere Versionsnummern zurück; die Paketversion heißt dann weiter 8.1 oder 7.4, der Code ist repariert. Das BSI schreibt darum auf Seite 2, ein „Abgleich der installierten Version mit der von der Linux-Distribution bereitgestellten gepatchten (Backport) Version“ sei „möglicherweise notwendig“. Die Distributionen hätten die Patches vorab erhalten, schreibt das Projekt, „so check your vendor for updated packages“. Um 15:37 Uhr führte Ubuntu⁸ die Lücke als „Critical“, für php7.4, php8.1, php8.3 und php8.5 mit dem Stand „Needs evaluation“; der Debian-Tracker kannte den Eintrag nicht.

Huntress hatte am Vorabend geschrieben: „If you’re running PHP 5, 7, or 8.0/8.1, you may not get a fix at all“. Das BSI empfiehlt die Migration auf einen gepflegten Zweig und nennt die „vorübergehende Trennung des Webservers vom Internet“ als Ausweg, falls Patches nicht kurzfristig installiert werden können. Eine bestätigte Ausnutzung kennt das BSI nicht, nur „unbestätigte Berichte über existierende Exploits“; das Projekt beschreibt einen vorgeführten Exploit gegen mod_php, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, „before any application code runs“. Für 8.2, den Zweig mit 23,8 Prozent der WordPress-Installationen, endet die Pflege am 31. Dezember, in 71 Tagen; blieben die Anteile, wie sie sind, stünden dann noch 39,8 Prozent der Installationen auf einem gepflegten Zweig.