# PHP-Patch-Service: Update einspielen lassen, mit Neustart und Nachweis

> PHP-Update einspielen lassen: Wir patchen auf die behobenen Versionen, starten alle Worker neu und belegen den Stand schriftlich. Für Firmen und Agenturen.

Quelle: https://phpsos.de/leistungen/php-patch-service/  
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:** Wer ein PHP-Update einspielen lassen will, braucht mehr als neue Pakete: Entscheidend sind der richtige Paketstand, der Neustart aller PHP-Prozesse und ein Beleg dafür. Genau das liefert unser PHP-Patch-Service. Sie erhalten einen schriftlichen Nachweis je Server, den Sie intern oder gegenüber Dritten vorlegen können.

## Warum ein PHP-Update allein oft nicht reicht

Seit dem 21.10.2026 gibt es Patches für die PHP2Shell-Lücken CVE-2026-109618 und CVE-2026-109619. Das BSI empfiehlt das sofortige Update. In der Praxis sehen wir drei typische Stolpersteine.

Erstens zeigt die Versionsnummer nicht immer den wahren Stand. Distributionen und Hoster spielen teils Backports ein; dann meldet zum Beispiel Plesk weiter 8.2.34, obwohl der Paketstand gepatcht ist. Zweitens laufen nach dem Einspielen oft alte PHP-Prozesse weiter. Neue Dateien auf der Platte schützen nicht, solange die alten Worker im Speicher arbeiten. Drittens laufen auf einem Server häufig mehrere PHP-Versionen parallel, und eine davon wird vergessen.

## PHP-Update einspielen lassen: die behobenen Versionen

| Zweig | Behoben ab | Vorgängerstand | Hinweis |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | zusätzlich `fatal_error_backtraces` prüfen |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | Unterstützung endet am 31.12.2026 |
| PHP 8.1 und älter | keine offiziellen Updates | – | nur minimale Quell-Backports für 7.4, 8.0, 8.1 |

Bei Paketen aus Distributionen oder von Hostern zählt nicht die Zahl hinter „PHP“, sondern der Paketstand, den der Anbieter als gepatcht bestätigt. Wie Sie das selbst prüfen, steht unter [PHP-Version und Patchstand richtig prüfen](https://phpsos.de/php2shell/php-version-pruefen/).

## Wie hilft PHP SOS konkret?

1. **Inventur:** Wir erfassen alle PHP-Installationen auf dem Server, die Betriebsart (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) und welche Website welche Version nutzt.
2. **Update einspielen:** Wir installieren die behobenen Versionen aus der Paketquelle Ihrer Distribution, Ihres Panels oder des offiziellen Projekts. Für Container bauen wir mit Ihnen neue Images.
3. **Neustart aller Prozesse:** Wir starten PHP-FPM, Apache, LiteSpeed oder die jeweiligen Worker vollständig neu und kontrollieren, dass kein Prozess älter ist als das Update. Hintergründe stehen auf [PHP-FPM und alle Worker neu starten](https://phpsos.de/php2shell/php-fpm-neustart/).
4. **Funktionsprüfung:** Wir rufen die wichtigsten Seiten und Funktionen auf, etwa Startseite, Login, Formulare und Kasse, und prüfen die Fehlerprotokolle.
5. **Nachweis:** Sie erhalten je Server ein Protokoll mit Version, Paketstand, Zeitpunkt des Neustarts und offenen Punkten.

Ein typischer Prüfschritt nach dem Neustart sieht so aus:

```bash
# Version der PHP-CLI und des FPM-Binärs (Pfad je nach System)
php -v
php-fpm8.3 -v
# Startzeit der FPM-Prozesse: muss nach dem Update liegen
ps -o pid,lstart,cmd -C php-fpm8.3
```

## Sonderfälle: Panels, Container und mehrere PHP-Versionen

Auf Servern mit **Plesk oder cPanel** kommen PHP-Versionen oft aus den Paketquellen des Panels und nicht aus der Distribution. Dort prüfen wir jede installierte Version einzeln, auch solche, die gerade keiner Website zugeordnet sind. Unbenutzte, veraltete Versionen entfernen wir nach Absprache, damit sie nicht versehentlich wieder aktiviert werden.

In **Docker- und Kubernetes-Umgebungen** reicht ein Update auf dem Host nicht. Das PHP steckt im Image, und erst ein neu gebautes Image mit gepatchtem Basisstand, ausgerollt auf alle laufenden Container, schließt die Lücke. Wir prüfen dabei auch, ob ältere Images in Registrierungen oder Deployments noch verwendet werden. Einzelheiten stehen unter [PHP in Docker-Containern patchen](https://phpsos.de/php2shell/docker-container-patchen/).

Bei **mod_php** läuft PHP direkt im Apache-Prozess. Das PHP-Team stuft das Risiko dort am höchsten ein. Nach dem Update muss deshalb Apache selbst vollständig neu gestartet werden, ein bloßes Neuladen der Konfiguration genügt nicht in jedem Fall.

## Was Sie von uns bekommen

- ein Patch-Protokoll je Server: installierte Pakete, Versionen, Quelle, Zeitpunkt
- den Beleg, dass alle PHP-Prozesse neu gestartet wurden
- eine Liste der geprüften Websites und Funktionen
- Hinweise auf Systeme, die nicht gepatcht werden konnten, mit Begründung
- eine Empfehlung für den weiteren Weg, zum Beispiel bei PHP 8.2 wegen des nahen Supportendes

## Was wir von Ihnen brauchen

- **Zugang:** SSH mit Administratorrechten oder Panel-Zugang (Plesk, cPanel o. Ä.)
- **Wartungsfenster:** wann ein kurzer Neustart erfolgen darf
- **Ansprechpartner:** für Rückfragen und für die Freigabe nach der Funktionsprüfung
- **Backups:** Bestätigung, dass eine aktuelle Sicherung vorliegt, oder den Auftrag, vorher eine anzulegen
- **Hinweise zu Eigenentwicklungen:** besondere PHP-Erweiterungen oder Konfigurationen, die beachtet werden müssen

Bei Shared Hosting ohne eigenen Serverzugang können wir nicht selbst patchen. Wir helfen Ihnen dann, beim Hoster die richtigen Fragen zu stellen und die Antwort zu bewerten.

## Was wir nicht versprechen

Der Patch-Service schließt die bekannte Lücke. Er beantwortet nicht, ob der Server vor dem Update schon kompromittiert wurde, und entfernt keine eingeschleuste Schadsoftware. Wenn Sie das wissen möchten, ist die [PHP2Shell-Soforthilfe](https://phpsos.de/leistungen/php2shell-soforthilfe/) mit Spurensuche der passende Auftrag.

Für PHP 8.1 und älter gibt es keine offiziellen Updates mehr. Hier setzen wir Übergangsmaßnahmen um und empfehlen die [Migration auf eine unterstützte Version](https://phpsos.de/leistungen/php-migration-legacy/). Eine Kompatibilitätszusage für Ihr CMS geben wir nicht aus dem Gedächtnis, sondern prüfen sie anhand der Systemanforderungen des Herstellers.


## Häufige Fragen

**Warum zeigt mein Server nach dem Update noch die alte PHP-Version?**  
Das kann zwei Gründe haben. Entweder hat die Distribution einen Backport eingespielt, dann bleibt die Versionsnummer gleich, obwohl der Paketstand gepatcht ist. Oder alte PHP-Prozesse laufen noch im Speicher und müssen neu gestartet werden.

**Welche PHP-Versionen schließen PHP2Shell?**  
Behoben ist die Lücke in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21.10.2026. Bei Distributionspaketen zählt der Paketstand, den der Anbieter als gepatcht bestätigt.

**Kann das Update meine Website lahmlegen?**  
Ein Update innerhalb derselben Hauptversion, etwa von 8.3.35 auf 8.3.36, ist in der Regel unkritisch. Ein kurzer Neustart der PHP-Prozesse ist aber nötig. Wir stimmen das Zeitfenster mit Ihnen ab und prüfen die Seiten danach.

**Ist mit dem Patch alles erledigt?**  
Für die Lücke selbst ja, sobald alle Prozesse neu gestartet sind. Ob vor dem Patch schon jemand eingedrungen ist, zeigt der Patch nicht. Dafür braucht es eine eigene Prüfung.

## Quellen

- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: Unterstützte Versionen](https://www.php.net/supported-versions.php)
- [BSI: Bundesamt für Sicherheit in der Informationstechnik](https://www.bsi.bund.de/)