- Aktenzeichen
- BEO-2026-051
- Eingang
- Rubrik
- Technik IT-Sicherheit
- Einstufung
- offen
- Verfasser
- M.V.R.H.S.Rufname
- Bearbeiter
PHP2Shell: Zwei kritische PHP-Lücken, Patches seit heute
.-. .-.
/ \ / \
| / \ | | / \ |
|| || || ||
|| || || ||
.-' ' - ' '-.
,' .--. .--. '.
.-. | _ | ___ | _ | ,.-.
( \ .(_).' \ / .(_).' / )
>- '--------\_|_/--------' -<
(_ .-------------------------. _)
`--- ---'-,
/ .-'''-. ';
; / ', \ Rabbit of
) / - y=, Caerbannog
_/ / /\ ' ; c
((((_/(((_______/_;,v=" ldb
ehrung an monty python. ascii-zeichnung von laura brown (ldb), via asciiart.website.
211620Z oct 26 · 51.7275 N, 11.5148 E
Das BSI warnt am 21. Oktober 2026 vor zwei Schwachstellen in PHP, die in Berichten „PHP2Shell“ genannt werden. Die Patches sind seit heute 16 Uhr deutscher Zeit verfügbar. Ich fasse hier den BSI-Hinweis, das Advisory des PHP-Projekts, die Warnung von CERT-EU und die Statusseiten von Debian und Ubuntu zusammen. Selbst getestet habe ich nichts.
Was das BSI meldet
Der Sicherheitshinweis (BITS-H Nr. 2026-297981-1032, Version 1.0) hat die Kritikalität 3 von 4, „Orange“: „Maßnahmen müssen unverzüglich ergriffen werden“. Betroffen sind zwei Lücken, CVE-2026-109618 und CVE-2026-109619, beide mit einem CVSS-Wert von 9.2 von 10 (CVSS 4.0). Laut BSI legen die Werte nahe, dass Angreifer aus der Ferne Code auf Webservern mit PHP ausführen könnten, ohne Anmeldung und ohne Zutun eines Nutzers. Der Name spielt auf „Log4Shell“ an.
Verwundbar sind nach BSI, das sich dabei auf CERT-EU beruft, alle bekannten PHP-Versionen „zurückgehend bis mindestens PHP 5“. Als Beispiele für verbreitete PHP-Software nennt das BSI WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense. Das zeigt die Größenordnung: Es geht nicht um ein Nischenprodukt, sondern um die Sprache, in der ein großer Teil der Websites, Shops, Cloud-Ablagen und sogar Firewall-Oberflächen geschrieben ist. Bestätigte Angriffe gab es zum Zeitpunkt des Hinweises nicht, aber „unbestätigte Berichte über existierende Exploits“. Das BSI hält eine breite Ausnutzung „innerhalb weniger Stunden nach Erscheinen der Patches für wahrscheinlich“. Der Grund ist bekannt: Sobald ein Patch öffentlich ist, lässt sich aus dem Unterschied zwischen altem und neuem Code ablesen, wo der Fehler lag.
Was CERT-EU vorab sagte
Das Computer-Notfallteam der EU-Institutionen hatte am 21. Oktober gewarnt, noch bevor es Patches gab. CERT-EU stützte sich auf die Vorankündigung des PHP-Projekts und auf weitere Berichte. Technische Details lagen damals nicht vor, nur die CVSS-Werte. Die Empfehlung lautete, PHP-Anwendungen zu inventarisieren und das Patchen vorzubereiten; wo das nicht sofort geht, sollten Organisationen erwägen, aus dem Internet erreichbare Anwendungen vom öffentlichen Netz zu trennen. Als Termin der Veröffentlichung nannte CERT-EU den 21. Oktober, 14:00 UTC, das sind 16 Uhr deutscher Zeit.
Was das PHP-Projekt sagt
Das PHP-Projekt hat am 21. Oktober 2026 PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Gefährdet sind laut Advisory alle Installationen, die Webanfragen bedienen, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Entscheidend ist also, ob PHP Anfragen aus dem Netz verarbeitet. Am höchsten schätzt das Projekt das Risiko bei mod_php ein: Dort sei ein Exploit gezeigt worden, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, „before any application code runs“. Eine sauber programmierte Anwendung schützt also nicht, weil der Fehler vor ihr greift.
Kurz zu den beiden Lücken, wie das Advisory sie beschreibt:
- CVE-2026-109618: Die Behandlung von Speichermangel (out of memory) kann PHP unterbrechen, während interne Anfragedaten nur halb initialisiert sind. Ubuntu ergänzt in der CVE-Beschreibung, dass das Aufräumen der Anfrage diese ungültigen Daten dann als gültig behandeln kann.
- CVE-2026-109619: Interner Zustand einer Anfrage kann überleben, obwohl sein Speicher schon freigegeben ist; eine spätere Anfrage im selben Worker kann ihn nutzen.
Beides sind Fehler im Umgang mit Speicher innerhalb von PHP selbst, nicht in einer Anwendung. PHP 8.1 und älter bekommt vom Projekt keine regulären Updates mehr. Wegen der Schwere gibt es aber minimale Quell-Backports für PHP 7.4, 8.0 und 8.1.
Welche Versionen noch wie lange Updates bekommen
Die Patches gibt es nur für die vier Zweige, die das Projekt noch pflegt. Wie lange sie noch Sicherheitsupdates bekommen, steht auf der Seite Supported Versions:
Dauer der Sicherheitsunterstützung je PHP-Zweig ab heute, mit Patch-Version. Quellen: php.net Supported Versions, PHP Security Advisory vom 21.10.2026.
PHP 8.2 bekommt also nur noch gut zwei Monate Sicherheitsupdates, das deckt sich mit dem BSI-Hinweis. Wer heute auf 8.2.35 patcht, hat das akute Problem gelöst, steht aber zum Jahreswechsel vor der nächsten Migration.
Wie weit die Distributionen sind
Viele Server beziehen PHP nicht direkt vom Projekt, sondern aus der Paketverwaltung ihrer Linux-Distribution. Laut PHP-Projekt haben Distributionen und LTS-Anbieter die Patches vorab bekommen. Der Stand bei meinem Abruf am Nachmittag war gemischt:
- Ubuntu stuft die Lücke als „Critical“ ein und listet unter anderem Korrekturen für PHP 8.3 in 24.04 LTS, für PHP 8.1 in 22.04 LTS und für PHP 8.5 in 26.04 LTS, dazu die Sicherheitsmeldung USN-8948-1.
- Debian meldete PHP 8.4 in Trixie über DSA-6574-1 als behoben, das PHP-8.2-Paket in Bookworm aber noch als verwundbar. Dasselbe Bild zeigt der Eintrag zu CVE-2026-109619.
Solche Tabellen ändern sich schnell. Wer Debian Bookworm betreibt, sollte den Tracker heute mehrfach prüfen.
Was ein Betreiber jetzt tun sollte
- Auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren, bei Distributionspaketen auf die gefixte Paketversion. Das BSI rät, den Stand mit
php -vgegen das Advisory abzugleichen, bei Backports gegen die Paketversion der Distribution. - Wer rpms.remirepo.net nutzt: Das Repo bekommt laut Advisory heute keine Updates. Das Projekt rät, auf Distributionspakete umzusteigen oder selbst zu bauen.
- Docker-Container mit PHP neu bauen bzw. aktualisieren (BSI). Ein altes Image bleibt verwundbar, auch wenn der Host gepatcht ist.
- Wer nicht sofort aktualisieren kann, nutzt die Übergangsmaßnahmen aus dem Advisory, die das Projekt ausdrücklich nicht als sicher bezeichnet. Zum Beispiel
session.upload_progress.enabled=0in php.ini oder im FPM-Pool und alle Worker neu starten, ein niedrigespost_max_size(8M ohne Uploads, 32M mit Uploads) undmemory_limit=-1so gesetzt, dass Anwendungen es nicht überschreiben. Unter PHP 8.5 zusätzlichfatal_error_backtraces=0. - Als letzte Möglichkeit nennt das BSI eine Web Application Firewall, sofern sie Erkennungen für die Lücken hat, oder den Webserver bis zum Patch vom Internet zu trennen; CERT-EU empfiehlt Letzteres ebenfalls.
- Exponierte PHP-Server verstärkt auf Auffälligkeiten beobachten. Konkrete Angriffsindikatoren gibt es laut BSI noch nicht.
- Alte Versionsstränge (vor 8.2, bald auch 8.2) auf eine unterstützte Version migrieren.
Für Geräte mit eingebautem PHP, etwa Firewalls wie pfSense oder OPNsense, hilft kein Paket-Update auf dem eigenen Server; hier ist ein Firmware-Update des Herstellers nötig.
Offen bleibt, ob die Lücken seit Erscheinen der Patches schon aktiv ausgenutzt werden.
Quellen
- BSI, 21.10.2026: PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit (BITS-H 2026-297981-1032)
- PHP, 21.10.2026: Security advisory: Critical remote code execution vulnerabilities, update now
- CERT-EU, 21.10.2026: Security Advisory 2026-018: Critical Vulnerabilities in PHP
- PHP: Supported Versions (abgerufen 21.10.2026)
- Debian Security Tracker: CVE-2026-109618, CVE-2026-109619 (abgerufen 21.10.2026)
- Ubuntu: CVE-2026-109618 (abgerufen 21.10.2026)
Horidor