Qualys warnt vor kritischen PHP-Schwachstellen und empfiehlt sofortige Updates

PHP2Shell entwickelt sich zu einer ernsthaften Bedrohung für die Sicherheit von Webservern und Unternehmensanwendungen. Zwei kritische Schwachstellen in der PHP-Engine ermöglichen Angreifern unter bestimmten Bedingungen die Ausführung von Schadcode – ohne Anmeldung und unabhängig von Sicherheitslücken im Anwendungscode. Während bereits Angriffsversuche beobachtet werden, wächst der Druck auf Unternehmen, ihre PHP-Infrastrukturen unverzüglich abzusichern.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat für PHP2Shell eine Cybersicherheitswarnung der Stufe 3 (Orange) ausgesprochen und stuft die Bedrohung damit als außerordentlich hoch ein. Einige Organisationen haben vorsorglich Dienste vom Netz genommen, um mögliche Angriffe zu verhindern.

Saeed Abbasi, Leiter der Threat Research Unit (TRU) und Director Product bei Qualys , warnt vor den weitreichenden Auswirkungen der Schwachstellen. Da die Sicherheitsprobleme unmittelbar in der PHP-Laufzeitumgebung liegen, können selbst Anwendungen mit fehlerfreiem Programmcode betroffen sein.

Das betrifft zahlreiche Content-Management-Systeme wie WordPress, Drupal und Joomla ebenso wie Shopware, Magento und individuell entwickelte Unternehmensanwendungen.

Zwei kritische Schwachstellen ermöglichen Remote Code Execution

Im Zentrum der aktuellen Sicherheitswarnung stehen zwei Schwachstellen, die unter den Kennungen CVE-2026-109618 und CVE-2026-109619 geführt werden. Beide erreichen einen CVSS-v4.0-Wert von 9,2 und gelten damit als kritisch. Die Sicherheitsprobleme beruhen auf Fehlern in der Speicherverwaltung der PHP-Engine:

CVE-2026-109618 – Fehlerhafte Speicherbereinigung: Wird ein Verarbeitungsvorgang aufgrund von Speichermangel unterbrochen, können interne Datenstrukturen in einem unvollständigen Zustand zurückbleiben. Bei der anschließenden Speicherbereinigung können diese ungültigen Daten verarbeitet werden. Angreifer können diesen Zustand gezielt ausnutzen, um Schadcode auszuführen.

CVE-2026-109619 – Zugriff auf bereits freigegebenen Speicher: Hier bleiben unter bestimmten Bedingungen interne Verweise auf Speicherbereiche bestehen, die bereits freigegeben wurden. Greift eine nachfolgende Anfrage auf denselben PHP-Worker zu, kann daraus eine sogenannte Use-after-free-Situation entstehen. Sicherheitsforscher konnten darüber ebenfalls Remote Code Execution demonstrieren.

Besonders problematisch ist, dass die Schwachstellen ohne vorherige Authentifizierung ausgenutzt werden können.

Apache mod_php besonders gefährdet

Nach Angaben des PHP-Projekts sind grundsätzlich sämtliche PHP-Installationen betroffen, die Webanfragen verarbeiten. Dazu gehören PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed.

Das höchste Risiko besteht derzeit bei Apache-mod_php-Installationen. Hier wurde bereits ein Exploit nachgewiesen, der greift, bevor überhaupt Anwendungscode ausgeführt wird.

Auch PHP-FPM ist keineswegs sicher. Neben der Möglichkeit zur Remote Code Execution wurde die Offenlegung von Speicherinhalten nachgewiesen. Dadurch könnten Angreifer an sensible Informationen wie Passwörter, Authentifizierungstoken oder API-Schlüssel gelangen.

Cloudflare hat bereits Angriffsverkehr im Zusammenhang mit PHP2Shell registriert, darunter Versuche, bestehende Schutzmechanismen zu umgehen.

Für Unternehmen bedeutet das: Die Absicherung einzelner Webanwendungen reicht nicht aus. Entscheidend ist die Sicherheit der zugrunde liegenden PHP-Laufzeitumgebung.

Sicherheitsupdates stehen bereits zur Verfügung

Das PHP-Projekt hat am 21. Oktober 2026 korrigierte Versionen veröffentlicht. Qualys empfiehlt, sämtliche betroffenen Installationen schnellstmöglich zu aktualisieren.

Bei Linux-Distributionen können Sicherheitskorrekturen durch sogenannte Backports auch in Paketen mit älteren Versionsnummern enthalten sein. Deshalb sollten Administratoren die Sicherheitshinweise ihres jeweiligen Distributionsanbieters berücksichtigen.

Für die nicht mehr regulär unterstützten PHP-Versionen 7.4, 8.0 und 8.1 stehen lediglich begrenzte Quellcode-Backports zur Verfügung. Betreiber sollten daher auf korrigierte Builds ihrer Supportanbieter oder auf eine unterstützte PHP-Version wechseln.

Wenn Updates nicht sofort möglich sind

Nicht jede produktive Umgebung lässt sich kurzfristig aktualisieren. Gerade bei komplexen Unternehmensanwendungen, älteren Shopsystemen oder geschäftskritischen Webdiensten können Abhängigkeiten eine unmittelbare Umstellung erschweren. Das PHP-Projekt nennt verschiedene Maßnahmen, mit denen sich das Risiko vorübergehend reduzieren lässt.

Dazu gehören die administrative Anpassung von Speichergrenzen, die Begrenzung von HTTP-Anfragen sowie das Deaktivieren bestimmter Funktionen wie session.upload_progress.

Für CVE-2026-109618 kann beispielsweise ein administrativ erzwungenes memory_limit=-1 bestimmte Angriffspfade erschweren. Allerdings steigt dadurch das Risiko einer Ressourcenerschöpfung.

Zur Eindämmung von CVE-2026-109619 empfiehlt PHP unter anderem, session.upload_progress.enabled=0 auf Server- oder Administrationsebene zu setzen. Bei PHP 8.5 sollte zusätzlich fatal_error_backtraces=0 geprüft werden.

Diese Konfigurationsänderungen müssen auf der richtigen Ebene erfolgen und erfordern anschließend einen Neustart der betroffenen Worker.

Entscheidend bleibt jedoch: Keine dieser Maßnahmen bietet vollständigen Schutz. Nur ein Sicherheitsupdate beseitigt die Schwachstellen zuverlässig.

Ist eine Aktualisierung kurzfristig ausgeschlossen, sollten Unternehmen den öffentlichen Zugriff auf betroffene Anwendungen einschränken oder die entsprechenden Dienste vorübergehend isolieren.

Versteckte PHP-Installationen als zusätzliches Risiko

Eine besondere Herausforderung liegt in der vollständigen Erfassung aller betroffenen Systeme.

PHP ist häufig nicht nur Bestandteil klassischer Webserver, sondern auch in Containern, Hosting-Plattformen, Appliances und individuell entwickelten Anwendungen integriert.

Die Abfrage über php -v reicht deshalb nicht zwangsläufig aus. Die angezeigte Version muss nicht mit der tatsächlich für Webanfragen verwendeten PHP-Instanz übereinstimmen.

Qualys empfiehlt einen strukturierten Ansatz:

1. PHP-Installationen vollständig inventarisieren: Einschließlich paralleler Versionen, Container und eingebetteter Laufzeitumgebungen.
2. Internetexponierte Systeme priorisieren: Insbesondere Apache-mod_php-Installationen sollten zuerst aktualisiert werden.
3. Korrigierte Pakete und Images bereitstellen: Auch Container müssen mit aktualisierten PHP-Versionen neu erstellt oder bereitgestellt werden.
4. Worker und Dienste neu starten: Damit keine Prozesse mit verwundbaren PHP-Versionen aktiv bleiben.
5. Wirksamkeit überprüfen: Nach der Aktualisierung müssen die tatsächlich eingesetzten PHP-Versionen kontrolliert und temporäre Schutzmaßnahmen überprüft werden.

PHP2Shell wird zum Praxistest für das Schwachstellenmanagement

Die Sicherheitslücken zeigen, wie schnell eine Schwachstelle in einer weitverbreiteten Laufzeitumgebung zu einem unternehmensweiten Sicherheitsproblem werden kann.

Für Organisationen, die unter die Anforderungen von NIS2 beziehungsweise des österreichischen NISG 2026 fallen, wird PHP2Shell damit auch zu einem wichtigen Praxistest für das eigene Schwachstellen- und Patchmanagement.

Entscheidend ist nicht allein, ob Sicherheitsupdates verfügbar sind. Unternehmen müssen wissen, wo verwundbare Komponenten eingesetzt werden, welche Systeme öffentlich erreichbar sind und wie schnell sich kritische Schwachstellen tatsächlich beseitigen lassen.

Die zentrale Erkenntnis aus PHP2Shell: Sicherheit endet nicht beim Anwendungscode. Wer seine Laufzeitumgebungen nicht vollständig kennt und konsequent aktualisiert, riskiert schwerwiegende Angriffe auf vermeintlich sichere Anwendungen.