Aktuelle Lage: PHP2Shell. Zwei kritische PHP-Lücken (CVSS 9.2) erlauben Schadcode ohne Anmeldung. Patches seit 21.10.2026.Was jetzt zu tun ist →

PHP-Version und Patchstand richtig prüfen

Die angezeigte PHP-Version allein sagt nicht, ob PHP2Shell geschlossen ist. Entscheidend sind Paketstand, Backports und ob die neuen Prozesse wirklich laufen.

Stand 4 Min. LesezeitPHP2Shell

Kurz gesagt: Um die PHP-Version zu prüfen, reicht php -v nicht aus. Sie müssen wissen, welche PHP-Version der Webserver wirklich nutzt, ob das Paket die Korrektur enthält, auch als Backport mit alter Nummer, und ob nach dem Update alle Prozesse neu gestartet wurden. Behoben ist PHP2Shell in 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Warum die Versionsnummer allein nicht reicht

Für PHP2Shell gibt es eine klare Liste behobener Versionen. In der Praxis führen trotzdem drei Situationen zu Fehleinschätzungen:

  • Mehrere Installationen: Die Kommandozeile zeigt PHP 8.3, die Website läuft aber über einen Pool mit PHP 8.1.
  • Backports: Distributionen und Hoster spielen Korrekturen teils in bestehende Pakete ein. Dann zeigt zum Beispiel Plesk weiter 8.2.34, obwohl gepatcht ist.
  • Alte Prozesse: Die neuen Dateien liegen auf der Platte, die laufenden Worker stammen aber noch von vorher.

Für Geschäftsführung und Nicht-Techniker hilft eine einfache Faustregel: Fragen Sie nicht nur „Welche PHP-Version haben wir?“, sondern „Ist PHP2Shell auf allen Servern geschlossen, und woran sehen wir das?“. Eine belastbare Antwort enthält drei Belege: Version oder Backport, Paketstand und Zeitpunkt des Neustarts.

Die technische Prüfung hat deshalb drei Schritte: Version, Paketstand, laufende Prozesse. Die Befehle unten sind rein lesend. Paket- und Dienstnamen weichen je Distribution, PHP-Quelle und Hosting-Oberfläche ab; die Beispiele gehen von PHP 8.3 aus.

PHP-Version prüfen auf der Kommandozeile

php -v                                  # Version der Kommandozeile
ls /etc/php/ 2>/dev/null                # Debian/Ubuntu: installierte Zweige
php-fpm8.3 -v                           # Version des FPM-Binarys (Name je Distribution)
php -i | grep -E "^PHP Version|Server API|Loaded Configuration File"

Unter RHEL, AlmaLinux oder Rocky heisst das FPM-Binary meist php-fpm; bei Software-Collections oder Fremdquellen liegen weitere Versionen in eigenen Pfaden. Plesk und cPanel bringen eigene PHP-Installationen mit, die neben der System-PHP existieren. Wie Sie dort vorgehen, beschreiben wir auf den Seiten zu Plesk und cPanel.

Welche PHP-Version eine Website im Webkontext nutzt, sehen Sie am verlässlichsten in der Pool- oder VirtualHost-Konfiguration oder in der Hosting-Oberfläche. Eine phpinfo-Seite zeigt es ebenfalls; legen Sie sie nur kurz, mit Zugriffsschutz und zufälligem Namen an und löschen Sie sie sofort danach.

Auf Shared Hosting haben Sie meist keinen Zugriff auf die Kommandozeile. Dann zeigt die Hosting-Oberfläche die eingestellte PHP-Version je Website. Ob ein Backport eingespielt und neu gestartet wurde, steht dort aber selten. Hier ist die schriftliche Bestätigung des Hosters der verlässliche Weg.

Paketstand und Backports prüfen

Der Paketstand zeigt, was Ihre Distribution tatsächlich ausgeliefert hat:

# Debian/Ubuntu
apt policy php8.3-fpm
apt changelog php8.3-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"

# RHEL, AlmaLinux, Rocky, Fedora
dnf info php-fpm
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"

Steht eine der CVE-Nummern im Changelog, ist der Backport im installierten Paket enthalten. Fehlt der Eintrag, ist das noch kein Beweis für eine Lücke: Manche Paketbetreuer formulieren Changelogs anders. Dann vergleichen Sie die Paketversion mit den Sicherheitsmeldungen Ihrer Distribution oder fragen beim Anbieter nach. Eine Vorlage für diese Anfrage finden Sie unter So fragen Sie Ihren Hoster nach dem Patch-Status.

Wichtig: Prüfen Sie jedes installierte PHP-Paket, nicht nur das erste. Auf Servern mit mehreren Zweigen ist häufig einer gepatcht und ein anderer nicht.

Läuft die neue Version auch wirklich?

Ein Update ist erst wirksam, wenn alle PHP-Prozesse neu gestartet wurden. Vergleichen Sie die Startzeit der laufenden Prozesse mit dem Zeitpunkt des Updates:

ps -o pid,lstart,cmd -C php-fpm8.3      # Startzeit der FPM-Prozesse
systemctl status php8.3-fpm             # seit wann der Dienst läuft
needrestart -r l                        # Debian/Ubuntu, falls installiert: zeigt veraltete Prozesse

Liegt die Startzeit vor dem Update, laufen noch alte Prozesse. Bei Apache mit mod_php gilt dasselbe für die Apache-Prozesse. Wie Sie sauber neu starten, beschreibt PHP-FPM und alle Worker neu starten.

Tipp

Halten Sie das Ergebnis schriftlich fest: Server, PHP-Version, Paketversion, CVE im Changelog ja oder nein, Zeitpunkt des Neustarts. Diese Notiz brauchen Sie für Geschäftsführung, Versicherer und eine spätere Spurenprüfung.

Ergebnis einordnen

Befund Bewertung
Offizielle Version 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, Prozesse neu gestartet PHP2Shell geschlossen
Ältere Nummer, CVE-Nummern im Paket-Changelog, Prozesse neu gestartet Backport eingespielt, geschlossen
Ältere Nummer, kein Changelog-Eintrag, keine Bestätigung unklar, beim Anbieter klären
PHP 8.1 oder älter ohne bestätigten Backport offen, Übergangsmassnahmen und Migration nötig
Prozesse älter als das Update Neustart fehlt, Lücke weiter aktiv

Bleibt ein Server im Status „unklar“, behandeln Sie ihn wie einen offenen: Übergangsmassnahmen setzen und die Klärung nachhalten, bis ein Beleg vorliegt. Die vollständige Versionsübersicht steht unter Welche PHP-Versionen sind betroffen?.

Wie hilft PHP SOS konkret?

Mit dem PHP-Patch-Service übernehmen wir die Prüfung und den Nachweis:

  • Alle Installationen finden, auch Zweitversionen aus Hosting-Panels, Software-Collections oder Containern.
  • Paketstand bewerten: offizielles Release, Backport oder offen, mit Beleg aus dem Changelog oder vom Anbieter.
  • Neustart kontrollieren, bis kein Prozess mit altem Code mehr läuft.
  • Prüfprotokoll erstellen, das Sie intern und gegenüber Dritten verwenden können.

Häufige Fragen

Warum zeigt php -v eine andere Version als meine Website?

Auf vielen Servern sind mehrere PHP-Versionen installiert. Die Kommandozeile nutzt eine davon, der Webserver oder ein FPM-Pool eine andere. Prüfen Sie deshalb die Version, die tatsächlich im Webkontext läuft, etwa über das FPM-Binary oder die Hosting-Oberfläche.

Wie erkenne ich einen Backport?

Bei Distributionspaketen steht die Korrektur oft im Paket-Changelog, häufig mit der CVE-Nummer. Unter Debian und Ubuntu hilft apt changelog, unter RHEL-artigen Systemen rpm -q --changelog. Fehlt der Eintrag, klären Sie den Stand beim Anbieter.

Kann ich die PHP-Version im Hosting-Kundenmenü prüfen?

Ja, die meisten Oberflächen zeigen die eingestellte Version je Website. Ob ein Backport eingespielt und neu gestartet wurde, sehen Sie dort meist nicht. Dafür ist eine schriftliche Bestätigung des Hosters der verlässliche Weg.

Quellen

Sofort-Kontakt

Jede Stunde zählt. Schreiben Sie uns jetzt.

Schildern Sie kurz System, PHP-Version und Beobachtung. Wir melden uns, klären die Lage und arbeiten remote, bis der Vorfall abgeschlossen und dokumentiert ist.

Sofort-Hilfe