Das außerplanmäßige PHP-Sicherheitsrelease vom 21. Oktober ist draußen, die Fix-Versionen heißen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Wer zügig war, hat das Update eingespielt und die Dienste neu gestartet. Und dann kommt die nächste Frage, meist von jemandem ohne Root-Zugang: "Können wir unseren Kunden belegen, dass wir abgesichert sind?"
Die Frage ist berechtigt. "Haben wir gepatcht" ist eine Aussage über eine Handlung, kein Beleg für einen Zustand. Zwischen beidem liegen mehr Fallstricke, als man nach einem apt upgrade vermuten würde. Die Lage bei den Lücken selbst habe ich in Kritisches PHP-Sicherheitsupdate am 21. Oktober beschrieben. Hier geht es um die Zeit danach.
Was sich beweisen lässt und was nicht
Dass eine Lücke nicht mehr ausnutzbar ist, beweisen Sie nicht, indem Sie einen Exploit aus dem Netz gegen Ihr Produktivsystem feuern. Ein fehlgeschlagener Angriff zeigt nur, dass dieser eine Versuch nicht funktioniert hat. Öffentliche Proof-of-Concepts sind außerdem selten sauber, und Sie wissen nicht, was der Code nebenbei tut.
Belegen lässt sich etwas anderes, und das reicht auch Auditoren in aller Regel: Auf jedem System, das PHP-Anfragen verarbeitet, läuft seit Zeitpunkt X ein Build, den der Hersteller als gefixt ausweist. Darin stecken drei Prüfungen. Läuft die richtige Version dort, wo Anfragen ankommen? Ist diese Version wirklich gefixt? Und haben Sie alle Systeme erwischt?
Läuft die neue Version dort, wo Anfragen ankommen?
php -v im Terminal zeigt die CLI-Version. Ihre Webseite läuft aber über PHP-FPM oder Apache mit mod_php, und das ist ein anderer Prozess, oft auch ein anderes Paket. Dass beide auseinanderlaufen, ist bei gewachsenen Servern eher die Regel (mehr dazu in PHP-Version prüfen).
Der zweite Klassiker: Das Paket ist neu, aber der Dienst läuft noch mit dem alten Code im Speicher. Paketmanager starten PHP-FPM nicht immer neu, und mod_php hängt am Apache-Prozess. Prüfen lässt sich das, indem Sie Installationszeit und Startzeit vergleichen:
grep -h 'php8.3' /var/log/apt/history.log | tail -5
systemctl show php8.3-fpm -p ActiveEnterTimestamp
Liegt der Start des Dienstes vor der Installation, läuft der alte Code. Auf RHEL-Systemen liefert dnf history die Installationszeit.
Was der Webserver tatsächlich ausliefert, sehen Sie nur über eine echte Anfrage. Bitte nicht mit einer phpinfo()-Seite, die offen im Netz liegt, die verrät Angreifern Ihre komplette Konfiguration. Besser ist eine Datei mit einem langen, zufälligen Namen, die nur das Nötigste ausgibt und direkt danach wieder gelöscht wird:
<?php
header('Content-Type: application/json');
header('Cache-Control: no-store');
echo json_encode(['version' => PHP_VERSION, 'sapi' => PHP_SAPI]);
Rufen Sie sie für jeden virtuellen Host auf, nicht nur für die Hauptdomain. In Plesk oder cPanel kann jede Domain eine andere PHP-Version haben.
Und dann gibt es noch die Prozesse, an die bei Updates kaum jemand denkt: langlaufende PHP-Worker. Eine Queue mit Symfony Messenger, Laravel Horizon oder ein selbstgeschriebener Daemon läuft als CLI-Prozess, manchmal seit Wochen. Der hat die alte PHP-Version geladen, egal was auf der Platte liegt. Supervisor- oder systemd-Units für Worker gehören in die Neustartliste.
Sagt die Versionsnummer überhaupt etwas aus?
Hier wird es für viele unübersichtlich. Wenn Sie PHP aus den offiziellen Paketen von Ubuntu oder Debian beziehen, bekommen Sie die Fix-Version 8.3.36 nie zu sehen. Die Distributionen bleiben bei ihrer PHP-Version, etwa 8.3.6 auf Ubuntu 24.04, und portieren den Fix zurück. PHP_VERSION meldet dann weiter 8.3.6, obwohl der Fix drin ist. Umgekehrt meldet ein ungepatchtes System dieselbe Zahl.
Ob der Fix enthalten ist, steht nur in der vollständigen Paketversion und im Changelog des Pakets:
apt list --installed 'php8*' 2>/dev/null
apt changelog php8.3-fpm | grep -m3 CVE-2026-109619
Die vollständige Paketversion (der lange String mit ubuntu oder deb darin) vergleichen Sie mit der Sicherheitsmeldung Ihrer Distribution, bei Ubuntu einer USN, bei Debian einer DSA oder DLA. Auf Ubuntu prüft pro fix CVE-2026-109619 den Status für genau diese Lücke.
Das hat eine unangenehme Folge für den Nachweis: Die Test-Datei aus dem vorigen Abschnitt kann die Paketversion nicht ausgeben. PHP selbst kennt sie nicht. Bei Backport-Systemen brauchen Sie deshalb beides, die Web-Prüfung für "welches PHP liefert aus" und die Paket-Prüfung für "ist dieses PHP gefixt".
Wer PHP aus dem Repository von Ondřej Surý, von Remi oder als offizielles Docker-Image bezieht, hat es leichter. Dort entspricht die Version der von php.net, und 8.3.36 heißt 8.3.36.
Haben Sie alle Systeme erwischt?
Der Nachweis ist nur so gut wie die Liste, auf der er steht. Die Lücken, die nach solchen Updates offen bleiben, finden sich selten auf dem Hauptserver. Sie stecken in:
- Docker-Containern, deren Image neu gebaut, aber nie neu deployt wurde. Prüfen Sie im laufenden Container (
docker exec <container> php -v), nicht im Dockerfile. - Staging- und Testsystemen, die öffentlich erreichbar sind, weil das mal bequem war.
- Cron- oder Worker-Servern, die keine Webseite ausliefern, aber dieselbe Datenbank sehen.
- Software mit eingebautem PHP: Ticketsystem, Monitoring, die Oberfläche eines Herstellers. Dort hilft nur die Nachfrage beim Hersteller, schriftlich.
- Hosting-Paketen, die jemand vor Jahren für eine Kampagnenseite angelegt hat.
Wenn Sie beim Lesen dieser Liste nicht sicher sind, ob es bei Ihnen so etwas gibt, ist das die eigentliche Antwort auf die Frage Ihres Kunden. Die ehrliche Formulierung wäre dann: "Gepatcht, soweit uns die Systeme bekannt sind." Das will niemand unterschreiben.
Wie ein Nachweis aussieht, den Sie weitergeben können
Ein Screenshot von phpinfo() überzeugt Laien, beantwortet aber keine Rückfrage. Was einer Rückfrage standhält, ist eine kurze Tabelle mit einer Zeile pro System:
| System | Rolle | SAPI | PHP-Version | Paketversion | Fix-Quelle | Neustart | Geprüft von |
|---|---|---|---|---|---|---|---|
| web-01 | Shop | fpm-fcgi | 8.3.6 | (vollständiger String) | USN der Distribution | 21.10., 18:40 | Name |
| worker-01 | Queue | cli | 8.3.6 | (vollständiger String) | USN der Distribution | 21.10., 18:45 | Name |
Dazu zwei Sätze: welche CVEs gemeint sind, und was der Nachweis nicht abdeckt (zum Beispiel, ob vor dem Update jemand eingedrungen ist). Das wirkt auf Kunden seriöser als ein pauschales "alles sicher", und es ist ehrlich. Wer vor dem Patch auf Spuren prüfen will, findet die Punkte am Ende des Beitrags zum Update.
Und wenn auf einem System PHP 8.1 oder älter läuft?
Dann gibt es vom PHP-Projekt keinen Fix, und "abgesichert" dürfen Sie nur schreiben, wenn Ihre Distribution oder ein kommerzieller Anbieter einen Backport liefert und die CVE in dessen Changelog steht. Ubuntu hat für ältere Releases teils zurückportiert, aber nicht jeder Hoster bezieht diese Pakete, und für selbst kompilierte oder exotische Setups gibt es gar nichts.
Was als Übergang möglich ist, steht in Sicherheitsupdates ohne Upgrade. Dauerhaft löst das nur der Schritt auf eine unterstützte Version. Den bieten wir als Minimal-Migration an, getestet und ohne Neuentwicklung. Droht der Hoster deswegen mit dem Abschalten, beschreibt diese Seite die Optionen.
Wer macht das beim nächsten Mal?
Dieses Release war nicht das letzte kritische. Die Frage, die nach dieser Woche bleibt: Gibt es bei Ihnen jemanden, der die Ankündigung mitbekommt, am selben Tag patcht, alle Systeme kennt und danach eine Tabelle wie die oben ausfüllen kann? In vielen Firmen mit einer gewachsenen PHP-Anwendung hat das bisher eine Person gemacht, ohne es aufzuschreiben. Solange diese Person da ist, fällt das nicht auf.
Wenn Sie die Frage nicht klar mit Ja beantworten können, sprechen Sie mit uns. Für die laufende Betreuung gibt es die Werkstatt-Bereitschaft mit Updates, Monitoring und einem vierteljährlichen Statusbericht. Wenn Sie erst wissen wollen, wo Ihre Systeme stehen, ist der kostenlose Kurz-Check der Einstieg, 30 Minuten, unverbindlich.
