Stand: 26.10.2026 14:30 Uhr – dieser Beitrag wird aktualisiert, sobald neue Informationen vorliegen.
Zwei neu bekannt gewordene Schwachstellen in PHP (ab Version 5.3) erlauben Angreifern, unter bestimmten Bedingungen beliebigen PHP-Code auf dem Server auszuführen – daher der Name PHP2Shell. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat dazu eine Cybersicherheitswarnung veröffentlicht und stuft die Lage als 3 ORANGE (höchste Stufe: 4 ROT) ein.
Betroffen ist nicht eine einzelne PHP-Anwendung oder ein Plugin, sondern der Kern der Programmiersprache selbst. Der Code wird dann direkt mit den Rechten des PHP-Interpreters ausgeführt.
Worum geht es?
RCE durch fehlerhafte Out-of-Memory-Behandlung, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): Geht PHP der Arbeitsspeicher aus, kann die Verarbeitung an einer Stelle abbrechen, an der interne Anfragedaten erst teilweise initialisiert sind. Beim anschließenden Aufräumen der Anfrage werden diese ungültigen Daten dann womöglich als gültig behandelt.
RCE durch veralteten globalen Zustand, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): Interne Zustandsdaten einer Anfrage können weiterbestehen, obwohl der zugehörige Speicher bereits freigegeben wurde. Bearbeitet derselbe Worker-Prozess später eine weitere Anfrage, greift er unter Umständen auf diese veralteten Daten zu, bevor die normale Initialisierung sie zurücksetzt.
Betroffen sind laut PHP.net die Versionen ab 5.3. Die Schwere wird mit einem CVSS-Wert von 9.2 angegeben. Es gibt bereits Hinweise auf aktive Ausnutzung bzw. öffentlich verfügbaren Exploit-Code.
Warum ist PHP2Shell so gefährlich?
Remote Code Execution (kurz: RCE) ist die schwerste Klasse von Webanwendungs-Schwachstellen. Wer Code auf dem Server ausführen kann, kann in der Regel Daten auslesen, Hintertüren (Webshells) installieren, Zugangsdaten zu Datenbanken abgreifen und sich von dort aus weiter im Netzwerk bewegen. Weil PHP auf einem großen Teil aller Webserver läuft, ist die potenzielle Angriffsfläche entsprechend groß.
Vorsorgliche Abschaltungen
Mehrere Betreiber haben ihre Angebote vorsorglich vom Netz genommen, darunter easybill, Charité. Ein solcher Schritt ist unbequem, aber nachvollziehbar: Solange kein Patch eingespielt und ein möglicher Einbruch nicht ausgeschlossen ist, ist ein kontrollierter Ausfall oft das kleinere Übel.
Was Betreiber jetzt tun sollten
Am wichtigsten ist es, die Updates sofort einzuspielen, beziehungsweise sobald sie in den Repositories bereitgestellt werden.
Das sind die gefixten Versionen:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Hinweis für Linux-Repositories: die Versionsnamen der unterschiedlichen Linux-Distributionen können irreführend sein. So ist bspw. bei Ubuntu 24.04 das Paket php8.3-cgi mit der Version 8.3.6-0ubuntu0.24.04.13 das Paket, das den Fix enthält (entscheidend ist hierbei die .13 am Ende). Bitte mit den Distri-Systemen abgleichen (vgl. Ubuntu USN, Debian DSA, Red Hat RHSA)
Ist das kurzfristig nicht möglich, sollten die beispielsweise vom sansec genannten Workarounds umgesetzt werden (ggf. Einschränkung der Funktionalität):
- Upload über Multipart-Formdata verbieten
- POST verhindern, nur GET/HEAD zulassen
- PHP-Upload abschalten
- Komplettabschaltung
Ebenso wichtig ist die Prüfung auf eine bereits erfolgte Kompromittierung. Dazu gehören ein Blick in die Webserver-Logs auf auffällige Anfragen, die Suche nach unbekannten oder kürzlich veränderten PHP-Dateien im Webroot und die Kontrolle auf neue Benutzerkonten, Cronjobs oder ausgehende Verbindungen. Bei Verdacht sollten alle Zugangsdaten, die auf dem System gespeichert waren, ausgetauscht werden.
Zusätzlich sollten IPS-Systeme mit aktuellen Signaturen versorgt werden; die Suche nach den CVE-Nummern hilft dabei.
PHP-Anwendungen entdecken
Um grob zu wissen, ob man potenziell betroffen ist, kann man schauen, ob eine der folgenden Anwendungen betrieben werden:
- WordPress / Joomla / Drupal
- Magento / Shopware / WooCommerce
- OPNsense / pfSense
- Owncloud / Nextcloud
- Moodle
- Dolibarr / OrangeHRM
- SuiteCRM / vTiger
- limesurvey
Hinweis: die Sicherheitslücke befindet sich nicht in den oben genannten Softwareprodukten, sondern sie basieren massgeblich auf PHP, das die Schwachstellen hat.
Updates und Patches
Achtung, entsprechende Sicherheitsupdates gibt es (Stand 21.10.2026) nur für jüngere PHP-Version ab 7.4. Ältere Versionen bleiben dauerhaft verwundbar und sollten auf eine unterstützte Version migriert werden.
Vergleichbare Sicherheitslücken
Die Lage erinnert an Log4Shell (CVE-2021-44228): Damals war mit log4j eine Bibliothek betroffen, die in unzähligen Java-Anwendungen steckt. Hier ist es sogar die Programmiersprache selbst.
PHP2Shell Mitigation
Eine gute Praxis ist es, Webservices nicht direkt ins Internet zu stellen, sondern einen Reverse Proxy (am besten mit WAF) zu integrieren. Dieser nimmt alle Anfragen von außen entgegen (kümmert sich auch um die Zertifikate) und reicht sie dann an den eigenen Webserver im internen Netzwerk weiter. Diese Strecke kann dabei sogar unverschlüsselt sein, um IPS die Möglichkeiten zu geben, den Traffic zu analysieren. OPNsense mit Suricata hat bereits passende Pattern für PHP2Shell parat:
Changelog
- Update 16:00 Uhr: Die PHP-Entwickler haben Sicherheitsupdates veröffentlicht.
(ganz plakativ: Auch die Bösen kennen nun das volle Potential der Lücke) - Update 17:00 Uhr: Alle wichtigen Distris (Debian, Ubuntu, RedHat) haben aktualisierte Pakete bereitgestellt.
- 26.10.2026: OPNsense hat über die ET-Liste für Suricata Patterns für das IPS
Quellen
- BSI-Cybersicherheitswarnung 2026-297981-1032: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-297981-1032.pdf?__blob=publicationFile&v=3
- PHP Security Advisory
- CVE-2026-109618 und CVE-2026-109619
- Berichte zu Abschaltungen
