Kritisches PHP-Sicherheitsupdate am 21. Oktober: so aktualisieren Sie richtig

Das PHP-Sicherheitsteam hat für Mittwoch, 21. Oktober 2026, 14:00 Uhr UTC ein außerplanmäßiges Sicherheitsrelease angekündigt. Das ist 16:00 Uhr deutscher Zeit. Behoben werden zwei kritische Schwachstellen, beide mit CVSS v4.0 9.2 bewertet. Das Team behält sich vor, früher zu veröffentlichen, falls Details öffentlich werden oder Angriffe auftauchen. Genau das ist teilweise schon passiert: Am 20. Oktober sind Informationen zu den Lücken vorzeitig durchgesickert.

Ich schreibe diesen Beitrag am Vormittag vor dem Release, damit Sie die Stunden bis 16:00 Uhr sinnvoll nutzen können. Sobald die offiziellen Angaben vorliegen, aktualisiere ich ihn.

Stand: 21.10.2026, 10:00 Uhr. Betroffene und gefixte Versionen sind noch nicht offiziell. Alles, was dazu kursiert, ist unten als unbestätigt markiert.

Was bisher bekannt ist und was nicht

Offiziell bestätigt (Ankündigung auf php.net und im Kanal der PHP Foundation):

• Zwei kritische Schwachstellen, beide CVSS v4.0 9.2.
• Release am 21.10.2026 um 14:00 UTC, eventuell früher.
• Betroffene Versionen, gefixte Versionen und Details erscheinen erst mit dem Release.
• Aktuell unterstützt werden PHP 8.2, 8.3, 8.4 und 8.5 (zuletzt 8.2.34, 8.3.35, 8.4.26 und 8.5.11 vom 24. September). PHP 8.1 und älter sind End-of-Life und bekommen keinen offiziellen Fix.

Berichtet, aber nicht offiziell bestätigt:

• Die CVE-Nummern CVE-2026-109618 und CVE-2026-109619. Beide sind reserviert, eine Beschreibung gibt es noch nicht.
• Es soll sich um Remote Code Execution im PHP-Kern handeln, also um die Möglichkeit, über eine Anfrage beliebigen Code auf dem Server auszuführen. watchTowr gibt an, eine der beiden Lücken nachgestellt zu haben. In der Szene läuft das Ganze unter dem Namen "php2shell".
• Laut mehreren Berichten sind sehr alte Versionen mit betroffen, teils ist von PHP 5.4 aufwärts die Rede. Belegt ist das nicht.
• Als Fix-Versionen werden 8.2.35, 8.3.36, 8.4.27 und 8.5.12 erwartet. Das ist die logische nächste Patch-Nummer, aber noch keine offizielle Angabe.
• Angriffe in freier Wildbahn sind bislang nicht beobachtet worden, ein öffentlicher Exploit ist nicht bekannt. Sicherheitsfirmen wie Sansec rechnen allerdings mit massenhaftem Scannen kurz nach dem Release, weil der Patch selbst zeigt, wo die Lücke sitzt.

Für Sie heißt das: Ein Plugin, ein Framework-Update oder eine Änderung an Ihrem Code helfen hier nicht. Die Lücke sitzt in PHP selbst, also muss PHP selbst aktualisiert werden.

Bin ich betroffen?

Bis das Advisory etwas anderes sagt, gehen Sie davon aus: ja, auf jedem Server mit PHP. Die eigentliche Frage ist, welche Version wo läuft und wer sie aktualisiert. Das ist in vielen Firmen schwerer zu beantworten, als man denkt.

• Auf der Kommandozeile: php -v zeigt die CLI-Version. Die Webseite läuft aber oft über PHP-FPM oder mod_php, und das kann eine andere Version sein. Prüfen Sie zusätzlich php-fpm8.3 -v (bzw. die passende Versionsnummer) oder ls /etc/php/ auf Debian und Ubuntu.
• Im Browser: Eine kurz angelegte Datei mit phpinfo() zeigt die Version, die tatsächlich Ihre Seite ausliefert. Danach sofort wieder löschen.
• Plesk, cPanel, ISPConfig: Dort laufen oft mehrere PHP-Versionen parallel, pro Domain eine andere. Jede einzelne muss aktualisiert werden.
• Docker: Jedes Image hat sein eigenes PHP. Das Update des Host-Systems ändert daran nichts.
• Die vergessenen Server: der alte Staging-Server, das interne Tool im Keller, die Appliance eines Herstellers mit eingebautem PHP. Die werden bei solchen Updates am häufigsten übersehen.

Eine ausführlichere Anleitung zur Versionsprüfung finden Sie unter PHP-Version prüfen.

Wenn Sie nach diesem Abschnitt nicht sicher sagen können, welche Versionen bei Ihnen laufen, sprechen Sie mit uns. Der Kurz-Check ist kostenlos und dauert 30 Minuten.

Kostenlosen Kurz-Check anfragen

Oder direkt anrufen: 06192 9899814

Vorbereitung bis 16:00 Uhr

Die Stunden vor dem Release sind die wertvollsten. Danach ist die Lücke für jeden nachvollziehbar, der den Patch liest.

1. Inventar: Liste aller Server, Container und Hosting-Pakete mit PHP, jeweils mit Version und der Person, die dort Updates einspielt.
2. Backup oder Snapshot: Vor dem Update ein aktueller Stand von Dateien und Datenbank. Bei VMs reicht meist ein Snapshot.
3. Testplan: Fünf bis zehn Klicks, die zeigen, dass die Anwendung nach dem Update noch funktioniert: Login, Bestellung, Formular, ein Cronjob. Aufschreiben, nicht im Kopf behalten.
4. Wartungsfenster: Klären Sie heute, wer am Nachmittag oder Abend verfügbar ist. Ein Patch-Update ist normalerweise in Minuten erledigt, aber jemand muss es tun und danach testen.
5. Hoster fragen: Wenn Sie nicht selbst Root-Zugriff haben, fragen Sie jetzt nach, ob und wann Ihr Hoster patcht (Vorlage weiter unten).
6. Rückweg: Wissen Sie, wie Sie im Notfall auf den alten Stand zurückkommen? Bei einem Patch-Release ist das selten nötig, aber Sie sollten es wissen, bevor Sie anfangen.

So spielen Sie das Update ein

Patch-Releases innerhalb einer Version (etwa von 8.3.35 auf 8.3.36) ändern kein Verhalten, auf das Ihr Code sich verlässt. Ein Upgrade auf eine neue Minor-Version ist das nicht. Für heute gilt deshalb: innerhalb der laufenden Version aktualisieren, nichts anderes.

Debian und Ubuntu

Mit den Paketen von Ondřej Surý (deb.sury.org bzw. ppa:ondrej/php), die auf vielen Servern im Einsatz sind:

sudo apt update
sudo apt install --only-upgrade 'php8.3-*'
sudo systemctl restart php8.3-fpm

Die Versionsnummer passen Sie an Ihre an. Wenn Sie die Pakete der Distribution selbst nutzen, kommt der Fix über die normalen Sicherheitsupdates. Dort bleibt die Versionsnummer oft gleich und der Fix wird zurückportiert. Ob er drin ist, sehen Sie mit apt changelog php8.2-fpm anhand der CVE-Nummer, nicht an der Versionsnummer.

RHEL, AlmaLinux, Rocky

Mit dem Remi-Repository:

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

Docker

Ein Image aktualisiert sich nicht von selbst. Wenn Sie ein Tag wie php:8.3-fpm verwenden, ziehen Sie es nach dem Release neu, bauen Ihr Image und deployen:

docker pull php:8.3-fpm
docker build --pull -t meine-app .

Haben Sie eine exakte Version festgenagelt, etwa php:8.3.35-fpm, müssen Sie das Tag im Dockerfile anheben. Prüfen Sie außerdem, ob das offizielle Image schon aktualisiert ist, bevor Sie bauen. Das kann nach dem Release ein paar Stunden dauern.

Shared Hosting und Managed Server

Hier können Sie selbst nichts aktualisieren. Schreiben Sie Ihrem Hoster heute noch, zum Beispiel so:

"Das PHP-Team veröffentlicht heute um 16:00 Uhr Fixes für zwei kritische Lücken (CVSS 9.2). Bitte bestätigen Sie, wann Sie diese für unser Paket bzw. unseren Server einspielen und für welche PHP-Versionen. Wir nutzen PHP [Version]."

Achten Sie auf die Antwort. "Zeitnah" ist keine Antwort. Wenn Ihr Hoster für Ihre Version keinen Fix anbietet, wird es ernst (siehe nächster Abschnitt).

Windows, XAMPP, Hersteller-Appliances

Unter Windows tauschen Sie die PHP-Binaries gegen die neue Version von windows.php.net. Bei Software mit eingebautem PHP (Monitoring, Ticketsysteme, NAS-Oberflächen) sind Sie auf den Hersteller angewiesen. Fragen Sie dort aktiv nach.

Danach: neu starten und prüfen

Der häufigste Fehler nach einem PHP-Update: Das Paket ist neu, aber PHP-FPM oder Apache laufen noch mit dem alten Code im Speicher. Starten Sie die Dienste neu und prüfen Sie die Version dort, wo sie zählt, also über phpinfo() im Browser und nicht nur mit php -v. Dann gehen Sie Ihren Testplan durch.

Sie wollen das heute nicht selbst machen oder haben niemanden, der es kann? Schreiben Sie uns über das Kontaktformular oder per E-Mail. Wenn Sie wissen wollen, wie es um Ihre ganze Landschaft steht, ist der Befund der passende Einstieg.

Was, wenn Sie auf PHP 8.1 oder älter sind?

Dann bekommen Sie heute vom PHP-Projekt keinen Fix. Ob alte Versionen überhaupt betroffen sind, steht noch nicht fest. Ich würde nicht darauf wetten, dass sie es nicht sind.

• Backports der Distribution: Manche Distributionen und kommerzielle Anbieter (Debian LTS/ELTS, einige Enterprise-Distributionen, kostenpflichtige Backport-Dienste) liefern Fixes auch für ältere PHP-Versionen. Prüfen Sie, ob das für Ihre Version und Ihr System zutrifft. Woran es scheitert: Solche Backports kommen oft Tage später, und nicht jeder Hoster bezieht sie.
• Abschotten als Übergang: Anwendung hinter VPN oder IP-Freigabe stellen, wenn sie nicht öffentlich erreichbar sein muss, oder eine WAF davorschalten. Woran es scheitert: Eine WAF kennt die Lücke erst, wenn es Signaturen gibt, und ein öffentlicher Shop lässt sich nicht hinter ein VPN stellen.
• Das eigentliche Upgrade: auf eine unterstützte Version, damit Sie beim nächsten Mal einfach patchen können. Woran es scheitert: Das ist nicht in einem Nachmittag erledigt, wenn der Code noch auf PHP 7 aufbaut.

Mehr zu den Übergangslösungen steht in Sicherheitsupdates ohne Upgrade. Wenn Ihr Hoster deswegen ohnehin mit dem Abschalten droht, beschreibt diese Seite die Optionen. Den Weg auf eine unterstützte Version, getestet und ohne Neuentwicklung, bieten wir als Minimal-Migration an.

Nach dem Update: auf Spuren achten

Die Informationen sind seit gestern im Umlauf. Dass vor dem Release niemand angegriffen hat, kann niemand garantieren. Werfen Sie in den nächsten Tagen einen Blick auf ein paar Dinge:

• PHP-Prozesse, die Shells oder Werkzeuge wie sh, bash, curl, wget oder nc starten. Das tut eine normale Webanwendung selten.
• Neue oder veränderte PHP-Dateien im Web-Verzeichnis, vor allem in Upload-Ordnern.
• Neue Cronjobs, neue Benutzer, unerwartete ausgehende Verbindungen.
• Auffällige Anfragen im Access-Log rund um den 20. und 21. Oktober.

Wenn Sie etwas finden: Server vom Netz nehmen oder isolieren, Logs sichern, nicht einfach löschen und weitermachen. Wie so ein Fall in der Praxis abläuft, habe ich in Anwendung gehackt, alter Server beschrieben. Im Verdachtsfall erreichen Sie uns unter 06192 9899814.

Wer patcht beim nächsten Mal?

Dieses Release wird nicht das letzte kritische sein. Die interessantere Frage für die Zeit nach heute: Gibt es bei Ihnen eine Person oder einen Dienstleister, der für PHP-Updates zuständig ist, die Ankündigung mitbekommt und am selben Tag handelt? Bei vielen Firmen mit einer gewachsenen PHP-Anwendung lautet die ehrliche Antwort: Das hat bisher der Entwickler gemacht, der nicht mehr da ist.

Für genau diesen Fall gibt es die Werkstatt-Bereitschaft. Wir übernehmen Sicherheitsupdates, Monitoring und den Notfall, laufend und mit festem Ansprechpartner. Alle Pakete im Überblick finden Sie unter Pakete und Preise.

Ein ehrlicher Praxis-Tipp zum Schluss

Das Update selbst ist meistens der leichte Teil. Schwierig wird es, wenn sich heute herausstellt, dass niemand genau weiß, welcher Server mit welcher Version läuft und wer dort Zugriff hat. Schreiben Sie sich diese Liste heute auf, auch wenn das Update reibungslos läuft. Beim nächsten kritischen Release sparen Sie damit die halbe Zeit.

Wenn Sie dabei Hilfe brauchen, heute oder danach:

• Kostenloser Kurz-Check, 30 Minuten, unverbindlich
• Befund anfragen, wenn Sie es schriftlich und vollständig wollen
• Telefon: 06192 9899814
• E-Mail: info@ucar-solutions.de