CVE-2026-87902: Kritische Schwachstelle in WordPress Core ermöglicht unter bestimmten Bedingungen unauthentifizierte RCE

WordPress hat ein Notfall-Sicherheitsupdate veröffentlicht, das eine kritische Schwachstelle in seiner Core-Software adressiert, die einem nicht authentifizierten Angreifer erlaubt, beliebige lokale PHP-Dateien zu laden und unter bestimmten Server- und Theme-Bedingungen eine Remote-Code-Ausführung zu erreichen. Diese als CVE-2026-87902 verfolgte Schwachstelle betrifft WordPress-Versionen von 4.7.0 bis 7.1.1 und hat einen CVSS 4.0-Score von 9,2.

Der Fehler liegt in der Seitenvorlagen-Auflösung von WordPress. Ein Angreifer kann den Wert manipulieren, den WordPress beim Auswählen einer Seitenvorlage verwendet, und dazu führen, dass die Funktion get_page_template() eine lesbare PHP-Datei außerhalb der Verzeichnisse des aktiven Themas einbezieht. Für die zugrunde liegende File-Inclusion-Attacke ist kein WordPress-Konto, Authentifizierungs-Cookie, Administrator-Interaktion oder anfälliges Plugin erforderlich.

Die Ausführung von Remote-Code ist bedingt und nicht universell. Das aktive Theme muss eine kompatible Verzeichnisstruktur enthalten, und der Server muss eine geeignete, lesbare PHP-Datei bereitstellen, die bei Einbeziehung ausgenutzt werden kann. Der öffentlich demonstrierte Angriff nutzte die Datei pearcmd.php von PEAR in einer Umgebung, in der die register_argc_argv-Einstellung von PHP aktiviert war.

WordPress hat am 22. September 2026 Version 7.1.2 speziell für die Behebung der Schwachstelle veröffentlicht und hat Korrekturen für gewartete Sicherheitszweige bis zurück zu WordPress 4.7 rückportiert. Site-Administratoren wird dringend empfohlen, sofort zu aktualisieren.

Vertrieb kontaktieren

Analyse von CVE-2026-87902

Die Schwachstelle entsteht darin, wie WordPress Core Vorlagen für Seiten auflöst. Wenn ein Besucher eine Seite anfordert, erstellt WordPress eine Liste potenzieller Vorlagendateinamen und durchsucht das aktive Theme nach einer passenden Datei.

In anfälligen Versionen sind die durch Angreifer kontrollierten Daten, die in diesem Prozess verwendet werden, nicht ausreichend eingeschränkt, bevor sie in den Seitenvorlagen-Pfad integriert werden. Eine manipulierte Anforderung kann daher Verzeichnisüberschreitungssequenzen einführen und dazu führen, dass WordPress eine PHP-Datei auflöst, die sich außerhalb der erwarteten Verzeichnisse des aktiven Themas befindet.

Der Schlüssel Details für CVE-2026-87902 sind, dass die Kernprimitive die lokale Dateieinbeziehung und nicht die uneingeschränkte Ausführung beliebigen Codes ist. WordPress beschreibt das Problem offiziell als eine Möglichkeit für einen nicht authentifizierten Angreifer, die Seitenvorlagenauflösung dazu zu bringen, eine ausgewählte, lesbare lokale .php-Datei außerhalb der Theme-Verzeichnisse einzuschließen. RCE wird nur dann möglich, wenn zusätzliche Umgebungsanforderungen erfüllt sind.

Ein anfälliges Theme muss ein oberstes Verzeichnis enthalten, dessen Name mit page- beginnt, wie z.B.:

page-templates

In der WordPress-Beratung werden die älteren Themes Twenty Twelve und Twenty Fourteen zu denjenigen gezählt, die diese strukturelle Anforderung erfüllen. Beliebte Drittanbieter-Themes wie Neve, Hestia und Sydney können ebenfalls kompatible Verzeichnislayouts enthalten.

Eine zweite Bedingung ist, dass der Angreifer eine lokale PHP-Datei identifizieren muss, die vom Webserver-Konto lesbar ist und bei Einbeziehung ein nützliches Verhalten erzeugt.

Der Sicherheitsforscher Robert Ressl demonstrierte den RCE-Pfad unter Verwendung einer PEAR-Komponente namens pearcmd.php. Damit diese Technik funktioniert, muss die PHP-Option register_argc_argv ebenfalls aktiviert sein. Das offizielle PHP-Docker-Image kann die relevanten Bedingungen erfüllen, während traditionelle cPanel-Konfigurationen mit PHP-Versionen vor 8.5 möglicherweise auch die erforderliche Umgebung freigeben.

Dieser Unterschied ist wichtig, da nicht jede anfällige WordPress-Installation sofort für die Ausführung beliebigen Codes ausgenutzt werden kann. Eine Site kann den anfälligen Core-Code enthalten und dennoch die für die nachgewiesene Exploit-Kette erforderliche Theme-Struktur oder PHP-Umgebung fehlen.

Dennoch überschreitet die lokale File-Inclusion-Primitive selbst eine wichtige Sicherheitsgrenze und erfordert keine Authentifizierung oder Benutzerinteraktion.

CVE-2026-87902 betrifft WordPress Core von Version 4.7.0 bis 7.1.1. Die offizielle Beratung listet anfällige Zweige einzeln auf, einschließlich:

• WordPress 7.1.0–7.1.1
• WordPress 7.0.0–7.0.5
• WordPress 6.9.0–6.9.8
• WordPress 6.8.0–6.8.9
• WordPress 6.7.0–6.7.8
• WordPress 6.6.0–6.6.8
• Alle entsprechenden betroffenen Zweige zurück bis WordPress 4.7.36

WordPress 7.1.1, das nur fünf Tage zuvor als Sicherheitsupdate veröffentlicht wurde, bleibt anfällig für dieses separate Problem.

Die Schwachstelle wurde vom Sicherheitsforscher Robert Ressl entdeckt und privat durch das HackerOne-Programm von WordPress am 20. Juli 2026gemeldet. WordPress bestätigte den Bericht am 21. Juli und informierte den Forscher am 15. September, dass ein Fix geplant war. Der Patch und die öffentliche Beratung wurden am 22. September veröffentlicht.

WordPress klassifiziert die Schwachstelle als Kritisch mit einem CVSS 4.0-Score von 9.2. Der Vektor spiegelt einen netzwerkzugänglichen Angriff mit geringer Komplexität wider, der keine Privilegien oder Benutzerinteraktionen erfordert, während auch vermerkt wird, dass zusätzliche Angriffsvoraussetzungen vorhanden sein müssen, bevor der maximale nachgewiesene Effekt möglich ist.

Ein öffentliches CVE-2026-87902 PoC wurde vom Forscher zusammen mit der Offenlegung veröffentlicht. Der Proof-of-Concept umfasst ein reproduzierbares lokales Labor und demonstriert den Weg von unauthentifizierter Template-Überschreitung zu lokaler PHP-Einbeziehung und bedingter RCE. Der Forscher testete den Exploit gegen WordPress 7.0.2 in isolierten Umgebungen und testete ihn nicht gegen produktive Live-Websites.

Erfolgreiche Ausführung in der demonstrierten Umgebung erfolgte mit den Privilegien des PHP-/Webserver-Kontos, identifiziert als www-data, anstatt automatisch Betriebssystem-Root-Rechte zu gewähren. Der praktische Effekt hängt daher teilweise von den an den Webserver-Prozess vergebenen Berechtigungen ab.

Ein Angreifer, der die Ausführung von PHP-Code erreicht, könnte möglicherweise eine Web-Shell bereitstellen, Website-Dateien ändern, WordPress-Konfigurationsdaten und Datenbank-Anmeldedaten stehlen, Persistenz schaffen, Inhalte ändern, Besucher umleiten oder die kompromittierte Site als Ausgangspunkt für weitere Angriffe nutzen. Dies sind potenzielle post-exploitative Konsequenzen, die derzeit keiner realen CVE-2026-87902-Kampagne zugeordnet werden.

Zum Zeitpunkt der ursprünglichen Offenlegung am 22. September wurde keine Ausnutzung in der freien Wildbahn gemeldet, und CISA’s Anreicherungsdatensatz listete Ausnutzung als keine auf.

Die Bedrohungslage begann sich jedoch innerhalb von Stunden nach der Offenlegung zu ändern. Patchstack berichtete, Erkennungsversuche um ca. 17:44 UTC am 22. Septemberfestgestellt zu haben, weniger als fünf Stunden nachdem WordPress 7.1.2 verfügbar wurde. Die beobachteten Anfragen entsprachen der Kodierung, die im Patch adressiert wurde, was auf eine schnelle Analyse des Sicherheitsunterschieds hinweist.

Wichtig ist, dass Patchstack den beobachteten Verkehr als Erkundung anstelle einer erfolgreichen Übertragung von Schadcodecharakterisierte. Die Anfragen versuchten, gewöhnliche PHP-Dateien des WordPress-Core einzubeziehen und demonstrierten keine durch Angreifer kontrollierte Codeausführung. Ab dem 23. September unterstützt öffentlich verfügbare Evidenz daher aktives Monitoring, aber keine bestätigte erfolgreiche Ausnutzung in Produktionsumgebungen.

Derzeit gibt es keine kampagnenspezifischen CVE-2026-87902 IOCs wie bösartige Domains, Dateihashes, Malware-Familien oder ein definitives Angreifer-Infrastruktur-Set. Verteidiger sollten sich stattdessen auf HTTP-Anforderungsmuster konzentrieren, die mit abnormaler Seitenvorlagen-Überschreitung und nachfolgender Dateisystem- oder PHP-Aktivität verbunden sind.

Mögliche Warnzeichen umfassen:

• Anfragen mit kodierten oder wiederholten Verzeichnisüberschreitungssequenzen
• Anfragen, die versuchen, die Seitenvorlagenauswahl zu manipulieren
• Zugriffsmuster, die unerwartete lokale PHP-Dateinamen betreffen
• Neue PHP-Dateien, die in beschreibbaren WordPress-Verzeichnissen erscheinen
• Unerwartete Kindprozesse, die vom PHP- oder Webserver-Konto gestartet werden
• Unerklärliche ausgehende Verbindungen, die von PHP-Workern ausgehen
• Neue Administrator-Konten oder unautorisierte Änderungen an WordPress-Inhalten
• Änderungen an Themes, Plugins oder Core-Dateien nach verdächtigen HTTP-Anfragen

Da öffentliche Exploit-Informationen jetzt verfügbar sind, sollten Organisationen breiteres Scannen und automatisierte Exploit-Entwicklung erwarten, auch wenn ein erfolgreicher realer Kompromiss noch nicht öffentlich bestätigt wurde.

CVE-2026-87902 Minderung

Die primäre Gegenmaßnahme besteht darin, sofort eine gepatchte WordPress-Version zu installieren. WordPress gibt an, dass der neueste Zweig, WordPress 7.1.2, den Sicherheitsfix enthält, und gepatchte Versionen wurden auch für ältere Zweige erstellt.

Die offiziell behobenen Versionen umfassen:

• 7.1 → 7.1.2
• 7.0 → 7.0.6
• 6.9 → 6.9.9
• 6.8 → 6.8.10
• 6.7 → 6.7.9
• 6.6 → 6.6.9
• 6.5 → 6.5.12
• 6.4 → 6.4.12
• 6.3 → 6.3.12
• 6.2 → 6.2.13
• 6.1 → 6.1.14
• 6.0 → 6.0.16

Sicherheits-Backports werden bis zu WordPress 4.7.37fortgesetzt. WordPress betont jedoch, dass nur die neueste WordPress-Version aktiv unterstützt wird, daher ist ein Upgrade auf den aktuellen Zweig vorzuziehen, wo dies betrieblich machbar ist.

Websites, die automatische Hintergrundaktualisierungen unterstützen, sollten beginnen, den Sicherheitspatch automatisch zu erhalten. Administratoren können das Update auch manuell installieren über:

WordPress Dashboard → Aktualisierungen → Jetzt aktualisieren

WordPress bietet keine vollständige Umgehungsmöglichkeit, die die Installation des Sicherheitspatches ersetzt.

CVE-2026-87902-Erkennung sollte damit beginnen, alle WordPress-Installationen zu identifizieren, die Core-Versionen 7.1.1 oder früher verwenden, und dann zu bestimmen, ob ihr aktives übergeordnetes oder untergeordnetes Theme ein oberes Verzeichnis enthält, das mit page- beginnt.

Administrator sollten auch feststellen, ob PHP mit aktivem:

register_argc_argv = On

läuft und ob lesbare PEAR-Komponenten wie pearcmd.php oder andere möglicherweise nützliche lokale PHP-Einstiegspunkte auf dem Server vorhanden sind. Diese Überprüfungen helfen, die Exposition gegenüber bekannten RCE-Techniken zu bewerten, bestimmen jedoch nicht, ob der zugrunde liegende WordPress-Fehler vorhanden ist.

To Um CVE-2026-87902 zu erkennen Erkundungs- oder Versuchs-Ausnutzung, sollten Sicherheitsteams Webserver-, WAF-, Reverse-Proxy-, PHP- und WordPress-Telemetrie auf folgende Punkte überprüfen:

• Kodierte ../ oder gleichwertige Überschreitungsmuster bei Frontend-Anfragen
• Anfragen, die versuchen, die WordPress-Seitenvorlagenauflösung zu manipulieren
• Ungewöhnliche Verweise auf .php-Dateien außerhalb aktiver Theme-Verzeichnisse
• Anfragen, die versuchen, PEAR-bezogene PHP-Komponenten zu erreichen
• Ausbrüche ähnlicher Überschreitungsanfragen von einer Quelle
• PHP-Worker, die unerwartet Shell-Befehle oder Systemprogramme starten
• Neue PHP-Dateien oder Web-Shells, die nach verdächtigen Anfragen erscheinen
• Unerwartete Änderungen an wp-config.php, Themes, Plugins oder Uploads
• Neu erstellte WordPress-Administrator-Konten
• Verdächtiger ausgehender Traffic, der vom Webserver ausgeht

Patchstacks beobachtetes Scannen zeigt, dass internetfähige WordPress-Sites möglicherweise bereits spezifische Schwachstellenproben erhalten, wodurch Web- und WAF-Telemetrie besonders wertvoll für die retrospektive Untersuchung wird.

Administratoren, die nicht sofort patchen können, können die Exposition gegenüber der demonstrierten PEAR-basierten Ausführungskette durch Deaktivierung von register_argc_argv für Web-Anfragen, wenn sie nicht erforderlich ist, und Entfernen ungenutzter web-lesbarer PEAR-Komponenten verringern. Robert Ressl betont, dass dies nur Härtungsmaßnahmen sind und nicht den zugrunde liegenden WordPress-Fehler beheben.

Organisationen können auch die potenziellen Auswirkungen nach der Ausnutzung verringern, indem sie sicherstellen, dass das PHP-/Webserver-Konto den Prinzipien des Least Privilege folgt. Es sollte keinen unnötigen Schreibzugriff auf Systemverzeichnisse oder sensible Anwendungsdateien haben.

Websites, die vor der Patch-Installation über das Internet zugänglich waren, sollten auf verdächtige Anfragen ab dem Zeitpunkt der öffentlichen Bekanntmachung am 22. September überprüft werden, insbesondere weil öffentliches PoC-Material gleichzeitig verfügbar wurde und Erkundung innerhalb von Stunden folgte.

Wenn verdächtige Ausnutzung identifiziert wird, sollten Administratoren relevante Logs bewahren und eine vollständige Integritätsüberprüfung folgender Passagen durchführen:

• WordPress-Core-Dateien
• Aktive und inaktive Themes
• Plugins
• Das Uploads-Verzeichnis
• wp-config.php
• Webserver-Konfiguration
• Geplante Aufgaben und Cron-Einträge
• WordPress-Administrator-Konten
• PHP-Prozesse und kürzlich erstellte Dateien

Potentiell exponierte Datenbankpasswörter, API-Keys, Anwendungstoken oder andere in lesbaren Dateien gespeicherte Anmeldeinformationen sollten zurückgesetzt werden, wenn die Untersuchung darauf hindeutet, dass ein Angreifer lokale Dateieinbindung oder Codeausführung erreicht hat.

Die sofortige Priorität bleibt die Aktualisierung von WordPress selbst. Änderungen an Themes, das Deaktivieren von PEAR oder das Ändern von PHP-Einstellungen können bestimmte Exploit-Pfade reduzieren, sollten jedoch nicht als Ersatz für das offizielle Sicherheitsrelease behandelt werden.