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

Aktualisiert am 31. Oktober 2026. Das PHP-Team hat am 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Schwachstellen, CVE-2026-109618 („RCE via OOM corruption“) und CVE-2026-109619 („RCE via stale global state“), beide mit CVSS v4.0 9.2 bewertet. Beide erlauben Remote Code Execution ohne Anmeldung, also das Ausführen beliebigen Codes auf dem Server über eine einzelne Anfrage. php.net dazu wörtlich: Es gibt keine vollständige Gegenmaßnahme, das Update ist die einzige sichere Wahl.

Ich habe diesen Beitrag am Vormittag vor dem Release geschrieben und danach um die offiziellen Angaben ergänzt. Die Vorbereitungsschritte weiter unten gelten unverändert, auch wenn Sie erst jetzt lesen.

Was offiziell bestätigt ist

Stand 31. Oktober, Quelle sind php.net und die Advisories des PHP-Projekts:

• Gefixte Versionen: 8.2.35, 8.3.36, 8.4.27 und 8.5.12, veröffentlicht am 21. Oktober 2026. Als betroffen nennen die Advisories alle Versionen davor.
• CVE-2026-109618: Codeausführung über eine Speicherkorruption, wenn PHP bei einem Out-of-Memory-Fehler den Request abbricht. CVE-2026-109619: Codeausführung über globalen Zustand, der von einem Request zum nächsten überlebt (Use-after-free). Beide CVSS v4.0 9.2, beide ohne Anmeldung ausnutzbar.
• Es gibt keine vollständige Gegenmaßnahme in der Konfiguration. Für die erste Lücke nennen die Advisories ein administrativ erzwungenes memory_limit=-1 als Teil-Mitigation und raten ausdrücklich davon ab, stattdessen RLIMIT_AS oder RLIMIT_DATA zu setzen. Wer nicht sofort patchen kann, sollte das als Übergang kennen, nicht als Lösung.
• Nachtrag vom 23. Oktober: Das PHP-Team empfiehlt, session.upload_progress.enabled=0 zu setzen, bis das nächste reguläre Bugfix-Release einen weiteren, laut Team unwahrscheinlichen Angriffsweg (CVE-2026-115560) schließt. Wer das Feature nicht nutzt, kann es dauerhaft abschalten.
• Nachtrag vom 26. Oktober: Für Windows gibt es neu gebaute Pakete (8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1) mit Brotli 1.2.1 wegen CVE-2026-111497 in der Brotli-Dekompression. Erreichbar ist die Lücke über die cURL-Erweiterung, wenn die automatische Dekompression aktiviert ist.
• PHP 8.1 und älter sind End-of-Life und haben keinen offiziellen Fix bekommen. PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitsupdates.

Die Angaben, die vor dem Release kursierten (die Fix-Versionen, die CVE-Nummern, der Name „php2shell“), haben sich damit bestätigt.

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?

Ja, auf jedem Server, der noch eine Version vor 8.2.35, 8.3.36, 8.4.27 bzw. 8.5.12 ausführt. 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, bevor Sie patchen

Seit dem Release ist die Lücke für jeden nachvollziehbar, der den Patch liest. Wer noch nicht aktualisiert hat, sollte das nicht weiter aufschieben, aber auch nicht blind erledigen. Sechs Punkte vorher, dann das Update.

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, wer das Update einspielt und wer danach testet. 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 dieses Update 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. Hat Ihr Hoster sich nicht von selbst gemeldet, schreiben Sie ihm, zum Beispiel so:

"Das PHP-Team hat am 21. Oktober mit 8.2.35, 8.3.36, 8.4.27 und 8.5.12 zwei kritische Lücken (CVSS 9.2) geschlossen. Bitte bestätigen Sie, ob und wann Sie diese Versionen für unser Paket bzw. unseren Server eingespielt haben. 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 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 vom PHP-Projekt keinen Fix. Die Advisories nennen als betroffen alle Versionen vor den gefixten Releases, eine Entwarnung für 8.1 und älter gibt es nicht.

• 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 waren schon vor dem Release im Umlauf, und seit dem 21. Oktober zeigt der Patch jedem, wo die Lücke sitzt. Dass Ihr Server bis zum Update unangetastet blieb, 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 danach: 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 herausstellt, dass niemand genau weiß, welcher Server mit welcher Version läuft und wer dort Zugriff hat. Schreiben Sie sich diese Liste jetzt auf, auch wenn das Update reibungslos lief. Beim nächsten kritischen Release sparen Sie damit die halbe Zeit.

Wenn Sie dabei Hilfe brauchen, jetzt 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