PHP2Shell: BSI warnt vor kritischen PHP-Lücken – diese Updates brauchen WordPress und Webserver

BSI-Warnung · PHP-Sicherheitsupdates · Stand 21. Oktober 2026

PHP2Shell: BSI warnt vor kritischen PHP-Lücken – was WordPress und Webserver jetzt brauchen

Zwei Sicherheitslücken in PHP können Angriffe auf Webserver ohne vorherige Anmeldung ermöglichen. Das BSI stuft die Lage mit Orange ein. Inzwischen nennt das PHP-Projekt die bereinigten Versionen. Hier erfährst du, wer handeln muss, wie du den PHP-Stand deiner Website findest und weshalb ein WordPress- oder Plugin-Update die Serverkorrektur nicht ersetzt.

• CVE-2026-109618 und CVE-2026-109619: jeweils CVSS 4.0 von 9,2
• PHP nennt Sicherheitsupdates für die Zweige 8.2, 8.3, 8.4 und 8.5
• Bei Webhosting ist der tatsächliche Patchstand des Anbieters entscheidend

Bereinigte Versionen WordPress prüfen

Eine aktuelle WordPress-Installation kann auf einem ungepatchten PHP-Unterbau laufen. Genau deshalb ist die neue BSI-Warnung auch für Menschen relevant, die ihren Blog, Verein, Onlineshop oder ihre geschäftliche Website ansonsten sorgfältig pflegen. Unter dem Namen PHP2Shell werden zwei kritische Schwachstellen in der PHP-Laufzeit zusammengefasst. Betroffen ist die technische Grundlage vieler Websites; nicht ein einzelnes WordPress-Plugin, das sich im Dashboard mit einem Klick austauschen ließe.

Das Bundesamt für Sicherheit in der Informationstechnik veröffentlichte dazu am 21. Oktober 2026 den Sicherheitshinweis BITS-H Nr. 2026-297981-1032. Seine Version 1.0 kündigt die Veröffentlichung der Updates für 16 Uhr deutscher Zeit an. Der Informationsstand ist inzwischen weiter: Das PHP-Projekt hat eine eigene Sicherheitsmeldung und die korrigierten Versionsstände veröffentlicht. Dieser Beitrag berücksichtigt diese neueren Herstellerinformationen.

Stand: 21. Oktober 2026. Ausgewertet wurden die BSI-Warnung einschließlich des vierseitigen Originaldokuments, CERT-EU, die PHP-Veröffentlichungen und die beiden technischen Hersteller-Advisories. Paketverfügbarkeit und ausgelieferte Updates unterscheiden sich nach Hosting-Anbieter und Betriebssystem.

PHP2Shell: Das Wichtigste in 30 Sekunden

Was das BSI zu PHP2Shell meldet – und was inzwischen neu ist

Der Sicherheitshinweis betrifft CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9,2 von 10 Punkten nach CVSS 4.0 bewertet. Die BSI-Einstufung lautet im Originaldokument Kritikalität 3 / Orange: Verantwortliche sollen unverzüglich Maßnahmen ergreifen. Das ist eine konkrete Handlungsempfehlung für den Betrieb gefährdeter Systeme, keine Aussage darüber, dass jede Website bereits kompromittiert wäre.

Die Vorabwarnung und das spätere technische Advisory erfüllen unterschiedliche Aufgaben. Die erste Meldung sollte Personal und Wartungsfenster vorbereiten, solange vollständige Details und Versionsnummern noch fehlten. Die inzwischen verfügbaren Angaben des PHP-Projekts ermöglichen die konkrete Auswahl der Korrekturen. Wer nur einen frühen Screenshot der Warnung weitergibt, kann deshalb einen überholten Stand verbreiten.

Auch die Aussage zur Ausnutzung muss ihren Zeitbezug behalten: Im BSI-Dokument waren noch keine bestätigten Angriffe bekannt. Die späteren PHP-Advisories beschreiben validierte technische Nachweise. Ein nachgewiesener Angriffspfad in einer Untersuchung und eine bestätigte Angriffskampagne gegen fremde Systeme sind unterschiedliche Sachverhalte. Aus den ausgewerteten Primärquellen lässt sich kein pauschaler Beleg ableiten, dass beliebige WordPress-Seiten bereits übernommen wurden.

Die Bewertung 9,2 ist außerdem keine Wahrscheinlichkeit von 92 Prozent. Der CVSS-Wert beschreibt Eigenschaften und mögliche Auswirkungen einer Schwachstelle. Die technischen Advisories nennen zugleich eine hohe Angriffskomplexität und erforderliche Randbedingungen. Das relativiert nicht den Updatebedarf, erklärt aber, weshalb ein einzelner Versionshinweis noch keine vollständige Aussage über die praktische Ausnutzbarkeit einer konkreten Installation ist. Quellen: BSI-Originaldokument, PHP-Veröffentlichungen und die technische Bewertung der ersten Lücke.

Warum PHP auch für WordPress, Shops und private Websites wichtig ist

PHP ist die Laufzeitumgebung, in der der Programmcode vieler Webanwendungen ausgeführt wird. Bei WordPress erzeugt sie beispielsweise Seiteninhalte, verarbeitet Verwaltungsfunktionen und führt Code von Erweiterungen aus. Eine Besucherin sieht im Browser das Ergebnis. Die dafür eingesetzte PHP-Installation liegt jedoch normalerweise beim Hosting-Anbieter oder auf dem selbst verwalteten Server.

Vereinfachte redaktionelle Darstellung. Welche Schritte eine Anfrage durchläuft, hängt vom Serveraufbau und vom angeforderten Inhalt ab.

Ein Update von WordPress-Core, Themes oder Plugins verändert nicht automatisch diese darunterliegende PHP-Laufzeit. Umgekehrt ersetzt eine korrigierte PHP-Version keine ausstehenden Sicherheitsupdates der Anwendung. Für den Betrieb braucht es beide Ebenen. Die offizielle WordPress-Anleitung zur PHP-Aktualisierung weist ausdrücklich auf die Verantwortung des Hosters beziehungsweise auf die Einstellungen im Hosting-Paket hin.

Eine nützliche Zuständigkeitsfrage lautet deshalb: Wer kann auf dieser Installation die PHP-Pakete oder das PHP-Image austauschen? Ist das die Agentur, das Rechenzentrum oder ein eigenes Administratorenteam, gehört die konkrete Anfrage dorthin. Ein Redakteur mit WordPress-Zugang kann wichtige Informationen zusammentragen, verfügt damit aber noch nicht zwangsläufig über die nötigen Serverrechte.

Welche Websites und Anwendungen betroffen sein können

Das BSI beschreibt eine mögliche Betroffenheit älterer PHP-Versionen zurück bis mindestens PHP 5 und nennt verschiedene auf PHP aufbauende Projekte. Das PHP-Projekt richtet seine aktualisierte Warnung an Installationen, die Webanfragen verarbeiten. Dazu zählen unterschiedliche Betriebsarten, unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Eine andere Serveranbindung ist daher kein ausreichender Grund, das Thema abzuhaken.

Die entscheidende Unterscheidung lautet: Ein Projekt kann PHP verwenden, ohne dass damit jede Version und jede Konfiguration gleichermaßen leicht ausnutzbar wäre. Bei Geräten mit gebündelter Laufzeit kann die passende Korrektur als Firmware erscheinen. Bei einem Hosting-Paket kann sie ohne sichtbaren Wechsel des ausgewählten Hauptzweigs eingespielt werden. Bei einem selbst gebauten Container muss gegebenenfalls ein neues Image bereitgestellt werden. Die Inventarisierung gehört deshalb vor die vermeintlich einfache Frage „Habe ich WordPress aktualisiert?“. CERT-EU empfiehlt ausdrücklich, PHP-basierte Anwendungen zu identifizieren.

Was die beiden PHP-Sicherheitslücken technisch bedeuten

Der Name PHP2Shell kann den Eindruck erwecken, es handele sich um ein einzelnes angreifbares Formular. Die Hersteller-Advisories beschreiben dagegen Fehler bei der internen Speicher- und Zustandsverwaltung der Laufzeit. Zum Verständnis reicht die Grundidee: PHP muss beim Verarbeiten und Beenden einer Anfrage verlässlich wissen, welche Daten noch gültig sind und welche bereits freigegeben wurden.

Remote Code Execution, kurz RCE, bedeutet hier, dass ein Angreifer unter passenden Voraussetzungen eigenen Code auf dem entfernten Server ausführen kann. Die bestätigte Auswirkung wird mit den Rechten des PHP-Webprozesses beschrieben. Das bedeutet nicht automatisch Root- oder vollständige Administratorrechte des Betriebssystems. Schon die Rechte einer Webanwendung können jedoch für deren Dateien, Konfiguration und erreichbare Daten sehr relevant sein.

Ein besonders wichtiger Punkt für Website-Betreiber: In bestätigten Konstellationen konnte die problematische Verarbeitung einsetzen, bevor normaler Anwendungscode ausgeführt wurde. Ein fehlender WordPress-Login oder das Abschalten eines einzelnen Upload-Plugins ist deshalb kein genereller Schutzbeleg. Welche Bedingungen zusammenspielen, erläutern die technischen Advisories. Für die praktische Entscheidung bleibt die Korrektur der Laufzeit der verlässliche Weg.

Welche PHP-Versionen PHP2Shell schließen

Das PHP-Projekt nennt für die unterstützten Versionszweige folgende korrigierte Releases. Die Tabelle gilt als Orientierung für die unveränderten PHP-Upstream-Versionen. Bei Distributionspaketen und verwalteten Hosting-Systemen können Sicherheitskorrekturen zurückportiert sein; dort ist zusätzlich die konkrete Paketfreigabe maßgeblich.

Die Sicherheitsveröffentlichung und die PHP-Änderungsübersicht ordnen die beiden Advisories den korrigierten Releases zu. Die Supportdaten stammen aus der offiziellen PHP-Supporttabelle. Ein späteres Release desselben unterstützten Zweigs kann die Korrekturen ebenfalls enthalten; zusätzliche Hinweise des Herstellers bleiben zu beachten.

Für PHP 7.4, 8.0 und 8.1 nennt das PHP-Projekt zusätzlich minimale Quellcode-Backports für Spezialfälle. Daraus wird kein wieder regulär gepflegter Versionszweig und kein gewöhnliches Endkundenupdate. Wer eine solche Umgebung betreibt, braucht eine belastbare Aussage des zuständigen Paket- oder LTS-Anbieters. Für eine normale WordPress-Website bleibt die Migration in einen unterstützten, kompatiblen Zweig die längerfristige Aufgabe.

PHP-Version in WordPress prüfen: die konkrete Anleitung

Mit Administratorzugang kannst du zunächst feststellen, welche PHP-Version WordPress für seine Webanfragen meldet. Dafür ist kein zusätzliches Sicherheitsplugin erforderlich. Der Weg wird in der offiziellen Dokumentation zum Website-Zustand beschrieben.

1. Öffne das WordPress-Dashboard deiner eigenen Website.
2. Gehe zu Werkzeuge → Website-Zustand.
3. Wechsle zum Bereich Bericht beziehungsweise „Info“, abhängig von Sprache und Oberfläche.
4. Klappe den Abschnitt Server auf.
5. Notiere die vollständige PHP-Version und den Servertyp für deine Anfrage an den Anbieter.
6. Vergleiche nach dem Update erneut und lass dir bei Anbieterpaketen den Sicherheits-Backport bestätigen.

Die Oberfläche kann bei verwaltetem Hosting oder eingeschränkten Benutzerrollen abweichen. Fehlt dir der Menüpunkt, frage den Website-Administrator oder die Agentur. Gib dafür keine Zugangsdaten über einen unbekannten Link weiter. Ein Screenshot des relevanten Versionsfelds kann hilfreich sein; ein vollständiger Serverbericht kann weitere interne Informationen enthalten und gehört nicht unüberlegt in öffentliche Kommentare.

Ein grüner Website-Zustand ist keine individuelle Entwarnung für diese beiden CVEs. Der WordPress-Test zur PHP-Version prüft grundsätzlich den empfohlenen und unterstützten Versionsstand. Eine frische Sicherheitslücke und der konkrete Backport eines Hosters sind eine zusätzliche Frage. Das lässt sich auch am offiziell dokumentierten Prüfverfahren nachvollziehen.

Schalte außerdem nicht allein wegen der Nachricht überstürzt auf einen ganz anderen Hauptzweig um. Wenn eine kompatible PHP-8.3-Installation durch das passende Sicherheitsupdate korrigiert werden kann, ist die sofortige Reparatur zunächst eine andere Aufgabe als ein späterer größerer Versionswechsel. Bei alten Themes, Zahlungsmodulen oder individuell entwickelten Erweiterungen sollte der Wechsel zusätzlich mit einer geeigneten Testumgebung und einem Wiederherstellungsplan vorbereitet werden.

Shared Hosting, Managed WordPress oder eigener Server: Wer muss handeln?

Für die meisten privaten Websites führt der schnellste Weg über den Anbieter. „Managed“ ist dabei keine technische Bestätigung eines bereits installierten Updates. Entscheidend sind eine konkrete Zuständigkeit, ein bestätigter Korrekturstand und die Frage, ob alle betroffenen Umgebungen erfasst sind.

Formuliere die Nachfrage möglichst überprüfbar: „Sind CVE-2026-109618 und CVE-2026-109619 für die PHP-Laufzeit meiner Domain behoben?“ ist aussagekräftiger als „Ist mein Hosting sicher?“. Bitte um die verwendete Versions- oder Paketkennung und darum, ob auch die laufenden Arbeitsprozesse erneuert wurden. Bei mehreren Domains, Subdomains und Testumgebungen sollte die Antwort deren Umfang ausdrücklich abdecken.

Ein sofortiger Anbieterwechsel ist dagegen kein eigener Schutzmechanismus. Ein neuer Vertrag kann ebenso auf einer ungeklärten Laufzeit laufen. Wenn der bisherige Anbieter keine zeitnahe Behebung oder verlässliche Auskunft ermöglicht, ist die Eskalation an Support und Wartungsdienst sinnvoll. Ein Umzug braucht ebenfalls eine passende technische Zielumgebung, DNS-Planung und Kontrolle der Datenübernahme.

Für Administratoren: Paketstand, PHP-FPM, Container und Backports prüfen

Die Veröffentlichung einer korrigierten PHP-Version ist der Anfang des betrieblichen Updates. Die eigentliche Arbeit endet erst, wenn die vorgesehenen Pakete beziehungsweise Images in den relevanten Laufzeitumgebungen aktiv sind. Der PHP-Hinweis empfiehlt, aktualisierte Pakete der eigenen Distribution oder des zuständigen Anbieters zu prüfen.

CLI-Version und Web-PHP können auseinanderliegen

Der lesende Befehl php -v zeigt die Version des über die Kommandozeile aufgerufenen PHP-Programms. Er ist ein nützlicher Anhaltspunkt, bestätigt aber nicht automatisch die Version eines getrennten FPM-Pools, Apache-Moduls oder Containers. Systeme können mehrere PHP-Zweige parallel installieren und Domains unterschiedlichen Pools zuweisen. Erfasst deshalb die Web-Laufzeit jeder relevanten Anwendung zusätzlich.

php -v

Eine öffentlich erreichbare phpinfo()-Datei als dauerhafte Diagnosehilfe ist dafür keine gute Lösung: Sie kann Konfigurationsdetails offenlegen. Verwendet den geschützten Verwaltungsbereich, die Diensteinstellungen oder eine geeignete interne Prüfung. Nach der Wartung muss erkennbar sein, welcher Pool beziehungsweise welche Modulversion die Anfragen tatsächlich verarbeitet.

Ein Paketupdate allein erneuert nicht zwingend jeden Prozess

PHP-FPM und andere Arbeitsprozesse können über viele Anfragen hinweg laufen. Prüft im Wartungsablauf des jeweiligen Systems, wie aktualisierte Binaries übernommen werden, und erneuert die betroffenen Dienste oder Deployments kontrolliert. Eine geänderte Datei auf dem Datenträger ist nicht derselbe Nachweis wie ein laufender Prozess auf dem korrigierten Stand. Beim erneuten Prüfen müssen auch weitere Server, Hintergrundumgebungen und Lastverteilungsziele berücksichtigt werden.

Bei Linux-Backports nicht nur Versionsnummern vergleichen

Distributoren können einzelne Sicherheitskorrekturen in einen älteren Softwarestand übernehmen. Deshalb kann ein Paket mit einer älteren sichtbaren PHP-Basisversion dennoch die nötige Korrektur enthalten. Umgekehrt beweist der allgemeine Status „LTS“ nicht, dass genau diese CVEs schon behoben sind. Maßgeblich sind Paketrevision und Sicherheitshinweis des zuständigen Anbieters. Die Backport-Erklärung von Red Hat erläutert dieses Prinzip; die beiden Ubuntu-CVE-Seiten zeigen, weshalb Status und Paketzweig einzeln betrachtet werden müssen.

Container brauchen korrigierte Images und ein wirksames Deployment

Ein Update auf dem Container-Host tauscht nicht automatisch die PHP-Laufzeit innerhalb eines unveränderten Images aus. Bezieht ein passendes korrigiertes Basisimage, baut eigene Anwendungsimages neu und rollt sie nach eurem Verfahren aus. Prüft anschließend die tatsächlich aktiven Replikate und die zugehörigen Imagekennungen. Alte Testcontainer und zusätzliche Worker dürfen nicht als ungepflegte Nebenwege übrig bleiben. Die Docker-Empfehlungen zum regelmäßigen Neubau von Images liefern den allgemeinen Hintergrund dazu.

Helfen WAF, Upload-Sperren oder PHP-Einstellungen?

Die vollständige Behebung erfolgt durch die passenden Sicherheitskorrekturen. Die PHP-Advisories beschreiben Konfigurationsmaßnahmen gegen bestimmte Angriffspfade, erklären aber zugleich ihre Grenzen. Wer einen einzelnen Tipp aus sozialen Medien herauskopiert, kann damit einen Teilpfad beeinflussen und trotzdem andere Voraussetzungen unverändert lassen.

Besonders erklärungsbedürftig ist der vom PHP-Projekt genannte Umgang mit dem Speicherlimit: Eine administrative Einstellung memory_limit=-1 kann einen bestimmten kontrollierbaren Fehlerpfad reduzieren, hebt aber die betreffende PHP-Speichergrenze auf. Sie ist deshalb kein allgemeiner Tipp für das WordPress-Dashboard und kein harmloser Kopierbefehl. Verfügbarkeitsgrenzen des Betriebssystems, Worker-Verhalten und die Anwendung müssen mitbedacht werden. Der Hersteller betont auch hier, dass zugrunde liegende Speicherfehler möglich bleiben.

Konfigurationsänderungen müssen außerdem an der richtigen Stelle wirksam werden. Einstellungen, die erst innerhalb einer bereits laufenden Anwendung greifen, können für vorgelagerte Verarbeitungsschritte zu spät kommen. PHP nennt ausdrücklich Grenzen bestimmter ini_set()– und .user.ini-Ansätze. Verantwortliche sollten deshalb die konkreten Hinweise zur Zustandslücke und zum eigenen Betriebsmodus lesen. Eine pauschale „Drei Zeilen einfügen, dann ist alles sicher“-Anleitung wäre hier unzuverlässig.

Wenn eine geeignete Korrektur kurzfristig nicht möglich ist, empfehlen BSI und CERT-EU, eine zeitweise Einschränkung der öffentlichen Erreichbarkeit zu erwägen. Das sollte gemeinsam mit den betrieblich Verantwortlichen entschieden werden. Eine Wartungsseite am falschen Endpunkt reicht nicht, wenn weitere PHP-Routen weiterhin öffentlich erreichbar bleiben.

Was bei verdächtigen Änderungen oder einem möglichen Angriff zu tun ist

Das BSI nennt in Version 1.0 noch keine belastbare Liste eindeutiger Angriffsindikatoren für diesen konkreten Fall. Allgemeine Auffälligkeiten sind daher Hinweise für eine Untersuchung, keine Diagnose „PHP2Shell“. Dazu können unerwartete Dateiänderungen, neue Administratorkonten, verdächtige ausgehende Verbindungen oder ungewöhnliche Fehlerhäufungen gehören. Ebenso kann eine solche Auffälligkeit eine andere Ursache haben.

1. Zuständige Stelle einbinden: Hoster, Administratoren und gegebenenfalls Incident-Response-Dienstleister informieren.
2. Beweismittel erhalten: Verfügbare Protokolle, Zeitpunkte und betroffene Systeme nachvollziehbar sichern; nicht vorschnell alles überschreiben.
3. Erreichbarkeit bewerten: Gemeinsam entscheiden, welche Zugänge oder Anwendungen vorübergehend eingeschränkt werden müssen.
4. Korrektur und Bereinigung unterscheiden: Das Schließen der Sicherheitslücke entfernt nicht automatisch bereits abgelegte Schadsoftware.
5. Wiederanlauf kontrollieren: Nur nachvollziehbar bereinigte und korrigierte Systeme wieder in den vorgesehenen Betrieb nehmen.

Ein Backup ist dafür ein wichtiger Baustein, aber kein automatischer Sauberkeitsnachweis. Eine Sicherung aus einem bereits kompromittierten Zustand kann den Fehler wiederherstellen. Die WordPress-Hinweise zur Absicherung und zur Datensicherung bieten allgemeine Grundlagen. Konkrete Zugangsdaten sollten bei einem bestätigten Vorfall abgestimmt und von einem vertrauenswürdigen System aus behandelt werden.

Für eine öffentliche Behauptung, ein bestimmter Shop oder Dienst sei über diese Lücken angegriffen worden, braucht es belastbare Belege. Die Verwendung von PHP allein ist ein solcher Beleg nicht. Das gilt ebenso für die eigene Website: Aus einer Versionsnummer lässt sich nicht rückwirkend ablesen, ob und wann ein Angriff erfolgreich war.

Was die Warnung für Onlineshops und normale Internetnutzer bedeutet

Für einen Shop verbindet sich die technische Wartung mit laufenden Bestellungen, Zahlungen, Schnittstellen und Kundenkonten. Deshalb ist ein kurzer, geplanter Funktionscheck nach der Korrektur besonders sinnvoll: Startseite, Anmeldung, Warenkorb, Zahlungsübergabe, Bestellbestätigung und angebundene Hintergrundprozesse gehören in die betriebliche Prüfung. Ein bloßer Aufruf der Homepage kann diese Abläufe nicht abdecken.

Vor einem größeren PHP-Zweigwechsel sollte außerdem klar sein, welche Erweiterungen und Integrationen kompatibel sind. Ein eng begrenztes Sicherheitsupdate im bestehenden Zweig und eine umfangreiche Plattformmigration sind zwei unterschiedliche Wartungsvorhaben. Die Priorität ist zunächst eine belegbar korrigierte Laufzeit; die langfristige Modernisierung einer auslaufenden Umgebung folgt als eigene Aufgabe.

Als Kundin oder Kunde kannst du die PHP-Version eines fremden Shops nicht zuverlässig von außen prüfen. Ein Schloss-Symbol für HTTPS bestätigt nicht den PHP-Patchstand. Umgekehrt ist eine öffentlich verwendete PHP-Technik kein Grund, einen konkreten Betreiber ohne weitere Hinweise als unsicher darzustellen. Bei einer tatsächlichen Vorfallmeldung des Dienstes sind dessen konkrete Hinweise zu beachten.

Ebenso wichtig: Für diesen serverseitigen Fehler brauchst du kein angebliches „PHP-Update“ als Browser-Erweiterung. Lade keine Reparaturprogramme aus fremden Warnmails herunter und gib keine Hosting-Zugangsdaten auf nachgebauten Loginseiten ein. Die Korrektur erfolgt über den zuständigen Anbieter beziehungsweise die Serververwaltung. Ein Passwortwechsel kann bei einem Vorfall sinnvoll sein, beseitigt aber die Lücke in der Laufzeit nicht.

Deine Handlungshilfe: Was solltest du als Nächstes tun?

Fertige Anfrage an deinen Hosting-Anbieter

Die folgende Vorlage fragt gezielt nach der technischen Behebung. Ergänze deine Domain und gegebenenfalls Vertragskennung selbst. Der Kopierknopf versendet keine Nachricht.

Checkliste: Wann ist die Aufgabe für meine Website erledigt?

Die Liste unterstützt die Abstimmung mit der zuständigen Administration. Sie ist kein automatisches Sicherheitszertifikat und ersetzt bei einem Vorfall keine Untersuchung.

• Zuständige Person oder Anbieter für PHP festgelegt.
• Hauptdomain, Subdomains und relevante Nebeninstallationen erfasst.
• Tatsächliche Web-PHP-Version beziehungsweise Paketrevision notiert.
• Behebung beider CVEs durch Hersteller- oder Anbieterhinweis bestätigt.
• Aktualisierte Laufzeit auch in den arbeitenden Prozessen beziehungsweise Containern aktiv.
• Funktionsprüfung von Anmeldung, Formularen und gegebenenfalls Shopabläufen durchgeführt.
• Auffälligkeiten und bestehende Protokolle mit den Verantwortlichen bewertet.
• Für ältere PHP-Zweige einen unterstützten Zielstand beziehungsweise belastbaren LTS-Pfad geplant.

Für die Dokumentation genügt eine klare, nachvollziehbare Rückmeldung: betroffene Umgebung, korrigierter Paketstand, Zeitpunkt der Aktivierung und durchgeführte Funktionskontrolle. Eine allgemeine Werbeaussage „Wir kümmern uns um Sicherheit“ beantwortet diese Fragen nicht. Ebenso sollte niemand allein wegen eines erledigten Updates behaupten, sämtliche denkbaren Angriffsfolgen seien damit ausgeschlossen.

Häufige Fragen zu PHP2Shell, WordPress und den Sicherheitsupdates

Fazit: Entscheidend ist die korrigierte PHP-Laufzeit hinter deiner Website

Quellen, Veröffentlichungsstand und redaktionelle Einordnung

Die konkrete Sicherheitsbewertung stützt sich auf BSI, CERT-EU und die Veröffentlichungen des PHP-Projekts. Allgemeine Betriebsanleitungen sind als solche eingeordnet. Die BSI-Version 1.0 ist eine Vorabmeldung; die später verfügbaren PHP-Angaben werden ergänzend berücksichtigt.

• BSI: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit, Version 1.0 vom 21. Oktober 2026.
• BSI: vollständiger Sicherheitshinweis als PDF, vier Seiten; Einstufung Orange, Hinweise zu Produkten, Betrieb und Bewertung.
• PHP: Veröffentlichungen und Sicherheitsmeldung vom 20./21. Oktober 2026, korrigierte Releases und weiterführende Advisories.
• PHP-Hersteller-Advisory GHSA-w8hw-w9fx-j79w, CVE-2026-109618.
• PHP-Hersteller-Advisory GHSA-6wmf-4rv5-p3rp, CVE-2026-109619.
• PHP: Änderungsübersicht der Versionen 8.x, Zuordnung der Sicherheitskorrekturen.
• PHP: offizielle Download- und Installationsseite, keine Empfehlung zum unkontrollierten Austausch verwalteter Serverpakete.
• PHP: unterstützte Versionszweige, reguläre Supportzeiträume.
• CERT-EU: Security Advisory 2026-018, Vorabinformation und Empfehlung zur Identifikation betroffener Systeme.
• Ubuntu: CVE-2026-109618, paketabhängiger Status.
• Ubuntu: CVE-2026-109619, paketabhängiger Status.
• Red Hat: Security Backporting Practice, allgemeine Erklärung zurückportierter Korrekturen.
• WordPress: PHP aktualisieren, allgemeine Anleitung zu Versionsabfrage, Vorbereitung und Zuständigkeit.
• WordPress: Site Health screen, Serverinformationen im Verwaltungsbereich.
• WordPress: Funktionsweise des PHP-Versionstests, Grenzen der allgemeinen Zustandsbewertung.
• WordPress: Hardening, allgemeine Absicherung und Vorgehen bei Sicherheitsproblemen.
• WordPress: Backups, allgemeine Grundlagen zu Sicherung und Wiederherstellung.
• Docker: bewährte Vorgehensweisen beim Image-Bau, regelmäßiger Neubau und aktualisierte Grundlagen.