Die als CVE-2026-109618 und CVE-2026-109619 geführten Lücken werden unter dem Namen „PHP2Shell“ diskutiert. Beide sind mit 9,2 von 10 Punkten nach CVSS v4.0 als kritisch eingestuft. [2] [3] [8]

Was bedeutet 9,2 von 10 Punkten?

CVSS steht für Common Vulnerability Scoring System. Das standardisierte Verfahren bewertet die technische Schwere einer Sicherheitslücke auf einer Skala von 0 bis 10. Ab 9,0 beginnt die höchste Schwereklasse „kritisch“. 9,2 liegt damit in dieser höchsten Kategorie. In die Bewertung fließen unter anderem der mögliche Zugangsweg, die Voraussetzungen eines Angriffs sowie die möglichen Folgen ein: ob Daten gestohlen oder manipuliert werden könnten und ob ein Dienst ausfallen könnte. [13]

Bei diesen beiden PHP-Lücken nennt die Bewertung einen Angriff über das Netzwerk, ohne vorhandenes Benutzerkonto und ohne Mitwirkung eines Nutzers. Zugleich stuft sie die technische Angriffskomplexität als hoch ein und nennt zusätzliche Angriffsvoraussetzungen. 9,2 ist deshalb keine Angabe wie „92 Prozent Angriffswahrscheinlichkeit“. Der Wert kennzeichnet eine besonders schwere Schwachstelle. Ob und wie eine bestimmte Installation angegriffen werden kann, hängt auch von ihrer PHP-Version, Konfiguration und den erreichbaren Angriffspfaden ab. Ein bereits erfolgter Einbruch lässt sich aus der Zahl nicht ablesen. [2] [3]

Nicht nur WordPress: Laravel, Symfony und weitere PHP-Systeme

Die Fehler liegen in der PHP-Laufzeit, also in der Software, die den Anwendungscode auf dem Server ausführt. Deshalb betrifft die Prüfung auch größere Unternehmensanwendungen auf Basis von Laravel, Symfony oder Laminas. Diese Frameworks sind Bausteine, mit denen Entwickler etwa Kundenportale, Buchungssysteme oder Schnittstellen für andere Programme erstellen. Ein aktuelles Framework ersetzt kein Sicherheitsupdate der darunter laufenden PHP-Installation. [1] [14]

Die genannten Systeme verwenden PHP. Die möglichen Folgen sind Beispiele und hängen von der jeweiligen Anwendung und ihren Zugriffsrechten ab. Die Liste ist keine Bestätigung, dass jede Installation dieser Produkte über denselben Weg angreifbar ist. [4] [14] [15] [16]

Ein Beispiel für Laravel oder Symfony: Ein Unternehmen betreibt ein Kundenportal, in dem Rechnungen und hochgeladene Dokumente liegen. Gelingt einem Angreifer die Codeausführung im Webprozess, könnte er mit dessen Rechten auf erreichbare Dateien oder Datenbanken zugreifen. Welche Unterlagen er lesen oder verändern könnte, hängt von den tatsächlich vergebenen Berechtigungen ab. Auch ein solches Portal hinter einer Anmeldeseite muss die PHP-Korrekturen erhalten, wenn der verwundbare Webprozess bereits vor der Anmeldung erreichbar ist. Das ist ein mögliches Schadensszenario, kein Bericht über einen konkreten Einbruch.

Was Code auf dem Server ausführen konkret bedeutet

Auf einer PHP-Website läuft bereits bei normalen Seitenaufrufen Programmcode: WordPress lädt Beiträge aus der Datenbank, eine Laravel-Anwendung verarbeitet eine Buchung, ein Shop legt eine Bestellung an. Bei einer solchen Sicherheitslücke kann ein Angreifer eigene Anweisungen ausführen lassen. Dafür benötigt er bei den beschriebenen Angriffen kein Benutzerkonto in der jeweiligen Anwendung.

Die folgenden Beispiele veranschaulichen mögliche Folgen eines erfolgreichen Angriffs. Was tatsächlich möglich ist, hängt von den Zugriffsrechten, gespeicherten Daten, verfügbaren Diensten und erlaubten Netzwerkverbindungen ab:

• Den Server aus der Ferne steuern: Reverse Shell. Der kompromittierte Server baut selbst eine Verbindung zu einem System des Angreifers auf. Über diese Verbindung kann der Angreifer weitere Befehle schicken und deren Ergebnisse erhalten, etwa um erreichbare Dateien zu durchsuchen. Dafür muss die ausgehende Verbindung möglich sein. Die Fernsteuerung hat zunächst die Rechte des angegriffenen Prozesses; sie ist keine automatische Übernahme des gesamten Servers mit Administratorrechten. [18]
• Einen späteren Zugang hinterlassen: Webshell. Mit ausreichenden Schreibrechten könnten Angreifer Schadcode in einer ausführbaren Website-Datei ablegen. Eine solche Webshell lässt sich über Webanfragen ansprechen und ermöglicht weitere Aktionen auf dem Server. Sie kann auch nach einem PHP-Update vorhanden sein. Eine Reverse Shell und ein dauerhaft hinterlassener Zugang sind dabei unterschiedliche Dinge: Eine einzelne Fernsteuerverbindung bleibt nicht automatisch nach einem Neustart bestehen. [17]
• Kunden- und Geschäftsdaten auslesen. Kann der angegriffene Prozess auf die Datenbank zugreifen, könnten etwa gespeicherte Namen, E-Mail-Adressen, Lieferanschriften oder Bestellungen kopiert werden. Für einen Shop kann das einen Datenabfluss und eine aufwendige Untersuchung bedeuten.
• Die Website manipulieren und SEO-Spam einschleusen. Mit den nötigen Schreibrechten könnten Angreifer Inhalte ändern, unerwünschte Werbeseiten und betrügerische Links einbauen oder Besucher auf gefälschte Anmeldeseiten umleiten. SEO-Spam bezeichnet hier eingeschleuste Inhalte, die Suchmaschinenbesucher zu fremden Angeboten locken sollen. Kunden würden solche Inhalte möglicherweise zunächst unter der vertrauten Domain des Unternehmens sehen.
• Spam- und Phishing-Mails versenden. Kann der Prozess E-Mails verschicken oder nutzbare Mail-Zugangsdaten auslesen, könnte der Server massenhaft unerwünschte oder betrügerische Nachrichten versenden. Wird die Versand-IP wegen Missbrauchs blockiert, können auch legitime Geschäftsmails betroffen sein. [19]
• Den Server in ein Botnetz einbinden. Ein Botnetz ist ein Verbund fremdgesteuerter Geräte oder Server. Der Webserver könnte darin DDoS-Angriffe unterstützen: Viele Systeme senden gleichzeitig Anfragen, um einen fremden Dienst zu überlasten. Die eigene Website kann dabei weiterhin normal wirken. [19]
• Rechenleistung und Bandbreite missbrauchen. Angreifer könnten verfügbare Ressourcen beispielsweise für das Schürfen von Kryptowährungen oder als Zwischenstation für fremden Netzwerkverkehr nutzen. Mögliche Folgen sind eine langsamere Anwendung, verbrauchte Kontingente und bei nutzungsabhängiger Abrechnung zusätzliche Kosten. Dafür müssen die jeweiligen Programme oder Netzwerkfunktionen ausführbar und erreichbar sein. [17]
• Den eigenen Betrieb stören. Erreichbare Dateien oder Datenbankinhalte könnten verändert, gelöscht oder bei entsprechenden Schreibrechten verschlüsselt werden. Mögliche Folgen sind ausgefallene Formulare, verlorene Inhalte und ein vorübergehend nicht nutzbarer Shop. [19]

Ein Beispiel für WordPress: Die Datei wp-config.php enthält die Datenbank-Verbindungsinformationen der Website. Kann fremder Code diese Informationen nutzen und die Datenbank erreichen, können die dort vergebenen Rechte auch einen Zugriff auf gespeicherte Website-Daten ermöglichen. Der Angreifer müsste dafür nicht zuerst das WordPress-Admin-Passwort kennen. [9]

Die PHP-Berichte bestätigen Codeausführung mit den Rechten des Webprozesses. Das bedeutet nicht automatisch vollständige Administratorrechte auf dem gesamten Server. Reverse Shells, Webshells, Spam-Versand, Botnetze und die anderen Beispiele sind mögliche Folgen einer erfolgreichen Kompromittierung. Dieser Beitrag behauptet damit nicht, dass diese Aktivitäten bereits bei einem konkreten PHP2Shell-Opfer nachgewiesen wurden. [2]

Dokumentierte Folgen aus Fallberichten von 2025 und 2026

Die folgenden Fallberichte beschreiben bereits kompromittierte Websites und andere Einbruchswege. Sie zeigen dokumentierte Folgen fremden Codes auf Webservern und Websites. Sie sind keine Schadensmeldungen zu den aktuellen PHP2Shell-Lücken. Die Datumsangaben beziehen sich auf die Veröffentlichung der jeweiligen Untersuchung.

September 2026: WordPress-Hintertür kehrte nach dem Löschen sofort zurück

Am 30. September 2026 beschrieb Sucuri einen untersuchten WordPress-Befall, bei dem eine Hintertür innerhalb von Sekunden nach ihrer Entfernung wieder auftauchte. Die Schadsoftware mit der Bezeichnung „SC“ war an mindestens acht Stellen verankert, verteilt auf Dateien, Datenbank und gemeinsam genutzten Arbeitsspeicher. Verbliebene Bestandteile konnten die gelöschten Teile wiederherstellen. Das sichtbare Schadprogramm zu löschen, beendete den unbefugten Zugriff deshalb nicht. Der untersuchte Code konnte außerdem einen versteckten Administratorzugang anlegen. [10]

Mai 2026: Spam-Weiterleitungen durch eine Hintertür auf Serverebene

In einer am 20. Mai 2026 veröffentlichten Untersuchung schilderte Wordfence einen WordPress-Betreiber, dessen Besucher beim Klicken Spam-Seiten in neuen Tabs öffneten. Entfernte der Betreiber den eingeschleusten Code, kehrte er innerhalb weniger Stunden zurück. Eine Prüfung auf WordPress-Ebene fand keine verbliebenen Auffälligkeiten. Erst die Untersuchung des Servers führte zu einer Hintertür mit Root-Rechten im Umfeld der Webmail-Software. Die Website wurde wiederholt manipuliert, obwohl die Bereinigung innerhalb von WordPress zunächst erfolgreich aussah. Die Rechteausweitung war Teil dieses konkreten Angriffs und ist keine automatische Folge jeder PHP-Lücke. [11]

WooCommerce 2025: Manipulierter Checkout und abgegriffene Zahlungsdaten

In einem am 14. März 2025 veröffentlichten Fallbericht beschrieb Sucuri einen kompromittierten WordPress-Shop mit WooCommerce. Das Untersuchungsteam fand Schadcode im Checkout, der Kreditkarten- und Rechnungsdaten an einen fremden Server übermittelte, sowie eine versteckte PHP-Hintertür. Laut Bericht hatten Kunden ungewöhnliche Aktivitäten auf ihren Kreditkarten nach Einkäufen in dem Shop gemeldet. Damit betraf der Angriff auch Menschen, die lediglich im Shop einkauften. Die ursprüngliche Einbruchsmethode und eine belastbare finanzielle Schadenssumme nennt der Bericht nicht. [12]

Für Betreiber sind damit konkrete Folgen belegt: fortbestehender Fremdzugriff, wiederholte Manipulationen und das Abgreifen von Zahlungsdaten. Die genannten Fallberichte liefern keine belastbare finanzielle Gesamtschadenssumme.

Warum aktuelle Anwendungen auf einer verwundbaren PHP-Version laufen können

WordPress ist die Anwendung, PHP führt deren Programmcode auf dem Server aus. Der Hoster bestimmt, welche PHP-Versionen verfügbar sind. Deshalb sind WordPress-Updates, Plugin-Updates und PHP-Updates unterschiedliche Wartungsaufgaben. Bei Managed Hosting kann der Anbieter PHP selbst aktualisieren; Betreiber sollten die Umsetzung trotzdem bestätigen lassen. [4]

Ein Beispiel: Eine Unternehmenswebsite hat alle WordPress-Updates installiert. Im Hosting läuft aber weiterhin PHP 8.3.35 ohne zurückportierte Sicherheitskorrektur. Die aktuellen WordPress-Dateien beheben den Fehler in dieser PHP-Installation nicht. Dasselbe Prinzip gilt für einen WooCommerce- oder Shopware-Shop sowie Anwendungen mit Laravel, Symfony oder Laminas: Auch deren Laufzeitumgebung muss gepatcht werden.

Besonders relevant ist ein Detail aus dem offiziellen Sicherheitsbericht: Bei Apache mit mod_php wurde ein Angriff nachgewiesen, der vor dem Start des Anwendungscodes ansetzt. Daraus folgt, dass Schutzmaßnahmen innerhalb der Anwendung für diesen Angriff zu spät greifen können. Ein Wartungsmodus per WordPress-Plugin ist deshalb keine verlässliche Isolation der verwundbaren PHP-Installation. [2]

Was über die beiden Sicherheitslücken gesichert ist

Bei CVE-2026-109618 kann ein Fehler bei Speichermangel dazu führen, dass PHP unvollständig initialisierte interne Daten weiterverarbeitet. CVE-2026-109619 betrifft internen Zustand, der nach einer Anfrage auf bereits freigegebenen Speicher verweist und bei einer späteren Anfrage erneut verwendet werden kann. Beide Fehler können zur Ausführung fremden Codes führen. [2] [3]

Die pauschale Beschreibung als reine Upload-Fortschrittslücke greift damit zu kurz. Die Funktion session.upload_progress ist an einem bestätigten Angriffspfad beteiligt; die veröffentlichten Berichte beschreiben weitere Pfade. Erfolgreich ausgeführter Code erhält zunächst die Rechte des PHP-Webprozesses. Welche Daten und anderen Systeme dadurch erreichbar sind, hängt von dessen Berechtigungen ab. [3]

Die frühe Warnung von CERT-EU nannte eine mögliche Betroffenheit ab PHP 5. Für die konkrete Freigabe einer Installation sollten Betreiber sich jetzt an den veröffentlichten Sicherheitskorrekturen und den Angaben ihres Paketlieferanten orientieren. [5]

Welche PHP-Versionen die Fehler beheben

Quelle: PHP-Sicherheitsmeldung vom 21. Oktober 2026. Bei Distributionspaketen kann eine zurückportierte Korrektur enthalten sein, obwohl die angezeigte PHP-Basisversion älter ist. Entscheidend ist die Bestätigung des Anbieters für beide CVEs. [1]

PHP 8.1 und ältere Reihen erhalten keine regulären Updates mehr vom PHP-Projekt. Für PHP 7.4, 8.0 und 8.1 stellt das Projekt ausnahmsweise minimale Quellcode-Backports bereit. Das ersetzt weder die Installation eines korrigierten Pakets noch die Planung eines Upgrades auf eine unterstützte Reihe. Bei LTS-Angeboten muss der jeweilige Anbieter den Schutz bestätigen. [1]

Was Website-Betreiber jetzt tun sollten

1. Zuständigkeit klären. Wer kann die PHP-Installation aktualisieren: der Hoster, die betreuende Agentur oder die eigene IT? Eine Person sollte die Bestätigung für alle betroffenen Websites einsammeln.
2. Die tatsächlich verwendete Version prüfen. In WordPress steht sie üblicherweise unter Werkzeuge → Website-Zustand → Bericht → Server. Bei abweichender Übersetzung helfen die englischen Bezeichnungen Tools → Site Health → Info → Server. Bei Laravel, Symfony und anderen Anwendungen sollte die verantwortliche IT den Versions- und Patchstand des produktiven PHP-Webdienstes bestätigen. [4]
3. Das Sicherheitsupdate veranlassen. Nach Möglichkeit zunächst innerhalb der vorhandenen, unterstützten Versionsreihe aktualisieren. Einen größeren Versionswechsel mit alten Plugins muss die betreuende Person gesondert prüfen. Ein verfügbares Backup und ein kurzer Funktionstest gehören dazu.
4. Das Ergebnis bestätigen lassen. Gefragt sind die korrigierte PHP-Paketversion und die Bestätigung, dass alle betroffenen Webprozesse sie verwenden. Anschließend insbesondere Login, Formulare, Uploads und bei Shops den Bestellablauf kontrollieren.
5. Ungeschützte Systeme abschirmen. Ist ein Update nicht zeitnah möglich, sollte die IT eine Isolation von öffentlichen Netzen prüfen. CERT-EU empfiehlt diese Abwägung ausdrücklich. Eine statische Wartungsseite kann dafür weiter sichtbar bleiben, sofern öffentliche Anfragen tatsächlich nicht mehr an das verwundbare PHP gelangen. [5]

Diese Anfrage lässt sich direkt an den Hoster schicken

Bitte bestätigen Sie für meine Domain beziehungsweise Anwendung, ob CVE-2026-109618 und CVE-2026-109619 in der produktiv verwendeten PHP-Installation behoben sind. Welche Paketversion beziehungsweise welcher Sicherheits-Backport ist aktiv? Verwenden alle betroffenen Webprozesse bereits die korrigierte Version? Falls nicht: Wann erfolgt das Update, und wie wird die Website bis dahin geschützt?

Warum eine einzelne Einstellung kein vollständiger Schutz ist

Der verbreitete Rat, session.upload_progress.enabled=0 zu setzen, ist nur eine begrenzte Maßnahme. Laut PHP blockiert sie bestätigte Session-Angriffspfade von CVE-2026-109619, sofern sie früh genug greift und alle Worker neu gestartet werden. Andere Pfade bleiben bestehen. [3]

Das PHP-Team stellt klar: Vollständig beheben lässt sich das Problem nur durch das Update. Auch vorgeschaltete Filter und Firewall-Regeln sollten deshalb als zusätzliche Maßnahme behandelt werden. Eine unauffällige Website oder ein einzelner negativer Online-Test sind kein belastbarer Nachweis, dass die Installation korrigiert ist. [1]

Was Entwickler bei Laravel, Symfony und anderen PHP-Anwendungen prüfen sollten

Die folgende Prüfliste ist eine betriebliche Empfehlung aus den veröffentlichten Befunden:

• Web-Laufzeit statt nur Terminal prüfen. php -v zeigt das aufgerufene CLI-Programm. Eine Website kann über einen anderen PHP-FPM-Pool, Container oder Server laufen.
• Alle Instanzen erfassen. Dazu zählen produktive Server, öffentlich erreichbare Testsysteme, alte Subdomains und Hilfswerkzeuge auf PHP-Basis. Bei Container-Betrieb müssen die korrigierten Images auch tatsächlich ausgerollt sein.
• Laufende Prozesse erneuern. Ein Paketupdate auf dem Dateisystem genügt als Nachweis nicht. Prüfen, ob die betroffenen Dienste und langlebigen Prozesse mit der korrigierten Laufzeit neu gestartet wurden.
• Abhängigkeiten getrennt behandeln. Ein composer update installiert Bibliotheken; die PHP-Laufzeit ist ein eigener Bestandteil des Deployments.
• Nachweise festhalten. Paketkennung, Herstellerhinweis zu beiden CVEs, ausgerollte Instanzen, Neustarts und Funktionstests dokumentieren. Bei einem Sicherheits-Backport ist der Herstellerhinweis aussagekräftiger als die Basisversion allein.

Sollte man wegen PHP2Shell die Plattform wechseln?

Meine Einordnung: Für den laufenden Vorfall hat das Patchen Vorrang. Ein Wechsel zu Node.js, Python oder einer anderen Plattform ist ein eigenes Projekt mit Migration, Tests und neuen Betriebsaufgaben. Er liefert keine pauschale Sicherheitsgarantie. Über einen Wechsel sollte entscheiden, ob sich das bestehende System zuverlässig und wirtschaftlich betreiben lässt.

Die Tabelle enthält Empfehlungen, keine Rangliste der Sicherheit einzelner Produkte. Zum statischen Rendering: Astro-Dokumentation [6].

Ein wichtiges Detail bei einem neuen Frontend: Bleibt WordPress dahinter als öffentlich erreichbares Redaktionssystem oder als API aktiv, bleibt auch diese PHP-Installation wartungsbedürftig. Die WordPress-REST-API ermöglicht ausdrücklich separate Oberflächen und Anwendungen. Ein neues Design allein beseitigt das bestehende Backend nicht. [7]

Ein Update beantwortet noch nicht die Frage nach einem früheren Einbruch

Eine korrigierte Laufzeit schließt die beschriebenen Fehler. Bereits abgelegte Schadsoftware oder gestohlene Zugangsdaten werden dadurch nicht automatisch entfernt. Bei verdächtigen Änderungen, unbekannten Administratorkonten oder auffälligen Serverprozessen sollte die zuständige IT deshalb zusätzlich den möglichen Vorfall untersuchen.

Für Betreiber bedeutet das: Update-Status und mögliche Kompromittierung getrennt prüfen lassen. Fehlen verdächtige Einträge in den Logs, ist das für sich genommen keine Entwarnung; auch der PHP-Sicherheitsbericht weist auf die Grenzen von Log-Prüfungen hin. [3]

Die Untersuchung sollte auch ausgehende Verbindungen, fremde Prozesse, Mail-Versand und Lastspitzen prüfen. Bei begründetem Verdacht sollte die IT den Server isolieren, Protokolle sichern und neben dem Einbruchsweg auch hinterlassene Zugänge und möglicherweise gestohlene Zugangsdaten untersuchen. [17] [19]

Quellen und Recherche

Dieser Beitrag wertet öffentlich zugängliche Originalquellen aus. Eigene Exploit-Tests oder Untersuchungen betroffener Kundensysteme sind nicht Grundlage des Artikels. Die Handlungsempfehlungen und die Bewertung eines Plattformwechsels sind als eigene Einordnung gekennzeichnet. Vor einer späteren Umsetzung sind neuere Herstellerhinweise zu berücksichtigen.

1. PHP-Projekt: Security advisory und Sicherheitsreleases vom 21. Oktober 2026
2. PHP-Projekt: CVE-2026-109618: RCE via OOM corruption
3. PHP-Projekt: CVE-2026-109619: RCE via stale global state
4. WordPress.org: PHP-Version prüfen und aktualisieren
5. CERT-EU: Security Advisory 2026-018. Frühe Warnung vor Veröffentlichung der Patches
6. Astro: Statisches und serverseitiges Rendering
7. WordPress: REST API Handbook
8. watchTowr: PHP2Shell FAQ. Einordnung der öffentlich verwendeten Bezeichnung
9. WordPress: Konfigurationsdatei und Datenbank-Verbindungsinformationen
10. Sucuri: SC WordPress Malware, 30. September 2026
11. Wordfence: How a Webmail Log File Became a Root-Level Backdoor, 20. Mai 2026
12. Sucuri: Credit Card Skimmer and Backdoor on WordPress E-commerce Site, 14. März 2025
13. FIRST: CVSS v4.0, Bewertungskriterien und Schwereklassen
14. PHP-Anforderungen und Betrieb der Frameworks: Laravel, Symfony und Laminas
15. Drupal: PHP-Anforderungen
16. PHP-basierte Shopsysteme: Shopware: Hosting sowie Adobe Commerce und Magento Open Source: Systemanforderungen
17. MITRE ATT&CK: Web Shell, Proxy und Resource Hijacking
18. Cloudflare: Technische Analyse mit Erläuterung einer Reverse Shell. Grundlage der Begriffserklärung, kein PHP2Shell-Fallbericht
19. Sucuri: Web Shells, Types, Mitigation & Removal, 26. März 2026. Einordnung möglicher Folgen und der Untersuchung eines kompromittierten Webservers