Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Korrekturen für zwei kritische Schwachstellen, die eine nicht authentifizierte Ausführung fremden Codes ermöglichen können. Korrigiert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die offizielle Empfehlung ist eindeutig: PHP soll sofort aktualisiert werden.
Wenn Ihr Unternehmen eine ältere PHP-Anwendung nutzt, bedeutet das nicht automatisch, dass sie sofort neu gebaut werden muss. Zuerst braucht die Laufzeitumgebung den Patch. Ein Kompatibilitätstest zeigt danach, ob die Anwendung unverändert weiterlaufen kann, aktualisierte Abhängigkeiten benötigt, schrittweise modernisiert oder kontrolliert neu gebaut werden sollte.
Das Neuschreiben des Anwendungscodes schließt keine Sicherheitslücke im PHP-Interpreter. Ein PHP-Update allein garantiert wiederum nicht, dass eine alte Anwendung mit der neuen Umgebung kompatibel ist. Es handelt sich um zwei getrennte Probleme und Entscheidungen.
Quellen zuletzt geprüft: 23.10.2026. Prüfen Sie vor einer Änderung den aktuellen Hinweis des PHP-Projekts und die Informationen des Anbieters Ihres Betriebssystems, Hostings oder Container-Images.
Was hat das PHP-Projekt genau bekannt gegeben?
Der Hinweis vom 21. Oktober betrifft CVE-2026-109618 und CVE-2026-109619. Nach Angaben des PHP-Projekts sind Installationen gefährdet, die Webanfragen bedienen, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko wurde für mod_php beschrieben. Dort konnte eine nicht authentifizierte Anfrage den Angriff auslösen, bevor der Anwendungscode ausgeführt wird.
Die Korrekturen sind enthalten in:
- PHP 8.5.12;
- PHP 8.4.27;
- PHP 8.3.36;
- PHP 8.2.35.
Diese vier Versionen sind keine frei austauschbaren Ziele. Aktualisieren Sie innerhalb des verwendeten Zweigs oder folgen Sie dem vom Betriebssystem, Hosting oder Container-Anbieter unterstützten Upgrade-Pfad. Liefert ein Anbieter ein eigenes Paket mit zurückportierten Korrekturen, muss dieser Stand im Sicherheitshinweis des Anbieters bestätigt werden. Die Versionsnummer allein reicht dann nicht.
PHP 8.1 und ältere Zweige erhalten keine Aktualisierungen mehr vom PHP-Projekt. PHP 8.2 erhält derzeit nur noch Korrekturen für kritische Sicherheitsprobleme. Diese Unterstützung endet am 31. Dezember 2026. Der Wechsel zu einem neueren Zweig kann deshalb ein eigenes Kompatibilitätsprojekt sein, auch wenn die dringende Korrektur bereits installiert wurde.
Zusätzliche Information vom 23. Oktober 2026
Am 23. Oktober beschrieb das PHP-Projekt einen unwahrscheinlichen Weg zur Ausführung fremden Codes im Zusammenhang mit session.upload_progress. Bis zur nächsten regulären Fehlerkorrektur wurde empfohlen, session.upload_progress.enabled=0 zu setzen. Das Problem erfordert eine ungewöhnliche Kombination aus Konfiguration und Anwendungsverhalten. Anwendungen, die den Handler für die Serialisierung von Sitzungen nie zur Laufzeit ändern, können die Funktion laut Mitteilung aktiviert lassen.
Das ist eine vorübergehende, konfigurationsabhängige Empfehlung. Sie ersetzt kein PHP-Update. Eine Änderung ohne Prüfung kann außerdem Funktionen beeinflussen, die den Fortschritt von Uploads verwenden. Prüfen Sie daher, ob die Einstellung relevant ist, und testen Sie die Auswirkung.
Erster Schritt: die Laufzeit der Website prüfen
Die Ausgabe von php -v in der Shell kann die Kommandozeilenversion anzeigen und nicht die PHP-Laufzeit, die Webanfragen verarbeitet. Ein Server kann für die Website, geplante Aufgaben und Warteschlangen unterschiedliche Versionen oder Konfigurationen verwenden.
Vor der Wahl des Arbeitsumfangs ist zu klären:
- welche PHP-Version die öffentliche Anwendung tatsächlich bedient;
- welche SAPI oder Serveranbindung eingesetzt wird, zum Beispiel FPM, mod_php oder CGI;
- woher die Konfiguration stammt und wer sie ändern darf;
- ob das Paket des Betriebssystems oder Container-Image eine zurückportierte Korrektur enthält;
- welche PHP-Version geplante Aufgaben, Warteschlangen, Importe und Wartungsskripte verwenden;
- ob eine wiederherstellbare Sicherung und ein Rückweg vorhanden sind;
- welche Geschäftsprozesse direkt nach der Änderung geprüft werden müssen.
Wenn die Anwendung bereits kompromittiert sein könnte, ist ein Update keine Untersuchung des Vorfalls. Relevante Spuren sollten erhalten und die nächsten Schritte mit der für Infrastruktur oder Incident Response verantwortlichen Stelle abgestimmt werden. Dieser Artikel ersetzt diese Arbeit nicht.
Dringendes Update und Anwendungsmodernisierung sind zwei verschiedene Aufgaben
Das dringende Ziel ist eine PHP-Version mit der Korrektur oder ein Paket, das der verantwortliche Anbieter ausdrücklich als korrigiert bestätigt hat. Modernisierung beginnt, wenn Code, Framework, Bibliotheken oder Deployment das Update blockieren oder sein Ergebnis unvorhersehbar machen.
Eine sichere Reihenfolge sieht normalerweise so aus:
- tatsächliche Laufzeit der Webanfragen bestimmen;
- Sicherheitskorrektur des Anbieters anwenden oder planen, ohne auf einen größeren Neubau zu warten;
- Sicherung erstellen und ihre Wiederherstellbarkeit prüfen;
- Anwendung in einer Testumgebung mit der korrigierten PHP-Version starten;
- kritische Abläufe, Integrationen, Warteschlangen, geplante Aufgaben und Dateioperationen prüfen;
- Inkompatibilitäten erfassen und dringende Fehler von späteren Verbesserungen trennen;
- kleinste begründete nächste Etappe mit Abnahmekriterien wählen;
- kontrolliert bereitstellen, erforderliche Prozesse neu starten und wirksame Version sowie Hauptabläufe prüfen.
Eine verwundbare öffentliche Instanz sollte nicht nur deshalb erreichbar bleiben, um die alte Anwendung zu testen. Dauert die Kompatibilitätsarbeit länger, muss das Risiko separat auf Infrastruktur- und Betriebsebene begrenzt werden.
Vier mögliche Wege nach Absicherung der Laufzeit
| Weg | Wann er ausreichen kann | Was geprüft werden muss |
|---|---|---|
| Laufzeit aktualisieren und Kompatibilität testen | Anwendung und Abhängigkeiten unterstützen eine korrigierte und gepflegte PHP-Version. | Sicherung, Testumgebung, kritische Abläufe, Hintergrundaufgaben, Integrationen und Rückweg. |
| Framework und Abhängigkeiten aktualisieren | Geschäftsregeln bleiben wertvoll, aber alte Pakete blockieren die neue Laufzeit. | Unterstützte Upgrade-Pfade, aufgegebene Pakete, Änderungen zwischen Versionen, Datenmigrationen und eigene Module. |
| Schrittweise modernisieren | Teile der Anwendung können bleiben, während sich Probleme auf bestimmte Module oder Schichten konzentrieren. | Modulgrenzen, Datenflüsse, Reihenfolge und Zeitraum der Zusammenarbeit alter und neuer Teile. |
| Kontrolliert neu bauen | Das System lässt sich nicht sicher in einer gepflegten Umgebung betreiben oder seine Architektur verhindert planbare Entwicklung. | Geschäftsregeln, Daten, Integrationen, Umfang der ersten Version, Umschaltung und Rückweg. |
Die PHP-Version allein reicht für diese Entscheidung nicht. Dieselbe alte Version kann bei einer Anwendung ein einfaches Update und bei einer anderen ein größeres Kompatibilitätsprojekt bedeuten.
Wann kann das Update der Laufzeit ausreichen?
Die einfachste Variante ist möglich, wenn Anwendung, Framework und Bibliotheken gepflegt werden, das Deployment wiederholbar ist und sich die wichtigsten Prozesse vor der Änderung testen lassen. Dann kann sich der Umfang auf Sicherung, Test mit der korrigierten Version, Aktualisierung der Umgebung und Kontrolle nach dem Deployment beschränken.
Hintergrundaufgaben dürfen dabei nicht fehlen. Zeitpläne, Warteschlangen, Importe und Skripte können eine andere Konfiguration als die Webanwendung verwenden.
Wann müssen Framework oder Bibliotheken aktualisiert werden?
Eine ältere Anwendung kann Syntax enthalten, die in neuen PHP-Versionen entfernt wurde, ein nicht mehr unterstütztes Framework oder aufgegebene Pakete verwenden. Auch eigene Module und Erweiterungen lassen sich möglicherweise nicht direkt ersetzen.
Zuerst ist der kleinste sichere Kompatibilitätsumfang zu bestimmen. Manchmal genügen einige Abhängigkeiten und ein begrenzter Teil des Codes. In anderen Fällen erfordern aufeinanderfolgende Framework-Versionen eine stufenweise Migration. Eine einzelne Fehlermeldung reicht für eine belastbare Antwort nicht.
Wann ist eine schrittweise Modernisierung sinnvoll?
Eine schrittweise Modernisierung ist sinnvoll, wenn die Anwendung weiterhin wichtige Abläufe unterstützt, benötigte Daten enthält und Teile ohne große Änderungen weiterarbeiten können. Statt alles gleichzeitig neu zu erstellen, lassen sich zuerst kritische Verhaltensweisen durch Tests schützen, das Deployment stabilisieren und problematische Bereiche nacheinander ersetzen.
Jede Etappe sollte ein eigenes Ergebnis, Abnahmekriterien und einen Rückweg haben. So beruhen weitere Entscheidungen auf einem funktionierenden System und nicht nur auf Annahmen.
Weitere Kriterien erläutert Modernisierung eines bestehenden Systems oder kompletter Neubau.
Wann kann ein Neubau begründet sein?
Ein Neubau kann sinnvoll sein, wenn zentrale Abhängigkeiten nicht mehr unterstützt werden, die Anwendung nicht in einer kontrollierten Umgebung reproduziert werden kann, kleine Änderungen unvorhersehbare Fehler auslösen oder die Architektur benötigte Geschäftsprozesse nicht trennen lässt.
Auch dann ist keine einzige große Umschaltung erforderlich. Zuerst kann ein Prozess neu erstellt und mit den vorhandenen Daten verglichen werden. Der Umfang wächst erst nach einem bestätigten Ergebnis. Ein Neubau ohne Erhebung der Geschäftsregeln übernimmt häufig alte Probleme in neuen Code oder entfernt Verhalten, das bei der Spezifikation niemand erwähnt hat.
Zwei Beispiele, zwei unterschiedliche Wege
Beim Projekt OBIBOOK reparierten wir zuerst einen fehlerhaften CSV-Import und die Darstellung auf mobilen Geräten. Erst nach dem Verständnis des Prozesses bauten wir den Buchkatalog vollständig neu. Reparatur und Neubau waren getrennte Etappen.
Bei Sprawdzeni.pl war die vorherige Anwendung schwer nutzbar und verursachte regelmäßig Fehler. Ihr Zustand sprach für einen Neubau unter Beibehaltung und Erweiterung des visuellen Konzepts des Eigentümers.
Keines dieser Projekte begann wegen der in diesem Artikel beschriebenen Schwachstellen. Sie zeigen lediglich, dass die Prüfung eines bestehenden Systems zu Reparatur, schrittweiser Arbeit oder Neubau führen kann. Für alte Anwendungen gibt es keine pauschale Antwort.
Was sollten Sie für eine erste Einschätzung vorbereiten?
Sie müssen nicht alle technischen Details kennen. Hilfreich sind:
- Adresse und kurze Beschreibung der Rolle der Anwendung im Unternehmen;
- Mitteilung des Hosters oder Administrators ohne Zugangsdaten;
- PHP-Version und Art der Laufzeit, falls bekannt;
- Name und Version von Framework oder CMS, falls bekannt;
- Herkunft des Quellcodes und Information, ob er dem Produktionsstand entspricht;
- Informationen zu Sicherungen, Testumgebung und Deployment;
- Abläufe, die nach dem Update geprüft werden müssen;
- Integrationen und Hintergrundaufgaben;
- erwartetes Ergebnis der ersten Etappe.
Senden Sie über das Formular keine Passwörter, API-Schlüssel, Datenbankkopien oder Kundendaten. Eine sichere Übergabe der Materialien vereinbaren wir nach Klärung des Umfangs.
Zuvor können Sie die Checkliste zur Anwendungsübernahme verwenden. Sie ordnet vorhandene Informationen, ersetzt aber keine technische Untersuchung.
Was lässt sich vor der Prüfung nicht versprechen?
Vor der Analyse eines konkreten Systems kann niemand seriös garantieren, dass:
- ein PHP-Update keine Änderungen am Code erfordert;
- jede Abhängigkeit einen sicheren und kompatiblen Ersatz hat;
- die Sicherung das System in der benötigten Zeit wiederherstellt;
- jeder Teil der Anwendung erhalten bleiben sollte;
- ein Neubau günstiger als eine Modernisierung ist;
- der PHP-Patch alle Sicherheitsprobleme der Anwendung löst.
Für eine breitere Prüfung der Anwendungsrisiken siehe unser Sicherheitsaudit für Webanwendungen. Benötigt das System nach der Stabilisierung dauerhafte Betreuung, kann die Wartung von Anwendungen und Shops separat vereinbart werden.
Prüfen wir, was Ihre Anwendung benötigt
Beschreiben Sie, wofür das Unternehmen das System nutzt, welcher Hinweis die Änderung ausgelöst hat und was beim Update nicht verloren gehen darf. Falls PHP-Version, Framework, Art der Laufzeit und Stand der Zugänge zu Code und Hosting bekannt sind, nennen Sie diese Angaben. Fehlende Details verhindern ein erstes Gespräch nicht.
Senden Sie keine Geheimnisse oder Kundendaten. Zunächst benötigen wir die Beschreibung der Situation und das erste erwartete Ergebnis.
Prüfen wir, was Ihre Anwendung benötigt, oder ordnen Sie zuerst die Unterlagen mit der Checkliste.
Quellen
Quellen geprüft am 23.10.2026:
- PHP: Security advisory - Critical remote code execution vulnerabilities, update now
- PHP: Informational advisory - Session upload progress
- PHP: Supported Versions
- PHP security advisory: CVE-2026-109618, RCE via OOM corruption
- PHP security advisory: CVE-2026-109619, RCE via stale global state
- PHP Manual: php_sapi_name
- PHP Manual: phpversion