# Nach dem Update: PHP-FPM und alle Worker neu starten

> PHP-FPM neu starten nach dem PHP2Shell-Update: warum neue Dateien nicht reichen, welche Dienste zählen und wie Sie prüfen, dass kein alter Worker läuft.

Quelle: https://phpsos.de/php2shell/php-fpm-neustart/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Nach dem PHP-Update müssen Sie PHP-FPM und alle anderen Dienste, die PHP laden, neu starten. Neue Dateien auf der Festplatte reichen nicht, solange alte PHP-Prozesse im Speicher laufen. Erst nach dem Neustart arbeitet der Server mit dem korrigierten Code von PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder dem Backport Ihres Anbieters.

## Warum Sie PHP-FPM neu starten müssen

Ein Paketupdate ersetzt die Dateien auf der Festplatte. Prozesse, die schon laufen, haben den alten Programmcode aber bereits in den Speicher geladen und arbeiten damit weiter. PHP-FPM, Apache mit mod_php oder LiteSpeed halten ihre Worker oft tagelang am Leben.

Für PHP2Shell ist das besonders wichtig. Die Lücke [CVE-2026-109619](https://phpsos.de/php2shell/cve-2026-109619/) hängt gerade an Zustand, der zwischen Anfragen im selben Worker bestehen bleibt. Ein Worker mit altem Code bleibt verwundbar, egal welche Version auf der Platte liegt. Laut php.net sind deshalb alle Worker und Prozesse neu zu starten.

Manche Paketmanager starten Dienste beim Update automatisch neu, andere nicht. Verlassen Sie sich nicht darauf, sondern prüfen Sie das Ergebnis.

Ein typisches Bild aus dem Alltag: Die Paketverwaltung meldet „PHP aktualisiert“, das Monitoring zeigt keine Fehler, die Website läuft. Trotzdem bedienen die alten Worker weiter jede Anfrage, weil niemand den Dienst neu gestartet hat. Von außen ist dieser Zustand nicht zu erkennen. Deshalb gehört die Prüfung der Prozess-Startzeiten zu jedem Update dazu.

## Welche Dienste laden PHP?

| Betriebsart | Was neu starten | Typischer Befehl (Namen je Distribution verschieden) |
|---|---|---|
| PHP-FPM | jeden FPM-Dienst, je installierter Version | `systemctl restart php8.3-fpm` oder `systemctl restart php-fpm` |
| Apache mit mod_php | Apache | `systemctl restart apache2` oder `systemctl restart httpd` |
| php-cgi | den aufrufenden Webserver bzw. FastCGI-Wrapper | je nach Setup |
| LiteSpeed | LiteSpeed und die lsphp-Prozesse | über die LiteSpeed-Verwaltung oder deren Dienst |
| FrankenPHP | den FrankenPHP-Dienst oder Container | `systemctl restart frankenphp` oder Container neu erstellen |
| Docker, Kubernetes | Container aus neuem Image neu erstellen | siehe [PHP in Docker-Containern patchen](https://phpsos.de/php2shell/docker-container-patchen/) |

Bei mod_php gilt: Das Update betrifft den Apache selbst, weil PHP in jedem Apache-Prozess steckt. Warum diese Betriebsart besonders heikel ist, steht unter [Warum mod_php das höchste Risiko trägt](https://phpsos.de/php2shell/mod-php-risiko/). Für LiteSpeed finden Sie Einzelheiten auf der Seite [LiteSpeed und LSAPI](https://phpsos.de/server/litespeed/).

## PHP-FPM neu starten: die Befehle

Zuerst finden Sie alle PHP-Dienste auf dem Server. Plesk, cPanel und andere Oberflächen bringen eigene PHP-Dienste mit eigenen Namen mit; die Liste zeigt sie mit.

```bash
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
```

Dann jeden gefundenen PHP-Dienst neu starten, nicht nur den ersten:

```bash
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm      # falls ein zweiter Zweig installiert ist
sudo systemctl restart apache2         # bei mod_php; RHEL-Familie: httpd
```

Wir empfehlen `restart` statt `reload`. Beim Reload bleibt der Hauptprozess bestehen; das ist für Konfigurationsänderungen gedacht. Nach einem Sicherheitsupdate wollen Sie sicher sein, dass jeder Prozess neu ist.

> **Wichtig:**
> Haben Sie zusätzlich Übergangsmaßnahmen wie `session.upload_progress.enabled=0` oder feste Speichergrenzen gesetzt, greifen diese ebenfalls erst nach dem Neustart. Ein Neustart erledigt beides in einem Schritt.

## Prüfen, dass kein alter Worker mehr läuft

Vergleichen Sie die Startzeit der Prozesse mit dem Zeitpunkt des Updates. Alle Befehle sind rein lesend.

```bash
ps -o pid,lstart,cmd -C php-fpm8.3     # unter RHEL: -C php-fpm
systemctl status php8.3-fpm            # Zeile „Active: … since …“
needrestart -r l                       # Debian/Ubuntu, falls installiert
```

Wenn ein Prozess älter ist als das Update, wurde er nicht erfasst. Häufige Ursachen sind ein vergessener zweiter PHP-Zweig, ein eigener Pool-Dienst aus einem Hosting-Panel oder ein Container, der nur neu gestartet statt aus dem neuen Image erstellt wurde. Ob die richtige Version läuft, zeigt die Seite [PHP-Version und Patchstand richtig prüfen](https://phpsos.de/php2shell/php-version-pruefen/).

## Neustart dokumentieren

Notieren Sie für jeden Server den Zeitpunkt des Updates und des Neustarts. Dieser Moment trennt die Zeit, in der der Server verwundbar war, von der Zeit danach. Für eine spätere Spurenprüfung, für Versicherer und für eine mögliche Meldung nach DSGVO ist das der wichtigste Bezugspunkt. Bewahren Sie außerdem die Server-Logs ab dem 20. Oktober auf, wie es die Fachpresse empfiehlt.

Auf Servern mit vielen Websites lohnt eine kurze Tabelle: Server, Dienst, PHP-Version, Paketversion, Zeitpunkt des Neustarts und die Person, die neu gestartet hat. So fallen Lücken in der Abdeckung schnell auf, etwa ein Pool, der übersehen wurde, oder ein Testsystem, das niemand auf dem Zettel hatte.

## Wie hilft PHP SOS konkret?

Im Rahmen des [PHP-Patch-Service](https://phpsos.de/leistungen/php-patch-service/) übernehmen wir Update und Neustart als zusammenhängenden Ablauf:

- **Dienste ermitteln:** Wir finden alle Prozesse, die PHP laden, auch aus Hosting-Panels und Containern.
- **Kontrolliert neu starten,** in Absprache mit Ihnen zu einem passenden Zeitpunkt und mit Blick auf laufende Bestellungen oder Formulare.
- **Nachprüfen,** dass kein Prozess älter als das Update ist und die Website normal antwortet.
- **Protokollieren:** Versionen, Paketstände und Neustartzeiten je Server.


## Häufige Fragen

**Reicht systemctl reload statt restart?**  
Für PHP2Shell empfehlen wir restart. Ein reload startet die Worker zwar meist neu, der Hauptprozess kann aber weiterlaufen. Mit restart stellen Sie sicher, dass kein Prozess mit altem Code übrig bleibt. Der kurzen Unterbrechung steht ein klarer Nachweis gegenüber.

**Muss ich nach dem PHP-Update den ganzen Server neu starten?**  
In der Regel nicht. Es genügt, alle Dienste neu zu starten, die PHP laden: PHP-FPM, Apache bei mod_php, LiteSpeed, FrankenPHP oder die betroffenen Container. Ein Neustart des ganzen Servers ist die einfache Variante, wenn Sie unsicher sind, welche Dienste PHP nutzen.

**Startet mein Hoster PHP nach dem Update automatisch neu?**  
Das hängt vom Anbieter ab. Fragen Sie konkret nach, ob nach dem Patch alle PHP-Prozesse neu gestartet wurden, und lassen Sie sich das schriftlich bestätigen.

## Quellen

- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
