An der Universität Duisburg-Essen und bei weiteren Einrichtungen in Duisburg sind am 21. Oktober 2026 mehrere Webseiten vorsorglich abgeschaltet worden. Auslöser ist eine schwere Sicherheitslücke in der Programmiersprache PHP, die weltweit Alarm unter IT-Experten ausgelöst hat. Seit mehreren Stunden waren unter anderem die Internetauftritte der Stadt Duisburg, der Stadtwerke, der Duisburger Versorgungs- und Verkehrsgesellschaft (DVV), der Universität Duisburg-Essen, des Zoo Duisburg und des Einkaufszentrums Forum nicht erreichbar.

Wann die Seiten wieder online gehen, war zunächst unbekannt. Möglicherweise sind weitere Webseiten in der Region betroffen. Die Lücke trägt den Namen „PHP2Shell“. Angreifer könnten darüber schädliche Software auf Servern ausführen und im schlimmsten Fall die Kontrolle über diese übernehmen. Dann wären etwa Zugriffe auf sensible Daten oder die Nutzung der Server für weitere Angriffe denkbar. Wie groß die konkrete Gefahr für die einzelnen Duisburger Webseiten ist und welche Schutzmaßnahmen jeweils ergriffen wurden, war zunächst nicht bekannt.

Warum PHP2Shell so brisant ist

Hinter „PHP2Shell“ stehen zwei kritische Schwachstellen im PHP-Interpreter: CVE-2026-109618 ermöglicht eine mögliche Remote-Code-Ausführung durch Speichermangel und die fehlerhafte Verarbeitung von Multipart-Formularen. CVE-2026-109619 betrifft veraltete globale Zustände in Worker-Prozessen, einen sogenannten „Use-after-free“, unter anderem über den Session-Upload-Fortschritt.

Das BSI bewertet beide Lücken mit CVSS 9.2 beziehungsweise 9,2 von 10 nach CVSS 4.0. Eine Ausnutzung ist ohne Anmeldung und ohne Zutun eines Nutzers möglich. Laut den Bewertungen könnten Angreifer aus der Ferne Schadcode auf Webservern mit PHP-Anwendungen ausführen. Wegen der Ähnlichkeit zu „Log4Shell“ werden die Schwachstellen in aktuellen Berichten auch „PHP2Shell“ genannt.

Betroffen sind alle PHP-Versionen unterhalb der jeweiligen Fix-Versionen. Das kann Anwendungen und Frameworks wie WordPress, Drupal, Magento, Laravel oder Eigenentwicklungen treffen, sobald PHP Internetanfragen verarbeitet. Aktuelle Plugins oder ein gepflegtes WordPress schützen also nicht, wenn der PHP-Interpreter selbst ungepatcht ist.

Hier könnte Ihr Advertorial stehen
Ein Advertorial bietet Unternehmen die Möglichkeit, ihre Botschaft direkt im redaktionellen Umfeld zu platzieren

Das höchste Risiko besteht laut PHP-Projekt bei mod_php; dort wurde ein Exploit vor der Ausführung von Anwendungscode demonstriert. PHP-FPM ist für CVE-2026-109619 bestätigt und laut Code-Analyse auch für CVE-2026-109618 anfällig. Kommandozeilenprogramme, Cronjobs und Queue-Worker ohne HTTP-Eingang sind über die beschriebenen Angriffswege nicht erreichbar. Wegen des gemeinsamen Pakets sollten aber auch sie aktualisiert werden.

Patchen, neu starten, nicht nur auf php -v schauen

Die PHP-Entwickler kündigten für den 21. Oktober 2026 um 16 Uhr deutscher Zeit, also 14:00 UTC, Details und Patches an. Wie angekündigt wurden an diesem Tag Korrekturen für mehrere PHP-Versionen bereitgestellt und weitere Informationen veröffentlicht. Hinweise finden sich unter anderem in den GitHub Advisories zu den CVEs sowie in Blogartikeln von Wiz.io und Calif.io. Wiz.io und Calif.io waren gemeinsam mit OpenAI an der Entdeckung der Schwachstellen beteiligt.

Verfügbar sind die Fix-Versionen PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 und PHP 8.2.35. Für PHP 8.1 und ältere Versionen gibt es keine offiziellen Releases mehr, lediglich Quellcode-Backports; ein Upgrade sollte eingeplant werden. PHP 8.2 erhält noch bis 31.12.2026 Sicherheitsupdates. PHP 7.4, 8.0 und 8.1 werden vom PHP-Projekt nicht mehr regulär veröffentlicht, für den Betrieb empfiehlt sich ein unterstützter Zweig.

Das BSI rät, Updates unverzüglich einzuspielen, und nennt keinen Workaround. Bei Distributionspaketen kann trotz eingespieltem Fix die alte PHP-Versionsnummer stehen. Entscheidend ist deshalb der Paket-Changelog mit den CVE-Nummern, nicht allein die Ausgabe von php -v. Diese zeigt außerdem die CLI-Konfiguration und nicht zwingend die von PHP-FPM verwendete Version.

Debian, Ubuntu, Red Hat, AlmaLinux und Rocky Linux übernehmen die Korrekturen in eigene Paketversionen. Auch bei Remi-Repositories und Container-Images muss der Fix ausdrücklich geprüft werden. Nach einem Container-Neubau braucht es einen Neustart; nach Paketupdates müssen PHP-FPM beziehungsweise Apache ebenfalls neu gestartet werden, weil laufende Worker sonst den alten Code verwenden.

Für Debian und Ubuntu gehören unter anderem apt update, die Paketupdates, die Changelog-Prüfung und ein Neustart von PHP-FPM oder Apache auf die Liste. Auf RHEL-basierten Systemen sind dnf updateinfo, die Paketupdates, die Prüfung des Changelogs sowie der Neustart von PHP-FPM oder Apache vorgesehen. Für alle PHP-Webserver sollten außerdem Test- und Altsysteme erfasst, PHP-Version und Installationsquelle dokumentiert und der Nachweis der CVE-Nummern im Paket-Changelog festgehalten werden.

Wenn der Patch noch warten muss

Ist eine Aktualisierung kurzfristig nicht möglich, kann die Angriffsfläche vorübergehend mit session.upload_progress.enabled = 0 reduziert werden. Für PHP 8.5 kommt fatal_error_backtraces = 0 hinzu. Außerdem sollte post_max_size möglichst niedrig gesetzt und Größenlimits am Webserver oder Proxy konfiguriert werden, etwa client_max_body_size bei nginx. Werden keine Uploads benötigt, lassen sich Multipart-Anfragen am vorgeschalteten Webserver blockieren.

Das macht ein System nicht sicher und ersetzt keinen Patch. Auch memory_limit = -1 beseitigt den Fehlerpfad nicht vollständig, sondern kann nur einen beschriebenen Auslöser reduzieren – zugleich hebt es alle Speicherlimits auf, sodass eine einzelne Anfrage den Server überlasten kann. session.use_strict_mode = 1 wird teilweise empfohlen, gehört aber nicht zu den offiziellen PHP-Gegenmaßnahmen.

Wichtig ist, dass die Einstellungen in der tatsächlich verwendeten SAPI beziehungsweise im FPM-Pool gelten. .user.ini, ini_set() und die CLI-Konfiguration reichen dafür nicht aus. Die wirksamen Werte lassen sich im PHP-FPM-Kontext oder kurzzeitig über eine phpinfo()-Seite prüfen. Danach soll diese Seite wieder gelöscht werden – sie muss nicht als kleines digitales Souvenir liegen bleiben.

Für die weitere Absicherung empfiehlt sich, jede Website in einem eigenen PHP-FPM-Pool und unter einem eigenen, möglichst eingeschränkten Systembenutzer zu betreiben. Der Webprozess sollte nur Leserechte auf den Anwendungscode haben; Schreibrechte gehören auf Upload- und Cache-Verzeichnisse beschränkt. PHP-Ausführung in Upload-Verzeichnissen sollte deaktiviert werden. Je nach Anwendung können außerdem open_basedir, disable_functions und allow_url_include = off eingesetzt werden. expose_php = Off gehört ebenfalls zu den Härtungsmaßnahmen.

disable_functions erschwert einfache Webshells, verhindert aber keine Ausführung nativen Codes. PHP-FPM lässt sich mit systemd-Einstellungen wie ProtectSystem, ProtectHome, PrivateTmp und NoNewPrivileges einschränken. AppArmor oder SELinux können ergänzend zum Einsatz kommen. Ausgehende Verbindungen des Webservers sollten per Egress-Filterung auf notwendige Ziele begrenzt werden. WAF- oder Reverse-Proxy-Regeln sind eine zusätzliche Schutzschicht, aber kein Ersatz für den Patch.

Spuren prüfen, bevor aus einem Verdacht ein Notfall wird

Uneinheitlich ist die Lage bei bereits laufenden Angriffen. Das BSI meldete keine bestätigten Angriffe, verwies aber auf unbestätigte Exploit-Berichte. Aikido und Patchstack berichteten über Ausnutzung beziehungsweise aktive Angriffe. JFrog und Huntress beobachteten bis zum Nachmittag keine breite Ausnutzung. Die Entwickler hatten deshalb schon vor der Veröffentlichung empfohlen, den Patch unmittelbar zu installieren.

Administratoren sollten neue oder geänderte PHP-Dateien seit dem 20.10.2026 suchen und Prozesse sowie Kindprozesse unter Benutzern wie www-data, apache, nginx oder php prüfen. Auch die Cronjobs des Webbenutzers gehören kontrolliert. In PHP