PHP2Shell-Sicherheitslücke: Das müssen Web- & Onlineshop-Betreiber jetzt wissen

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für mehrere PHP-Versionen veröffentlicht. Anlass sind zwei kritische Schwachstellen, bekannt unter dem Namen PHP2Shell. Sie können dazu führen, dass Angreifer Schadcode aus der Ferne auf einem Server ausführen, ohne sich zuvor anzumelden.

Für Betreiber von Websites, Onlineshops und PHP-Anwendungen ist das relevant. PHP steckt unter anderem in Adobe Commerce (Magento), Shopware, WordPress/WooCommerce, TYPO3, Drupal, Laravel und Symfony. Die Lücken können Verfügbarkeit, Nutzerdaten, Geschäftsprozesse und Vertrauen beeinträchtigen.

Bei der Remote Code Execution (RCE) können Angreifer aus der Ferne Code auf einem Zielsystem ausführen. Bei PHP2Shell entsteht dieses Risiko jedoch nicht durch ein einzelnes unsicheres Plug-in oder eine klassische Codeeinschleusung in der Anwendung, sondern durch Fehler im PHP-Kern selbst.

Insbesondere bei PHP ist RCE kritisch, da der Code serverseitig, also direkt auf dem Webserver, und nicht nur im Browser eines Besuchers ausgeführt wird. Angreifer können dadurch unter bestimmten Bedingungen Befehle oder Schadcode auf dem Zielsystem ausführen, i. d. R. mit den Rechten des betroffenen Webserver- oder PHP-Prozesses.

Das kann ausreichen, um eine Webshell einzuschleusen, Shop- oder Checkout-Prozesse zu manipulieren, Daten auszulesen oder Malware zu verbreiten.

Wie funktioniert PHP2Shell?

Beide Schwachstellen betreffen den PHP-Kern selbst, nicht ein einzelnes Plugin oder eine Erweiterung.

• CVE-2026-109618 betrifft die Verarbeitung von Speichermangel. Dabei können unvollständig initialisierte interne Daten fehlerhaft verarbeitet werden, wodurch unter bestimmten Bedingungen eine Codeausführung möglich wird.
• CVE-2026-109619 beeinträchtigt interne Zustandsdaten, auf die nach der Freigabe ihres Speichers weiterhin zugegriffen wird. Dadurch kann eine spätere Anfrage im selben PHP-Prozess unter bestimmten Bedingungen auf ungültige Daten zugreifen.

Beide Schwachstellen wurden nach CVSS v4.0 mit 9,2 von 10 Punkten als kritisch eingestuft. Die technische Komplexität bietet keinen verlässlichen Schutz. Laut AWS Security Blog wurden bereits Aktivitäten vom 17. Oktober 2026 beobachtet. Seit dem 21. Oktober 2026 berichtet AWS zudem von breiteren Ausnutzungsversuchen nach Veröffentlichung der Schwachstellen.

Wichtig ist dabei die Unterscheidung: Dokumentierte Ausnutzungsversuche bedeuten nicht automatisch, dass jedes angegriffene System erfolgreich kompromittiert wurde. Sie zeigen aber, dass die Schwachstellen aktiv aufgegriffen werden und ungepatchte Systeme zeitnah geprüft und abgesichert werden sollten.

Nach erfolgreicher Codeausführung können Angreifer beispielsweise eine Webshell in einem beschreibbaren Verzeichnis ablegen und damit weiteren Zugriff ermöglichen, auch wenn die Website äußerlich normal erreichbar bleibt.

Alle PHP-Installationen, die Webanfragen verarbeiten, sollten auf ihren Patch-Status geprüft werden. Die konkrete Ausnutzbarkeit hängt von Version, Konfiguration und Betriebsumgebung ab. Entscheidend sind vor allem die verwendete PHP-Version, die konkrete Serverkonfiguration und das jeweilige Hosting-Setup.

Nach Einschätzung des PHP-Projekts ist die Betriebsart mit Apache und mod_php besonders kritisch zu betrachten. Für diese Konstellation wurde eine Codeausführung bereits vor Beginn des eigentlichen Anwendungscodes demonstriert. Das bedeutet jedoch nicht, dass andere Betriebsarten automatisch unkritisch sind. Auch Umgebungen mit PHP-FPM, CGI/FastCGI, Container-Setups oder Hosting-Panels sollten geprüft und aktualisiert werden.

Laut den vom PHP-Projekt veröffentlichten Sicherheitsinformationen reichen die zugrunde liegenden Fehler weit zurück und betreffen auch sehr alte PHP‑Versionen. Die ersten korrigierten Releases der unterstützten PHP-Zweige sind:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Zusätzlich hat das PHP-Projekt am 23. Oktober 2026 eine weitere Sicherheitsmeldung zu CVE-2026-115560 veröffentlicht. Dabei handelt es sich um eine separate RCE-Schwachstelle, die nicht durch die PHP-Sicherheitsupdates vom 21. Oktober 2026 behoben wird. Nach Angaben des PHP-Projekts betrifft sie eine seltene Kombination aus Session-Konfiguration, einer Laufzeitänderung des Session-Serialisierungsverfahrens und aktivierter Upload-Fortschrittsfunktion. Anwendungen ohne den beschriebenen Wechsel des Session-Serialisierungsverfahrens sind von diesem speziellen Szenario laut PHP-Projekt nicht betroffen.

Für ältere Versionen wie PHP 7.4, 8.0 oder 8.1 können je nach Distribution oder Anbieter Backports verfügbar sein. Trotzdem sollten Unternehmen veraltete PHP-Versionen nicht als Dauerlösung betrachten, sondern als strategisches Sicherheits- und Wartungsrisiko.

Betroffen sein können PHP-basierte Websites und Shops auf Magento, Shopware, WordPress/WooCommerce, TYPO3, Drupal, Laravel oder Symfony, ebenso individuelle Webanwendungen, Docker-Container und Hosting-Umgebungen.

PHP wird nicht nur auf klassischen Webservern eingesetzt. Auch Verwaltungsoberflächen von Netzwerk- und Speichergeräten können PHP nutzen, etwa bei NAS-Systemen, Routern, Firewalls oder anderen Appliances. Solche Oberflächen sollten besonders dann geprüft werden, wenn sie aus dem Internet erreichbar sind.

Auch vorgeschaltete Schutzsysteme ersetzen kein Update. Ein Content Delivery Network (CDN), ein Reverse Proxy oder eine Web Application Firewall (WAF) können Angriffe zwar erschweren, schließen aber nicht die eigentliche Schwachstelle in der PHP-Laufzeitumgebung.

Eine Kompromittierung ist nicht immer sofort sichtbar. Der Shop oder die Website kann weiterhin erreichbar sein, während im Hintergrund bereits Schadcode aktiv ist. Einzelne Auffälligkeiten sind kein eindeutiger Nachweis für einen Angriff. Umgekehrt schließt ihr Fehlen eine Ausnutzung nicht aus.

Mögliche Hinweise auf einen Angriff oder eine Kompromittierung sind:

• Ungewöhnlich viele gleichartige HTTP-Anfragen
• Gehäufte PHP-Fehler oder Fatal Errors
• Auffällige POST-Anfragen, insbesondere im Zusammenhang mit PHP_SESSION_UPLOAD_PROGRESS
• Neue oder veränderte Dateien
• Unbekannte Dateien in Upload-, Cache- oder temporären Verzeichnissen
• Unerwartete Cronjobs oder Benutzerkonten
• Verdächtige Prozesse auf dem Server
• Plötzliche Weiterleitungen oder SEO-Spam

Vorhandene Webserver-, PHP- und Security-Logs sollten mindestens rückwirkend bis zum 17. Oktober 2026 geprüft werden. Einzelne Auffälligkeiten, etwa verdächtige POST-Anfragen mit PHP_SESSION_UPLOAD_PROGRESS, sind dabei als Untersuchungshinweise zu verstehen. Sie sind kein alleiniger Nachweis für eine erfolgreiche Kompromittierung, sollten aber im Kontext weiterer Logdaten, Dateisystemänderungen und Systemprozesse bewertet werden.

Bei E-Commerce-Systemen sollten zusätzlich Checkout, Payment, Kundenlogin und angebundene Schnittstellen geprüft werden. Wichtig ist außerdem: Eine Kompromittierung kann auch nach einem Update bestehen bleiben, wenn eingeschleuster Schadcode oder andere eingerichtete Zugänge bestehen bleiben.

Vorgehen bei Kompromittierungsverdacht

Wenn konkrete Hinweise auf eine Kompromittierung vorliegen, reicht ein PHP-Update allein nicht aus. Bereits eingeschleuster Schadcode, manipulierte Dateien oder eingerichtete Zugänge können auch nach dem Update weiter bestehen.

Betreiber sollten betroffene Systeme daher zunächst kontrolliert eindämmen, relevante Logs und Beweise sichern und eine technische Untersuchung durchführen lassen. Dabei sollten mögliche Hintertüren, veränderte Dateien, verdächtige Benutzerkonten und kompromittierte Zugangsdaten geprüft und bereinigt werden. Zusätzlich sollte bewertet werden, ob personenbezogene Daten betroffen sein könnten und ob daraus weitere Melde- bzw. Informationspflichten entstehen.

Für den Schutz vor PHP2Shell reicht es nicht aus, ein Updatepaket nur zu installieren. Entscheidend ist, dass die aktualisierte PHP-Version nach Update und Neustart tatsächlich aktiv läuft. Dafür sollten Betreiber strukturiert vorgehen:

• PHP-Systeme inventarisieren: Alle produktiven Systeme sowie Staging-, Test- und Administrationsumgebungen erfassen. Dazu gehören auch Container, Hosting-Panels, Cronjobs und nicht öffentlich beworbene PHP-Anwendungen.
• Angriffsfläche vorübergehend reduzieren: Nicht benötigte Dienste deaktivieren und den Zugriff auf betroffene Systeme nach Möglichkeit einschränken. Lässt sich das Sicherheitsrisiko nicht kurzfristig beheben, sollte geprüft werden, ob die Website oder Anwendung bis zur Installation der erforderlichen Sicherheitsupdates vorübergehend offline genommen werden muss.
• Backups und Wiederherstellungsoptionen prüfen: Aktuelle Backups, Snapshots und Rollback-Möglichkeiten sichern und sicherstellen, dass eine Wiederherstellung im Notfall möglich ist.
• Sicherheitsupdates installieren und zusätzliche PHP-Hinweise beachten: Die korrigierte PHP-Version oder das entsprechende Sicherheitsupdate des Distributors bzw. Hosting-Anbieters einspielen. Zusätzlich sollten Betreiber die PHP-Sicherheitsmeldung vom 23. Oktober 2026 zu CVE-2026-115560 prüfen. Bei entsprechend betroffenen Konfigurationen empfiehlt das PHP-Projekt, session.upload_progress.enabled=0 zu setzen, bis ein korrigiertes Release verfügbar ist.
• Dienste neu starten: PHP-FPM, Apache oder betroffene Container neu starten. Docker-Images sollten aktualisiert und neu bereitgestellt werden.
• Aktiven Patch-Status verifizieren: Nach Update und Neustart prüfen, ob alle betroffenen PHP-Laufzeitumgebungen tatsächlich aktualisiert sind. Bei Distributionspaketen sollte zusätzlich der Sicherheitsstatus des jeweiligen Anbieters berücksichtigt werden.
• Zentrale Funktionen testen: Login, Formulare und bei Shops zusätzlich Warenkorb, Kaufabschluss und Payment-Funktionen prüfen.
• Logs, Dateien und Systeme auf Kompromittierung prüfen: Webserver-, PHP-, Security- und Systemlogs auswerten sowie auffällige Dateien, Prozesse, Cronjobs und Benutzerkonten kontrollieren.

Temporäre Maßnahmen nach den Empfehlungen des PHP-Projekts und des jeweiligen Anbieters können einzelne Angriffswege erschweren und die Angriffsfläche reduzieren. Sie bieten jedoch keinen vollständigen Schutz und beseitigen nicht die zugrunde liegenden Sicherheitslücken. Sicherheitsupdates bleiben daher zwingend erforderlich und sollten nicht durch Übergangslösungen ersetzt werden.

Wann ist ein Sicherheitsaudit sinnvoll?

Ein Sicherheitsaudit ist besonders dann sinnvoll, wenn die technische Ausgangslage nicht eindeutig ist: etwa wenn unklar bleibt, welche PHP-Versionen tatsächlich im Einsatz sind, ältere Shop- oder CMS-Versionen betrieben werden oder mehrere Hosting-, Server- oder Container-Umgebungen parallel existieren.

Eine technische Prüfung hilft dabei, die tatsächliche Angriffsfläche besser einzuschätzen. Dazu gehören nicht nur installierte Updates, sondern auch Abhängigkeiten, Konfigurationen, Dateirechte, Logdaten und mögliche Hinweise auf eine bereits erfolgte Kompromittierung.

PHP2Shell zeigt, wie kritisch Sicherheitslücken in der PHP-Laufzeitumgebung für moderne Websites und Shop-Systeme sein können. Website- und Shop-Betreiber sollten deshalb nicht nur prüfen, ob Updates installiert wurden, sondern auch, ob die neue PHP-Version tatsächlich aktiv ist und ob es Hinweise auf eine mögliche Kompromittierung gibt.

Besonders bei gewachsenen Systemlandschaften, älteren PHP-Versionen, individuellen Erweiterungen oder mehreren Hosting-Umgebungen ist diese Prüfung oft nicht trivial. Dann geht es nicht mehr nur um ein einzelnes Update, sondern um die Frage, wie stabil, sicher und updatefähig die gesamte technische Basis ist.

alkima WEB & DESIGN ® unterstützt Unternehmen bei genau dieser Einordnung: von der Analyse bestehender PHP-, Hosting- und Shop-Setups über kontrollierte Updates bis hin zur technischen Umsetzung und Weiterentwicklung von Webprojekten.