PHP2Shell: Wie die kritische PHP-Sicherheitslücke funktioniert und wie Hoster und Webmaster sie schließen

PHP2Shell sind zwei kritische Sicherheitslücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619), über die Angreifer ohne Anmeldung Code auf einem Webserver ausführen können. Betroffen ist laut PHP-Projekt jede PHP-Installation, die Webanfragen bedient, und schützen kann nur das sofortige Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder ein gleichwertig gepatchtes Paket Ihrer Distribution oder Ihres Hosters. Die PHP-Sicherheitslücke steckt nicht in WordPress, Shopware oder einem Plugin, sondern in der PHP-Laufzeit. Ein Update der Anwendung schließt sie deshalb nicht, wie das BSI in seiner Cybersicherheitswarnung ausdrücklich betont.

Stand: 22. Oktober 2026. Die Lage ändert sich derzeit täglich. Grundlage sind die Advisories des PHP-Projekts, die Warnungen von BSI, CERT-EU und NCSC und die Sicherheitsseiten der Distributionen. Was nur ein Hoster, eine Sicherheitsfirma oder ein Medium berichtet, kennzeichne ich so. Links auf Exploit-Code enthält dieser Artikel bewusst nicht.

PHP2Shell in Kürze

Die wichtigsten Fakten nach Angaben des PHP-Projekts und des BSI, Stand 22. Oktober 2026:

Was ist PHP2Shell?

PHP2Shell ist der Name, unter dem zwei Schwachstellen im Kern von PHP bekannt geworden sind. Das BSI erklärt den Namen als Anlehnung an Log4Shell. Das PHP-Projekt selbst führt die Lücken nüchtern als „RCE via OOM corruption“ (CVE-2026-109618) und „RCE via stale global state“ (CVE-2026-109619). RCE steht für Remote Code Execution.

Gefunden haben die Lücken nach eigener Darstellung Forscher von Wiz zusammen mit Calif und OpenAI. Laut Wiz ging die Meldung am 24. August 2026 an das PHP-Projekt. Am 20. Oktober kündigte php.net ein kritisches Sicherheitsrelease für den 21. Oktober um 14:00 UTC an und behielt sich ein früheres Release vor. Laut Huntress und heise waren Details schon vorher durchgesickert, im Advisory von php.net steht davon nichts. Die korrigierten Versionen erschienen am 21. Oktober.

Mit der WordPress-Lücke wp2shell hat PHP2Shell nur einen Teil des Namens gemeinsam. wp2shell steckte im Juli 2026 im WordPress-Kern und war mit einem WordPress-Update behoben. PHP2Shell sitzt eine Ebene tiefer, in der Laufzeit, auf der WordPress, TYPO3, Shopware, Nextcloud und fast jede andere PHP-Anwendung läuft.

Wie die Sicherheitslücke funktioniert

Die Sicherheitslücke in PHP hat in beiden Fällen dieselbe Wurzel: PHP räumt nach einem schweren Fehler nicht sauber auf. Ich beschreibe die Mechanik nur so weit, wie es für die Gegenmaßnahmen nötig ist.

CVE-2026-109618: Abbruch bei Speichermangel

Jede PHP-Anfrage bekommt einen eigenen Speicherbereich. Geht der Speicher aus, brach PHP die Anfrage bisher abrupt ab und sprang direkt in die Aufräumroutine. Laut Advisory konnte das in einem Moment passieren, in dem interne Daten der Anfrage schon erreichbar, aber noch nicht fertig eingerichtet waren. Die Aufräumroutine hielt diese halbfertigen Daten trotzdem für gültig und arbeitete mit ihnen weiter.

Den Speichermangel kann ein Angreifer laut Advisory von außen herbeiführen, über mehrere Schwächen bei der Verarbeitung von Formular- und Datei-Uploads im Multipart-Format. Bei mod_php passiert das, bevor Ihre Anwendung überhaupt startet. Die Codeausführung hat das PHP-Projekt gegen mod_php mit Standardeinstellungen bestätigt. Für PHP-FPM liegt eine Quellcodeanalyse vor, aber kein vollständig gezeigter Angriff. FrankenPHP und LiteSpeed gelten als wahrscheinlich anfällig. Die Korrektur ersetzt den abrupten Abbruch: PHP reagiert auf Speichermangel jetzt verzögert an einer sicheren Stelle und beendet den Prozess hart, sobald eine höhere Schwelle erreicht ist.

CVE-2026-109619: veralteter Zustand im Worker

PHP startet auf einem Webserver nicht für jede Anfrage einen neuen Prozess. Ein Worker von PHP-FPM oder Apache bedient nacheinander viele Anfragen. Dabei hält PHP globalen Zustand, etwa zu Fehlern oder Sitzungen, der zeitweise auf Speicher der laufenden Anfrage zeigt. Endete eine Anfrage mit einem fatalen Fehler, zum Beispiel einem Parse-Fehler, einer Zeitüberschreitung oder Speichermangel, wurde dieser Zustand laut Advisory nicht immer zurückgesetzt. Die nächste Anfrage im selben Worker konnte dann auf bereits freigegebenen Speicher zugreifen (Use after free).

Für einen Angriff braucht es deshalb mindestens zwei Anfragen, die beim selben Worker landen. Eine der Stellen, an denen der veraltete Zustand früh benutzt wird, ist die Fortschrittsanzeige für Uploads in Sessions (session.upload_progress), die in PHP standardmäßig eingeschaltet ist. Diesen Weg hat das PHP-Projekt gegen mod_php und PHP-FPM validiert. Neben der Codeausführung ist laut Advisory auch das Auslesen von Speicher möglich. Laut Sansec können über ein solches Speicherleck Daten anderer Anfragen wie Session-Tokens, Passwörter oder API-Schlüssel nach außen gelangen. Sansec ordnet das Speicherleck allerdings CVE-2026-109618 zu, das Advisory des PHP-Projekts dagegen CVE-2026-109619. Für die Gegenmaßnahmen ändert das nichts, beide Lücken schließt dasselbe Update.

Warum die Bewertungen auseinandergehen

Das PHP-Projekt bewertet beide Lücken mit CVSS 4.0 9.2 und setzt dabei eine hohe Angriffskomplexität an. Die US-Datenbank NVD kommt nach CVSS 3.1 auf 9.8, Red Hat auf 8.1 und die Stufe Important. Red Hat begründet das damit, dass RHEL standardmäßig PHP-FPM nutzt und eine Codeausführung dort schwierig sei. heise berichtet, dass ein zuverlässiger Angriff teils Tausende bis Zehntausende Anfragen braucht. An der Dringlichkeit ändern die Unterschiede nichts.

Welche PHP-Versionen betroffen und welche korrigiert sind

Das PHP-Projekt hat am 21. Oktober 2026 vier korrigierte Versionen veröffentlicht. Für ältere Zweige gibt es kein offizielles Release:

Die offiziellen CVE-Daten nennen nur die unterstützten Zweige 8.2 bis 8.5. Wiz, Sansec und Hostinger gehen davon aus, dass alle Versionen ab PHP 5.4 betroffen sind, das BSI schreibt von allen bekannten Versionen bis mindestens PHP 5. Ich rate, jede ältere Version als betroffen zu behandeln. Das ist kein Randproblem: Laut W3Techs nutzen 69,3 Prozent der Websites mit bekannter Serversprache PHP, und davon laufen 26,9 Prozent noch auf PHP 7 und 7,7 Prozent auf PHP 5 (Stand 22. Oktober 2026). Die Testversion PHP 8.6.0 RC4 enthält die Korrekturen laut php.net bereits.

Betroffen ist laut php.net jede Betriebsart, die Webanfragen annimmt: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Projekt bei mod_php, weil der gezeigte Angriff dort vor jedem Anwendungscode greift. Nach einem Bericht von heise ist auch PHP unter Windows betroffen.

Bin ich betroffen? So prüfen Sie Ihre PHP-Version

Die Versionsnummer allein beantwortet die Frage oft nicht. Distributionen und viele Hoster bauen die Korrektur in ihre bestehenden Pakete ein, ohne die Nummer auf 8.3.36 oder 8.2.35 anzuheben. Das BSI empfiehlt deshalb, die Ausgabe von php -v mit der Paketversion der Distribution abzugleichen.

Bei Shared Hosting: im Kundencenter

Bei Webhosting zeigt das Kundencenter, welche PHP-Version eine Website nutzt. Ob diese Version gepatcht ist, sagt Ihnen nur Ihr Hoster. Viele Anbieter haben dazu Hinweise oder Statusmeldungen veröffentlicht. Hostinger empfiehlt nach eigener Aussage, das Build-Datum in der PHP-Info zu prüfen, das bei gepatchten Versionen am oder nach dem 21. Oktober 2026 liegt.

Auf VPS und Root-Servern: auf der Kommandozeile

php -v zeigt die Version der Kommandozeile. Sie kann sich von der Version unterscheiden, die PHP-FPM oder Apache tatsächlich lädt, wenn mehrere Versionen installiert sind. Prüfen Sie deshalb jede installierte Version und vergleichen Sie die Paketversion mit dem Stand, den Ihre Distribution als korrigiert angibt. Unter Debian und Ubuntu zeigt apt changelog für das PHP-Paket, ob der Eintrag zu CVE-2026-109618 enthalten ist, unter RHEL leistet rpm -q --changelog dasselbe. Nennt der Changelog keine CVE-Nummern, gilt die Paketversion, die der Anbieter als korrigiert angibt.

Quellen: Debian Security Tracker, Ubuntu mit USN-8948-1 und Red Hat RHSB-2026-013. Ein Ubuntu 24.04 meldet also weiterhin PHP 8.3.6 und ist trotzdem geschützt, sobald das Paket mindestens den Stand aus der Tabelle hat.

Ohne Shell-Zugang: kurz mit phpinfo

Wer keinen Zugang zur Kommandozeile hat, kann eine Datei mit phpinfo() anlegen, im Browser Version und Build-Datum ablesen und die Datei sofort wieder löschen. Eine vergessene phpinfo-Datei verrät Angreifern viele Details über Ihren Server.

Container, Appliances und vergessene Installationen

PHP steckt oft an Stellen, an die niemand denkt. Das BSI rät, Docker-Container mit PHP neu zu bauen, und weist darauf hin, dass Hersteller von Geräten mit eingebautem PHP neue Firmware liefern müssen. Als PHP-basierte Projekte nennt es unter anderem WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense. Das niederländische NCSC sammelt in einer noch unvollständigen Liste Produkte mit PHP-Abhängigkeit, darunter Appliances und Verwaltungsoberflächen, die Administratoren nicht selbst aktualisieren können. Laut Help Net Security hat Palo Alto Networks alle Versionen von PAN-OS und Panorama als betroffen gemeldet, ohne Fix zum Stand des Berichts. Die Herstellerseite habe ich dazu nicht geprüft.

So schließen Hoster die Lücke

Aus den Empfehlungen von php.net, BSI, NCSC UK und CloudLinux ergibt sich diese Reihenfolge:

1. Inventar: Alle PHP-Laufzeiten erfassen, beginnend mit den aus dem Internet erreichbaren. Dazu gehören auch Multi-PHP-Umgebungen wie ea-php, alt-php oder PHP Selector und das PHP, das Verwaltungsoberflächen selbst mitbringen.
2. Pakete aktualisieren: CloudLinux meldet gepatchte Pakete für cPanel EasyApache 4 von ea-php52 bis ea-php85, als Backport mit alter Versionsnummer, zum Beispiel ea-php84 in Version 8.4.26-2. Ob ein Paket die Korrektur enthält, zeigt der Paket-Changelog anhand der CVE-Nummern. Nennt der Changelog keine CVE-Nummern, wie laut CloudLinux bei dessen nativen PHP-Paketen, gilt die Paketversion, die der Anbieter als korrigiert angibt.
3. Alle Worker neu starten: PHP-FPM, Apache und LiteSpeed müssen nach dem Update neu starten, sonst laufen die alten Prozesse weiter.
4. Zwischenmaßnahmen plattformweit setzen, solange nicht alles gepatcht ist, vor allem session.upload_progress.enabled = 0 und Größenlimits am Proxy (siehe Workarounds).
5. WAF als zusätzliches Netz: Cloudflare hat nach eigener Angabe seit dem 21. Oktober 03:02 UTC Regeln aktiv, auch im kostenlosen Plan. CloudLinux hat Regeln für Imunify360 nachgeliefert, nach eigener Angabe aber keine Regel für CVE-2026-109618. Eine WAF ist ein virtueller Patch, kein Fix, und sie hilft nur bei Anfragen, die tatsächlich durch sie hindurchgehen.
6. Kunden informieren: klar sagen, was der Hoster erledigt und was Kunden mit VPS oder Root-Server selbst tun müssen.

Wie das in der Praxis aussieht, zeigen zwei Beispiele, beide nach Angaben der Hoster selbst. Hostinger hat vor dem Patch ModSecurity-Regeln aktiviert, die Upload-Fortschrittsanzeige auf LiteSpeed, PHP Selector, cPanel PHP-FPM und phpMyAdmin abgeschaltet und fehlerhafte Upload-Anfragen abgewiesen. Gepatchte Builds von PHP 5.2 bis 8.5 waren laut Hostinger am 22. Oktober um 06:44 UTC auf allen Plattformen außer VPS ausgerollt. IONOS hat nach eigener Angabe schon vor den Updates PHP-Konfiguration und Firewall-Regeln angepasst. Laut Statusseite begann das Update auf allen Systemen am 21. Oktober um 17:44 Uhr und war am 22. Oktober um 13:03 Uhr abgeschlossen. Kunden von Webhosting und Managed WordPress müssen dort nichts tun, Kunden mit eigenem VPS oder Dedicated Server schon. Andere Anbieter planten härtere Schritte: Uberspace hat laut heise angekündigt, seine PHP-Dienste am 21. Oktober ab 15:45 Uhr zeitweise komplett abzuschalten.

So schließen Webmaster und Agenturen die Lücke

Bei Shared Hosting und Managed Hosting

Hier liegt das Patchen beim Hoster. Ihre Aufgabe ist, sich das bestätigen zu lassen. Suchen Sie die Statusmeldung Ihres Anbieters. Findet sich keine, fragen Sie schriftlich nach, ob die PHP-Laufzeit für alle Versionen, die Ihre Websites nutzen, gegen CVE-2026-109618 und CVE-2026-109619 gepatcht ist. Ein Update von WordPress, Shopware oder Plugins behebt die Lücke nicht, das betonen BSI, Cloudflare und Hostinger gleichermaßen.

Checkliste für VPS, Root-Server und Container

1. PHP-Pakete über die Paketverwaltung aktualisieren und im Changelog prüfen, ob die CVE-Nummern enthalten sind. Fehlen sie dort, die Paketversion mit dem Stand vergleichen, den der Anbieter als korrigiert nennt.
2. Alle PHP-FPM-Pools und den Webserver neu starten, damit keine alten Worker weiterlaufen.
3. Jede installierte PHP-Version prüfen, nicht nur die der Kommandozeile.
4. Container-Images mit PHP neu bauen und neu ausrollen, statt nur laufende Container neu zu starten.
5. Die Upload-Fortschrittsanzeige abgeschaltet lassen, wenn Ihre Anwendung sie nicht braucht. Das empfiehlt das PHP-Projekt ausdrücklich auch nach dem Patch.
6. Als Agentur eine Liste aller betreuten Projekte samt Test- und Staging-Systemen anlegen und die aus dem Internet erreichbaren zuerst abarbeiten.
7. Nach dem Update die Prüfung auf Anzeichen eines Einbruchs durchführen (siehe Was nach dem Patch zu prüfen ist).
8. Den Umstieg von PHP 8.1 und älter planen. Das BSI rät zur Migration weg von diesen Versionen, und PHP 8.2 erhält nur noch bis Ende 2026 Sicherheitsupdates.

Workarounds bis zum Patch

Vorweg das Wichtigste: Das PHP-Projekt schreibt, „There are no complete mitigations, updating is the only safe choice.“ Die folgenden Maßnahmen aus dem Advisory von php.net und den beiden GitHub-Advisories verkleinern die Angriffsfläche für bekannte Wege, machen eine Installation aber nicht sicher. Sie sind nur für die Stunden oder Tage gedacht, bis das Update eingespielt ist.

• Upload-Fortschrittsanzeige abschalten: session.upload_progress.enabled = 0 in der php.ini, der FPM-Pool-Konfiguration oder der Serverkonfiguration setzen und alle Worker neu starten. ini_set() und .user.ini reichen nicht, weil sie zu spät greifen. Das blockiert die bestätigten Wege zu CVE-2026-109619, aber nicht jede Variante.
• Nur PHP 8.5: zusätzlich fatal_error_backtraces = 0 setzen und die Worker neu starten.
• Anfragen begrenzen: post_max_size auf 8M setzen, wenn keine Uploads nötig sind, sonst auf 32M mit upload_max_filesize darunter. Zusätzlich am Webserver oder Proxy Größe, Feldanzahl, Multipart-Teile, Header und Verschachtelungstiefe begrenzen, auch für Anfragen ohne verwertbare Längenangabe. Braucht eine Anwendung keine Uploads, empfiehlt das Advisory, Multipart-Anfragen schon am Frontend zu blockieren.
• Fatale Fehler reduzieren: Einstellungen entfernen, die vor der Initialisierung Diagnosen ausgeben, und von außen auslösbare fatale Fehler und Zeitüberschreitungen beheben.
• Worker häufiger erneuern: Das GitHub-Advisory nennt pm.max_requests=1 als Option, wenn die Leistung es zulässt. Dann bedient jeder Worker nur eine Anfrage.
• Speichergrenzen anders setzen: php.net nennt memory_limit=-1, nicht überschreibbar gesetzt, als Maßnahme gegen CVE-2026-109618, zusammen mit einem Limit über Container oder cgroups und ausdrücklich nicht über RLIMIT_AS oder RLIMIT_DATA. Meine Einordnung: Ohne PHP-Speichergrenze kann eine einzelne Anfrage den Arbeitsspeicher des Servers aufbrauchen. Ich würde diese Maßnahme nur mit einem funktionierenden Container- oder cgroup-Limit einsetzen.
• Schaden begrenzen: Das BSI empfiehlt SELinux oder AppArmor, damit eine erfolgreiche Codeausführung möglichst wenig erreicht, sowie eine WAF als ergänzenden Schutz.
• Letzte Option: Lässt sich ein System nicht patchen, raten BSI, CERT-EU und NCSC UK dazu, es vom Internet zu trennen, bis der Fix eingespielt ist.

Auswirkungen für Hoster, Kunden, Firmen und Konzerne

Für Hoster

Hoster tragen die Hauptlast. Sie müssen in kurzer Zeit sehr viele Systeme patchen, Altversionen mit eigenen Builds absichern, für die es vom PHP-Projekt nichts gibt, und dabei den Betrieb halten. IONOS hat seine Kunden auf kurze Unterbrechungen während des Updates hingewiesen. Dazu kommt die Kommunikation: Kunden wollen wissen, ob sie sicher sind, und die Grenze zwischen Hoster und Kunde muss klar sein. Bei VPS und Root-Servern liegt das Update beim Kunden, das sagen Hostinger und IONOS übereinstimmend. Erkennt ein Hoster als Auftragsverarbeiter eine Verletzung des Schutzes personenbezogener Daten, muss er nach Art. 33 Abs. 2 DSGVO den Verantwortlichen unverzüglich informieren.

Für Hosting-Kunden

Wer klassisches Webhosting nutzt, ist auf seinen Hoster angewiesen, und das ist in diesem Fall eher ein Vorteil. Hostinger und IONOS haben nach eigenen Angaben innerhalb eines Tages gepatcht. Prüfen Sie trotzdem, ob Ihr Anbieter das bestätigt hat, besonders wenn Ihre Website noch auf PHP 7 oder älter läuft. Rechnen Sie außerdem mit Trittbrettfahrern: IONOS warnt vor gefälschten E-Mails, die die Lücke als Aufhänger nutzen. Geben Sie Zugangsdaten nie über einen Link aus einer solchen Mail ein, sondern melden Sie sich direkt im Kundencenter an.

Für Firmen und den Mittelstand

Für ein mittelständisches Unternehmen betrifft PHP2Shell selten nur die Website. Shop, Kundenportal, Intranet, Nextcloud, Ticketsystem, das NAS im Keller oder die Firewall können PHP enthalten. Ein erfolgreicher Angriff kann Kundendaten abfließen lassen, die Website lahmlegen oder Schadcode auf ihr platzieren. Ein Vertreter des BSI hielt es laut ZDFheute für denkbar, dass solcher Schadcode auf die Systeme der Besucher übergeht. Fragen Sie Ihre Dienstleister aktiv, welche Ihrer Systeme PHP nutzen und ob sie gepatcht sind.

Kommt es zu einer Verletzung des Schutzes personenbezogener Daten, ist sie nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde zu melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Eine ungepatchte Version allein ist noch keine Verletzung, und dieser Hinweis ersetzt keine Rechtsberatung. Mehr zu den Pflichten rund um personenbezogene Daten steht in meinem Artikel zur DSGVO in der Softwareentwicklung.

Für Konzerne und die öffentliche Hand

Bei großen Organisationen ist das Problem die Breite. PHP läuft dort in Webauftritten, Fachanwendungen, Schatten-IT einzelner Abteilungen und in Appliances, die nur der Hersteller aktualisieren kann. Viele haben deshalb vorsorglich abgeschaltet: Laut Security-Insider nahmen die Landesregierung Baden-Württemberg (hier unter Berufung auf dpa), die Universitätsklinika Heidelberg und Mannheim und die Stadt Mainz Webseiten vorübergehend vom Netz. Die Kliniken betonten, die Patientenversorgung sei nicht betroffen. Der ORF meldet Einschränkungen bei der Universität Wien, der TU Wien und beim niederländischen DigiD.

Für das Patchmanagement heißt das: ein Notfall-Change mit klarer Verantwortung, ein vollständiges Inventar und Druck auf Hersteller, deren Produkte PHP mitbringen. Unternehmen, die unter NIS2 fallen, müssen erhebliche Sicherheitsvorfälle nach Angaben des BSI binnen 24 Stunden als Erstmeldung, binnen 72 Stunden als Folgemeldung und spätestens einen Monat danach abschließend melden. Was NIS2 sonst von Software und Lieferanten verlangt, beschreibe ich im Artikel zu NIS2 und Security by Design. Wer selbst Produkte mit eingebautem PHP herstellt, sollte zusätzlich prüfen, welche Pflichten der Cyber Resilience Act seit September 2026 vorsieht.

Wird PHP2Shell schon ausgenutzt?

Die Angaben widersprechen sich. So sieht die Lage nach den Quellen aus, die ich geprüft habe:

Meine Schlussfolgerung: Gehen Sie davon aus, dass Ihr Server angegriffen wird, auch wenn mir bis heute keine öffentlich belegte erfolgreiche Kompromittierung bekannt ist. Das BSI weist zudem darauf hin, dass KI-Werkzeuge die Entwicklung von Exploits aus veröffentlichten Patches beschleunigen. Die Zeit zwischen Patch und funktionierendem Angriff wird damit kürzer.

Was nach dem Patch zu prüfen ist

Ein Update schließt die Lücke, entfernt aber keinen Angreifer, der schon im System ist. Verbindliche Merkmale eines Angriffs gibt es laut BSI noch nicht. Amazon empfiehlt, Untersuchungen ab dem 17. Oktober zu beginnen. Aus den Hinweisen von Wiz, Huntress und Sansec ergibt sich diese allgemeine Prüfliste:

• Protokolle: Häufungen von Fehlern zum Speicherlimit, von HTTP-500-Antworten und von ungewöhnlichen Upload-Anfragen, besonders an Adressen ohne Upload-Funktion, dazu unerklärliche Neustarts von Workern.
• Prozesse: PHP- oder Webserver-Prozesse wie php-fpm, httpd oder apache2, die Shells, Interpreter oder Download-Werkzeuge starten.
• Dateien und Konten: neue oder geänderte PHP-Dateien im Webverzeichnis und in Upload-Ordnern, neue Cronjobs, neue Benutzer oder Administratorkonten in System und Anwendung.
• Zugangsdaten: Bei Verdacht Datenbankpasswörter, API-Schlüssel und Geheimnisse für Sessions erneuern und alle Sitzungen beenden, weil die Lücke auch Speicherinhalte offenlegen kann.
• Im Ernstfall: System isolieren, aus einer sauberen Sicherung neu aufsetzen statt nur aufzuräumen und prüfen, ob eine Meldepflicht besteht.

Häufige Fragen zu PHP2Shell

Was ist PHP2Shell?

Zwei kritische Sicherheitslücken in PHP selbst, CVE-2026-109618 und CVE-2026-109619, über die Angreifer ohne Anmeldung Code auf einem Webserver ausführen können. Das PHP-Projekt hat sie am 21. Oktober 2026 geschlossen.

Ist meine Website von PHP2Shell betroffen?

Wenn Ihre Website mit PHP läuft und der Server noch nicht gepatcht ist, ja, egal ob WordPress, TYPO3, Shopware oder eine eigene Anwendung.

Welche PHP-Versionen sind sicher?

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie die gepatchten Pakete der Distributionen, etwa unter Ubuntu 24.04 die Paketversion 8.3.6-0ubuntu0.24.04.13.

Warum zeigt mein Server eine ältere Versionsnummer, obwohl er gepatcht ist?

Distributionen wie Debian, Ubuntu und Red Hat sowie viele Hoster bauen die Korrektur in die bestehende Version ein, statt auf die neue Upstream-Version zu wechseln. Entscheidend ist dann die Paketversion oder das Build-Datum, nicht die Ausgabe von php -v.

Reicht es, WordPress, Shopware oder die Plugins zu aktualisieren?

Nein. Die Lücke liegt in der PHP-Laufzeit. Ein Update der Anwendung ändert daran nichts, die PHP-Laufzeit muss gepatcht werden.

Reicht es, session.upload_progress zu deaktivieren?

Nein. Die Einstellung blockiert die bestätigten Wege zu CVE-2026-109619, aber nicht jede Variante und nicht CVE-2026-109618. Sie ist eine Übergangslösung bis zum Update.

Schützt eine Web Application Firewall vor PHP2Shell?

Teilweise. Cloudflare und andere Anbieter haben Regeln veröffentlicht, die bekannte Angriffsmuster blockieren. Abgewandelte Angriffe und Anfragen, die direkt am Server ankommen, erfasst eine WAF nicht sicher. Sie ersetzt das Update nicht.

Was ist mit PHP 7.4, 8.0 und 8.1?

Dafür gibt es keine neuen Releases, nur Quellcode-Backports des PHP-Projekts und Pakete von Distributionen, LTS-Anbietern und Hostern. Langfristig hilft nur der Umstieg auf eine unterstützte Version.

Muss ich als Hosting-Kunde selbst etwas tun?

Bei Webhosting und Managed Hosting in der Regel nicht, das Patchen übernimmt der Hoster. Lassen Sie sich das aber bestätigen. Bei VPS, Root-Servern und Containern müssen Sie selbst aktualisieren.

Ist PHP2Shell dasselbe wie wp2shell?

Nein. wp2shell war im Juli 2026 eine Lücke im WordPress-Kern. PHP2Shell steckt in PHP selbst und betrifft alle PHP-Anwendungen.

Muss ein Angriff der Datenschutzbehörde gemeldet werden?

Wenn personenbezogene Daten betroffen sind, in der Regel ja, nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden, es sei denn, es besteht voraussichtlich kein Risiko für die Betroffenen. Eine ungepatchte Version allein ist kein Meldefall. Im Zweifel klären Sie das mit Ihrem Datenschutzbeauftragten.

Quellen

• PHP-Projekt: Security Advisory vom 21.10.2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, PHP 8.6.0 RC4
• Behörden: BSI, BITS-H 2026-297981-1132, Version 1.1, CERT-EU 2026-018, NCSC UK, NCSC-NL Produktliste
• Distributionen: Debian zu CVE-2026-109618 und CVE-2026-109619, Ubuntu USN-8948-1 und Ubuntu-CVE-Seite, Red Hat RHSB-2026-013
• Hoster und Anbieter (eigene Angaben): Hostinger, IONOS, CloudLinux, Cloudflare
• Sicherheitsfirmen und Medien: Wiz, Sansec, Huntress, Amazon, heise, Security-Insider, ZDFheute, ORF