PHP Sicherheitsupdate durchführen: Versionen prüfen, patchen, testen und Worker neu starten

Das Ticket ist kurz: „PHP kritisch, bitte sofort prüfen." Im Browser öffnet ein Kollege die GitHub-Advisories, ein anderer schaut nach, auf welchen Versionen die drei Produktivsysteme laufen – und stellt fest, dass zwei davon noch auf PHP 8.3.34 stehen. Genau in diesem Moment beginnt eine kontrollierte Notfallreaktion, die in den nächsten Stunden entweder sauber oder chaotisch verläuft.

Das PHP-Projekt hat am 20. Oktober 2026 ein kritisches Sicherheitsrelease angekündigt und die gepatchten Builds einen Tag später, am 21. Oktober 2026, veröffentlicht. Wer ein PHP Sicherheitsupdate durchführen muss, hat es in diesem Fall mit zwei kritischen RCE-Schwachstellen zu tun, die ohne Authentifizierung aus dem Netz ausnutzbar sind.

Was hinter CVE-2026-109618 und CVE-2026-109619 steckt

Beide Schwachstellen tragen den CVSS-v4.0-Basiswert 9.2 (Vektor: AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H). Das bedeutet: nicht authentifizierte Remote-Code-Ausführung mit den Rechten des Web-Worker-Kontos. Die hohe Angriffskomplexität (AC:H) zeigt, dass ein Angreifer bestimmte Bedingungen herstellen muss – einfache Massenscanns sind damit schwieriger, gezielte Angriffe aber realistisch.

CVE-2026-109618 – „RCE via OOM corruption" (GitHub Advisory GHSA-w8hw-w9fx-j79w): PHP verlässt einen Request bei Speichermangel per longjmp(). In bestimmten Startphasen ist Request-Speicher erreichbar, bevor er vollständig initialisiert ist. Der Abbruch hinterlässt ungültigen Zustand, den das Request-Ende weiterverwendet. Beim Parsen von Multipart-Anfragen ist dieser Pfad besonders zugänglich. Für Apache mod_php ist RCE über HTTP mit Standardlimits demonstriert. Für PHP-FPM, FrankenPHP und LSAPI gilt laut Quellcodeanalyse: voraussichtlich anfällig, ein vollständiger Exploit ist dort nicht demonstriert.

CVE-2026-109619 – „RCE via stale global state" (GitHub Advisory GHSA-6wmf-4rv5-p3rp): Globaler Zustand eines Workers – Fehler-, Session-, Objekt- und Extension-Zustand – zeigt nach Request-Ende auf bereits freigegebenen Speicher (Use-after-free). Ein Angreifer benötigt zwei aufeinanderfolgende Requests an denselben Worker. Für Apache mod_php ist RCE bestätigt. Für PHP-FPM ist der Pfad über „session upload progress" validiert.

Betroffene Versionen und Patches

Betroffen sind alle Versionen unter 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Die Schwachstellen sind ausschließlich in diesen gepatchten Versionen behoben:

PHP 8.1 und älter erhalten vom PHP-Projekt keine offiziellen Updates mehr. Das PHP-Security-Team hat minimale Quell-Backports für 7.4, 8.0 und 8.1 veröffentlicht – Distributionen, Hoster und LTS-Anbieter wie Plesk liefern teils eigene Backports. Für PHP 5 gibt es keinen Patch.

Workarounds schützen nicht vollständig

Das Advisory listet mehrere Teilmaßnahmen, die die Angriffsfläche verkleinern, aber keine vollständige Abhilfe bieten: memory_limit=-1 ohne RLIMIT-Grenzen, konservative post_max_size, Begrenzung von Eingabevariablen, Blockade von Multipart-Anfragen am Frontend, session.upload_progress.enabled=0, fatal_error_backtraces=0 (PHP 8.5), pm.max_requests=1. Diese Maßnahmen können als Überbrückung sinnvoll sein, ersetzen das Update nicht. Die einzige vollständige Abhilfe laut PHP-Projekt: Update auf eine gepatchte Version und anschließender Neustart aller PHP-Worker.

Zur Ausnutzungslage: Das Sicherheitsunternehmen watchTowr meldet, in seinem Honeypot-Netz seit dem 21. Oktober 2026 Ausnutzungsversuche beobachtet zu haben. In Fachmedien kursiert der Name „PHP2Shell" für entsprechende Angriffswerkzeuge. Das ist eine einzelne Herstellerquelle; eine behördliche Warnung durch ENISA oder BSI zu diesen CVEs ist nicht verifiziert.

PHP Sicherheitsupdate durchführen: Der vollständige Ablauf

Das Ziel ist klar: alle PHP-Worker auf einer gepatchten Version, getestete Geschäftsprozesse, dokumentierter Rollback-Pfad. Der folgende Ablauf orientiert sich an einer typischen LAMP/LEMP-Umgebung mit PHP-FPM, ist aber auf Apache mod_php und andere SAPI-Varianten übertragbar.

Schritt 1 – Inventar erstellen

Bevor ein einziges Paket aktualisiert wird, muss bekannt sein, was wo läuft. Typische blinde Flecken in mittleren IT-Umgebungen: ein vergessener Staging-Server, ein Legacy-CMS auf einem Subhostingsystem, ein Cronjob-Knoten mit separater PHP-Installation.

Auf jedem Zielsystem die aktive PHP-Version prüfen:

php -v
php-fpm8.3 -v    # oder php-fpm8.2 etc.

Bei Webservern mit mehreren PHP-Versionen (häufig bei cPanel, Plesk oder ISPConfig) hilft:

find /usr/bin /usr/local/bin /opt -name 'php*' -type f 2>/dev/null | xargs -I{} {} -v 2>/dev/null

Notiere je System: PHP-Version, SAPI (FPM, mod_php, CLI, FrankenPHP, LSAPI), Betriebssystem und Paketverwaltung (apt, dnf, brew, portage, manuelles Kompilat). Systeme auf PHP 8.1 oder älter markieren – hier ist der Pfad zum Patch abhängig vom Distributor oder Hoster.

Schritt 2 – Backup und Rollback-Punkt sichern

Ein Update ohne Rollback-Pfad ist ein Glücksspiel. Vor dem Patch:

• Systemsnapshot oder VM-Snapshot anlegen (bei Cloud-VMs: snapshot via API oder Konsole)
• Datenbankdump mit Zeitstempel
• Aktuelle PHP-Konfiguration sichern: php.ini, alle conf.d-Dateien, FPM-Poolkonfigurationen
• Webserver-Konfiguration sichern: vHost-Dateien, .htaccess-Dateien, NGINX-Configs
• Paketliste einfrieren (Debian/Ubuntu: dpkg --get-selections > pkg-list-$(date +%F).txt)

Bei Plesk-Umgebungen: Plesk selbst liefert für die mitgelieferten PHP-Versionen teils eigene Backports – der Plesk-Support-Artikel zu CVE-2026-109618 und CVE-2026-109619 beschreibt den spezifischen Update-Pfad.

Schritt 3 – Staging-Test vor dem Produktivupdate

Wer kein Staging-System hat, baut eines – zumindest für diesen Vorgang. Ein kurzzeitiger Snapshot einer Produktivmaschine in einer isolierten Netzwerkzone reicht für den Funktionstest. Auf dem Staging-System zuerst patchen, dann die kritischsten Anwendungsflüsse testen:

• PHP-Anwendung startet ohne Fehler
• Login und Session-Handling funktionieren (besonders relevant für CVE-2026-109619 via Session-Upload-Progress)
• Datei-Uploads und Multipart-Formulare verarbeiten korrekt (besonders relevant für CVE-2026-109618)
• Datenbankverbindungen bestehen
• Cron-Jobs und CLI-Skripte laufen ohne Fatal Errors durch

Wenn Erweiterungen (Extensions) oder Anwendungen eine bestimmte PHP-Nebenversionsserie erwarten – etwa ext-xdebug, ext-imagick oder Composer-Abhängigkeiten mit fest gepinnter PHP-Rangeangabe – treten Inkompatibilitäten hier zutage, nicht im Produktivbetrieb.

Schritt 4 – Das eigentliche PHP-Update installieren

Debian/Ubuntu (apt):

sudo apt-get update
sudo apt-get install --only-upgrade php8.3 php8.3-fpm php8.3-cli
# Für mehrere Versionen entsprechend wiederholen
sudo apt-get install --only-upgrade php8.2 php8.2-fpm php8.2-cli

Nach der Installation die Versionen verifizieren:

php8.3 -v    # muss 8.3.36 ausgeben
php8.2 -v    # muss 8.2.35 ausgeben

RHEL/AlmaLinux/Rocky Linux (dnf/rpm):

sudo dnf update php php-fpm

manuell kompilierte PHP-Instanzen (selten in Produktivumgebungen, aber existent): Den neuen Quellcode von php.net herunterladen, mit identischen ./configure-Flags kompilieren, vorhandene Binaries ersetzen. Genau hier liegt das Risiko: abweichende Compiler-Flags führen zu Verhaltensunterschieden. Dokumentiere die verwendeten Flags.

Composer-Abhängigkeiten werden durch das PHP-Binary-Update selbst nicht berührt. Prüfe nach dem Update trotzdem, ob composer check-platform-reqs sauber durchläuft.

Schritt 5 – PHP-FPM neu starten und alle Worker ersetzen

Das ist der kritischste Schritt, der im Alltag am häufigsten vergessen oder halbherzig ausgeführt wird. Ein bloßer Reload genügt nicht – die laufenden Worker-Prozesse müssen durch neue Prozesse ersetzt werden, die den gepatchten Code laden.

PHP-FPM vollständig neu starten (systemd):

sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm

systemctl reload sendet nur SIGUSR2 und tauscht die Worker graceful aus – das ist für Zero-Downtime-Deployments nützlich, aber es können kurzzeitig noch alte Worker-Prozesse aktive Requests abarbeiten. Bei einem Sicherheitspatch ist ein harter Restart (stop → start oder restart) vorzuziehen.

Apache mod_php: Hier läuft PHP direkt im Apache-Prozess. Den Webserver selbst neu starten:

sudo systemctl restart apache2    # Debian/Ubuntu
sudo systemctl restart httpd      # RHEL-basiert

NGINX + PHP-FPM: NGINX muss nicht neu gestartet werden. Nur PHP-FPM-Dienst(e) neu starten, wie oben gezeigt.

FrankenPHP und LSAPI: Prozesse vollständig beenden und neu starten – konkrete Befehle hängen von der Betriebsumgebung ab (Supervisor, systemd, Docker).

Docker-basierte Umgebungen: Das Docker-Image auf die gepatchte PHP-Version aktualisieren, Container neu bauen und deployen. Das bloße Neu-Starten des Containers ohne Image-Update bringt keine gepatchte Version.

Nach dem Neustart prüfen, dass die neuen Worker-Prozesse mit dem gepatchten Binary laufen:

ps aux | grep php-fpm
# PID-Zeitstempel sollten nach dem Restart-Zeitpunkt liegen

Schritt 6 – Smoke-Tests auf dem Produktivsystem

Nach dem Produktivupdate sofort prüfen:

1. HTTP-Antwortcodes der kritischen URLs (200, keine 500/502/503)
2. Login-Flow – Session-Handling ist ein direkter Angriffspunkt von CVE-2026-109619
3. Datei-Upload – Multipart-Verarbeitung ist ein direkter Angriffspunkt von CVE-2026-109618
4. Cron-Jobs – PHP-CLI-Version prüfen
5. Monitoring-Alerts – bestehende Alarmierungen für 5xx-Raten, Speicher und CPU im Blick behalten

Ein einfacher Smoke-Test für die PHP-Version aus dem Webserver-Kontext (über eine temporäre, nicht öffentliche Route):

<?php echo PHP_VERSION; ?>

Diese Datei nach dem Test sofort entfernen – sie liefert sonst Versionsinformationen an Angreifer.

Schritt 7 – Rollback, wenn etwas schiefgeht

Der Snapshot aus Schritt 2 ist der Fallback. Konkretes Vorgehen:

• VM-Snapshot wiederherstellen (erfordert kurzen Ausfall)
• Alternativ: Downgrade auf die vorherige Paketversion via apt-get install php8.3=<alte-version> – nur wenn das Paket noch im Cache vorliegt
• Apache oder PHP-FPM danach neu starten
• Ursache des Fehlers dokumentieren und in der Staging-Umgebung lösen, bevor der Produktivversuch wiederholt wird

Schritt 8 – Dokumentation und Nachbereitung

Ein Patch ohne Dokumentation ist ein Patch, der beim nächsten Audit unbekannte Fragen aufwirft. Festhalten:

• Datum und Uhrzeit des Updates je System
• Vorherige und neue PHP-Version
• Wer das Update durchgeführt hat
• Ergebnis der Smoke-Tests
• Eventuelle Anpassungen an Konfigurationen oder Anwendungscode

Außerdem nach dem Patch empfohlen (unabhängig vom Update): session.upload_progress.enabled=0 in der php.ini setzen, wenn Session-Upload-Progress nicht genutzt wird. Und pm.max_requests=1 in FPM-Pools erwägen, wo es die Last erlaubt – das begrenzt die Lebensdauer von Workern und reduziert das Use-after-free-Fenster, ist aber kein Ersatz für den Patch.

Hypothetisches Praxisbeispiel: Mittelständischer Onlineshop auf PHP 8.3.34

Ein Online-Shop-Betreiber mit Magento 2.4 auf einem dedizierten Server betreibt PHP 8.3.34 unter PHP-FPM hinter NGINX. Am 21. Oktober 2026 erscheint das Advisory. Der Betreiber führt folgende Schritte durch:

Tag 1 (21.10.): Inventory – alle PHP-Binaries und FPM-Pools identifiziert. Snapshot des Servers erstellt. Staging-VM aus Snapshot hochgefahren. apt-get update && apt-get install --only-upgrade php8.3 php8.3-fpm auf Staging ausgeführt. PHP-Version nach Update: 8.3.36. Checkout-Flow, Login, Bild-Upload im Admin getestet – keine Fehler. Dritte Composer-Abhängigkeit ext-imagick läuft weiter.

Tag 1 (Abend, Wartungsfenster): Produktivupdate. apt-get install --only-upgrade php8.3 php8.3-fpm. systemctl restart php8.3-fpm. PHP-Version verifiziert: 8.3.36. Smoke-Tests: Startseite, Produktseite, Login, Checkout bis zur Zahlungsseite – alles grün. Monitoring-Dashboard zeigt normale 5xx-Rate.

Tag 2: Dokumentation abgeschlossen. session.upload_progress.enabled=0 in der php.ini gesetzt (da Funktion ungenutzt).

Dieses Vorgehen – Staging vor Produktiv, vollständiger FPM-Neustart, sofortige Smoke-Tests – ist das Minimum für einen kontrollierten Ablauf.

Sonderfälle: PHP 8.1 und älter, End-of-Life-Systeme

PHP 8.2 läuft noch bis 31. Dezember 2026 im Sicherheitssupport, erhält also Patches. PHP 8.1 hat dieses Datum bereits überschritten – das PHP-Projekt liefert keine offizielle gepatchte Version. Systeme auf 8.1 sind damit dauerhaft exponiert, sofern kein Distributor oder Hoster einen Backport liefert.

Wer PHP 8.1 oder älter betreibt, steht vor einer Entscheidung: entweder kurzfristig auf einen Support-Branch migrieren (8.3 oder 8.4 empfehlen sich nach aktueller Supportlaufzeit) oder zumindest die Workaround-Maßnahmen aus dem Advisory als Notpflaster aktivieren – bei klarem Bewusstsein, dass diese keinen vollständigen Schutz bieten.

Eine Migration von PHP 8.1 auf 8.3 oder 8.4 ist kein Drop-in-Austausch. Abhängigkeiten, Deprecations und Typstriktheit haben sich über zwei Hauptversionen verändert. Das erfordert eine vollständige Testphase, nicht nur einen Smoke-Test. Systeme auf PHP 7.x oder 5.x in Produktion sind ein eigenes Kapitel – dort ist das Sicherheitsrisiko struktureller Natur und übersteigt diesen einzelnen Patch.

Eine vollständige Übersicht über kritische PHP-Sicherheitslücken 2026 und den strategischen Modernisierungskontext hilft dabei, den Handlungsbedarf über diesen einzelnen Patch hinaus einzuordnen.

Wann Sie das Update begleiten lassen sollten

Ein Sicherheitsupdate unter Zeitdruck auf einem System durchzuführen, das man gut kennt und das ein sauberes Staging hat, ist handhabbar. Die Situation ändert sich in folgenden Konstellationen:

• Kein Staging-System vorhanden: Das Update wird direkt in Produktion getestet – der Ausfall bei einem Fehler trifft Kunden oder interne Abläufe.
• Gemischte PHP-Versionen: Mehrere Anwendungen, teils mit widersprüchlichen Versionsanforderungen, auf demselben Server.
• PHP 8.1 oder älter: Kein offizieller Patch verfügbar, Migration notwendig, Kompatibilitätsprüfung aufwendig.
• Legacy-Anwendungen: Keine aktive Wartung, unklare Extension-Abhängigkeiten, kein composer.lock mit aktuellen Prüfsummen.
• Fehlende Dokumentation: Weder der Update-History noch der aktuellen Konfiguration ist vertrauenswürdig.
• Produktivausfälle politisch nicht tolerierbar: Etwa bei kritischen Buchungssystemen, Produktionssteuerungen oder Patientenportalen.

In diesen Fällen ist das Risiko eines unkontrollierten Ausfalls höher als der Aufwand einer begleiteten Durchführung. SW Business Solutions übernimmt Inventar, Staging-Aufbau, Update-Durchführung, Smoke-Tests, Rollback-Plan und technische Abnahme – mit dokumentiertem Ergebnis.

Weiterführende Maßnahmen nach dem Patch

Das Update schließt die Lücke. Es beantwortet aber nicht die Frage, ob die Schwachstelle bereits ausgenutzt wurde. Wer seine Anwendung zwischen dem 21. Oktober 2026 und dem Patch-Zeitpunkt öffentlich zugänglich hatte, sollte prüfen:

• Webserver-Logs auf ungewöhnliche POST-Anfragen mit Multipart-Bodies und auffälligen Content-Length-Werten
• Neue oder modifizierte Dateien im Webroot (Webshells)
• Unbekannte Prozesse oder Cron-Jobs, die unter dem Web-Worker-Konto laufen
• Unerwartete ausgehende Verbindungen vom Webserver

Eine Anleitung zur systematischen Nachuntersuchung – Logs, Webshells, Konten und Daten – folgt als separater Artikel in dieser Serie.

Strukturell lohnt es sich nach diesem Vorfall, das Thema Patch-Management zu überdenken: Wie lange dauerte es vom Advisory (20.10.) bis zur ersten Maßnahme? Wer auf Systemen arbeitet, die mehrere Tage ohne Monitoring und Paket-Update-Routine laufen, hat ein strukturelles Problem – nicht nur ein akutes. Automatisierte Sicherheitsupdates für PHP-Pakete (mit Staging-Validierung), regelmäßige Versionschecks und klare Eskalationswege für kritische Advisories sind Investitionen, die sich genau in solchen Situationen amortisieren.

Wenn Sie regelmäßige Managed IT-Services für den Mittelstand in Betracht ziehen, ist ein strukturiertes Patch-Management einer der Kernbestandteile, der solche Notsituationen zu Routinevorgängen macht.

Jetzt handeln: PHP-Update begleitet umsetzen lassen

Wenn Ihr System PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 noch nicht erreicht hat, läuft es auf einer Version mit bestätigten kritischen RCE-Lücken. Je länger das Fenster offenbleibt, desto wahrscheinlicher wird eine Ausnutzung – Honeypot-Daten von watchTowr zeigen aktive Angriffsversuche seit dem 21. Oktober 2026.

SW Business Solutions plant und begleitet das Update: Inventar, Staging-Test, Produktiv-Rollout, Worker-Neustart, Smoke-Tests und Dokumentation. Der nächste Schritt ist ein kurzes Erstgespräch, in dem wir gemeinsam klären, welche Systeme betroffen sind und wie der Ablauf aussieht.

Kritisches PHP-Update begleitet umsetzen lassen – sprechen Sie uns direkt an.