# PHP2Shell: Bin ich betroffen und was tun?

> PHP2Shell nennen Medien zwei kritische PHP-Lücken (CVE-2026-109618 und CVE-2026-109619), über die Angreifer aus der Ferne Schadcode auf Webservern ausführen könnten. Betroffen sind laut PHP-Projekt alle Installationen, die Webanfragen bedienen; behoben sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Prüfen Sie Ihre Version oder fragen Sie Ihren Hoster, und starten Sie nach dem Update alle PHP-Prozesse neu.

Veröffentlicht: 29.10.2026 · Kategorie: Recht und Sicherheit · Adresse: https://www.heisenberg-it.de/blog/php2shell-php-luecke-pruefen-update

## Das Wichtigste in Kürze

- PHP2Shell steht für zwei kritische PHP-Lücken, die das BSI mit CVSS 4.0 bei 9.2 von 10 bewertet.
- Gepatcht sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35; bei Distributionen mit Backports kann die Versionsnummer gleich bleiben.
- Ein CMS-, Plugin- oder Shop-Update ersetzt das PHP-Update nicht, und Anmeldung im Anwendungscode stoppt den Angriff nicht.
- PHP 8.1 und älter erhalten keine regulären Updates; ein Umstieg auf eine unterstützte Version ist sinnvoll.
- Zur tatsächlichen Ausnutzung sind die Angaben widersprüchlich; bei Verdacht gilt: patchen, Logs prüfen, Zugangsdaten erneuern.

## Was ist PHP2Shell?

PHP2Shell ist der Medienname für zwei kritische Schwachstellen in PHP. Angreifer könnten damit aus der Ferne Schadcode auf Webservern mit PHP-Anwendungen ausführen [1]. Der Name stammt aus der Berichterstattung. Das BSI zieht den Vergleich mit Log4Shell [1].

Die beiden Lücken im Überblick:

- **CVE-2026-109618:** Remote Code Execution (Ausführung fremden Codes aus der Ferne) durch Speicherkorruption bei Speichermangel. Unvollständig initialisierte Anfragedaten werden beim Aufräumen als gültig behandelt [2].
- **CVE-2026-109619:** Remote Code Execution durch veralteten globalen Zustand. Interner Zustand einer Anfrage überlebt den freigegebenen Speicher. Eine spätere Anfrage am selben Worker kann ihn nutzen [2].

Das BSI nennt für CVSS 4.0 (ein Bewertungssystem für Schwachstellen) einen Wert von 9.2 von 10 [1]. Aus den Scores lässt sich ableiten, dass weder Anmeldung noch Nutzerinteraktion nötig sind [1].

Die Lücke wurde dem PHP-Team laut Offsec am 24.08.2026 gemeldet. Behebung und Bekanntgabe folgten am 21.10.2026 [3]. Das Release erschien laut JFrog um 14:00 UTC [4]. Die BSI-Warnung liegt in Version 1.2 vor (Stand 22.10.2026) [1].

> **Gut zu wissen:** Lesen Sie die vollständige BSI-Warnung mit Bewertung und Empfehlungen selbst nach. Sie wird fortgeschrieben, die Änderungshistorie zeigt den aktuellen Stand [1].

## Bin ich betroffen und welche PHP-Version brauche ich?

Betroffen sind laut PHP-Projekt alle PHP-Installationen, die Webanfragen bedienen [2]. Dazu zählen die Betriebsarten PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed [2]. Wer PHP nur auf der Kommandozeile für eigene Skripte nutzt, bedient keine Webanfragen.

Diese Versionen enthalten die Korrektur [2]:

| PHP-Zweig | Gepatchte Version | Support-Ende (SOCRadar) |
|---|---|---|
| 8.5 | 8.5.12 | nicht angegeben |
| 8.4 | 8.4.27 | 31.12.2026 (aktiver Support) [5] |
| 8.3 | 8.3.36 | 31.12.2027 (Sicherheitsfixes) [5] |
| 8.2 | 8.2.35 | 31.12.2026 (nur Sicherheitsfixes) [5] |

Stand: Oktober 2026.

Die Angaben zu älteren Versionen weichen ab:

- Das PHP-Projekt spricht von „all PHP installations“ [2].
- Sansec und Offsec nennen jedes ungepatchte PHP seit Version 5.4 [6][3].
- cms-admins.de nennt nur PHP 8.2 bis 8.5 [7].

Gehen Sie deshalb davon aus: Alles, was nicht auf einer gepatchten Version oder einem gepatchten Distributionspaket läuft, gilt als verwundbar.

Bei Shop- und CMS-Systemen gilt: Magento, Shopware und WooCommerce sind laut Sansec auch bei sauberem eigenen Code betroffen [6]. Der Fehler liegt in PHP, nicht in der Anwendung.

> **Achtung:** Das PHP-Team nennt mod_php als Betriebsart mit dem höchsten Risiko. Dort ist ein Exploit gezeigt, der vor jedem Anwendungscode greift [2].

## Wie finde ich meine PHP-Version?

Die Prüfung hängt davon ab, wo Ihre Website läuft. Entscheidend ist die Version, die Webanfragen bedient. Die Version auf der Kommandozeile kann davon abweichen.

### Shared und Managed Hosting

Bei gemietetem Webspace steht die Version meist im Hosting-Panel. In WordPress finden Sie sie unter Werkzeuge → Website-Zustand → Bericht → Server [8].

Die Versionsnummer allein genügt hier nicht. Den Patch-Stand muss Ihr Hoster bestätigen. Fragen Sie konkret nach:

1. Ist die Korrektur für CVE-2026-109618 und CVE-2026-109619 eingespielt?
2. Wurden die PHP-Prozesse danach neu gestartet?
3. Bis wann bekommt Ihr Tarif PHP-Versionen mit Sicherheitsfixes?

Können Sie die PHP-Version im Panel selbst wählen, stellen Sie auf einen gepatchten Zweig um, sobald der Hoster ihn anbietet.

### Eigener Server und Distributionen mit Backports

Auf einem eigenen Server fragen Sie die Version mit `php -v` ab. Prüfen Sie bei PHP-FPM oder Apache zusätzlich, welches Paket die Webanfragen tatsächlich bedient.

> **Definition:** Ein Backport bedeutet, dass eine Distribution den Fix in ein älteres Paket übernimmt, ohne die Versionsnummer zu ändern [9].

Bei Ubuntu, Debian und Red Hat kann die Nummer deshalb gleich bleiben. Ein Berater nennt Ubuntu 24.04 als Beispiel: Die korrigierte Fassung werde weiter als PHP 8.3.6 ausgeliefert [9]. Eine Zahl unterhalb von 8.3.36 heißt dort also nicht automatisch „verwundbar“.

So gehen Sie vor:

1. Lesen Sie den Changelog des installierten Pakets, etwa mit `apt changelog <Paketname>` (Debian, Ubuntu) oder `rpm -q --changelog <Paketname>` (Red Hat).
2. Suchen Sie nach den CVE-Nummern CVE-2026-109618 und CVE-2026-109619.
3. Suchen Sie bei Zweifeln den Sicherheitshinweis Ihrer Distribution und vergleichen Sie die dort genannte Paketversion mit Ihrer.
4. Installieren Sie verfügbare Paket-Updates, wenn weder Changelog noch Hinweis den Fix bestätigen.

## Was tun: Update einspielen?

Ja. Laut PHP-Team ist nur ein Update eine vollständige Lösung [2]. Linux-Distributionen und LTS-Anbieter (Anbieter mit verlängertem Support) erhielten die Patches vorab [2].

Auf eigenen Servern spielen Sie das Update über die Paketverwaltung ein. Starten Sie danach alle PHP-Prozesse neu [10]. Ohne Neustart laufen alte Prozesse mit altem Code weiter. Prüfen Sie nach dem Neustart erneut die Version.

Was nicht reicht:

- **CMS-, Plugin- oder Shop-Updates:** Sie ersetzen das PHP-Update nicht [10]. Der Fehler sitzt in PHP selbst.
- **Anmeldung und Rechteprüfung in der Anwendung:** Datadog bestätigt, dass Authentifizierung auf Anwendungsebene den Angriff nicht stoppt. PHP verarbeitet die Anfrage vor jedem Anwendungscode [11].
- **Firewall:** Für Firewall-Regeln gibt es keine belegte Schutzzusage. Planen Sie das Update ein, statt sich auf Filter zu verlassen.

> **Beispiel:** Angenommen, ein Webshop läuft auf einem gemieteten Managed-Server mit PHP 8.3. Der Betreiber aktualisiert Shop und Plugins, fragt aber nicht beim Hoster nach. Das Risiko bleibt, solange PHP selbst nicht gepatcht und neu gestartet ist.

## Was gilt für PHP 8.1 und älter?

Diese Versionen erhalten vom Projekt keine regulären Updates mehr [2]. Das Projekt stellte jedoch minimale Quell-Backports für 7.4, 8.0 und 8.1 bereit [2]. Das sind Quellcode-Patches, keine fertigen Pakete. Sie müssten selbst gebaut und eingespielt werden.

Sinnvoll ist der Umstieg auf eine unterstützte Version. Beachten Sie die Enddaten (Stand: Oktober 2026) [5]:

- PHP 8.2: nur noch Sicherheitsfixes bis 31.12.2026
- PHP 8.4: aktiver Support bis 31.12.2026
- PHP 8.3: Sicherheitsfixes bis 31.12.2027

Planen Sie den Umstieg mit Test: Prüfen Sie vorab, ob Theme, Plugins und Erweiterungen mit der neuen Version laufen. Legen Sie ein Backup an. Testen Sie zuerst in einer Staging-Umgebung, einer Kopie der Website.

## Was hilft, wenn ich nicht sofort updaten kann?

Mit Notmaßnahmen lässt sich die Angriffsfläche verringern. Das PHP-Team nennt etwa `memory_limit=-1` und ein niedriges `post_max_size` [2]. Das PHP-Team betont, dass diese Maßnahmen die Installation nicht sicher machen. Nur ein Update ist eine vollständige Lösung [2].

Behandeln Sie solche Einstellungen als Übergang:

1. Notieren Sie die geänderten Werte, damit Sie sie nach dem Update zurücknehmen können.
2. Prüfen Sie, ob Uploads und Formulare Ihrer Anwendung mit dem niedrigen `post_max_size` weiter funktionieren.
3. Setzen Sie einen festen Termin für das Update.

Sansec nennt in seiner Analyse außerdem die Funktion Session-Upload-Progress als Angriffsweg [6]. Abstract Security rät, diese Funktion abzuschalten [12]. Das ist die Einschätzung einer einzelnen Firma. Prüfen Sie vor einem Abschalten, ob Ihre Anwendung die Funktion nutzt, und behandeln Sie es wie die anderen Notmaßnahmen als Übergang bis zum Update.

## Wird die Lücke ausgenutzt?

Die Lage ist widersprüchlich. Zum Zeitpunkt der BSI-Meldung gab es keine bestätigten Ausnutzungen, aber unbestätigte Berichte über existierende Exploits [1].

Was dazu bekannt ist (alles Herstellerangaben):

- Unit 42 meldete am 23.10.2026 Aktivität nach einem Einbruch bei einer europäischen Behörde über eine verwundbare PHP-Anwendung. Die Verbindung zu PHP2Shell ist laut SOCRadar zunächst nur angenommen [5].
- Laut Sansec funktionieren öffentliche Proofs-of-Concept (Demo-Angriffe) gegen eine Standardinstallation nicht. Die meisten brauchen eine Local-File-Inclusion-Lücke in der Anwendung [6].

> **Achtung:** Ein fehlender Beweis für Angriffe ist keine Entwarnung. Die Lücke ist öffentlich bekannt, und das BSI warnt vor Webanwendungen weltweit [1].

Wer jetzt wartet, geht ein vermeidbares Risiko ein.

## Was tun bei Verdacht auf einen Angriff?

Patchen Sie zuerst, damit sich der Angriff nicht wiederholt. Prüfen Sie danach die Logs von Webserver und Anwendung auf auffällige Anfragen und unbekannte Dateien.

Erneuern Sie dann Zugangsdaten. Sansec weist darauf hin, dass CVE-2026-109618 Serverspeicher offenlegen kann, darunter Passwörter, Tokens und Schlüssel [6]. Tauschen Sie deshalb aus:

- Passwörter für Datenbank, Admin-Konten, FTP und SSH
- API-Tokens und Zugangsschlüssel
- Schlüssel und Salts in der Anwendungskonfiguration

Holen Sie bei einem bestätigten Einbruch Fachleute für IT-Forensik dazu. Ob eine Meldepflicht besteht, etwa wegen betroffener personenbezogener Daten, hängt vom Einzelfall ab. Fragen Sie Ihre Datenschutzbeauftragte oder einen Fachanwalt. Dieser Artikel ist keine Rechtsberatung.

## Grenzen und offene Fragen

Nicht alles ist geklärt. Wichtig für Ihre Entscheidung:

- **Betroffene Altversionen:** Die Angaben reichen von „nur 8.2 bis 8.5“ [7] bis „alle Versionen seit 5.4“ [6][3]. Das PHP-Projekt spricht von allen Installationen [2].
- **Distributionen:** Der konkrete Patch-Stand bei Debian, Ubuntu, Red Hat und SUSE hängt vom jeweiligen Sicherheitshinweis ab. Prüfen Sie ihn selbst.
- **Reichen die Patches?** Abstract Security stellt in einem Beitrag unter dem Titel „The patch stops these CVEs, not the RCE“ die These auf, dass der Patch nicht alle Wege zur Codeausführung schließt, und verweist auf eine weitere Lücke (CVE-2026-115560) [12]. Das ist die Einschätzung einer einzelnen Firma, keine gesicherte Tatsache. Beobachten Sie die Ankündigungen des PHP-Projekts und des BSI.
- **Ausnutzung:** Das BSI nannte zunächst keine bestätigten Ausnutzungen [1]; der Unit-42-Fall ist nur über SOCRadar berichtet, und die Verbindung zu PHP2Shell ist angenommen [5].
- **Recht:** Ob Meldepflichten gelten, hängt vom Einzelfall ab; lassen Sie das prüfen.

Der Hinweis auf weitere CVEs im selben Release, etwa zu Brotli in den Windows-Builds, betrifft ein anderes Thema [2].

## Fazit

Prüfen Sie Ihre PHP-Version oder fragen Sie beim Hoster nach dem Patch-Stand. Aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder ein bestätigt gepatchtes Distributionspaket, und starten Sie alle PHP-Prozesse neu. Lösen Sie veraltete Versionen ab; Notmaßnahmen sind nur eine Übergangslösung [2].

## Häufige Fragen

### Warum heißt die Lücke PHP2Shell und was hat sie mit Log4Shell zu tun?

Der Name PHP2Shell stammt aus der Berichterstattung, nicht vom PHP-Projekt [1]. Das BSI zieht den Vergleich mit Log4Shell, weil auch hier Angreifer aus der Ferne Schadcode auf Servern ausführen könnten [1]. Maßgeblich für Ihre Maßnahmen sind die CVE-Nummern CVE-2026-109618 und CVE-2026-109619, nicht der Medienname.

### Muss ein Vorfall gemeldet werden?

Das lässt sich nicht pauschal beantworten, es hängt vom Einzelfall ab. Entscheidend ist unter anderem, ob personenbezogene Daten betroffen sind. Wenden Sie sich bei einem Verdacht an Ihre Datenschutzbeauftragte, einen Fachanwalt oder Fachleute für IT-Sicherheit. Dieser Artikel enthält keine Rechtsberatung und nennt keine konkreten Fristen.

### Was bedeuten die unterschiedlichen Bewertungen (CVSS 4.0: 9.2, NVD CVSS 3.1: 9.8 und 8.1)?

Es handelt sich um zwei verschiedene Bewertungssysteme. Das BSI nennt für CVSS 4.0 einen Wert von 9.2 [1]. Laut cms-admins.de vergibt das PHP-Team nach CVSS 4.0 ebenfalls jeweils 9.2, die NVD bewertet nach CVSS 3.1 mit 9.8 für CVE-2026-109618 und 8.1 für CVE-2026-109619 [7]. Alle genannten Werte liegen im hohen bis kritischen Bereich.

### Hilft eine Firewall gegen PHP2Shell?

Als vollständige Lösung nicht: Laut PHP-Team ist nur ein Update eine vollständige Lösung [2]. Auch Anmeldung im Anwendungscode stoppt den Angriff nicht, weil PHP die Anfrage vorher verarbeitet [11]. Eine Firewall kann höchstens ergänzen. Eine belegte Schutzzusage gibt es nicht, planen Sie also das PHP-Update ein.

### Betrifft die Lücke auch WordPress, WooCommerce, Shopware und Magento?

Ja, indirekt, weil die Lücke in PHP selbst liegt. Betroffen sind laut PHP-Projekt alle PHP-Installationen, die Webanfragen bedienen [2]. Magento, Shopware und WooCommerce sind laut Sansec auch bei sauberem eigenen Code betroffen [6]. Ein Update der Anwendung ersetzt das PHP-Update nicht [10].

### Warum ist mod_php besonders gefährdet?

Das PHP-Team nennt mod_php als Betriebsart mit dem höchsten Risiko. Dort ist ein Exploit gezeigt, der vor jedem Anwendungscode greift [2]. Anwendungsseitige Schutzmechanismen wie eine Anmeldung kommen dann zu spät. Betreiber mit mod_php sollten das Update deshalb zuerst einplanen und Prozesse danach neu starten.

## Quellen

1. [Version 1.2: PHP - Kritische Schwachstellen bedrohen Webanwendungen weltweit](https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-297981-1032.html) – BSI, 22.10.2026
2. [PHP: News Archive - 2026](https://www.php.net/archive/2026.php) – PHP, 2026
3. [PHP2Shell - Critical Vulnerabilities in PHP Core](https://www.offsec.com/blog/php2shell-critical-vulnerabilities-in-php-core/) – Offsec, CVE-2026-109618/CVE-2026-109619
4. [PHP2Shell: All You Need to Know About CVE-2026-109618 and CVE-2026-109619 - JFrog Security Research](https://research.jfrog.com/post/php2shell-all-you-need-to-know-about-cve-2026-109618-and-cve-2026-109619/) – JFrog
5. [PHP2Shell CVE-2026-109618 & 109619: Affected Versions & Fix](https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/) – SOCRadar
6. [PHP2Shell: PHP RCE](https://sansec.io/research/php2shell) – Sansec, CVE-2026-109618
7. [PHP2Shell (CVE-2026-109618, CVE-2026-109619): Diese PHP-Versionen sind gepatcht](https://www.cms-admins.de/news/php2shell-kritische-php-sicherheitsluecken-cve-2026-109618/) – cms-admins.de
8. [PHP-Sicherheitslücke testen, prüfen, beheben (PHP2Shell)](https://zybee.ai/de/blog/php-sicherheitsluecke-pruefen-beheben/) – zybee.ai
9. [PHP2Shell: Ist meine Website von der PHP-Lücke betroffen?](https://patrickhilker.de/wissen/php-sicherheitsluecke-php2shell) – patrickhilker.de
10. [PHP-Sicherheitslücke PHP2Shell: Was Sie jetzt tun müssen](https://www.unicorn-factory.net/php-sicherheitsluecke/) – unicorn-factory.net
11. [PHP2Shell - Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619): detection, analysis, and remediation](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/) – Datadog Security Labs
12. [PHP2Shell: Critical PHP RCE Vulnerabilities CVE-2026-109618 and CVE-2026-109619](https://www.abstract.security/blog/php2shell-critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619) – Abstract Security

Mit KI-Unterstützung recherchiert und geschrieben, fachlich geprüft von Hannes Ftuni am 29.10.2026. Herausgeber: Heisenberg IT GmbH, Bochum.