PHP2Shell: Kritische PHP-Sicherheitslücken und was Websitebetreiber jetzt tun sollten

IT-Sicherheit

Veröffentlicht am 22. Oktober 2026

aktualisiert am 29. Oktober 2026

7 Min. Lesezeit

Inhalt

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen in der PHP-Laufzeit veröffentlicht. Sicherheitsforscher und Behörden sprechen von PHP2Shell, in Anlehnung an Log4Shell. Die Lücken CVE-2026-109618 und CVE-2026-109619 ermöglichen es Angreifern unter bestimmten Bedingungen, ohne Anmeldung Code auf dem Webserver auszuführen.

Betroffen ist nicht ein einzelnes Content-Management-System, sondern PHP selbst. Damit geht die Meldung praktisch jeden an, der eine Website mit WordPress, einem Onlineshop oder einer anderen PHP-Anwendung betreibt. Dieser Beitrag fasst zusammen, was bekannt ist, welche Versionen abgesichert sind, wo Schutzmaßnahmen an Grenzen stoßen und was Sie konkret tun sollten. Stand der Angaben: 29. Oktober 2026.

Was hinter PHP2Shell steckt

Beide Schwachstellen betreffen die Speicherverwaltung zwischen einzelnen Web-Anfragen. Laut den Sicherheitshinweisen des PHP-Projekts verhalten sie sich so:

  • CVE-2026-109618 („RCE via OOM corruption“): Läuft PHP während einer Anfrage in einen Speicherfehler (Out of Memory), kann teilweise initialisierter Speicher beim Aufräumen ungültige Daten verarbeiten. Auslösen lässt sich das unter anderem über manipulierte Multipart-Anfragen, also das Format, in dem Formulare und Datei-Uploads übertragen werden. Bestätigte Folge ist eine Codeausführung mit den Rechten des Webserver-Kontos.
  • CVE-2026-109619 („RCE via stale global state“): Zustandsdaten einer Anfrage bleiben nach deren Ende im PHP-Prozess erreichbar und werden von einer späteren Anfrage weiterverwendet (Use-after-free). Folgen sind Speicheroffenlegung und Codeausführung. Ein bekannter Weg führt über die standardmäßig aktive Funktion „Session Upload Progress“.

Das PHP-Projekt bewertet beide Lücken nach CVSS 4.0 mit 9.2 (kritisch). Die US-Schwachstellendatenbank NVD vergibt nach CVSS 3.1 die Werte 9.8 bzw. 8.1. Weder Anmeldung noch Mitwirkung eines Nutzers sind nötig.

Betroffene PHP-Versionen und Sicherheitsupdates

Laut php.net sind alle PHP-Installationen betroffen, die Web-Anfragen bedienen, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Projekt bei mod_php, wo ein Angriff demonstriert wurde, der greift, bevor überhaupt Anwendungscode läuft.

PHP-Zweig Abgesicherte Version Hinweis
8.5 8.5.12 aktiv unterstützt
8.4 8.4.27 aktiv unterstützt
8.3 8.3.36 Sicherheitsupdates bis Ende 2027
8.2 8.2.35 Support endet am 31. Dezember 2026
8.1 und älter kein offizielles Release Support beendet, nur Quellcode-Backports

Für PHP 8.1, 8.0 und 7.4 gibt es nur Quellcode-Korrekturen, aber keine offiziellen Releases. Einige Linux-Distributionen liefern eigene, gepatchte Pakete aus. Dabei kann die angezeigte PHP-Versionsnummer gleich bleiben, maßgeblich ist dann die Paketversion der Distribution.

Beobachtete Ausnutzung: Angriffe schon vor der Veröffentlichung

Amazon Threat Intelligence hat den ersten Ausnutzungsversuch bereits am 17. Oktober 2026 in einem Honeypot beobachtet, also vier Tage vor der offiziellen Veröffentlichung. Ab dem 21. Oktober, nachdem erste Proof-of-Concept-Exploits kursierten, folgten weitere Versuche mehrerer Akteure. Amazon beschreibt ausdrücklich Versuche; ob sie auf realen Systemen erfolgreich gewesen wären, bleibt laut Amazon unklar.

Die US-Behörde CISA hat beide Lücken am 26. Oktober 2026 in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen. Auf seiner Lageseite gibt das BSI Medienberichte wieder (zuletzt vom 25. Oktober 2026), nach denen Angriffsversuche im zweistelligen Millionenbereich registriert wurden. Eine großflächige Ausnutzung und erfolgreiche Angriffe mit Datenabfluss waren in Deutschland danach bis dahin nicht bekannt.

Für mich zeigt der Fall vor allem eines: Bei öffentlich erreichbaren Systemen bleibt zwischen Bekanntwerden und Angriff oft kaum Zeit. Ein Update, das erst mit dem nächsten monatlichen Wartungstermin eingespielt wird, kommt in solchen Fällen zu spät.

Grenzen von Schutzmaßnahmen und Workarounds

Das PHP-Projekt stellt klar: Es gibt keine vollständige Absicherung außer dem Update. Die veröffentlichten Workarounds senken das Risiko nur teilweise, etwa:

  • session.upload_progress.enabled=0 in der php.ini oder Pool-Konfiguration (nicht per ini_set()), danach alle PHP-Prozesse neu starten
  • niedrigere Grenzwerte für post_max_size und Request-Größen am Webserver oder Proxy
  • Multipart-Anfragen am Frontend blockieren, wenn keine Uploads nötig sind

Der letzte Punkt ist für WordPress meist keine Option, weil Medien-Uploads im Backend und viele Formulare genau dieses Format nutzen. Auch eine Web Application Firewall (WAF) hilft nur begrenzt. Ein großer Cloud-Anbieter weist in seiner Anleitung zu eigenen WAF-Regeln gegen PHP2Shell darauf hin, dass die Firewall weder den Speicherzustand der PHP-Prozesse noch die Serverkonfiguration sieht und das Risiko bei Anwendungen mit Datei-Uploads nur senkt, die Lücke aber nicht schließt. CISA empfiehlt, PHP-Systeme vom Netz zu nehmen, wenn sie nicht sofort aktualisiert werden können oder auf PHP 8.1 und älter laufen. Das BSI nennt bei einer Bedrohung als Überbrückung bis zum Update eine WAF mit passenden Regeln oder die vorübergehende Trennung betroffener Websites vom Internet.

Loganalyse und Monitoring: Woran Sie Angriffe erkennen

Weil die ersten Versuche vor der Veröffentlichung lagen, sollten rückwirkende Prüfungen mindestens ab dem 17. Oktober 2026 ansetzen. Hinweise auf Angriffe oder eine Kompromittierung können sein:

  • POST-Anfragen mit Datei-Upload, die die Zeichenkette PHP_SESSION_UPLOAD_PROGRESS enthalten
  • ungewöhnliche Multipart-Anfragen mit anschließenden Speicherfehlern oder gehäuften HTTP-500-Antworten
  • unerklärliche Neustarts von PHP-Prozessen sowie unerwartete Prozessstarts auf dem Webserver
  • neue oder veränderte PHP-Dateien, insbesondere mögliche Webshells

Amazon nennt sechs IP-Adressen aus den beobachteten Versuchen: 103[.]216[.]220[.]92 (17.10.), 31[.]223[.]184[.]166, 37[.]19[.]200[.]5, 134[.]209[.]159[.]64, 103[.]114[.]163[.]188 und 95[.]217[.]98[.]37 (jeweils 21.10.). Darunter sind laut Amazon Adressen gemeinsam genutzter Anonymisierungsdienste, die nicht ausschließlich für diese Angriffe verwendet werden. Treffer sollten daher untersucht statt pauschal blockiert werden.

Wichtig: Ein unauffälliges Log beweist keine Sicherheit. Für eine dauerhafte Überwachung lohnt ein Blick auf eine strukturierte Angriffserkennung, die Auffälligkeiten auf Servern zeitnah meldet.

Was heißt das für meine Website?

Die Lücke steckt in PHP, nicht in WordPress. Ein Update von WordPress, Plugins oder Themes behebt sie deshalb nicht. Sicherheitsforscher haben eine Codeausführung ohne Anmeldung unter anderem gegen das zum Testzeitpunkt aktuelle offizielle WordPress-Container-Image demonstriert, ganz ohne Schwachstelle in der Anwendung selbst.

  • Shared Hosting: Hier entscheidet in der Regel der Hoster über PHP-Version und Patchstand. Fragen Sie nach, ob die Updates eingespielt sind, so empfiehlt es auch das BSI.
  • Eigener Server oder VPS: Sie sind selbst zuständig. Aktualisieren Sie PHP sofort und starten Sie alle PHP-Dienste neu.
  • Veraltete PHP-Version: Läuft Ihre Website noch auf PHP 8.1 oder älter, ist ein Umstieg auf einen unterstützten Zweig überfällig.

Wer die Pflege nicht selbst übernehmen möchte, findet bei der WordPress-Wartung und beim Hosting von Unique-Webdesign Unterstützung beim Patchstand.

Weitere PHP-Hinweise seit dem 23. Oktober

Getrennt von PHP2Shell hat das PHP-Projekt zwei weitere Hinweise veröffentlicht:

  • CVE-2026-115560 (Session Upload Progress): ein „Informational Advisory“ vom 23. Oktober 2026. Ausnutzbar ist die Lücke laut php.net nur in einer ungewöhnlichen Kombination von Session-Einstellungen. Ein Fix steht noch aus (Stand 29. Oktober 2026), das vollständige Advisory soll mit dem nächsten regulären Release folgen. Als Abhilfe nennt php.net ebenfalls session.upload_progress.enabled=0.
  • CVE-2026-111497 (Brotli, nur Windows-Builds): ein Fehler in der Brotli-Dekompression, erreichbar über die cURL-Erweiterung in PHP-Builds für Windows, wenn die automatische Dekompression von HTTP-Antworten aktiviert ist (in cURL standardmäßig aus, Anwendungen können sie aber einschalten). Am 26. Oktober 2026 erschienen neu gebaute Windows-Pakete (z. B. 8.3.36-1), die PHP-Versionsnummern blieben gleich.

Was Sie jetzt tun können

  1. PHP-Version prüfen: 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 bzw. neuer. Bei Distributionspaketen die Paketversion prüfen.
  2. Hoster anfragen, wenn Sie keinen eigenen Server betreiben, und die Antwort dokumentieren.
  3. Sofort patchen und PHP-Prozesse neu starten. Wo das nicht möglich ist: Workarounds setzen und eine Abschaltung abwägen.
  4. Logs ab 17. Oktober 2026 auswerten, verdächtige Treffer untersuchen, Dateisystem auf neue PHP-Dateien prüfen.
  5. Session Upload Progress deaktivieren, wenn die Funktion nicht genutzt wird, auch nach dem Patch.
  6. Prozesse nachschärfen: Wer ist zuständig, wie schnell wird bei kritischen Lücken reagiert, wer wird informiert?

Für Unternehmen, die unter NIS2 fallen, gehört das zu den Pflichten im Schwachstellenmanagement; mehr dazu im Beitrag zu NIS2-Pflichten für Unternehmen. Wie KI Angriffe beschleunigt, beschreibt der Beitrag zu KI-spezifischen Bedrohungen.

Fazit

PHP2Shell betrifft die Grundlage sehr vieler Websites. Das Update ist die einzige vollständige Maßnahme, Workarounds und Firewalls überbrücken nur. Ebenso wichtig wie das Patchen ist eine Überwachung, die Auffälligkeiten auf dem Server früh sichtbar macht. Prüfen Sie Ihren Patchstand und klären Sie für die Zukunft, wer bei der nächsten kritischen Lücke in welcher Zeit handelt.

Quellen

Beitrag teilen

LinkedIn
XING
E-Mail

Weitere Beiträge zum Thema