PHP2Shell: Was wir getan haben – und was jetzt bei Ihnen liegt

Was am 20. und 21. Oktober passiert ist

Im Kern von PHP – also nicht in einem einzelnen CMS oder Plugin, sondern in der Programmiersprache selbst – wurden zwei kritische Schwachstellen entdeckt. Sie tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und werden mit 9,2 von 10 Punkten auf der CVSS-Skala bewertet.

Auf betroffenen Systemen können Angreifer aus dem Internet heraus und ohne jede Anmeldung eigenen Code ausführen. Betroffen ist praktisch jede PHP-Installation, die Webanfragen verarbeitet. Damit standen faktisch alle WordPress-, TYPO3-, Joomla-, Shopware-, Magento- oder Nextcloud-Installationen im Feuer – und unzählige individuelle Webanwendungen.

Besonders heikel war der Ablauf: Details zu den Lücken gelangten am 20. Oktober vorzeitig an die Öffentlichkeit, noch bevor Updates bereitstanden. Das PHP-Team zog die Veröffentlichung daraufhin vor – auf den nächsten Tag, 16 Uhr. Sicherheitsdienstleister wie Cloudflare und watchTowr meldeten unmittelbar nach dem Release erste Angriffsversuche. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hatte eine Warnung der Stufe 3 („Orange“) herausgegeben und empfohlen, Webserver notfalls vom Internet zu trennen.

Die offiziell korrigierten Versionen lauten PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Und hier liegt der Knackpunkt für viele Websites: Für PHP 8.1 und alle älteren Versionen liefert das PHP-Projekt keine Sicherheitsupdates mehr.

Sie waren nicht allein: Die Welt im Ausnahmezustand

Wer am Mittwochabend oder Donnerstag im Netz unterwegs war, stieß vielerorts auf Wartungsseiten. In Deutschland nahmen unter anderem die Stadt Mainz, die Stadt Düsseldorf und die Berliner Charité ihre Websites vom Netz, die Ruhr-Universität Bochum schränkte den Zugriff ein. Auch Polizeibehörden waren betroffen, etwa in Berlin und Baden-Württemberg. Selbst Angebote der Bundesverwaltung wurden vorsorglich abgeschaltet; die Website des Bundesinnenministeriums war zeitweise nicht erreichbar.

Im Ausland sah es nicht anders aus: Der Kanton Basel-Stadt fuhr seine Websites herunter, ebenso die ETH Lausanne und die Universität Genf. In den Niederlanden gingen das staatliche Bürgerportal MijnOverheid und der Login-Dienst DigiD vorübergehend offline. Von japanischen Fluglinien bis zum Cyber Security Centre der australischen Regierung gingen weltweit Websites vom Netz.

Was wir bei Portunity konkret getan haben

Eine Besonderheit vorweg, weil sie für alles Weitere wichtig ist: Wir installieren PHP nicht einfach als fertiges Paket aus einer Linux-Distribution, sondern bauen und paketieren es für unsere Systeme komplett selbst. Das ist im Alltag mehr Aufwand, gibt uns aber die volle Kontrolle – über parallel angebotene Versionen, über Konfiguration und eben auch über Sicherheitskorrekturen. In einer Lage wie dieser bedeutet das: Ein Update ist bei uns nicht „einmal Update-Befehl ausführen“, sondern Quellcode übernehmen, kompilieren, paketieren, testen und ausrollen – für jede Version einzeln.

Maßnahmen im Vorfeld: Noch bevor es offizielle Patches gab, hatten wir Schutzmaßnahmen (Mitigations) auf unseren Servern implementiert.

Maßnahmen bei der Veröffentlichung: Wir haben mit Veröffentlichung sofort alle Pakete für PHP 8.2 bis 8.5 neu gebaut. Die Updates liefen dann sofort auf unseren Webspace-Servern an. Wer eine dieser Versionen nutzt, blieb geschützt online – ohne eigenes Zutun. Projekte auf älteren, noch nicht abgesicherten PHP-Versionen haben wir temporär vom Netz genommen.

Für PHP 7.4 gibt es vom PHP-Projekt seit Jahren keine Updates mehr. Wir haben die offiziellen Korrekturen deshalb analysiert, auf den deutlich älteren Codestand übertragen, neu gebaut und getestet. Das ist ein zusätzlicher Aufwand, den wir gern für unsere Kunden geleistet haben – und der erklärt, warum 7.4 erst verzögert wieder zur Verfügung stand.

Für PHP 8.0 und 8.1 haben wir keinen Backport gebaut. Der Umstieg von dort auf PHP 8.2 gelingt nach unserer Erfahrung in den allermeisten Fällen ohne größere Anpassungen – der sinnvollere Weg ist hier also das Upgrade, nicht ein weiteres Flickwerk an einer ausgelaufenen Version. Bestehende Kundenwebsites haben wir von PHP 8.0/8.1 auf 8.2 umgestellt.

Unabhängig von den Patches setzen wir auf unseren Servern SELinux ein. Dieses Sicherheitsmodul im Linux-Kernel schränkt die Tätigkeit von Systemdiensten ein – welche Dateien diese lesen, welche Programme sie starten, wohin sie sich verbinden dürfen. Gelänge es einem Angreifer trotz aller Vorkehrungen, Code auszuführen, würde diese zusätzliche Schicht seinen Spielraum deutlich einschränken. Eine Garantie ist das nicht und auch kein Ersatz für Updates, aber ein wichtiger Baustein in unserem Sicherheitskonzept.

Weiterer Handlungsbedarf für alle PHP 7.4 Projekte

Dass wir heute noch PHP 7.4 anbieten, ist ein bewusstes Entgegenkommen: Nicht jedes Projekt lässt sich von heute auf morgen modernisieren, und wir möchten niemanden im Regen stehen lassen. Es ist aber kein Dauerzustand. PHP 7.4 erhält seit Ende 2022 keine offiziellen Sicherheitsupdates mehr. Dieses Mal konnten wir für 7.4 mit einem eigenen Backport einspringen. Ob das bei der nächsten Lücke wieder möglich ist, können wir nicht versprechen.

Deshalb unsere herzliche Bitte: Wenn Ihre Website noch auf PHP 7.4 läuft, nehmen Sie bitte die Ereignisse der vergangenen Tage zum Anlass, jetzt mit Ihrer Agentur oder Ihren Entwicklern ein Update Ihrer Projekte, Websites und Web-Systeme durchzuführen.

Ihre Checkliste für die nächsten Tage

Unabhängig davon, ob Ihre Website abgeschaltet war oder nicht – diese Punkte empfehlen wir allen Kunden:

• PHP-Version prüfen: Im Kundenmenü sehen Sie, welche Version Ihr Projekt nutzt. Empfehlenswert ist mindestens PHP 8.2, besser 8.3 oder 8.4. Läuft Ihr Projekt auf 8.0 oder 8.1, stellen Sie jetzt auf 8.2 oder neuer um – idealerweise nach einem kurzen Test. Bitte beachten Sie, dass es für einzelne Verzeichnisse in einem Webhosting-Paket abweichende Einstellungen geben kann!
• Anwendung aktualisieren: CMS, Shop-System, Plugins und Themes auf den neuesten Stand bringen – nicht verwendete Plugins am besten ganz entfernen.
• Auf Auffälligkeiten achten: Neue, unbekannte Admin-Benutzer, fremde Dateien oder veränderte Inhalte sind Warnsignale. Angriffsversuche gab es bereits vor Veröffentlichung der Patches.
• Zugangsdaten erneuern: Wenn Sie unsicher sind, ändern Sie die Passwörter für CMS-Admin, SFTP/FTP und Datenbank.
• Mit Ihrer Agentur / Entwicklern sprechen: Vereinbaren Sie einen konkreten Plan für das Upgrade auf eine aktuelle PHP-Version, inklusive Test vorab.
• Backups im Blick behalten: Prüfen Sie, ob aktuelle Sicherungen Ihrer Website und Datenbank vorliegen.

Technik-Deep-Dive (optional)

CVE-2026-109618 betrifft die Behandlung von Speichermangel: PHP verlässt bei Out-of-Memory-Fehlern den aktuellen Kontext per longjmp(). In einigen Code-Pfaden bleiben interne Anfragedaten dabei nur teilweise initialisiert, und die anschließende Bereinigung behandelt sie als gültig. CVE-2026-109619 betrifft globalen Zustand, der auf bereits freigegebenen Request-Speicher verweist und von einer späteren Anfrage im selben Worker weiterverwendet werden kann.

Die Lage ist noch in Bewegung: Für 8.4.27 und 8.5.12 wird ein Absturz in SimpleXML („zend_mm_heap corrupted“) berichtet, außerdem ein weiterer Speicherfehler in unserialize(). Korrekturen dafür sind angekündigt.

Offizielle Informationen: Security Advisory des PHP-Projekts · Cybersicherheitswarnung des BSI

Was Sie daraus mitnehmen – und wie es weitergeht

PHP2Shell hat gezeigt, wie schnell aus einer Lücke ein Notfall für das halbe Internet wird – und wie viel davon abhängt, dass Hoster und Website-Betreiber jeweils ihren Teil erledigen.

Sofern von Ihrer Seite noch Fragen zu Ihren Webhostings oder gar noch Probleme mit den Updates auftreten sollten, stehen wir Ihnen gerne zur Verfügung.