PHP: Zwei kritische Schwachstellen im Kern gefährden Millionen Web-Instanzen.

Im PHP-Kern wurden zwei kritische Sicherheitslücken veröffentlicht (CVE-2026-109618 und CVE-2026-109619, CVSS v4.0 9,2). Angreifer können darüber ohne vorherige Authentifizierung Schadcode aus der Ferne ausführen. Die Updates sind seit dem 21. Oktober 2026 verfügbar, erste Angriffsversuche wurden bereits beobachtet. Aktualisieren Sie betroffene Systeme umgehend.

Stand: 22. Oktober 2026

In der weit verbreiteten Skriptsprache PHP bestehen zwei kritische Schwachstellen im Kern der Speicher- und Request-Verarbeitung. Beide Lücken werden mit einem CVSS-v4.0-Score von 9,2 als schwerwiegend eingestuft und erlauben die unbefugte Codeausführung aus der Ferne (Remote Code Execution, RCE). In Fachkreisen laufen die Lücken unter dem Namen „php2shell“.

Die Dimension unterscheidet sich fundamental von typischen Appliance-Schwachstellen: Da PHP nach wie vor mehr als die Hälfte aller weltweiten Webpräsenzen antreibt, beläuft sich der globale Footprint auf weit über eine Million aus dem Internet erreichbare, potenziell verwundbare Systeme. Gemessen an Websites ist die Reichweite noch größer: PHP läuft laut W3Techs auf rund 70 Prozent aller Websites mit bekannter Serversprache, darunter verbreitete CMS wie WordPress, TYPO3, Drupal und Joomla. Oft teilen sich viele Websites einen Server, die Zahl der betroffenen Websites liegt daher um ein Vielfaches über der Zahl verwundbarer Server.

Gleichzeitig ist der Zeitdruck hoch: Die CVE-Nummern wurden vor dem geplanten Termin öffentlich, PHP hat das Update daraufhin vorgezogen. Angriffsversuche wurden bereits vor der Veröffentlichung beobachtet, Sicherheitsforscher haben die Ausnutzung gegen WordPress, Drupal, Joomla und Magento demonstriert. Erste Proof-of-Concept-Exploits sind öffentlich im Umlauf. Das BSI hat am 21. Oktober eine Cybersicherheitswarnung herausgegeben und die Lage mit der Warnstufe 3 (Orange) eingestuft. Ein rein manueller Patch-Zyklus über dezentrale Web- und Serverlandschaften hinweg birgt daher ein hohes Risiko.

Ihre wichtigsten Aufgaben: Exponierte PHP-Instanzen lückenlos identifizieren, umgehend auf die korrigierten Versionen aktualisieren und alle PHP-Prozesse neu starten. Wo das nicht sofort geht, Systeme isolieren und die von PHP veröffentlichten Übergangsmaßnahmen umsetzen.

Sie sind betroffen, wenn Sie Webanwendungen, APIs oder Appliances von Drittanbietern betreiben, die auf einer anfälligen PHP-Version laufen und Anfragen aus nicht vertrauenswürdigen Netzen – insbesondere dem öffentlichen Internet – entgegennehmen. Betroffen sind alle gängigen Betriebsarten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht PHP bei mod_php. Dort löst eine einzige Anfrage ohne Anmeldung den Angriff aus, bevor Anwendungscode läuft.

Ihren Versionsstand ermitteln Sie auf Serverebene über die Befehlszeile (php -v) oder über die Paket- und Container-Verwaltung Ihres Webservers. Wichtig: Linux-Distributionen spielen den Fix oft in ihre eigene Paketversion ein. Die angezeigte Versionsnummer kann dann unter den Werten der Tabelle liegen, obwohl das System geschützt ist. Maßgeblich ist das Sicherheitsbulletin Ihres Distributors oder Anbieters. Für die nicht mehr unterstützten Versionen 7.4, 8.0 und 8.1 hat PHP einfache Quellcode-Korrekturen bereitgestellt, einzelne Distributoren liefern Backports. Mittelfristig führt kein Weg an einem unterstützten Zweig vorbei. PHP 8.2 erhält nur noch bis 31. Dezember 2026 Sicherheitsupdates.

Die Schwachstellen betreffen nicht nur klassische Webserver (Apache, Nginx mit PHP-FPM). Auch Hosting-Panels (z. B. Plesk, cPanel), Software mit mitgeliefertem PHP sowie Netzwerk- und Sicherheits-Appliances können PHP nutzen, etwa für administrative Konsolen, Portale oder API-Schnittstellen. Da Kunden auf diesen Systemen keine manuellen Updates der Laufzeitumgebung einspielen können, besteht hier eine direkte Abhängigkeit von den Sicherheits-Updates (Firmware/Hotfixes) der jeweiligen Hersteller.

Arbeiten Sie die folgenden Schritte priorisiert ab. Das Update ist die einzige vollständige Abhilfe und hat Vorrang vor allen Übergangsmaßnahmen.

1. PHP-Systeme erfassen und Exposition analysieren.

Verschaffen Sie sich unverzüglich einen vollständigen Überblick über Ihre öffentlich erreichbaren Web-Assets. Erfassen Sie je System die PHP-Version und den Bezugsweg: Linux-Distribution, Drittanbieter-Paketquelle, Container-Image, Hoster oder Control-Panel oder Software, die PHP mitbringt. Davon hängt ab, wann und von wem das Update kommt. Attack Surface Management (ASM) und automatisierte Discovery-Scans sind essenziell, um Schatten-IT, vergessene Testsysteme oder veraltete Container in Ihrer Bereitstellungskette aufzudecken.

2. Nach Erreichbarkeit (Reachability) priorisieren.

In komplexen Infrastrukturen lässt sich selten die gesamte Systemlandschaft simultan aktualisieren. Bewerten Sie die Angriffswege: PHP-Instanzen, die direkt ohne vorgeschaltete Sicherheitsinstanz am Internet hängen, müssen als erstes aktualisiert oder, wo das nicht sofort geht, isoliert werden. Interne Systeme, die nur über authentifizierte Netze erreichbar sind, folgen in der zweiten Prioritätsstufe.

3. Sicherheitsupdates sofort einspielen.

Bringen Sie alle Systeme auf die fehlerbereinigten Versionen oder auf das korrigierte Paket Ihres Distributors, sobald Ihr Bezugsweg es bereitstellt. Starten Sie danach alle PHP-Prozesse neu (PHP-FPM, Apache, php-cgi), sonst läuft der alte Code weiter. In Container-Umgebungen (Docker, Kubernetes) die Basis-Images neu bauen und ausrollen. Wer PHP über die Paketquelle rpms.remirepo.net bezieht, erhält dort vorerst kein Update und sollte auf Distributionspakete wechseln.

4. Wo das nicht sofort geht: isolieren und überbrücken.

Ist ein Update nicht sofort möglich, nehmen Sie aus dem Internet erreichbare Anwendungen bis zur Fehlerbehebung vom Netz oder schotten Sie sie ab. Das empfiehlt auch CERT-EU. Zusätzlich hat PHP Übergangsmaßnahmen veröffentlicht, unter anderem Einstellungen in der php.ini (z. B. session.upload_progress.enabled=0) und Grenzwerte für Größe und Umfang von Anfragen am Webserver oder Proxy. WAF-Regeln können Angriffsversuche zusätzlich abfangen. PHP stellt klar: Keine dieser Maßnahmen macht ein System sicher, sie verschaffen nur Zeit bis zum Update.

5. Auf Kompromittierung prüfen und Erkennungszeiten straffen.

Überprüfen Sie Webserver- und Zugriffsprotokolle ab dem 17. Oktober 2026 auf Auffälligkeiten. Typische Anzeichen: PHP- oder Webserver-Prozesse, die Shells, Skriptinterpreter oder Download-Werkzeuge wie curl und wget starten, neue Dateien oder Webshells im Web-Verzeichnis, neue Cronjobs oder Benutzerkonten. Bei Verdacht das System isolieren, Logs sichern und das Bechtle SIRT einschalten. Da eine der Lücken Speicherinhalte preisgeben kann, tauschen Sie nach einer Kompromittierung Passwörter, API-Schlüssel und Zertifikate, die auf dem Server lagen. Da automatisierte Angriffe Angriffsfenster auf Minuten komprimieren, sollten Detection- und Response-Mechanismen im SOC engmaschig auf Webperimeter-Alerts reagieren.

1. Appliance- und Software-Inventar erfassen.

Identifizieren Sie neben Ihren eigenen Web-Applikationen auch alle Sicherheits- und Netzwerk-Appliances am Perimeter, die Web-Oberflächen bereitstellen. Klären Sie über Software-Inventare oder Herstelleranfragen (SBOM), ob in diesen Systemen anfällige PHP-Komponenten betrieben werden.

2. Management-Schnittstellen sofort vom Internet trennen.

Prüfen Sie die Erreichbarkeit administrativer Schnittstellen von Gateways, Firewalls und Load-Balancern. Administrative Oberflächen gehören grundsätzlich nicht ins öffentliche Internet. Beschränken Sie den Zugriff strikt auf interne Management-Netze oder erzwingen Sie den Zugang über gesicherte VPN- und ZTNA-Verbindungen.

3. Hersteller-Advisories (PSIRT) engmaschig überwachen.

Fragen Sie bei Ihren Herstellern nach, ob ihre Produkte betroffen sind, und verfolgen Sie deren Security Bulletins. Achten Sie dort auf temporäre Workarounds (z. B. Deaktivierung anfälliger Teilfunktionen) und spielen Sie bereitgestellte Firmware-Patches unmittelbar nach Veröffentlichung ein.

4. Schutzmaßnahmen und Virtual Patching vorschalten.

Müssen Portale von Drittanbieter-Appliances zwingend öffentlich erreichbar bleiben, schalten Sie kompensierende Sicherheitsmaßnahmen vor: Nutzen Sie Web Application Firewalls (WAF) mit aktuellen generischen Exploit-Signaturen, um verdächtige Payloads abzufangen, bevor sie die Appliance erreichen. Das ersetzt das Update des Herstellers nicht.

Der Unterschied zu früheren Sicherheitsvorfällen liegt im Zusammenspiel aus Angriffsfläche und Geschwindigkeit. Bei Vorfällen wie Citrix NetScaler oder BeyondTrust ging es um klar umrissene Gateways, die sich gezielt finden und patchen ließen. PHP dagegen steckt in Webservern, Content-Management-Systemen, Shops, Hosting-Panels und Appliances, oft ohne dass die IT davon weiß. Angriffsversuche wurden bereits vor dem Release beobachtet, seit dem 21. Oktober berichten Sicherheitsanbieter von ersten Angriffen.

Dazu kommt, dass Angreifer mit KI-gestützter Analyse öffentlich gewordene Schwachstellen innerhalb kürzester Zeit für Massenscans und Exploits adaptieren können. Wer sich ausschließlich auf manuelle, mehrwöchige Patch-Rhythmen verlässt, riskiert, dass Angreifer Systeme kompromittieren, bevor das reguläre Wartungsfenster greift.

BSI: Cybersicherheitswarnung „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“

PHP: Security Advisory und korrigierte Versionen

CERT-EU: Security Advisory 2026-018

Sie können die notwendigen Schutz- und Patchmaßnahmen selbstständig durchführen. Sollten Ihnen dafür Ressourcen, Werkzeuge oder Kapazitäten fehlen, unterstützen wir Sie herstellerunabhängig. Kunden des Bechtle CDC wenden sich an ihre gewohnten Ansprechpartner im CDC.