Kurz gesagt: Wenn php -v nach dem Update dieselbe Version zeigt, liegt das meist an einem Backport: Die Distribution übernimmt nur die Sicherheitskorrektur in ihre bestehende PHP-Version, die Nummer bleibt gleich. Ubuntu 24.04 meldet so weiter 8.3.6, obwohl das Paket gegen PHP2Shell korrigiert ist. Klären Sie die Frage über Paketstand und Changelog, und prüfen Sie zusätzlich, ob die Website wirklich mit dem neuen Code läuft.
Ein typischer Moment nach PHP2Shell
Der Admin hat das Update eingespielt, alles ohne Fehler. Zur Kontrolle tippt er php -v und sieht dieselbe Version wie vorher. Hat das Update nicht funktioniert? Ist der Server weiter offen? Diese Frage gehört zu den häufigsten seit dem 21. Oktober 2026.
Die gute Nachricht: In den meisten Fällen ist alles in Ordnung. Die schlechte: Es gibt auch Fälle, in denen die gleiche Nummer tatsächlich ein Problem anzeigt. Dieser Beitrag hilft, beides zu unterscheiden.
Warum Distributionen die Nummer nicht ändern
Unternehmens- und LTS-Distributionen versprechen Stabilität. Innerhalb eines Releases sollen sich Verhalten und Schnittstellen möglichst nicht ändern. Ein Sprung von PHP 8.3.6 auf 8.3.36 brächte aber zahlreiche Fehlerbehebungen und kleine Verhaltensänderungen mit, die Anwendungen stören könnten.
Deshalb übernehmen viele Paketbetreuer nur die konkrete Sicherheitskorrektur in ihre bestehende Version. Diesen Vorgang nennt man Backport. Die Upstream-Version, die PHP selbst über php -v meldet, bleibt gleich. Was sich ändert, ist der Paketstand, den die Distribution vergibt.
Am Beispiel Ubuntu 24.04 sieht das so aus: PHP meldet 8.3.6. Der korrigierte Paketstand lautet laut USN-8948-1 aber 8.3.6-0ubuntu0.24.04.13. Der hintere Teil zählt. Debian hat bei PHP2Shell anders entschieden und für bookworm und trixie die neuen Upstream-Versionen 8.2.35 und 8.4.27 ausgeliefert. Die Übersicht je Release steht im Beitrag Debian und Ubuntu: Ist mein PHP-Paket gepatcht?.
Es lohnt sich, eine solche Paketversion einmal zu zerlegen. Am Beispiel 8.3.6-0ubuntu0.24.04.13: Der Teil vor dem Bindestrich ist die Upstream-Version, also das, was PHP selbst meldet. Dahinter folgt die Revision der Distribution. ubuntu0.24.04 verweist auf das Release, die letzte Zahl zählt die Überarbeitungen. Jede Sicherheitskorrektur erhöht diese Zahl. Bei Ubuntu Pro erscheint zusätzlich ein Zusatz wie +esm5, bei Debian-Sicherheitsupdates einer wie ~deb12u1. Wer diese Teile lesen kann, erkennt auf einen Blick, ob ein Paket nach einer Sicherheitsmeldung verändert wurde.
Wo die alte Nummer überall auftaucht
Die unveränderte Nummer erscheint nicht nur in php -v. Sie steht auch an Stellen, die von aussen sichtbar sind oder von Werkzeugen ausgewertet werden:
| Ort | Was dort steht | Folge |
|---|---|---|
php -v und php -i |
Upstream-Version, Build-Datum | Admins zweifeln am Update |
| phpinfo-Seite | Upstream-Version | gleicher Effekt im Browser |
Header X-Powered-By |
Upstream-Version, falls expose_php an ist |
externe Scanner melden eine Lücke |
| Hosting-Panels wie Plesk | Upstream-Version | Anzeige etwa 8.2.34 trotz Patch |
| Schwachstellenscanner | Vergleich nach Nummer | Fehlalarm bei Backports |
Externe Scanner sind ein eigener Fall. Wer sie einsetzt, bekommt nach PHP2Shell womöglich Funde für Server, die längst korrigiert sind. Ignorieren Sie diese Funde nicht pauschal, sondern belegen Sie für jeden Server den Paketstand und vermerken Sie den Fund als geprüft. Ein weiterer Grund, Versionsangaben nach aussen zu verbergen, steht im Beitrag expose_php und Server-Header.
Wann die gleiche Nummer ein Warnsignal ist
Es gibt drei Situationen, in denen die unveränderte Nummer tatsächlich auf ein Problem hinweist:
- Die Paketquelle liefert die Upstream-Version. Kommt PHP aus einer Quelle, die normalerweise die aktuelle Upstream-Version ausliefert, etwa Debian bei PHP2Shell oder Drittquellen wie Remi und sury.org, sollte nach dem Update 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 erscheinen. Steht dort weiter die alte Nummer, wurde das Paket nicht aktualisiert.
- Sie prüfen die falsche Installation.
php -vzeigt die Kommandozeile. Läuft die Website über eine andere Version, etwa aus einem Hosting-Panel oder einer Software-Collection, sagt die Ausgabe nichts über die Website. - Der Paketstand hat sich nicht geändert. Ist auch der Paketstand derselbe wie vor dem Update, ist das Update für dieses Paket nicht angekommen, etwa weil es gehalten wurde oder die Quelle fehlt.
Für Nicht-Techniker lässt sich das so zusammenfassen: Die Versionsnummer beschreibt das Modell, der Paketstand den Wartungsstand. Zwei Server mit derselben PHP-Version können sich in der Sicherheit deutlich unterscheiden. Fragen Sie deshalb Ihre IT oder Ihren Dienstleister nicht nach der Version, sondern nach dem Beleg für den Patch.
So klären Sie die Frage in fünf Minuten
Die folgenden Befehle sind rein lesend. Die Beispiele gehen von Ubuntu oder Debian und PHP 8.3 aus; auf RHEL-Systemen nutzen Sie rpm -q statt dpkg-query.
# 1. Was meldet PHP selbst, inklusive Build-Datum?
php -v
# 2. Welcher Paketstand ist installiert, aus welcher Quelle?
apt policy php8.3-fpm
# 3. Enthält das Changelog die CVE-Nummern?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Seit wann laufen die PHP-Prozesse der Website?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Das Build-Datum in der Ausgabe von php -v ist ein Hinweis, aber kein Beweis. Den belastbaren Nachweis liefert der Changelog-Eintrag. Wie Sie ihn finden und festhalten, wenn er anders formuliert ist oder fehlt, beschreibt der Beitrag CVE-Nummern im Paket-Changelog nachweisen.
Notieren Sie nach jeder Prüfung beide Nummern: die Upstream-Version aus php -v und den Paketstand. Wer später fragt, warum der Server „noch 8.3.6“ hat, bekommt so eine klare Antwort.
Die allgemeine Prüfung über Version, Paket und Prozesse fasst die Seite PHP-Version und Patchstand richtig prüfen zusammen.
Wie hilft PHP SOS konkret?
- Wir klären für jeden Server, ob eine unveränderte Versionsnummer ein Backport oder ein fehlendes Update ist.
- Wir bewerten Funde aus Schwachstellenscannern und belegen Fehlalarme mit Paketstand und Changelog.
- Wir prüfen, welche PHP-Installation die Website tatsächlich nutzt und ob deren Prozesse neu gestartet wurden.
- Im PHP-Patch-Service dokumentieren wir Upstream-Version und Paketstand nebeneinander.
Häufige Fragen
Ist mein Server ungepatcht, wenn php -v die alte Nummer zeigt?
Nicht unbedingt. Viele Distributionen übernehmen Korrekturen als Backport in die bestehende Version. Ubuntu 24.04 zeigt zum Beispiel weiter 8.3.6, obwohl das Paket laut USN-8948-1 korrigiert ist. Entscheidend sind Paketstand und Changelog.
Warum meldet mein Sicherheitsscanner trotz Update eine Lücke?
Viele Scanner lesen nur die Versionsnummer, etwa aus dem Header X-Powered-By. Bei Backports führt das zu Fehlalarmen. Prüfen Sie den Paketstand und dokumentieren Sie das Ergebnis, statt den Fund einfach zu ignorieren.
Kann es sein, dass php -v eine neue Nummer zeigt, die Website aber nicht?
Ja. php -v zeigt die Kommandozeile. Die Website kann über eine andere Installation oder über Prozesse laufen, die vor dem Update gestartet wurden. Prüfen Sie deshalb auch den FPM-Dienst oder Apache und deren Startzeit.
Hilft das Build-Datum in der Ausgabe von php -v?
Es ist ein Hinweis, aber kein Beweis. Ein Build-Datum nach dem 21. Oktober 2026 passt zu einem korrigierten Paket, belegt aber nicht, dass die Korrektur enthalten ist. Der Changelog-Eintrag ist der bessere Beleg.