PHP2Shell: Kritische PHP-Sicherheitslücke – was du jetzt tun musst

Am 21.10.2026 hat das BSI vor zwei kritischen Sicherheitslücken in PHP gewarnt, die unter dem Namen „PHP2Shell“ bekannt sind (CVE-2026-109618 und CVE-2026-109619). Betroffen ist laut BSI jede PHP-Installation, die Webanfragen verarbeitet, also auch Websites mit WordPress, TYPO3, Drupal, Joomla, Magento oder Nextcloud. Du musst PHP selbst auf eine gepatchte Version aktualisieren, ein Update deiner Website-Software allein reicht nicht.

Kurz gesagt:

• Zwei PHP-Lücken mit CVSS 9.2 erlauben es Angreifern womöglich, ohne Login Code auf deinem Webserver auszuführen.
• Gepatcht sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, für ältere Versionen gibt es Backports von Distributionen und LTS-Anbietern.
• Das BSI stuft die Lage als Kritikalität 3 / Orange ein: Maßnahmen müssen unverzüglich ergriffen werden.

Was ist PHP2Shell?

PHP2Shell ist der Sammelname für zwei Schwachstellen in der PHP-Laufzeitumgebung. Der Name lehnt sich laut BSI an die Lücke „Log4Shell“ aus dem Jahr 2021 an und soll die Ähnlichkeit deutlich machen: Eine weit verbreitete Basistechnologie ist betroffen, und Angreifer können aus der Ferne Code ausführen.

Das BSI hat die Warnung am 21.10.2026 als IT-Sicherheitshinweis veröffentlicht und am selben Tag in Version 1.1 aktualisiert. Die Einstufung lautet Kritikalität 3 / Orange. Das bedeutet nach BSI-Definition: Maßnahmen müssen unverzüglich ergriffen werden, eine massive Beeinträchtigung des Regelbetriebs ist möglich.

Die zwei Schwachstellen im Überblick

Laut dem Security Advisory auf php.net steckt hinter den beiden CVEs Folgendes:

• CVE-2026-109618 – Codeausführung durch Speicherfehler (OOM-Korruption): Läuft PHP in einen Out-of-Memory-Zustand, kann die Verarbeitung abbrechen, während interne Anfragedaten nur teilweise initialisiert sind. Beim Aufräumen werden diese ungültigen Daten dann womöglich als gültig behandelt.
• CVE-2026-109619 – Codeausführung durch veralteten globalen Zustand: Interne Daten einer Anfrage können überleben, obwohl der zugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage im selben Worker-Prozess kann diesen Zustand nutzen, bevor er zurückgesetzt wird.

Beide Lücken sind nach CVSS 4.0 mit 9.2 von 10 bewertet. Aus den Bewertungen leitet das BSI ab, dass für einen Angriff weder ein Login noch eine Aktion eines Nutzers nötig ist. Entdeckt wurden die Schwachstellen unter anderem von den Sicherheitsfirmen Wiz.io und Calif.io gemeinsam mit OpenAI.

Wie ernst ist die Lage?

Zum Zeitpunkt der BSI-Warnung waren noch keine bestätigten Angriffe bekannt. Es gibt aber einen öffentlichen Proof-of-Concept, und in sozialen Medien wird von ersten Angriffsversuchen berichtet, die das BSI noch nicht verifizieren konnte. Das BSI hielt eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für wahrscheinlich und geht inzwischen von einer kurzfristigen Ausnutzung verwundbarer Systeme aus.

Als Grund nennt das BSI auch KI-gestützte Werkzeuge: Angreifer können Patches damit schnell analysieren und daraus Exploits bauen. Einige Betreiber haben ihre PHP-Server vorsorglich vom Internet getrennt, weshalb manche Websites in Deutschland zeitweise nicht erreichbar waren.

Bin ich betroffen?

Die kurze Antwort: sehr wahrscheinlich ja, wenn du eine Website, einen Shop oder eine Web-Anwendung mit PHP betreibst. Laut BSI sind alle bekannten PHP-Versionen bis mindestens PHP 5 verwundbar.

Betroffene Setups

Gefährdet ist jede PHP-Installation, die Webanfragen verarbeitet. Das BSI und das PHP-Team nennen ausdrücklich:

• PHP-FPM
• Apache mit mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

Das höchste Risiko sieht das PHP Security Team bei mod_php. Dort wurde ein Exploit gezeigt, bei dem eine Anfrage ohne Login den Angriff auslöst, bevor überhaupt Code deiner Anwendung läuft.

Auch Software, die du vielleicht nicht sofort mit PHP verbindest, ist betroffen. Das BSI nennt als Beispiele WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud sowie die Firewall-Systeme pfSense und OPNsense. Das niederländische NCSC sammelt auf GitHub eine Liste betroffener Produkte, die laufend erweitert wird.

So prüfst du deine PHP-Version

1. Auf dem eigenen Server: Melde dich per SSH an und führe php -v aus. Das BSI empfiehlt genau diesen Abgleich. Bedenke: Kommandozeile und Webserver können unterschiedliche PHP-Versionen nutzen, wenn mehrere installiert sind. Prüfe deshalb auch die Version, die dein Webserver tatsächlich verwendet.
2. Im Hosting-Paket (z. B. bei IONOS, Strato & Co.): Im Kundenbereich deines Hosters findest du in der Regel die eingestellte PHP-Version deiner Website.
3. Bei Linux-Paketen: Installierst du PHP über die Paketverwaltung deiner Distribution (z. B. apt), steht nach dem Update nicht unbedingt 8.4.27 oder 8.3.36 in der Versionsnummer. Distributionen spielen Fixes oft als Backport ein. Gleiche deine Paketversion deshalb mit dem Advisory deiner Distribution ab, etwa bei Ubuntu, Debian oder Red Hat.
4. Bei Docker-Containern: Container mit PHP müssen laut BSI unabhängig vom Host aktualisiert bzw. neu gebaut werden.

Du kommst nicht an den Server oder bist unsicher, welche Version wirklich läuft? Dann prüfen und patchen wir das für dich – im Paket Patch + Check für 399 € netto, inklusive Kontrolle, ob schon jemand eingedrungen ist.

PHP Server patchen: Schritt für Schritt

Der einzige verlässliche Schutz ist das Update. Das PHP-Projekt hat diese Versionen veröffentlicht:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Für die End-of-Life-Versionen 7.4, 8.0 und 8.1 hat das PHP Security Team Backport-Patches bereitgestellt. Linux-Distributionen und LTS-Anbieter liefern gegebenenfalls Patches für noch ältere Versionen.

So gehst du vor:

1. Backup anlegen. Sichere Dateien und Datenbank, bevor du etwas änderst.
2. PHP aktualisieren. Über die Paketverwaltung deiner Distribution, über deinen Hoster oder durch Neubau deiner Container-Images.
3. Dienste neu starten. Damit die neue Version greift, müssen PHP-FPM bzw. der Webserver neu gestartet werden.
4. Version prüfen. Kontrolliere mit php -v und anhand des Advisories deiner Distribution, ob der Patch wirklich aktiv ist.
5. Website testen. Prüfe, ob Seiten, Formulare, Logins und der Checkout weiterhin funktionieren.

Wichtig: Ein Update von WordPress, Plugins oder Themes berührt PHP nicht. Das BSI schreibt dazu ausdrücklich, dass die zugrundeliegende PHP-Laufzeitumgebung gepatcht werden muss.

Wenn du keinen Serverzugang hast oder dir das Update nicht zutraust, übernehmen wir das. Mit unserem PHP2Shell-Patch-Paket aktualisieren wir PHP zum Festpreis von 299 € netto, inklusive Backup und Kurzprotokoll.

Du kannst nicht sofort patchen?

Dann empfiehlt das BSI, eine vorübergehende Trennung vom Internet zu erwägen. Alle bekannten Workarounds verringern die Angriffsfläche nur, schließen die Lücke aber nicht. Ist beides nicht möglich, solltest du mindestens die Workarounds aus dem PHP-Advisory umsetzen, um eine Ausnutzung zu erschweren. Das BSI betont: Alle Workarounds müssen gemeinsam umgesetzt werden.

Für CVE-2026-109618:

• memory_limit=-1 setzen, möglichst so, dass Anwendungen den Wert nicht überschreiben können (z. B. per php_admin_value im FPM-Pool oder in der Apache-Konfiguration).
• post_max_size niedrig halten: 8M ohne Datei-Uploads, 32M mit Uploads. upload_max_filesize muss darunter liegen.
• Zusätzlich auf Webserver- oder Proxy-Ebene Grenzen für Anfragegröße, Anzahl der Felder, Multipart-Teile, Header und Verschachtelungstiefe erwägen.
• Speichergrenzen auf Container- oder cgroup-Ebene nutzen, aber nicht RLIMIT_AS oder RLIMIT_DATA, da diese den verwundbaren Fehler auslösen können.

Für CVE-2026-109619:

• session.upload_progress.enabled=0 setzen und alle Worker neu starten. Die Einstellung muss über php.ini, den FPM-Pool oder die Serverkonfiguration greifen, nicht über ini_set() oder .user.ini.
• Unter PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und Worker neu starten.
• Ungültige oder veraltete Einstellungen entfernen, die pro Anfrage Diagnosemeldungen erzeugen. Unterdrücken per error_reporting, display_errors oder @ hilft nicht.
• Fatale Fehler und Timeouts beheben, die Angreifer auslösen können, etwa bei Uploads, Importen oder Callbacks.

Eine Web Application Firewall kann zusätzlich helfen. Cloudflare und Bunny Shield haben Regeln gegen bekannte Angriffspfade veröffentlicht. Vollständigen Schutz bietet laut BSI aber nur der Patch.

Logs und Spuren prüfen

Das Update schließt die Tür, verrät dir aber nicht, ob vorher schon jemand drin war. Hier ist Ehrlichkeit wichtig: Laut BSI gibt es noch keine verbindlichen Angriffsindikatoren für PHP2Shell. Im Netz kursierende Indicators of Compromise und Hunting-Anleitungen empfiehlt das BSI ausdrücklich noch nicht verbindlich.

Was du trotzdem tun kannst, ist, deinen Server auf typische Einbruchsspuren zu prüfen, die nach jedem erfolgreichen Angriff auf eine Web-Anwendung auftauchen können:

• Fremde Dateien: neue oder kürzlich geänderte PHP-Dateien in Upload-Ordnern oder im Webroot, die du nicht kennst
• Neue Benutzer: unbekannte Admin-Konten im CMS oder neue Systembenutzer auf dem Server
• Verdächtige Cronjobs: geplante Aufgaben, die du nicht selbst angelegt hast
• Auffällige Logs: ungewöhnliche Anfragen, Fehlerhäufungen oder Abstürze von PHP-Workern im Zeitraum rund um den 21.10.2026

Beobachte exponierte PHP-Webserver in den nächsten Tagen verstärkt, wie es das BSI empfiehlt. Das NCSC-NL stellt in seinem GitHub-Repository einen Bereich zu Erkennung und Gegenmaßnahmen bereit, der weiter ausgebaut wird.

Im Paket Patch + Check für 399 € netto übernehmen wir genau diese Prüfung auf Einbruchsspuren, härten den Server mit Firewall-Regeln und überwachen ihn 30 Tage lang.

Was tun, wenn dein Server schon kompromittiert ist?

Findest du Spuren eines Einbruchs, gilt: Ruhe bewahren, aber nicht einfach weitermachen. Ein Patch allein entfernt keinen Angreifer, der sich bereits eingenistet hat.

1. System isolieren. Nimm den betroffenen Server vom Netz oder schalte die Website in den Wartungsmodus, damit kein weiterer Schaden entsteht.
2. Beweise sichern. Lösche nicht vorschnell verdächtige Dateien oder Logs. Sie werden gebraucht, um zu verstehen, was passiert ist.
3. Zugangsdaten ändern. Passwörter für Server, Datenbank, CMS und Hosting-Konto sollten neu gesetzt werden, idealerweise von einem sauberen Gerät aus.
4. Sauber neu aufsetzen. Oft ist ein Neuaufbau aus einem Backup von vor dem Einbruch sicherer als das Bereinigen eines kompromittierten Systems.
5. Datenschutz prüfen. Wurden personenbezogene Daten abgegriffen, können Meldepflichten bestehen. Hol dir dazu rechtlichen Rat.

Bei akutem Verdacht hilft dir unsere Notfallhilfe bei Hacks. Für mehrere Server, sehr alte PHP-Versionen oder einen konkreten Einbruch gibt es das Paket „Individuell“ auf Anfrage.

Langfristig: PHP aktuell halten

PHP2Shell zeigt ein strukturelles Problem: Laut BSI haben alle PHP-Versionen vor 8.2 ihr End-of-Life erreicht, und PHP 8.2 erhält nur noch bis Jahresende Sicherheitsupdates. Das BSI empfiehlt, grundsätzlich auf eine noch unterstützte PHP-Version zu migrieren.

Darüber hinaus rät das BSI:

• den Zugriff auf Webanwendungen so restriktiv wie möglich zu gestalten,
• die eingesetzten Komponenten umfassend zu härten,
• ergänzend Web Application Firewalls einzusetzen,
• auf Linux SELinux oder AppArmor zu nutzen, um die Folgen solcher Lücken zu begrenzen.

Aus unserer Erfahrung bei der Betreuung von Kundenservern ist das größte Risiko selten die einzelne Lücke, sondern der Server, um den sich niemand kümmert. Wer Updates regelmäßig einspielt und Systeme überwacht, kann in einer Lage wie dieser schnell reagieren statt hektisch zu suchen. Genau das übernehmen wir mit unserer laufenden IT-Betreuung.

Fazit

PHP2Shell ist ernst, aber beherrschbar. Prüfe heute deine PHP-Version, spiel den Patch ein und kontrolliere deinen Server auf Auffälligkeiten. Wenn du Unterstützung brauchst, buche ein Festpreis-Paket oder schreib uns direkt. Wir patchen werktags meist noch am selben Tag.

Quellen

• BSI-IT-Sicherheitshinweis „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Version 1.1 vom 21.10.2026
• PHP Security Advisory: Critical remote code execution vulnerabilities, update now (php.net)
• GitHub Advisory CVE-2026-109618 – RCE via OOM corruption (php-src)
• GitHub Advisory CVE-2026-109619 – RCE via stale global state (php-src)
• CERT-EU Security Advisory 2026-018 – Critical Vulnerabilities in PHP
• NCSC-NL: php2shell auf GitHub
• Ubuntu Security: CVE-2026-109618
• Debian Security Tracker: CVE-2026-109618

Häufige Fragen

Was ist PHP2Shell?

PHP2Shell ist der Spitzname für die zwei kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619. Beide sind mit CVSS 9.2 bewertet und können es Angreifern ermöglichen, ohne Login Code auf Webservern mit PHP auszuführen.

Welche PHP-Versionen sind von PHP2Shell betroffen?

Laut BSI sind alle bekannten PHP-Versionen bis mindestens PHP 5 verwundbar. Behoben ist die Lücke in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35; für 7.4, 8.0 und 8.1 gibt es Backport-Patches.

Reicht ein Update von WordPress oder meinen Plugins?

Nein. Die Lücke steckt in der PHP-Laufzeitumgebung selbst. Ein Update der Anwendung reicht laut BSI nicht, PHP auf dem Server oder im Hosting muss ebenfalls gepatcht werden.

Schützt eine Web Application Firewall vor PHP2Shell?

Nur teilweise. Anbieter wie Cloudflare oder Bunny Shield haben Regeln gegen bekannte Angriffspfade veröffentlicht, vollständigen Schutz bietet laut BSI aber nur das Patchen oder die Trennung vom Internet.

Wie erkenne ich, ob mein Server schon angegriffen wurde?

Verbindliche Angriffsindikatoren gibt es laut BSI noch nicht. Prüfe deshalb auf typische Einbruchsspuren wie unbekannte PHP-Dateien, neue Admin-Konten oder fremde Cronjobs und beobachte deine Logs genau.