# CVE-2026-109619: RCE durch veralteten globalen Zustand

> CVE-2026-109619 verständlich erklärt: warum interner Zustand zwischen Anfragen gefährlich wird, welche PHP-Versionen behoben sind und wie Sie absichern.

Quelle: https://phpsos.de/php2shell/cve-2026-109619/  
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:** CVE-2026-109619 ist die zweite Lücke hinter PHP2Shell. Interner Zustand, der zu einer Anfrage gehört, kann nach dem Freigeben des Speichers bestehen bleiben; eine spätere Anfrage im selben Worker kann ihn nutzen, bevor er zurückgesetzt wird. Die Folge ist Codeausführung ohne Anmeldung. Abhilfe: Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und Neustart aller Worker.

## Was ist CVE-2026-109619?

CVE-2026-109619 (GitHub-Kennung GHSA-6wmf-4rv5-p3rp) ist mit CVSS v4.0 9.2 bewertet. Zusammen mit [CVE-2026-109618](https://phpsos.de/php2shell/cve-2026-109618/) bildet sie PHP2Shell. Beide Lücken stecken in PHP selbst und nicht in einer Anwendung.

Die Wirkung ist dieselbe wie bei der Schwesterlücke: Ein Angreifer kann aus der Ferne, ohne Passwort und ohne Benutzerkonto, Code auf dem Server ausführen. Die Ursache ist aber eine andere.

## Warum veralteter Zustand im Worker gefährlich ist

Ein PHP-Webserver startet nicht für jede Anfrage einen neuen Prozess. Bei PHP-FPM, Apache mit mod_php, LiteSpeed oder FrankenPHP bearbeitet ein Worker nacheinander viele Anfragen. Zwischen zwei Anfragen setzt PHP seinen internen Zustand zurück, damit nichts von Anfrage A in Anfrage B gelangt.

Bei CVE-2026-109619 klappt dieses Zurücksetzen nicht vollständig. Laut php.net kann zur Anfrage gehörender interner Zustand nach dem Freigeben des Speichers bestehen bleiben. Eine spätere Anfrage im selben Worker kann diesen veralteten Zustand nutzen, bevor er zurückgesetzt wird. Vereinfacht gesagt: Etwas wird weiterverwendet, das eigentlich schon nicht mehr gültig ist.

Aus Sicht des Betriebs ist das bemerkenswert. Die Wiederverwendung von Workern ist gewollt, weil sie Webserver schnell macht: Ein Worker muss nicht für jede Anfrage neu starten, Erweiterungen laden und Speicher anlegen. Die Lücke trifft also eine Eigenschaft, die praktisch jede produktive PHP-Installation hat. php.net nennt keine Konfiguration, die das Problem vollständig vermeidet; deshalb führt der Weg über das Update.

Einzelheiten zur Ausnutzung veröffentlichen wir nicht. Für Betreiber zählt: Jede Betriebsart, in der Worker mehrere Anfragen bedienen, ist im Blick zu behalten, und genau diese Betriebsarten sind die üblichen.

## Die beiden PHP2Shell-Lücken im Vergleich

| Merkmal | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub-Kennung | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Bewertung | CVSS v4.0 9.2 | CVSS v4.0 9.2 |
| Auslöser | Out-of-Memory während der Initialisierung der Anfragedaten | Interner Zustand bleibt nach Freigabe bestehen |
| Wirkung | Codeausführung ohne Anmeldung | Codeausführung ohne Anmeldung |
| Behoben in | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

Betroffen sind PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php; warum, erklären wir unter [Warum mod_php das höchste Risiko trägt](https://phpsos.de/php2shell/mod-php-risiko/).

## CVE-2026-109619 schließen: Update, dann alle Worker neu starten

Gerade bei dieser Lücke ist der Neustart entscheidend. Solange alte Worker im Speicher laufen, arbeitet der Server mit dem fehlerhaften Code weiter, auch wenn die neuen Dateien längst auf der Platte liegen.

Prüfen Sie Version und Paketstand. Paketnamen weichen je Distribution und Hoster-Oberfläche ab:

```bash
php -v
php-fpm8.3 -v                  # FPM-Binary kann eine andere Version haben als die CLI
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL-Familie
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
```

Danach alle betroffenen Dienste neu starten:

```bash
sudo systemctl restart php8.3-fpm     # je installierter PHP-Version
sudo systemctl restart apache2        # bei mod_php; unter RHEL heißt der Dienst httpd
```

Wenn Ihre Distribution oder Ihr Hoster einen Backport einspielt, bleibt die angezeigte Versionsnummer womöglich gleich. Dann zählen der Changelog des Pakets und die schriftliche Bestätigung des Anbieters. Eine Schritt-für-Schritt-Prüfung finden Sie unter [PHP-FPM und alle Worker neu starten](https://phpsos.de/php2shell/php-fpm-neustart/).

> **Tipp:**
> Notieren Sie Datum und Uhrzeit des Neustarts. Für die spätere Bewertung, ob ein Angriff vor oder nach dem Patch stattfand, ist dieser Zeitpunkt der wichtigste Bezugspunkt.

## Was nach dem Patch noch zu tun bleibt

Ein Patch beweist nicht, dass vorher nichts passiert ist. Laut Medienberichten wurde ein erster Angriffsversuch am 17. Oktober beobachtet, vier Tage vor den Patches. Bewahren Sie Server-Logs ab dem 20. Oktober auf, wie es die Fachpresse empfiehlt, und prüfen Sie den Server auf Auffälligkeiten. Hinweise dazu liefert die Seite [Bin ich schon kompromittiert?](https://phpsos.de/php2shell/bin-ich-gehackt-anzeichen/).

Denken Sie dabei an die Reichweite: Bei einer erfolgreichen Codeausführung hat der Angreifer die Rechte des PHP-Prozesses. Er kann lesen, was die Anwendung lesen darf, etwa Konfigurationsdateien mit Datenbankzugängen oder API-Schlüsseln. Bestätigt sich ein Vorfall, gehören diese Zugangsdaten nach der Bereinigung erneuert.

## Wie hilft PHP SOS konkret?

Mit dem [PHP-Patch-Service](https://phpsos.de/leistungen/php-patch-service/) setzen wir die Korrektur nachvollziehbar um:

- **Erfassen:** Welche PHP-Versionen und Betriebsarten laufen auf welchem Server, und welche Paketquelle liefert sie?
- **Patchen:** Update aus der richtigen Quelle oder Übergangsmaßnahmen nach php.net, wo das Update noch blockiert ist.
- **Neustart kontrollieren:** Wir prüfen Prozess für Prozess, dass nur noch die korrigierte Version läuft.
- **Dokumentieren:** Versionen, Paketstände und Neustartzeitpunkte, damit Sie den Stand belegen können.


## Häufige Fragen

**Was unterscheidet CVE-2026-109619 von CVE-2026-109618?**  
CVE-2026-109618 entsteht, wenn ein Out-of-Memory-Zustand die Anfrage mitten in der Initialisierung unterbricht. CVE-2026-109619 betrifft Zustand, der nach dem Ende einer Anfrage im Worker übrig bleibt. Beide führen zu Codeausführung ohne Anmeldung und sind in denselben PHP-Versionen behoben.

**Hilft es, PHP-FPM-Worker öfter neu zu starten?**  
Als Ersatz für das Update ist das nicht geeignet. php.net nennt häufigere Worker-Neustarts nicht als Übergangsmaßnahme. Neu starten müssen Sie die Worker aber nach dem Update, damit die korrigierte Version überhaupt läuft.

**Bin ich mit einem CMS-Update gegen CVE-2026-109619 geschützt?**  
Nein. Die Lücke liegt in PHP und nicht in WordPress, Shopware, TYPO3 oder einem anderen System. Nur ein PHP-Update oder ein bestätigter Backport des Anbieters schließt sie.

**Gibt es bekannte Spuren eines Angriffs über CVE-2026-109619?**  
Bestätigte Indicators of Compromise wurden bisher nicht veröffentlicht. Erkennung beruht auf Verhaltensanalyse, etwa neuen PHP-Dateien, ungewöhnlichen ausgehenden Verbindungen oder unbekannten Cronjobs.

## Quellen

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