PHP2Shell-Lücke: Betroffene Websites per Inventar finden

Was das BSI zu PHP2Shell meldet

Der BSI-IT-Sicherheitshinweis „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“ trägt die Nummer BITS-H 2026-297981-1232 und liegt in Version 1.2 vom 22. Oktober 2026 vor (BSI). Er betrifft zwei Schwachstellen, CVE-2026-109618 und CVE-2026-109619, die nach dem Bewertungssystem CVSS in Version 4.0 jeweils mit 9,2 von 10 eingestuft sind (BSI). Betroffen sind nach den dort genannten Informationen alle bekannten PHP-Versionen, zurückgehend bis mindestens PHP 5 (BSI). Der Name PHP2Shell stammt aus der Berichterstattung und soll die Ähnlichkeit mit der früheren Lücke Log4Shell zeigen (BSI).

Behoben sind die Lücken in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (PHP Group). Für die Zweige 8.1 und älter liefert das PHP-Projekt keine Updates mehr (PHP Group); das PHP Security Team hat für die EoL-Versionen 7.4, 8.0 und 8.1 lediglich Backport-Patches für den Quellcode bereitgestellt (BSI). Für die Inventur ist ein Satz aus dem Hinweis besonders wichtig: Die Schwachstellen betreffen die PHP-Laufzeitumgebung selbst und keine konkreten Anwendungen (BSI). Ein Update von WordPress, Shopware oder TYPO3 schließt sie also nicht, die Laufzeit darunter muss ebenfalls aktualisiert werden.

Warum PHP2Shell zuerst eine Inventurfrage ist

Bei einer Lücke in einem Plugin genügt oft ein Blick in die Plugin-Liste. Bei einer Lücke in der Laufzeit ist die Frage breiter: Jede Website, deren Seiten von PHP ausgeliefert werden, ist ein Kandidat, unabhängig vom CMS. Die gemeinsame Erklärung von EU-Kommission, ENISA, CERT-EU, Europol und dem Netz der nationalen CSIRTs formuliert den ersten Schritt entsprechend: Organisationen sollen ihre PHP-basierten Anwendungen identifizieren, sich mit Hostern und Dienstleistern abstimmen und die Updates einspielen (ENISA). Systeme, die aus dem Internet erreichbar sind, sollen dabei Vorrang haben (ENISA).

Für Agenturen kommt eine zweite Ebene hinzu: die Zuständigkeit. Bei einer Website auf eigenem Server patcht die Agentur selbst, bei Shared Hosting oder einem verwalteten Server der Hoster, bei einem Container-Deployment derjenige, der das Abbild baut. Das BSI weist eigens darauf hin, dass Anwendungen in Docker-Containern unabhängig vom Host aktualisiert oder neu gebaut werden müssen, sofern sie PHP verwenden (BSI). Eine Liste, die nur Domains enthält, beantwortet die Frage „Wer macht was?“ nicht.

PHP steckt zudem nicht nur hinter klassischen Websites: Viele Produkte nutzen PHP im Hintergrund und können betroffen sein, auch wenn sie nicht danach aussehen (ENISA). Dieser Beitrag bleibt bei den Websites; Geräte mit Weboberfläche gehören in eine eigene Liste. Je Website sollte die Liste mindestens diese Felder tragen:

• Adresse und Umgebung: Live, Staging, Microsite, Landingpage. Jede Umgebung mit eigener PHP-Instanz zählt einzeln.
• Betrieb: eigener Server, verwalteter Server, Shared Hosting oder Container, dazu der Ansprechpartner beim Hoster.
• PHP-Zweig und Paketstand: so, wie php -v und die Paketverwaltung ihn zeigen, nicht nur so, wie die Kopfzeile ihn behauptet.
• Betriebsart: PHP-FPM, Apache mit mod_php, php-cgi oder ein anderer Server. Das PHP-Projekt stuft das Risiko bei mod_php als am höchsten ein (PHP Group).
• Zuständig für den Patch: Agentur, Hoster oder Kunde, mit Namen.
• Nachweis: Datum des Updates, Datum des Neustarts, Ergebnis der Kontrolle.

Schritt 1: Alle Websites erfassen, nicht nur die bekannten

Die Liste beginnt nicht im Monitoring, sondern in den Verträgen, im DNS und in den Hosting-Konten. Typische Lücken im Bestand sind Staging-Umgebungen, Aktionsseiten vergangener Kampagnen, ein altes Kundenportal und Websites, die nach einem Relaunch unter einer zweiten Adresse weiterlaufen. Gerade dort sitzen erfahrungsgemäß die ältesten PHP-Zweige.

Steht eine Website im Monitoring, liefert das CRA-Komponenten-Cockpit eine kontoweite Übersicht: je Website die Zahl der erkannten Komponenten, die Zahl der potenziell veralteten Komponenten, die Zahl der Komponenten mit auslesbarer Version, den höchsten Schweregrad und den Zeitpunkt der letzten Tech-Stack-Prüfung. Sortiert ist die Liste nach der Zahl der potenziell veralteten Komponenten, die auffälligsten Websites stehen also oben. Sie umfasst eigene und für das Konto freigegebene Websites, was bei Agenturen mit Team- und Kundenzugängen den Bestand an einer Stelle zusammenführt. Das Cockpit ist ab dem Business-Plan enthalten.

Was nicht im Monitoring steht, fehlt auch dort. Der Abgleich zwischen der Liste aus Verträgen und DNS und der Liste im Cockpit ist deshalb der erste echte Befund der Inventur: Jede Domain, die nur auf einer der beiden Seiten auftaucht, ist eine offene Frage. Wer die fehlenden Websites bei der Gelegenheit ins Monitoring aufnimmt, hat beim nächsten Anlass eine vollständigere Ausgangslage.

Der Name des Cockpits verweist auf den Cyber Resilience Act, nach dem Hersteller von Produkten mit digitalen Elementen seit dem 11. September 2026 aktiv ausgenutzte Schwachstellen melden müssen (ENISA). Wer ausschließlich Websites betreibt, fällt in der Regel nicht darunter; die Komponentenliste ist davon unabhängig nutzbar.

Schritt 2: PHP erkennen, so weit es von außen sichtbar ist

Von außen verrät sich PHP vor allem über die Kopfzeile X-Powered-By. Die Einstellung expose_php gibt dort bekannt, dass PHP auf dem Server installiert ist, einschließlich der Versionsnummer (PHP-Handbuch). Manche Server nennen PHP auch im Server-Kopf. XICTRAQ liest beide Kopfzeilen beim Scan und leitet daraus die PHP-Komponente im Cockpit ab. Der Security-Scan führt eine sichtbare X-Powered-By-Kopfzeile zugleich als Befund, weil sie Angreifern dieselbe Auskunft gibt wie dem Monitoring.

Wie viel davon im Netz sichtbar ist, misst der Web Almanac auf Basis der vom HTTP Archive erfassten Hosts: Die Kopfzeile X-Powered-By erscheint auf 23,9 Prozent dieser Hosts (Web Almanac 2025), und mehr als 27 Prozent dieser Kopfzeilen enthalten eine Versionsangabe (Web Almanac 2025). PHP neigt nach derselben Auswertung dazu, die genaue Version gerade in X-Powered-By preiszugeben (Web Almanac 2025). Umgekehrt heißt das: Bei einem großen Teil der Websites ist von außen gar keine PHP-Version zu sehen.

Wo die Kopfzeile schweigt, hilft das System dahinter weiter. WordPress, Drupal, TYPO3, Joomla und Magento wurden mit PHP entwickelt (BSI), eine Website mit einem dieser Systeme ist also ein PHP-Kandidat, auch wenn keine Version zu sehen ist. Ein weiteres Indiz ist ein Sitzungscookie mit dem Standardnamen PHPSESSID. Das Cockpit führt ein erkanntes CMS dann als Komponente, aber keine PHP-Version. In seinen Kennzahlen steht, wie viele Komponenten überhaupt eine Version preisgeben; nennt keine einzige eine Version, zeigt es „nicht bewertbar“ statt einer beruhigenden Null.

Schritt 3: Vorrang nach Supportende

Nicht jede Website ist gleich dringend. Den weitesten Weg zur Lösung haben Zweige, für die das PHP-Projekt keine Updates mehr liefert. Das BSI hält fest, dass alle PHP-Versionen vor 8.2 ihr End-of-Life bereits erreicht haben (BSI) und dass PHP 8.2 nur noch bis zum Jahresende mit Sicherheitsupdates unterstützt wird (BSI). Die Tabelle des PHP-Projekts nennt dafür den 31. Dezember 2026 (PHP Group). Nach der Regel des Projekts erhält jeder Zweig nach zwei Jahren aktiver Unterstützung zwei weitere Jahre nur für kritische Sicherheitsprobleme (PHP Group).

Die Daten der Tabelle stammen aus den Übersichten der unterstützten und der nicht mehr unterstützten Zweige (PHP Group) und aus dem Sicherheitshinweis vom 21. Oktober 2026 (PHP Group). Zuerst kommen Websites auf Zweigen ohne Sicherheitsupdates, denn dort gibt es vom PHP-Projekt keine fertige Version mit Patch. Das BSI nennt genau diese Systeme neben den noch ungepatchten als Grund dafür, dass die Zahl verwundbarer Systeme weltweit hoch bleibt (BSI). Danach folgen Websites mit verborgener Version, weil über sie nichts bekannt ist, und erst dann die unterstützten Zweige, bei denen nur noch der Patchstand zu prüfen ist.

Für 8.2 lohnt es sich, den Patch mit dem Wechsel auf einen neueren Zweig zu verbinden. Wie der Umstieg bei WordPress aussieht, beschreibt der Beitrag zum Supportende von PHP 8.2, die Planung sicherer Upgrades im Shop der Beitrag zum PHP-EOL-Management. Das Cockpit nimmt einen Teil der Sortierung ab: Eine sichtbare PHP-Version unter 8.2 markiert es als Supportende, mit einem Schweregrad je nach Alter des Zweigs, und solche Websites rücken in der Übersicht nach oben. Wie man Supportenden im ganzen Web-Stack verfolgt, nicht nur bei PHP, steht im Beitrag zum Supportende im Web-Stack.

Was die Heuristik bewertet und was nicht

Hier liegt die wichtigste Einschränkung dieses Ablaufs, und sie gehört offen benannt. XICTRAQ sieht nur, was der Server von außen zeigt. Die Bewertung im Cockpit ist eine Offline-Heuristik: Sie vergleicht die sichtbare Versionsnummer mit hinterlegten Schwellen, ohne eine Schwachstellen-Datenbank live abzufragen. Die PHP2Shell-Kennungen CVE-2026-109618 und CVE-2026-109619 stehen nicht in diesen Regeln. XICTRAQ erkennt PHP2Shell nicht und gibt das auch nicht vor.

Für PHP setzt die Heuristik die Grenze beim Supportende: Unter 8.2 meldet sie einen Hinweis, ab 8.2 nicht. Den Patchstand innerhalb der Zweige 8.2 bis 8.5 bewertet sie nicht. Eine Website, die PHP/8.3.20 meldet, gilt dort also nicht als veraltet, obwohl 8.3.20 unter der behebenden Version 8.3.36 liegt (PHP Group). Für diese Websites liefert das Inventar die Liste, die Prüfung des Patchstands bleibt beim Betreiber.

Die zweite Grenze ist der Backport. Linux-Distributionen spielen Sicherheitskorrekturen häufig in ihre Pakete ein, ohne die Versionsnummer auf den Stand des PHP-Projekts zu heben. Das BSI schreibt dazu, ein Abgleich der installierten Version mit der von der Distribution bereitgestellten gepatchten Version sei möglicherweise notwendig (BSI). Wie unterschiedlich das aussieht, zeigen die Sicherheitsseiten der Distributionen zu CVE-2026-109618:

• Debian 12 führt die Korrektur im Paket 8.2.35-1~deb12u1, also mit der behebenden Nummer des PHP-Projekts (Debian).
• Ubuntu 24.04 LTS führt sie im Paket 8.3.6-0ubuntu0.24.04.13 (Ubuntu). Die Grundversion 8.3.6 liegt weit unter 8.3.36, das Paket ist trotzdem korrigiert.
• Ubuntu 22.04 LTS korrigiert sogar den Zweig 8.1, für den das PHP-Projekt keine Updates mehr liefert, im Paket 8.1.2-1ubuntu2.28 (Ubuntu).

Eine alte Nummer in der Kopfzeile ist also kein Beweis für eine offene Lücke, und eine neue Nummer in php -v kein Beweis für einen Neustart: Die Kommandozeile lädt bei jedem Aufruf das installierte Paket, ein laufender FPM-Dienst arbeitet bis zum Neustart mit dem alten Stand. Steht in der Kopfzeile ein Paketsuffix der Distribution, lässt sich der Stand mit deren Sicherheitsseite abgleichen; ohne Suffix bleibt nur der Blick auf den Server. Das Cockpit trägt dem mit der Markierung „Backport möglich“ Rechnung, die es bei PHP, nginx, Apache httpd und OpenSSL setzt. Das Handbuch zum CRA-Cockpit beschreibt den Vorbehalt im Einzelnen.

Schritt 4: Patchen und neu starten

Dieser Beitrag ist keine Patch-Anleitung, drei Punkte aus den Hinweisen gehören aber in jede Liste. Erstens hat das PHP-Projekt die Korrekturen vorab an Linux-Distributionen und Anbieter mit Langzeitpflege gegeben und verweist für aktualisierte Pakete auf diese (PHP Group). Wer PHP aus der Paketverwaltung bezieht, wartet also auf das Paket der Distribution. Zweitens prüft man den Patchstand nach dem BSI-Hinweis mit php -v und dem Abgleich gegen das Advisory (BSI). Drittens werden Container mit PHP neu gebaut, statt nur den Host zu aktualisieren (BSI).

Ein neues Paket wirkt erst, wenn die laufenden PHP-Prozesse neu gestartet sind: der FPM-Dienst, der Apache-Server bei mod_php, die Worker eines Anwendungsservers. Die Übergangsmaßnahmen des PHP-Projekts sagen das für geänderte Einstellungen ausdrücklich, dort heißt es, jeder Worker sei neu zu starten (PHP Group). Für ein Paket-Update gilt dasselbe. In die Liste gehört deshalb neben dem Datum des Updates das Datum des Neustarts, ablesbar zum Beispiel am Startzeitpunkt des Dienstes.

Wer einen Neustart im laufenden Betrieb plant, kann im Uptime-Monitoring ein Wartungsfenster setzen. Alarme schweigen in dieser Zeit, die Prüfungen laufen weiter und zählen in die Verfügbarkeit. So bleibt im Protokoll sichtbar, ob die Website nach dem Fenster wieder erreichbar war.

Schritt 5: Nach dem Neustart kontrollieren

Nach Patch und Neustart stehen zwei Fragen an, die sich von außen beantworten lassen: Ist die Website erreichbar, und sieht sie aus wie vorher? Ein PHP-Update kann Erweiterungen verändern, eine Konfiguration zurücksetzen oder einen Dienst nicht wieder anlaufen lassen. Das ist kein Grund, auf den Patch zu verzichten, aber ein Grund, danach hinzusehen. CERT-EU spricht in seinem Hinweis von einer Korrektur, die eingespielt und überprüft ist (CERT-EU). Wie man eine Änderung am laufenden System nachmisst und notfalls zurückrollt, beschreibt der Beitrag zu Deploy-Fehlern als Ausfallursache.

Eine Grenze gilt auch hier: Von außen lässt sich nicht feststellen, ob ein Server vor dem Patch kompromittiert wurde. Das BSI nennt dafür Prüfungen auf dem Server selbst, etwa die Suche nach neu erstellten oder veränderten PHP-Dateien, ausführbaren Dateien und möglichen Webshells (BSI) und die Beobachtung ungewöhnlicher Prozesse, die vom Webserver gestartet werden (BSI). Eine sichtbare Verunstaltung der Seite würde der Screenshot-Vergleich zeigen, eine still abgelegte Hintertür nicht.

Schritt 6: Den Stand belegen

Am Ende steht eine Liste, die für jede Website sagt, was geprüft, was getan und was kontrolliert wurde. Im Cockpit lässt sich ein Hinweis je Komponente als bekannt markieren, etwa der Supportende-Hinweis zu PHP 8.1 auf einem Server, dessen Paket die Distribution nachweislich korrigiert hat. Gespeichert wird der Zeitpunkt der Bestätigung, und sie lässt sich zurücknehmen. Die Begründung, also Paketstand und Datum des Neustarts, gehört in die eigene Liste. Die Komponentenliste lässt sich außerdem als CycloneDX-Datei exportieren. Für einen Stichtag ist das ein brauchbarer Schnappschuss, auch wenn er nur zeigt, was von außen sichtbar ist; der Unterschied zu einer vollständigen Software-Stückliste steht im Beitrag zur SBOM nach dem CRA.

Für den Kunden oder die Geschäftsführung reicht oft eine einfache Tabelle oder eine Datei je Anlass. Ein Beispiel, wie die Einträge je Website aussehen können:

occasion: PHP2Shell (CVE-2026-109618, CVE-2026-109619)
basis: BSI BITS-H 2026-297981-1232, Version 1.2
sites:
  - address: shop.example
    hosting: eigener Server, Apache mit mod_php
    php_before: "8.1.31, Kopfzeile sichtbar"
    action: Umstieg auf 8.3, Paket der Distribution
    restart: 2026-10-22 07:41
    check: erreichbar, Screenshot unverändert
    owner: Agentur
  - address: www.example
    hosting: verwalteter Server beim Hoster
    php_before: "verborgen, laut Hoster 8.2"
    action: "Paket 8.2.35-1~deb12u1 laut Hoster"
    restart: "2026-10-21 laut Hoster-Ticket"
    check: erreichbar, Screenshot unverändert
    owner: Hoster
open:
  - Staging-Umgebungen ohne Monitoring

Wichtig ist die Unterscheidung zwischen gemessen und angegeben. „Erreichbar“ und „Screenshot unverändert“ sind Messungen mit Zeitstempel. „Laut Hoster 8.2“ ist eine Auskunft und gehört als solche gekennzeichnet. Wer beides vermischt, hat im Streitfall eine Liste, der man nicht ansieht, worauf sie beruht. Offene Punkte gehören ausdrücklich hinein, statt wegzufallen.

Der Ablauf bleibt, die Lücke wechselt

PHP2Shell wird nicht die letzte kritische Lücke im Web-Stack gewesen sein. Schon zwei Tage nach den Patches hat das PHP-Projekt eine weitere Schwachstelle, CVE-2026-115560, mit einer Übergangsmaßnahme angekündigt; sie betrifft nur ungewöhnlich konfigurierte Anwendungen und wird im regulären Releasezyklus behoben (PHP Group). CERT-EU hat seinen Hinweis am 23. Oktober entsprechend ergänzt (CERT-EU). Das BSI hält es für möglich, dass wegen der erhöhten Aufmerksamkeit auf PHP weitere Lücken entdeckt werden (BSI).

Die Liste aus dieser Woche ist deshalb kein Wegwerfprodukt. Sie wird beim nächsten Anlass wieder gebraucht, für PHP, für den Webserver, für eine Bibliothek im Frontend. Wer sie laufend aktuell hält, beantwortet die Frage nach den betroffenen Websites beim nächsten Mal aus der Liste statt aus dem Gedächtnis. Wie man passende Schwachstellen-Feeds auswählt, beschreibt der Beitrag zu EUVD und CVE; welche Kopfzeile Kamera, Mikrofon und Standort sperrt, zeigt der Beitrag zur Permissions-Policy.

Für Agenturen ist der Ablauf zugleich eine Leistung, die sich dem Kunden zeigen lässt: ein datierter Stand je Website statt einer Rundmail mit „alles erledigt“. Wie XICTRAQ mehrere Kundenwebsites in einem Konto zusammenführt, steht auf der Seite für Agenturen. Der Ablauf in Kurzform:

1. Bestand aus Verträgen, DNS und Hosting-Konten gegen das Monitoring abgleichen.
2. Je Website PHP-Zweig, Betrieb und Zuständigkeit eintragen, verborgene Versionen von innen ergänzen.
3. Zweige ohne Sicherheitsupdates zuerst, dann verborgene Versionen, dann den Patchstand der unterstützten Zweige prüfen.
4. Paket der Distribution oder behebende Version einspielen, Container neu bauen, Dienste neu starten.
5. Erreichbarkeit und Erscheinungsbild nach dem Neustart kontrollieren, Prüfungen auf dem Server veranlassen.
6. Gemessenes und Angegebenes getrennt und mit Datum festhalten, offene Punkte benennen.