# Hoster-PHP-Update-Bestätigung: So fragen Sie nach dem Patch-Status

> So holen Sie beim Hoster eine belastbare Bestätigung zum PHP-Update nach PHP2Shell ein: welche Angaben zählen, Vorlage zum Kopieren, Antwort bewerten.

Quelle: https://phpsos.de/ratgeber/hoster-patch-status-erfragen/  
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 PHP2Shell beweist die angezeigte PHP-Version allein wenig, weil Hoster Korrekturen oft als Backport einspielen. Fordern Sie deshalb eine schriftliche Hoster-PHP-Update-Bestätigung an: Paketstand je PHP-Zweig, Zeitpunkt der Installation und Neustart aller PHP-Prozesse. Eine Vorlage zum Kopieren finden Sie unten.

## Warum gerade jetzt eine schriftliche Bestätigung zählt

Am 21.10.2026 hat das PHP-Projekt die Patches für zwei kritische Lücken veröffentlicht, die unter dem Namen PHP2Shell bekannt sind. Beide erlauben die Ausführung von Schadcode aus der Ferne ohne Anmeldung. Das BSI hat Warnstufe 3 / Orange ausgerufen und empfiehlt das sofortige Update.

Wer seine Website bei einem Hoster betreibt, kann das Update oft nicht selbst einspielen. Gleichzeitig tragen Sie als Betreiber die Verantwortung für die Daten Ihrer Kunden. Eine schriftliche, konkrete Bestätigung des Hosters ist deshalb mehr als Formsache. Sie ist ein Baustein Ihrer Dokumentation, etwa gegenüber Datenschutzbeauftragten, Versicherern oder der Geschäftsführung.

Hinzu kommt: Ein Patch entfernt keine Schadsoftware, die vorher eingeschleust wurde. Laut Medienberichten gab es bereits am 17.10. einen ersten beobachteten Angriffsversuch. Der genaue Zeitpunkt, zu dem Ihr Server geschützt war, ist daher wichtig für die Frage, ob Sie weiter prüfen müssen.

## Warum die angezeigte PHP-Version nicht reicht

Behoben sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Viele Distributionen und Hoster übernehmen die Korrektur aber als Backport in ihr eigenes Paket. Dann zeigt eine Oberfläche wie Plesk weiter 8.2.34 an, obwohl der Server gepatcht ist.

Umgekehrt kann eine korrekte Versionsnummer täuschen. Neue Dateien allein schützen nicht, solange alte PHP-Prozesse im Speicher laufen. Erst nach einem Neustart aller Worker ist der neue Stand aktiv. Mehr dazu im Beitrag [PHP-Version und Patchstand richtig prüfen](https://phpsos.de/php2shell/php-version-pruefen/).

| Aussage des Hosters | Was sie belegt | Was noch fehlt |
|---|---|---|
| „Alle Systeme sind aktuell.“ | wenig | Version oder Paketstand, Datum, Neustart |
| „PHP 8.3.36 ist installiert.“ | Version | Datum, Neustart, betroffene Server |
| „Backport im Paket xy, Neustart am …“ | Patch und Aktivierung | ggf. Angaben zu PHP 8.1 und älter |

## Welche Angaben Sie vom Hoster brauchen

Bitten Sie um Antworten auf diese Punkte, möglichst je Website oder Vertrag:

- Welche PHP-Zweige und Versionen sind für Ihre Websites aktiv, auch ältere, die nur für einzelne Verzeichnisse laufen?
- Sind die Korrekturen für CVE-2026-109618 und CVE-2026-109619 enthalten, als offizielle Version oder als Backport?
- Wann wurde das Update installiert, und wann wurden alle PHP-Prozesse (FPM-Pools, Apache, LiteSpeed) neu gestartet?
- Ist `session.upload_progress.enabled` wegen CVE-2026-115560 deaktiviert?
- Welche Betriebsart nutzt Ihr Tarif, etwa PHP-FPM oder Apache mit mod_php? Bei mod_php sieht das PHP-Team das höchste Risiko.
- Welche Zugriffs- und Fehlerlogs ab dem 20.10.2026 werden aufbewahrt, und wie erhalten Sie diese?

Läuft eine Website noch auf PHP 8.1 oder älter, fragen Sie gesondert nach. Für diese Zweige gibt es keine offiziellen Updates mehr, nur minimale Quell-Backports für 7.4, 8.0 und 8.1.

## Vorlage: Hoster-PHP-Update-Bestätigung anfordern

Kopieren Sie den Text in ein Support-Ticket oder eine E-Mail an Ihren Hoster. Ergänzen Sie die Angaben in eckigen Klammern.

```text
Betreff: Bitte um Bestätigung zum PHP-Patchstand (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)

Guten Tag,

wir betreiben bei Ihnen folgende Websites / Verträge:
[Kundennummer, Vertrag, Domains]

Im Zusammenhang mit den PHP-Sicherheitslücken CVE-2026-109618 und
CVE-2026-109619 (PHP2Shell, Patches vom 21.10.2026) sowie dem Hinweis
zu CVE-2026-115560 vom 23.10.2026 bitten wir um eine schriftliche
Bestätigung zu folgenden Punkten:

1. Welche PHP-Versionen bzw. Paketstände sind für unsere Websites aktiv?
2. Enthalten diese die Korrekturen (offizielle Version oder Backport)?
3. Datum und Uhrzeit der Installation.
4. Datum und Uhrzeit des Neustarts aller PHP-Prozesse (FPM, Apache,
   LiteSpeed o. Ä.).
5. Ist session.upload_progress.enabled serverseitig deaktiviert?
6. Welche PHP-Betriebsart wird verwendet (z. B. PHP-FPM, mod_php)?
7. Werden Zugriffs- und Fehlerlogs ab dem 20.10.2026 aufbewahrt, und
   wie können wir sie erhalten?
8. Falls eine Website noch PHP 8.1 oder älter nutzt: Welche Absicherung
   besteht dort, und welchen Umstieg empfehlen Sie?

Die Angaben benötigen wir für unsere interne Dokumentation.

Vielen Dank und freundliche Grüße
[Name, Firma, Funktion]
```

## Die Antwort richtig bewerten und selbst gegenprüfen

Eine gute Antwort nennt konkrete Stände, Daten und Uhrzeiten. Allgemeine Formulierungen wie „wir haben reagiert“ reichen für Ihre Akte nicht. Fragen Sie in diesem Fall freundlich nach den fehlenden Punkten.

Wenn Ihr Tarif es erlaubt, prüfen Sie zusätzlich selbst. Mit SSH-Zugang genügen meist diese Befehle:

```bash
# Version der Kommandozeile (kann von der Web-Version abweichen)
php -v
# Paketstand unter Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Paketstand unter RHEL, Alma, Rocky
rpm -qa | grep -i php
# Seit wann laufen die PHP-FPM-Prozesse?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
```

Liegt der Startzeitpunkt der PHP-Prozesse vor dem bestätigten Installationsdatum, war der Neustart nicht vollständig.

### Wenn der Hoster nicht oder nur ausweichend antwortet

Bleibt eine Antwort aus oder fehlen die entscheidenden Angaben, sollten Sie die Lage nicht als geklärt betrachten. Das BSI empfiehlt, Webserver vorübergehend vom Netz zu nehmen, wenn ein Update nicht sofort möglich ist. Ob das für Ihre Website verhältnismäßig ist, entscheidet die Geschäftsführung, idealerweise schriftlich und mit Datum.

Parallel lohnt der Blick auf mögliche Spuren eines Angriffs, denn der Patch-Zeitpunkt bleibt offen. Anhaltspunkte liefert der Beitrag [Bin ich schon kompromittiert?](https://phpsos.de/php2shell/bin-ich-gehackt-anzeichen/). Ohne SSH-Zugang bleibt die schriftliche Bestätigung Ihr wichtigster Beleg. Welche Pflichten beim Hoster liegen und welche bei Ihnen, erklärt die Seite [Shared Hosting: Was der Hoster macht](https://phpsos.de/server/shared-hosting/); für betreute Server hilft [Managed Server: Verantwortung klären](https://phpsos.de/server/managed-server/).

> **Tipp:**
> Legen Sie Anfrage, Antwort und eigene Prüfergebnisse mit Datum in einem Ordner ab. Diese Akte hilft später bei Fragen von Versicherern oder Datenschutzbeauftragten.

## Wie hilft PHP SOS konkret?

- Wir formulieren mit Ihnen die Anfrage an den Hoster und bewerten die Antwort fachlich.
- Wo Zugriff besteht, prüfen wir Paketstand, aktive Betriebsart und Neustart der PHP-Prozesse selbst.
- Bleiben Lücken, setzen wir Übergangsmaßnahmen um oder planen den Umstieg auf eine unterstützte Version.
- Wir halten Ergebnis und Zeitpunkte in einem Nachweis fest, den Sie intern weitergeben können.

Wie das Update mit Neustart und Nachweis abläuft, beschreibt unser [PHP-Patch-Service](https://phpsos.de/leistungen/php-patch-service/).


## Häufige Fragen

**Reicht es, wenn mein Hoster schreibt, dass alles aktuell ist?**  
Für Ihre Dokumentation eher nicht. Bitten Sie um konkrete Angaben: Paketstand oder Version je PHP-Zweig, Datum der Installation und Datum des Neustarts aller PHP-Prozesse. Erst damit können Sie das Zeitfenster der Verwundbarkeit eingrenzen.

**Warum zeigt meine Hosting-Oberfläche noch PHP 8.2.34 an?**  
Distributionen und Hoster spielen Sicherheitskorrekturen teils als Backport ein, ohne die Versionsnummer zu ändern. Plesk kann dann weiter 8.2.34 anzeigen, obwohl der Server gepatcht ist. Klarheit schafft nur die Bestätigung des Anbieters zum Paketstand.

**Was mache ich, wenn der Hoster nicht antwortet?**  
Dokumentieren Sie Ihre Anfrage mit Datum und fragen Sie nach einer angemessenen Zeit erneut nach. Prüfen Sie parallel, ob Sie Übergangsmaßnahmen selbst setzen können, und stimmen Sie mit der Geschäftsführung ab, ob die Website bis zur Klärung vom Netz geht, wie es das BSI für nicht gepatchte Server empfiehlt.

**Schließt ein WordPress- oder Shop-Update die Lücke ebenfalls?**  
Nein. PHP2Shell steckt in PHP selbst. Ein Update des CMS oder der Shopsoftware ändert nichts am PHP-Interpreter, der auf dem Server läuft.

## 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/)