An der Freien Universität Berlin war die digitale Tür am 21. Oktober 2026 zeitweise nur angelehnt: Die Erreichbarkeit von IT-Diensten wurde vorsorglich eingeschränkt. Seit 16 Uhr installierte die Universität verfügbare Updates; die Wiederfreigabe sollte schnellstmöglich erfolgen. Die Arbeiten sollten voraussichtlich bis Donnerstagvormittag dauern.

Auslöser war keine bestätigte Attacke auf die FU, sondern eine weltweit bekannt gewordene Sicherheitslücke im PHP-Kern. Auch die Charité nahm am Mittwochmittag ihre offiziellen Webseiten vorsorglich vom Netz. Betroffen waren die Charité-Webseite, Seiten des Berlin Institute of Health at Charité und weitere an das Charité-Portal angebundene Angebote. Die notwendigen Sicherheitsupdates sollten bis Donnerstag installiert werden.

Webseiten offline, Klinikbetrieb läuft weiter

Laut Charité-Sprecher Markus Heggen hatte die Maßnahme keinen Einfluss auf den Klinikbetrieb. Eingeschränkt waren lediglich Sichtbarkeit und Erreichbarkeit nach außen. Online konnten unter anderem keine Termine gebucht werden. Webseiten des Berliner Senats und des Abgeordnetenhauses waren am frühen Abend erreichbar.

Auch Mainz schaltete nach einer Warnung des Bundes mehrere städtische Internetdienste sowie das Portal mainz.de vorsorglich ab. Der Grund liegt in PHP, einer Programmiersprache, die unter anderem Blogs, Nachrichtenportale, Onlineshops und Content-Management-Systeme wie WordPress antreibt. Das IT-Sicherheitsunternehmen Huntress, das Bundes-CERT und das PHP-Sicherheitsteam stuften die Lage als akuten Notfall ein.

Unter dem Namen „PHP2Shell“ wurden zwei kritische Schwachstellen bekannt: CVE-2026-109618 und CVE-2026-109619. Angreifer können sie aus der Ferne und ohne Anmeldung oder Nutzerinteraktion ausnutzen, um Schadcode auf betroffenen Servern auszuführen. Im schlimmsten Fall übernehmen sie Webseiten vollständig, greifen Kundendaten ab oder missbrauchen Server für weitere Cyberangriffe. Weil technische Details vorzeitig öffentlich wurden, läuft die Zeit. Branchenexperten rechnen mit automatisierten Angriffen auf ungeschützte Systeme.

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

Was hinter PHP2Shell steckt

CVE-2026-109618 ermöglicht Remote-Code-Ausführung durch Speichermangel beim Einlesen von Multipart-Formularen. CVE-2026-109619 nutzt einen veralteten globalen Zustand nach einem fatalen Fehler aus, unter anderem über den Session-Upload-Fortschritt. Beide Lücken wurden nach CVSS 4.0 mit 9,2 von 10 bewertet.

Besonders gefährdet sind mod_php unter Apache – ein Exploit wurde demonstriert, bevor Anwendungscode ausgeführt wird – sowie PHP-FPM. Für die zweite Schwachstelle ist PHP-FPM bestätigt anfällig, für die erste gilt es nach Codeanalyse als gefährdet. PHP über CLI, Cronjobs oder Queue-Worker ist über die beschriebenen HTTP-Angriffswege nicht erreichbar. Wegen des gemeinsamen Pakets sollten aber auch diese Komponenten aktualisiert werden.

Die Einschätzungen zu laufenden Angriffen gehen auseinander: Das BSI meldete keine bestätigten Angriffe, aber unbestätigte Exploit-Berichte. Aikido und Patchstack berichteten von Ausnutzung beziehungsweise aktiven Angriffen, während JFrog und Huntress zunächst keine breite Ausnutzung sahen. In Berichten tauchte wegen der vermuteten Tragweite und der Ähnlichkeit zu „Log4Shell“ die Bezeichnung „PHP2Shell“ auf.

PHP-Entwickler hatten für den 21. Oktober 2026 ab 16:00 Uhr deutscher Zeit, also 14:00 UTC, Details und Patches angekündigt. Das BSI empfahl, den Patch unmittelbar nach der Veröffentlichung einzuspielen. Im Update vom 21. Oktober 2026 hieß es, dass für verschiedene PHP-Versionen Patches bereitstehen und weitere technische Einzelheiten veröffentlicht wurden. Dazu gehören GitHub Advisories zu den CVEs sowie Blogartikel von Wiz.io und Calif.io; beide waren gemeinsam mit OpenAI an der Entdeckung beteiligt.

Patchen heißt auch neu starten

Empfohlen werden PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1, 8.0 und 7.4 veröffentlicht das PHP-Projekt keine regulären Releases mehr, sondern nur Quellcode-Backports. PHP 8.2 erhält noch bis 31. Dezember 2026 Sicherheitsupdates. Distributionen können Fixes zudem in eigenen Paketversionen ausliefern, ohne die PHP-Versionsnummer zu verändern. Entscheidend ist deshalb der Paket-Changelog mit den CVE-Nummern – nicht allein die Ausgabe von php -v.

Nach der Installation müssen PHP-FPM beziehungsweise Apache neu gestartet und Container neu ausgerollt werden. Sonst arbeiten alte Worker-Prozesse weiter, der Patch bleibt für sie wirkungslos. WordPress, aktuelle Plugins oder andere aktuelle CMS-Komponenten schützen nicht vor den Lücken, wenn der PHP-Interpreter ungepatcht ist. Ein alter Wert bei php -v wiederum bedeutet bei Distributionspaketen nicht zwingend, dass der Fix fehlt.

Das veröffentlichte Prüfskript php2shell.sh findet PHP-, PHP-FPM-, CGI- und mod_php-Installationen, prüft Versionen und Paket-Changelogs, erkennt fehlende Neustarts, untersucht Docker- und Podman-Container und sucht nach möglichen Kompromittierungsspuren. Der Prüfmodus verändert nichts. Übergangsmaßnahmen werden separat und mit Sicherung ausgeführt; das Skript ersetzt keinen Patch.

Falls ein sofortiges Update nicht möglich ist, können einige Einstellungen die Angriffswege vorübergehend einschränken: session.upload_progress.enabled = 0, bei PHP 8.5 fatal_error_backtraces = 0, außerdem post_max_size = 8M oder der niedrigste für die Anwendung geeignete Wert. Hinzu kommen zusätzliche Größenlimits am Webserver oder Proxy und – wenn keine Datei-Uploads gebraucht werden – das Abweisen von Multipart-Anfragen.

memory_limit = -1 kann einen bestimmten Speichermangel verhindern, beseitigt die Schwachstelle aber nicht vollständig. Unbegrenzter Speicherverbrauch kann sogar einen Ausfall verursachen. Das PHP-Projekt bezeichnet diese Einstellungen ausdrücklich nicht als vollständigen Schutz, sondern als kurzfristige Überbrückung. Sie müssen in der tatsächlich verwendeten SAPI beziehungsweise im FPM-Pool gesetzt werden, nicht in .user.ini oder per ini_set(). Die CLI-Konfiguration ist von der PHP-FPM-Konfiguration getrennt. Wirksame FPM-Werte lassen sich über php-fpm -i oder vorübergehend im Web-Kontext mit phpinfo() prüfen.

Spuren suchen, bevor sie verschwinden

Zur Schadensbegrenzung empfiehlt sich, jede Website in einem eigenen FPM-Pool und unter einem eigenen Benutzer auszuführen. Schreibrechte des Webprozesses sollten auf Upload- und Cache-Verzeichnisse beschränkt, PHP-Ausführung in Upload-Verzeichnissen verhindert werden. Zu prüfen sind außerdem open_basedir, disable_functions, allow_url_include = off und expose_php = Off. PHP-FPM lässt sich mit systemd, AppArmor oder SELinux einschränken; ausgehende Netzwerkverbindungen des Webservers können per Egress-Filterung begrenzt werden. WAF- oder Reverse-Proxy-Regeln kommen ebenfalls infrage.

Alarm schlagen sollten Betreiber bei auffälligen Kindprozessen wie sh, bash, curl oder wget unter PHP-FPM beziehungsweise Apache sowie bei neuen PHP-Dateien im Webverzeichnis. Für eine mögliche Kompromittierung empfiehlt der Artikel, nach neuen oder geänderten PHP-Dateien seit dem 20. Oktober 2026 zu suchen, Shell- und Downloader-Prozesse unter dem Webbenutzer zu prüfen und dessen Cronjobs zu kontrollieren.

Auch Häufungen von Speicherfehlern und HTTP-500-Fehlern, auffällige Multipart-Anfragen, übergroße PHPSESSID-Cookies und unerwartete Worker-Neustarts gehören auf die Liste. Neu angelegte Administratorkonten im CMS sollten ebenfalls kontrolliert werden. Bei begründetem Verdacht gilt das System als kompromittiert: isolieren statt nur patchen, Datenbank-, API-, SMTP- und Deploy-Zugangsdaten wechseln und einen Incident-Response-Prozess einleiten.

Für Betreiber ergibt sich daraus eine ziemlich praktische Checkliste: alle PHP-Webserver einschließlich Test- und Altsysteme erfassen, das Prüfskript ausführen, PHP-Version und Paketquelle dokumentieren, den Fix anhand des Paket-Changelogs bestätigen, PHP-FPM beziehungsweise Apache neu starten und Container