PHP2Shell: Was die PHP-Lücken bedeuten und was zu tun ist

Stand: 24. Oktober 2026

Was ist PHP2Shell und wie gefährlich ist die Lücke?

PHP2Shell ist der Name für zwei kritische Sicherheitslücken in der Programmiersprache PHP: CVE-2026-109618 und CVE-2026-109619. Das BSI bewertet beide nach CVSS 4.0 mit 9.2 von 10 Punkten [1]. Der Name soll an die Log4Shell-Lücke erinnern [1].

Laut BSI könnten Angreifer Schadcode auf Webservern mit PHP-Anwendungen ausführen. Dafür wären weder Anmeldung noch Nutzerinteraktion nötig [1]. Das BSI leitet das aus den CVSS-Werten ab. Zur Vorab-Warnung waren nur wenige Details bekannt [1].

Details nennt das BSI in GitHub Advisories zu den CVEs sowie in Blogartikeln von Wiz.io und Calif.io. Beide waren laut BSI zusammen mit OpenAI an der Entdeckung beteiligt [1].

Was ist passiert? Ablauf und Abschaltungen

Die Patches erschienen am 21.10.2026 um 16 Uhr deutscher Zeit (14:00 UTC), das PHP-Projekt hatte sie vorab angekündigt [1][2]. CERT-EU hatte schon am 20.10.2026 ein Advisory veröffentlicht (2026-018) [2].

Danach nahmen Betreiber weltweit Webseiten vorsorglich vom Netz [1][3]. Das Handelsblatt berichtet von Millionen automatisierter Angriffsversuche. In den zehn Stunden vor der Ankündigung seien es einige Tausend gewesen, zwei Stunden nach der Veröffentlichung Hunderttausende [3].

Das BSI meldete am 22.10.2026 noch keine erfolgreiche Ausnutzung in der Breite [1]. Viele abgeschaltete Seiten gingen nach der Absicherung wieder online. Nicht aktualisierte Systeme bleiben laut Handelsblatt gefährdet [3].

Warum waren Behördenseiten so lange offline?

Das Einspielen war aufwendig, weil Behörden verschiedene Fachanwendungen betreiben. So begründete es das niedersächsische Innenministerium [4]. Der Landesdienstleister IT.Niedersachsen begann am 22.10.2026 mit den Updates. Niedersachsen.de war danach wieder erreichbar. Bis alle Systeme wieder online seien, könne es bis Freitag (23.10.) dauern [4].

In Bremen waren vorübergehend abgeschaltete Webseiten laut Finanzressort inzwischen wieder erreichbar [4]. Ob die Wiederherstellung bei allen Behörden abgeschlossen ist, geht aus den Meldungen vom 22.10.2026 nicht hervor.

Welche PHP-Versionen sind betroffen und welche Fix-Versionen gibt es?

Betroffen sind PHP-Installationen ohne Patch, auch ältere Versionen. Korrigierte Versionen gibt es für vier Zweige: 8.5, 8.4, 8.3 und 8.2; die genauen Nummern zeigt die Tabelle [5][6][7][2]. Für PHP 8.1 und älter gibt es keine offiziellen Releases. Das PHP-Sicherheitsteam hat aber minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht [5][8][6].

Als frühester betroffener Stand wird PHP 5.4 aus dem Jahr 2012 genannt [8][9]. TuxCare weist darauf hin, dass dies für ein geleaktes Exploit-Werkzeug gilt [9]. Ein Datenschutzblog schildert das BSI-Bild so, dass alle bekannten Versionen zurück bis mindestens PHP 5 betroffen sind [7].

Wie prüfe ich, ob meine Website betroffen ist?

Entscheidend ist die PHP-Version samt Laufzeitumgebung. Genannt werden PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed [7].

Die Versionsnummer allein genügt nicht. Ubuntu 26.04, 24.04 und 22.04 waren am 23.10.2026 laut HostSpezial gepatcht (USN-8948-1), jeweils unter der alten PHP-Versionsnummer [6]. Eine ältere Nummer kann also trotzdem einen gepatchten Stand bedeuten. Prüfen Sie deshalb den Paketstand Ihrer Distribution.

Schritte zur Einordnung:

1. PHP-Version und Laufzeitumgebung jedes Servers und jedes Containers ermitteln.
2. Bei Distributionspaketen den Paketstand statt nur die Nummer prüfen.
3. Bei gemieteten Angeboten den Hoster nach dem Patchstand fragen.
4. Netzwerkgeräte nicht vergessen, siehe unten.

Muss ich selbst patchen oder macht das mein Hoster?

Das hängt vom Angebot ab. Automatische Updates greifen laut digitec nicht, die Patches müssen manuell auf dem Server eingespielt werden [8]. Wer Webspace oder einen verwalteten Server mietet, sollte beim Hoster nachfragen, ob und wann gepatcht wurde.

Bei eigenen Servern gilt:

• Plesk: Laut HostSpezial liefert Plesk gepatchte Pakete für alle mitgelieferten Versionen [6].
• Docker: Container müssen neu gebaut werden [7].
• Neustart: Nach dem Patch sind laut TuxCare alle PHP-Worker neu zu starten [9].
• Ältere Versionen: Für 7.4, 8.0 und 8.1 kommen die Backports des PHP-Sicherheitsteams infrage [5][8][6].

Helfen Übergangslösungen und Extended Support?

Nur begrenzt. Die php.ini-Einstellungen verkleinern laut HostSpezial lediglich die Angriffsfläche. Das PHP-Projekt hält die Installation damit nicht für sicher [6]. Sie überbrücken Zeit, ersetzen den Patch aber nicht.

Für ausgelaufene Versionen bieten Anbieter wie TuxCare kommerzielle Pflege an (Extended Lifecycle Support, ELS) [9]. Das ist ein werbliches Angebot. Es kann eine Option sein, wenn ein Upgrade kurzfristig nicht möglich ist. Es bindet Sie aber an einen Anbieter und löst nicht das Problem der veralteten PHP-Version. Prüfen Sie zuerst, ob ein Wechsel auf eine Fix-Version machbar ist.

Gilt das auch für WordPress, Router und Firewalls?

Ja, soweit PHP darunter läuft. WordPress und andere PHP-Anwendungen nutzen die PHP-Version des Servers und sind deshalb mitbetroffen. Ein eigenes Plugin-Update ersetzt den PHP-Patch nicht.

Auch Netzwerkgeräte können betroffen sein. Laut BSI haben immer mehr Hersteller von Netzwerkkomponenten Advisories veröffentlicht, weil PHP teils in ihren Produkten steckt [1]. Greenbone zufolge führt Palo Alto Networks alle Versionen von PAN-OS und Panorama als betroffen. Korrigierte Versionen gab es zum Zeitpunkt der Meldung nicht. Bis dahin empfiehlt der Hersteller, den Zugriff auf die Management-Schnittstelle auf vertrauenswürdige interne IP-Adressen zu beschränken [5].

Wie erkenne ich, ob meine Seite kompromittiert wurde?

Eine belastbare Anleitung dazu liegt bisher nicht vor. Technische Ratgeber nennen Prüfschritte und Härtungsmaßnahmen [5][6]. Gleichen Sie diese mit den Hinweisen Ihres Hosters und der Hersteller ab, bevor Sie sich darauf verlassen.

Bei Verdacht gehört der Vorfall zum Hoster, zur IT-Sicherheit und zur oder zum Datenschutzbeauftragten. Ob und welche Meldepflichten gelten, etwa nach DSGVO oder NIS2, lässt sich nicht pauschal beantworten. Lassen Sie das im Einzelfall prüfen. Dieser Artikel ist keine Rechtsberatung.

Grenzen und offene Fragen

• Technische Ursache: Ein Datenschutzblog nennt Speicherfehler [7]. Die BSI-Warnung nennt die Ursache nicht [1].
• Datenlage: Das BSI leitet die Gefahr aus den CVSS-Werten ab, Details waren zur Vorab-Warnung knapp [1]. Die Versionsangaben stammen von Hostern, Sicherheitsanbietern und dem BSI [1][5][6][2].
• Angriffe in Deutschland: Das BSI meldete bis 22.10.2026 keine erfolgreiche Ausnutzung in der Breite [1]. Bestätigte Kompromittierungen in Deutschland sind nicht bekannt. Auch die Zahl der abgeschalteten Seiten hierzulande ist offen.
• Rechtspflichten: Zu Meldungen nach DSGVO oder NIS2 gibt es hier keine gesicherte Aussage.

Die Lage kann sich schnell ändern. Die BSI-Warnung [1] wird fortlaufend relevant bleiben.

Fazit: Was Betreiber jetzt tun sollten

Prüfen Sie PHP-Version und Laufzeitumgebung, patchen Sie auf eine Fix-Version oder einen Backport [5][8], bauen Sie Container neu [7] und starten Sie die PHP-Worker neu [9]. Fragen Sie Hoster und Hersteller von Netzwerkgeräten nach Advisories [1][5]. Behandeln Sie php.ini-Einstellungen nur als Übergang [6].

Mit KI-Unterstützung recherchiert und geschrieben, fachlich geprüft von Hannes Ftuni am 25. Oktober 2026. Herausgeber: Heisenberg IT GmbH, Bochum.