Kurz gesagt: Wer einen Root-Server oder vServer selbst verwaltet, muss ihn nach PHP2Shell auch selbst absichern: PHP-Pakete auf einen behobenen Stand bringen, alle PHP-Prozesse neu starten und das Ergebnis prüfen. Der Rechenzentrumsbetreiber kümmert sich in der Regel nur um Hardware, Virtualisierung und Netz. Danach lohnt es, den Server dauerhaft zu härten.
Ihre Verantwortung beim eigenen Server
Bei einem unverwalteten Root-Server oder vServer mieten Sie Rechenleistung, nicht Betreuung. Betriebssystem, Webserver, PHP, Datenbank, Firewall, Backups und Überwachung liegen in Ihrer Hand. Für Geschäftsführung und Inhaber heißt das: Wenn niemand im Haus oder bei einem Dienstleister diese Aufgaben ausdrücklich übernommen hat, erledigt sie niemand.
PHP2Shell macht das sichtbar. Die beiden Lücken CVE-2026-109618 und CVE-2026-109619 stecken in PHP selbst und erlauben Codeausführung ohne Anmeldung. Das PHP-Projekt hat am 21.10.2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Das BSI empfiehlt sofortiges Update und, wenn das nicht geht, den Webserver vorübergehend vom Netz zu nehmen.
vServer absichern: Bestand und Paketstand prüfen
Verschaffen Sie sich zuerst einen Überblick, welche PHP-Versionen installiert sind und aus welcher Quelle sie stammen. Viele Server nutzen neben den Paketen der Distribution zusätzliche Paketquellen. Die folgenden Befehle lesen nur. Paketnamen sind Beispiele.
# Debian/Ubuntu: installierte PHP-Pakete und ihre Herkunft
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Welche PHP-Binaries gibt es überhaupt?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Die Versionsnummer allein reicht nicht. Distributionen liefern Sicherheitskorrekturen oft als Backport aus, die angezeigte Nummer bleibt dann älter. Den Ausschlag gibt das Änderungsprotokoll des Pakets.
# Debian/Ubuntu (Paketname als Beispiel)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL-Familie (Paketname als Beispiel)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Eine ausführliche Anleitung steht unter PHP-Version und Patchstand prüfen.
Update einspielen und alle Prozesse erneuern
Spielen Sie die Updates über die Paketverwaltung ein und starten Sie danach jeden Dienst neu, der PHP lädt. Das sind je nach Aufbau PHP-FPM, Apache mit mod_php, LiteSpeed oder ein Anwendungsserver. Neue Dateien auf der Festplatte reichen nicht, solange alte Prozesse im Speicher laufen.
# Dienste mit PHP finden
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Prozesse mit Startzeit anzeigen
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: Programme mit veralteten Bibliotheken erkennen (falls installiert)
needrestart -r l
Jeder relevante Prozess sollte nach dem Update gestartet sein. Hilfreich ist das Werkzeug needrestart auf Debian-Systemen, das Dienste mit veralteten Bibliotheken anzeigt. Details zum Neustart beschreibt PHP-FPM und alle Worker neu starten.
Ein Patch entfernt keine Schadsoftware, die vor dem Update eingeschleust wurde. Bewahren Sie die Webserver-Logs ab dem 20.10.2026 auf und prüfen Sie den Server auf Spuren, bevor Sie ihn als sauber einstufen.
Für eine erste Spurensuche bieten sich einige Prüfungen an, die nichts verändern. Suchen Sie nach PHP-Dateien, die seit dem 17.10.2026 in Web-Verzeichnissen neu angelegt oder geändert wurden, nach unbekannten Einträgen in den Crontabs aller Benutzer, nach neuen Systembenutzern und SSH-Schlüsseln sowie nach Prozessen des Webserver-Benutzers, die ausgehende Verbindungen halten.
# Seit dem 17.10.2026 geänderte PHP-Dateien (Pfad als Beispiel)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Netzwerkverbindungen mit zugehörigem Prozess
ss -tupn
Keine dieser Prüfungen beweist für sich einen Einbruch, und ein leeres Ergebnis beweist nicht das Gegenteil. Sie zeigen aber, ob eine tiefere Untersuchung nötig ist. Arbeiten Sie auf Kopien der Logs und verändern Sie verdächtige Dateien nicht, bis der Zustand gesichert ist. Bei Funden ist eine geordnete Untersuchung der sichere Weg. Schalten Sie den Server in diesem Fall nicht einfach ab und setzen Sie ihn nicht sofort neu auf, denn damit gehen Spuren verloren, die für die Bewertung von Meldepflichten und für eine mögliche Anzeige wichtig sind.
Den Server dauerhaft härten
Nach dem akuten Patch folgt die Grundsicherung. Sie verhindert nicht jede Lücke, begrenzt aber den Schaden und verkürzt die Reaktionszeit beim nächsten Mal. Bewährt haben sich diese Punkte:
- Zugänge: SSH nur mit Schlüssel, keine direkte Root-Anmeldung, Verwaltungsoberflächen nur aus bekannten Netzen erreichbar.
- Firewall: nur die Ports öffnen, die wirklich gebraucht werden, ausgehende Verbindungen des Webservers einschränken.
- PHP-Konfiguration: gefährliche Funktionen deaktivieren,
open_basedirje Website, eigene Pools und Benutzer je Anwendung. - Dateirechte: Webserver darf Programmcode nicht beschreiben, Upload-Verzeichnisse führen kein PHP aus.
- Updates: Sicherheitsupdates automatisch einspielen, Neustart und Kontrolle fest einplanen.
- Backups: Sicherungen nach der 3-2-1-Regel, mindestens eine Kopie außerhalb des Servers und vor Veränderung geschützt.
- Protokolle: Logs zentral sammeln und lange genug aufbewahren.
Wie eine belastbare Sicherung aussieht, beschreibt Backups nach der 3-2-1-Regel. Als Rahmen für Unternehmen eignet sich der IT-Grundschutz des BSI.
Wann ein Managed Server die bessere Wahl ist
Ein eigener Server lohnt sich, wenn jemand die Pflege zuverlässig übernimmt: Updates verfolgen, Lagen wie PHP2Shell bewerten, nachts reagieren können. Fehlt diese Kapazität, ist entweder ein Managed Server oder ein fester Wartungsvertrag sinnvoll. Wichtig ist in beiden Fällen, die Zuständigkeiten schriftlich festzuhalten. Mehr dazu unter Managed Server: Verantwortung klären.
Wie hilft PHP SOS konkret?
- Wir erfassen alle PHP-Installationen, Paketquellen und Dienste Ihres Servers und bewerten den tatsächlichen Patch-Stand.
- Wir spielen Updates ein, starten alle Prozesse neu und dokumentieren das Ergebnis.
- Wir prüfen den Server auf Spuren einer Kompromittierung und sichern Logs für eine spätere Auswertung.
- Im Rahmen unserer Server-Härtung setzen wir Zugänge, Firewall, PHP-Pools und Rechte sauber auf.
- Auf Wunsch übernehmen wir die laufende Pflege per Security-Wartungsvertrag.
Häufige Fragen
Patcht mein Rechenzentrum den vServer automatisch?
Bei unverwalteten Root-Servern und vServern in der Regel nicht. Der Anbieter stellt Hardware oder Virtualisierung und Netz bereit, das Betriebssystem und alle Dienste darauf verwalten Sie selbst. Prüfen Sie im Zweifel Ihren Vertrag.
Reichen automatische Sicherheitsupdates aus?
Sie helfen, ersetzen aber nicht die Kontrolle. Automatische Updates starten laufende PHP-Prozesse nicht immer neu und decken Pakete aus Fremdquellen oft nicht ab. Prüfen Sie nach jedem Sicherheitsupdate Paketstand und Prozess-Startzeiten.
Wie finde ich heraus, ob mein Paket einen Backport enthält?
Im Änderungsprotokoll des Pakets und in den Sicherheitsmeldungen Ihrer Distribution. Steht dort die CVE-Nummer, ist der Fix enthalten, auch wenn die Versionsnummer älter wirkt. Fehlt der Eintrag, klären Sie den Stand, bevor Sie den Server als gepatcht einstufen.
Was tue ich, wenn kein Patch für meine PHP-Version kommt?
PHP 8.1 und älter erhalten keine offiziellen Updates mehr. Setzen Sie die Übergangsmaßnahmen nach php.net, planen Sie zügig den Wechsel auf eine unterstützte Version und nehmen Sie den Server nach BSI-Empfehlung notfalls vorübergehend vom Netz.