# Was ist PHP2Shell? Die Lücke einfach erklärt

> PHP2Shell einfach erklärt: was hinter den zwei kritischen PHP-Lücken steckt, welche Server betroffen sind und welche Schritte Sie jetzt gehen sollten.

Quelle: https://phpsos.de/php2shell/was-ist-php2shell/  
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:** PHP2Shell ist der Name für zwei kritische Sicherheitslücken in PHP selbst, CVE-2026-109618 und CVE-2026-109619. Über sie können Angreifer auf verwundbaren Webservern ohne Anmeldung Schadcode ausführen. Abhilfe schafft nur das Update auf eine behobene PHP-Version mit anschließendem Neustart aller PHP-Prozesse.

## Was ist PHP2Shell?

PHP ist die Programmiersprache, auf der ein großer Teil aller Websites läuft: Unternehmensseiten mit WordPress oder TYPO3, Onlineshops mit Shopware oder WooCommerce, interne Portale und Eigenentwicklungen. Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei Lücken veröffentlicht, die unter dem Namen PHP2Shell bekannt geworden sind.

Beide Lücken sind mit CVSS v4.0 9.2 bewertet, also als kritisch. Die Folge ist in beiden Fällen dieselbe: Ausführung von Schadcode aus der Ferne, ohne dass sich der Angreifer anmelden muss. Fachleute sprechen von „unauthenticated Remote Code Execution“. Wer Code auf dem Server ausführen kann, kann im schlimmsten Fall Daten lesen, Hintertüren einbauen oder den Server für weitere Angriffe nutzen.

Wichtig für das Verständnis: Die Lücke steckt nicht in einem bestimmten CMS oder Plugin, sondern in PHP. Ein Update von WordPress, Shopware oder TYPO3 schließt sie deshalb nicht.

## Warum ist die Lücke so ernst?

Drei Punkte machen PHP2Shell aus Sicht von Sicherheitsbehörden besonders heikel:

- **Breite:** Betroffen sind die gängigen Betriebsarten von PHP, nämlich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Palo Alto Networks (Unit 42) zählte mehr als 22,6 Millionen exponierte, potenziell verwundbare Instanzen.
- **Kein Login nötig:** Der Angreifer braucht weder Passwort noch Benutzerkonto.
- **Früher Zeitpunkt:** Bei Apache mit mod_php wurde laut PHP-Team ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Schutzfunktionen innerhalb der Website greifen dann nicht.

Das BSI hat die Warnstufe 3 (Orange) ausgerufen. Es empfiehlt das sofortige Update und, wenn das nicht sofort möglich ist, die betroffenen Webserver vorübergehend vom Netz zu nehmen.

## Welche Server sind von PHP2Shell betroffen?

Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Stände dieser Zweige sind betroffen. Für PHP 8.1 und älter gibt es keine offiziellen Updates mehr; laut Fachpresse sind nahezu alle Versionen bis zurück zu PHP 5.4 betroffen. Die vollständige Übersicht finden Sie auf der Seite [Welche PHP-Versionen sind betroffen?](https://phpsos.de/php2shell/betroffene-php-versionen/).

Eine Besonderheit: Linux-Distributionen und Hoster spielen die Korrekturen teils als Backport ein. Dann zeigt etwa Plesk weiterhin 8.2.34 an, obwohl der Fehler behoben ist. Maßgeblich sind der Paketstand und die Bestätigung des Anbieters. Wie Sie das prüfen, erklären wir unter [PHP-Version und Patchstand richtig prüfen](https://phpsos.de/php2shell/php-version-pruefen/).

## Was ist belegt, was ist offen?

**Belegt** sind die beiden CVE-Nummern, die behobenen Versionen und die Übergangsmaßnahmen, die php.net veröffentlicht hat. Am 23. Oktober kam ein Hinweis zu einer weiteren Lücke hinzu, CVE-2026-115560, die nur bei einer ungewöhnlichen Konfiguration greift.

**Wahrscheinlich** ist, dass Angreifer ungepatchte Server weiter aktiv suchen. Laut Medienberichten wurde ein erster Angriffsversuch bereits am 17. Oktober beobachtet, also vor der Veröffentlichung der Patches. Cloudflare meldete Angriffsversuche und hat Schutzregeln ausgerollt, weist aber darauf hin, dass Regeln anhand der Anfragedaten allein nicht genügen.

**Offen** ist, wie viele Server bereits erfolgreich angegriffen wurden. Bestätigte erfolgreiche Angriffe in der Breite waren laut BSI zunächst nicht bekannt. Es gibt keine veröffentlichten, bestätigten Indicators of Compromise. Ob ein Server betroffen war, lässt sich deshalb nur über eine Verhaltensanalyse einschätzen. Den zeitlichen Ablauf fasst die [Chronologie vom 17. bis 25. Oktober](https://phpsos.de/ratgeber/php2shell-chronologie/) zusammen.

## Was Unternehmen jetzt tun sollten

1. **Klären, wer zuständig ist:** eigener Server, Managed Server oder Hoster.
2. **PHP aktualisieren** auf eine behobene Version oder einen bestätigten Backport.
3. **Alle PHP-Prozesse neu starten.** Neue Dateien allein reichen nicht, solange alte Prozesse im Speicher laufen.
4. **Logs sichern,** und zwar ab dem 20. Oktober. Die Fachpresse rät, diese Daten aufzubewahren.
5. **Auf Spuren prüfen.** Ein Patch entfernt keine bereits eingeschleuste Schadsoftware und beweist nicht, dass vorher nichts passiert ist. Hinweise dazu gibt die Seite [Bin ich schon kompromittiert?](https://phpsos.de/php2shell/bin-ich-gehackt-anzeichen/).

> **Wichtig:**
> Ein Update schließt die Tür, räumt aber nicht auf. Wenn Ihr Server zwischen dem 17. Oktober und dem Patch erreichbar war, gehört eine Prüfung auf Spuren zur Pflicht, nicht zur Kür.

## Wie hilft PHP SOS konkret?

Mit der [PHP2Shell-Soforthilfe](https://phpsos.de/leistungen/php2shell-soforthilfe/) übernehmen wir die Schritte, die viele Unternehmen intern nicht kurzfristig abdecken können:

- **Bestandsaufnahme:** Wir ermitteln PHP-Version, Betriebsart und Paketstand jedes betroffenen Servers.
- **Patch oder Übergang:** Wir spielen das Update ein oder setzen, wo das noch nicht geht, die Übergangsmaßnahmen von php.net und klären die Frage, ob der Server vorübergehend vom Netz muss.
- **Neustart und Nachweis:** Wir starten alle PHP-Prozesse neu und dokumentieren den Stand vorher und nachher.
- **Spurenprüfung:** Wir sichern Logs ab dem 20. Oktober und prüfen auf Auffälligkeiten, bis der Vorfall abgeschlossen und dokumentiert ist.


## Häufige Fragen

**Ist PHP2Shell eine WordPress-Lücke?**  
Nein. Die Lücken stecken in PHP, also in der Programmiersprache, auf der WordPress, Shopware, TYPO3 und viele andere Systeme laufen. Ein Update des CMS schließt sie deshalb nicht. Entscheidend ist der PHP-Stand auf dem Server.

**Muss ich als Kunde eines Hosters selbst etwas tun?**  
Beim Shared Hosting spielt in der Regel der Hoster das PHP-Update ein. Sie sollten sich trotzdem schriftlich bestätigen lassen, dass die von Ihnen genutzte PHP-Version gepatcht und neu gestartet wurde. Ob vor dem Patch etwas passiert ist, beantwortet das Update nicht.

**Woher kommt der Name PHP2Shell?**  
Der Name beschreibt die Folge: Über PHP kann ein Angreifer im schlimmsten Fall eine Kommandozeile, also eine Shell, auf dem Server erlangen. Offizielle Bezeichnungen sind die CVE-Nummern CVE-2026-109618 und CVE-2026-109619.

**Wurde meine Website schon angegriffen, wenn sie offline genommen wurde?**  
Nicht unbedingt. Einige Anbieter haben Websites vorsorglich vom Netz genommen, wie es das BSI empfiehlt, wenn ein Update nicht sofort möglich ist. Das ist eine Schutzmaßnahme und kein Beleg für einen Angriff.

## 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/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)