PHP2Shell: Wer kümmert sich eigentlich um das PHP auf Ihrer Webseite?

Offizielle Warnung des BSI: Cybersicherheitswarnung „PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit“ (Bundesamt für Sicherheit in der Informationstechnik, 21.10.2026). Das BSI ruft dazu auf, die Patches unverzüglich zu installieren. Auch die tagesschau berichtet über die Lücke und ihre Folgen.

Seit heute Nachmittag gibt es die Korrektur für zwei kritische Lücken in PHP, der Programmiersprache, auf der ein Großteil aller Webseiten, Shops und Webanwendungen läuft. Über die Lücken lässt sich mit einer einzigen präparierten Anfrage Code auf dem Server ausführen. Ein Exploit ist bereits im Umlauf.

Das Update selbst ist schnell eingespielt. Die schwierigere Frage lautet in vielen Unternehmen und Kommunen: Wer kümmert sich eigentlich um das PHP auf unserer Webseite – und auf all den anderen Systemen, von denen niemand weiß, dass sie PHP verwenden?

Was passiert ist

Am Abend des 20. Oktober kündigte das PHP-Sicherheitsteam ein außerplanmäßiges Update für zwei kritische Lücken an. Zu diesem Zeitpunkt waren Details bereits durchgesickert, was die Veröffentlichung beschleunigt hat. Das BSI warnte am Nachmittag des 21. Oktober mit der zweithöchsten Stufe. Kurz vor dem angekündigten Termin um 16 Uhr erschienen die korrigierten Versionen samt Sicherheitshinweisen.

Beide Lücken stecken im Kern von PHP, nicht in WordPress, Shopware oder einem Plugin. Betroffen sind laut PHP-Team alle Versionen seit PHP 5 und alle gängigen Betriebsarten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Projekt bei mod_php, weil dort ein Angriff nachgewiesen wurde, der greift, bevor überhaupt Code der Anwendung läuft. Technisch beschädigt PHP bei der einen Lücke seinen Speicher, wenn eine Anfrage das Speicherlimit erreicht. Bei der anderen bleiben Daten einer Anfrage im Speicher zurück, obwohl sie bereits freigegeben wurden – bestätigt unter anderem für die Upload-Fortschrittsanzeige, die in der Standardkonfiguration eingeschaltet ist. Ein Angriff braucht nur eine gewöhnliche Formular- oder Upload-Anfrage.

Das Video der Entdecker, das den Angriff auf einen Laravel-Server zeigt, ist im Beitrag von heise online zu php2shell eingebunden. Es zeigt eindrücklich, wie wenig Aufwand ein Angriff erfordert.

Die eigentliche Frage: Wer ist zuständig?

Die wenigsten Unternehmen und Kommunen betreiben ihren Webserver selbst. Die Webseite liegt bei einem Hoster, der Shop bei einer Agentur, das Bürgerportal bei einem kommunalen Dienstleister. Das ist sinnvoll – aber nur, wenn klar geregelt ist, wer bei einer Lücke wie dieser handelt. In der Praxis sehen wir häufig, dass sich jeder auf den anderen verlässt: Der Kunde auf die Agentur, die Agentur auf den Hoster, der Hoster auf den Kunden, der ja „seine“ PHP-Version selbst ausgewählt hat.

Den Verlauf dokumentiert Hetzner auf seiner Statusseite zu den PHP-Sicherheitslücken. Vergleichbare Statusmeldungen gibt es bei den meisten großen Hostern – ein Blick dorthin ist der schnellste Weg zu erfahren, ob Ihre Webseite bereits geschützt ist.

Ihre Webseite ist plötzlich nicht erreichbar oder Formulare funktionieren nicht? Zahlreiche Hoster haben vorsorglich reagiert: Einige haben PHP-Dienste ihrer Kunden vollständig pausiert, bis das Update eingespielt ist, andere sperren Datei-Uploads über Webseiten oder haben zusätzliche Schutzregeln aktiviert. Kontaktformulare mit Anhang, Bewerbungsportale oder Upload-Funktionen in Shops können deshalb gerade ausfallen. Eine Wartungsseite oder Fehlermeldung bedeutet in diesen Tagen meist eine Schutzmaßnahme und keinen Angriff. Schauen Sie auf der Statusseite oder im Kundenbereich Ihres Hosters nach oder fragen Sie dort direkt nach.

Wo PHP läuft, ohne dass es jemand weiß

Die Firmenwebseite ist meist bekannt. Kritischer sind Systeme, die auf PHP laufen, ohne dass das jemandem bewusst ist: Webmail-Oberflächen wie Roundcube, ein altes Intranet oder Wiki, Ticket- und Zeiterfassungssysteme, Monitoring-Werkzeuge und Testinstallationen, die ein Dienstleister einmal aufgesetzt hat. Dazu kommen NAS-Systeme, Appliances und Router mit eigener Weboberfläche, ebenso Steuerungen in Haus- und Gebäudetechnik, Telefonanlagen oder Kamerasystemen. Auch heise online rät ausdrücklich, solche Geräte zu überprüfen. Sie bekommen oft nur langsam oder gar keine Updates und hängen nicht selten über eine alte Portfreigabe direkt im Internet. Wie schnell solche Systeme in Vergessenheit geraten, haben wir zuletzt am Beispiel AnyDesk und im Beitrag „Fahrlässig ab Werk“ beschrieben.

Was jetzt zu tun ist

1. Systeme mit PHP auflisten: Webseite, Shop, Portale und alle internen Anwendungen mit Weboberfläche. Im Zweifel beim jeweiligen Dienstleister nachfragen.
2. Zuständigkeit klären und nachfragen: Bei Hostern, Agenturen und Dienstleistern aktiv nachfragen, ob und wann auf die korrigierte Version aktualisiert wurde. Eine schriftliche Antwort hilft auch später, etwa gegenüber dem Datenschutzbeauftragten.
3. Eigene Server aktualisieren: Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. auf die gepatchten Pakete der Distribution. Danach PHP-FPM oder den Webserver neu starten, sonst läuft weiter die alte Version im Speicher.
4. Plugin-Updates reichen nicht: Die Lücke sitzt in PHP selbst. Updates von WordPress, Joomla, Shopware oder deren Erweiterungen ändern daran nichts.
5. Alte PHP-Versionen ernst nehmen: Für PHP 8.1 und älter gibt es nur Quellcode-Korrekturen, keine fertigen Updates. Wie verbreitet das Problem ist, zeigt eine Zählung der Sicherheitsfirma Mallory: Am 20. Oktober meldeten rund 884.000 Server im Internet eine PHP-Version 8.1 oder älter – 59 Prozent aller Server, die überhaupt eine Versionsangabe machten. Weitere 740.000 gaben keine Version preis. Solche Systeme sollten jetzt auf eine unterstützte Version gehoben, über erweiterte Wartung der Distribution oder des Hosters versorgt oder vom Netz genommen werden.
6. Auf Spuren prüfen – ab dem 20. Oktober: Angriffe liefen bereits vor dem Patch, unmittelbar nach dem Leak. Wer am 20. und 21. Oktober ungepatchte Systeme im Netz hatte, sollte sie deshalb unbedingt prüfen und nicht nur aktualisieren. Ein Angriff erfordert typischerweise tausende Anfragen: Auffällig viele POST-Anfragen einer einzelnen IP-Adresse in kurzer Zeit in den Webserver- oder WAF-Protokollen sind ein deutliches Warnsignal. Ein typisches Zeichen eines erfolgreichen Angriffs sind außerdem ungewöhnliche Kindprozesse der PHP- oder Webserver-Prozesse, etwa eine Shell unter php-fpm, apache2 oder php-cgi.exe, sowie neue oder veränderte PHP-Dateien im Webverzeichnis.

php -v

# Version von PHP-FPM, z. B. fuer 8.3
php-fpm8.3 -v

# Installierte Zweige (Debian, Ubuntu)
ls /etc/php/

sudo apt update
sudo apt install --only-upgrade 'php8.3-*'
sudo systemctl restart php8.3-fpm

apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'

ps -eo pid,ppid,user,lstart,cmd --forest | grep -B1 -A3 -E 'php-fpm|php-cgi|apache2|httpd'

Dauerhafte Überwachung ohne Endpoint-Schutz: Für Linux-Server ohne EDR-Lösung hat der Sicherheitsforscher Florian Roth mit dem process-watcher ein Werkzeug veröffentlicht, das jedes Programm protokolliert, das ein PHP-Prozess startet – samt Befehlszeile. Es dient der Erkennung, nicht dem Schutz: Ein Programm wird erst nach dem Start sichtbar, verhindert wird nichts. Als zusätzliches Frühwarnsystem bis zum Update ist es aber hilfreich.

Get-ChildItem -Path C:\, D:\ -Filter php.exe -Recurse -ErrorAction SilentlyContinue |
    Select-Object FullName, @{ n = 'Version'; e = { $_.VersionInfo.ProductVersion } }

Import-Module WebAdministration
Get-WebConfiguration system.webServer/fastCgi/application |
    Select-Object fullPath, arguments

# In der jeweiligen php.ini eintragen bzw. aendern:
session.upload_progress.enabled = 0

# Danach IIS neu starten
iisreset

# Oder Apache neu starten (z. B. XAMPP), Dienstname anpassen
Restart-Service Apache2.4

Wenn das Update nicht sofort möglich ist

PHP nennt als Übergangslösung, die Upload-Fortschrittsanzeige mit session.upload_progress.enabled = 0 in der php.ini oder im FPM-Pool abzuschalten und alle Worker neu zu starten. Eine Einstellung per ini_set() greift zu spät. Viele Hoster haben das bereits global gesetzt. Bei PHP-FPM verkürzt ein niedriger Wert für pm.max_requests zusätzlich, wie lange ein manipulierter Zustand in einem Worker überlebt – auf Kosten der Leistung. Wichtig: Diese Maßnahmen reichen nicht aus. Ein Sicherheitsforscher hat inzwischen eine Analyse mit Proof-of-Concept-Code veröffentlicht, nach der das Abschalten der Upload-Fortschrittsanzeige nicht alle Angriffswege schließt. Vollständig schützt nur das Update. Wo es noch nicht möglich ist, bleibt nur die Sperre des Zugriffs aus dem Internet.

Wer eine Anwendung nicht sofort aktualisieren kann, weil der Hersteller noch kein Update liefert, sollte sie bis dahin aus dem Internet nehmen oder nur noch über VPN bzw. bekannte IP-Adressen erreichbar machen. Die Anmeldung der Anwendung selbst schützt hier nicht, weil die Lücke greift, bevor die Anwendung überhaupt startet. Genau so sind wir auch selbst vorgegangen: Unser eigenes Ticketsystem basiert auf PHP, der Hersteller hat noch kein Update bereitgestellt. Wir haben den Zugang aus dem Internet deshalb am Abend des 21. Oktober an der Firewall gesperrt. Intern und über VPN läuft es weiter, freigeschaltet wird es erst wieder mit dem Update. Das ist unbequem, aber die einzige wirksame Maßnahme, solange es keinen Patch gibt.

Für Einkäufe im Internet in den nächsten Tagen

Das größte Risiko tragen derzeit die Shopbetreiber. Auf kompromittierten Shops können Angreifer aber Zahlungs- und Zugangsdaten abgreifen, vor allem bei kleineren Shops mit veralteter Technik. Einen pauschalen Verzicht auf Online-Einkäufe halten wir nicht für nötig. Mit wenigen Vorsichtsmaßnahmen, die auch für Firmeneinkäufe gelten, lässt sich das Risiko deutlich senken:

• Zahlungsart mit Bedacht wählen: Möglichst Verfahren nutzen, bei denen Kartendaten nicht im Shop selbst eingegeben werden, etwa PayPal, Kauf auf Rechnung oder die Weiterleitung zum Zahlungsanbieter.
• Eigenes Passwort je Shop: Wird ein Shop kompromittiert, bleiben die anderen Konten sicher.
• Links in Shop-Mails misstrauen: Mails zu Bestellungen, Lieferungen oder angeblichen Problemen mit dem Kundenkonto besonders kritisch prüfen. Den Shop lieber direkt im Browser aufrufen.
• Abrechnungen kontrollieren: Kontoauszüge und Kreditkartenabrechnungen in den nächsten Wochen aufmerksam durchsehen und Unstimmigkeiten sofort bei der Bank melden.

Einordnung

Technisch ist die Lösung einfach: aktualisieren, neu starten, fertig. Schwierig wird es dort, wo niemand genau weiß, welche Systeme betroffen sind und wer sie betreut. Genau diese Frage sollten Unternehmen und Kommunen jetzt klären – nicht nur für diese Lücke, sondern für die nächste. Wie schnell Angreifer öffentliche Exploits heute nutzen, zeigt unser Beitrag zur negativen Time-to-Exploit.

Warum solche Lücken gerade jetzt gefunden werden

Dass ein Fehler nach rund 20 Jahren entdeckt wird, ist kein Zufall. An der Entdeckung von PHP2Shell waren laut BSI die Sicherheitsfirmen Wiz und Calif gemeinsam mit OpenAI beteiligt. KI-Modelle durchsuchen Quellcode inzwischen in einem Tempo und einer Tiefe nach Schwachstellen, das für Menschen allein nicht erreichbar ist. Das betrifft nicht nur PHP: Auch Modelle wie Claude Mythos von Anthropic finden nach Angaben des Herstellers Tausende schwerwiegende Lücken, weshalb Bankenaufsicht und Notenbanken bereits vor den Folgen für das Finanzsystem warnen – die tagesschau berichtet darüber. Für Verteidiger ist das eine Chance, weil Lücken früher gefunden und geschlossen werden. Es bedeutet aber auch: Wir müssen uns auf mehr und schnellere Sicherheitsupdates einstellen, und auf Angreifer, die dieselben Werkzeuge nutzen. Wer seine Systeme kennt und zügig patchen kann, ist klar im Vorteil.

Quellen & weiterführende Links

• Bundesamt für Sicherheit in der Informationstechnik (BSI)

  Cybersicherheitswarnung: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit (21.10.2026)
• tagesschau

  Bericht zur PHP-Lücke (21.10.2026)
• heise online

  php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP (21.10.2026)
• Hetzner Online

  Statusmeldung: PHP Sicherheitslücken CVE-2026-109618 und CVE-2026-109619
• dpa-AFX via finanzen.net

  Baden-Württemberg: Shutdown im Netz – Regierung geht vorsorglich offline (21.10.2026)
• Stuttgarter Nachrichten

  Angriffe befürchtet: Universitäten im Südwesten gehen wegen Sicherheitslücken offline (21.10.2026)
• Stuttgarter Zeitung

  PHP2Shell: Welche Webseiten sind von der PHP-Lücke betroffen?
• Marzahn-Hellersdorf LIVE

  Kritische PHP-Lücke „PHP2Shell“: Charité, Feuerwehr und zahlreiche weitere Seiten offline
• Pasquale Pillitteri

  PHP2Shell: Niederlande und Finnland nehmen Staatsseiten vor dem Patch vom Netz
• t-online

  Gravierende Sicherheitslücke: Städte nehmen Online-Dienste vom Netz
• cms-admins.de

  php2shell: PHP-Notfall-Patch 21.10., Check & Sofortmaßnahme (laufend aktualisiert)
• ma.ttias.be

  PHP CVE-2026-109618 and CVE-2026-109619: early mitigation steps
• CERT.at

  Bevorstehendes kritisches PHP-Sicherheitsupdate

Recherchestand: 21. Oktober 2026, abends. Die Lage entwickelt sich weiter.