CVE-2026-87902-Toolkit

WordPress CVE-2026-87902 LFI-zu-RCE-Toolkit mit einer weaponisierten Exploit-Kette (PEAR RCE, Webshell, Admin-Erstellung, Loot) sowie einer nicht-intrusiven SafeChecker-Version und einem Risiko-Auditor.

Die Schwachstelle betrifft jede WordPress-Version seit 2016 – ein Jahrzehnt von Versionen, die die Code-Review ohne Entdeckung passiert haben. Die Ursache ist ein einzelner fehlender Validierungsaufruf in einem der am häufigsten durchlaufenen Codepfade des CMS .

Funktionsweise

1. Unbereinigte Template-Auflösung – get_page_template() in wp-includes/template.php erstellt Template-Kandidaten aus der pagename-Query-Variable. Ein benachbarter Codepfad in derselben Funktion wendet validate_file() an, um ../-Sequenzen zu blockieren, aber der $pagename-Zweig ruft sie nicht auf. Jegliches Traversal in pagename passiert ungeprüft .

2. Doppelt kodierte Traversal-Umgehung – WordPress wendet sanitize_title_for_query() auf pagename an, was literale Punkte (.) durch Bindestriche ersetzt, um Traversal zu verhindern. Die Funktion arbeitet jedoch mit bereits dekodierter Eingabe und dekodiert nicht rekursiv. Ein Angreifer sendet %252e%252e%252f; der Webserver dekodiert es einmal zu %2e%2e%2f; der Sanitizer sieht keine literalen Punkte und lässt es durch; dann ruft get_page_template() innerhalb der Funktion erneut urldecode() auf, was ../ erzeugt .

3. Theme-Verzeichnis-Voraussetzung – Das aktive Theme muss ein Verzeichnis auf oberster Ebene enthalten, dessen Name mit page- beginnt (z. B. page-templates/). Der konstruierte Dateiname page-{pagename}.php entkommt dann über das Traversal aus dem Theme-Root. Ältere Standard-Themes (Twenty Twelve, Twenty Fourteen) und beliebte Drittanbieter-Themes (Neve, Hestia, Sydney) liefern dieses Verzeichnis mit. Child-Themes, die von solchen Parents erben, erfüllen die Voraussetzung ebenfalls .

4. LFI-Sink in locate_template() – Der Kandidatenpfad wird an locate_template() übergeben, das die Theme-Verzeichnisse durchsucht. Da das Traversal zu einer Datei außerhalb dieser Verzeichnisse auflöst und die Funktion nur file_exists() prüft, wird jede lesbare .php-Datei mit vollen Webserver-Privilegien eingebunden. Dies macht die LFI bedingungslos auf jeder ungepatchten Seite, die die Theme-Voraussetzung erfüllt – einschließlich wp-config.php mit seinen Datenbank-Zugangsdaten und Authentifizierungs-Salts .

5. PEAR pearcmd.php RCE-Eskalation – PEAR wird mit vielen PHP-Installationen ausgeliefert. Sein pearcmd.php ist normalerweise nur für die CLI gedacht, aber wenn register_argc_argv=On, füllt PHP $_SERVER['argv'] aus dem URL-Query-String. Der Angreifer bindet pearcmd.php über die LFI ein, übergibt config-create als Argument und liefert PHP-Code plus einen Ausgabepfad (/tmp/shell.php). PEAR schreibt den Code des Angreifers auf die Festplatte; ein zweites Include führt ihn aus .

6. Zweiter Ausnutzungsweg – Eine Anfrage, die name (Front-Page-Slug), page_id (Posts-Page-ID), preview=true und eine pagename-Payload kombiniert, leitet WP_Query in seinen post_name-Zweig um, der pagename niemals durch sanitize_title_for_query() umschreibt. Dies erlaubt literale Punkte im Traversal. Erfordert ein Theme ohne single.php .

7. Server-Konfigurationsanforderungen – RCE hängt von zwei Bedingungen ab, die in realen Deployments häufig vorkommen: pearcmd.php vorhanden/lesbar (häufig bei Shared Hosting, cPanel, offiziellen PHP-Docker-Images) und register_argc_argv=On (Standard in PHP unter 8.5). PHP 8.5 änderte den Standard auf Off. Auf einem modernen PHP 8.5+-Server ohne PEAR stoppt die Ausnutzung bei LFI .

8. Der Patch – WordPress 7.1.2 fügt zwei Verteidigungsebenen hinzu: (a) den fehlenden validate_file()-Aufruf im pagename-Zweig und (b) eine neue Funktion _wp_is_template_path_allowed(), die von locate_template() für jedes aufgelöste Template aufgerufen wird. Die Funktion lehnt Pfade mit .. ab, löst dann den realen Pfad über realpath() auf und verifiziert, dass er innerhalb eines der erlaubten Theme-Verzeichnisse liegt. Diese Defense-in-Depth schließt den Sink, nicht nur einen Weg dorthin .

9. Aktive Ausnutzung in freier Wildbahn – Erste bösartige Anfragen wurden 5 Stunden nach Patch-Veröffentlichung beobachtet (17:44 UTC, 22. September 2026). Der Datenverkehr verzehnfachte sich am nächsten Tag. Drei Phasen wurden beobachtet: config-show-Aufklärung → Core-Datei-Erkennung → config-create-Waffenisierung. Payload-Dateinamen umfassten wp-pear-rce-flag.php, poc87902.php, luci_*.php, zeta_*.php, geschrieben nach /tmp und /var/tmp. Angreifer-IPs: 169.58.48.193, 169.58.48.195, 2001:df1:e8c0::106b .

10. Auswirkung – Codeausführung mit Webserver-Privilegien. Vollständige Website-Übernahme, Diebstahl von wp-config.php-Zugangsdaten, Datenexfiltration, Webshell-Installation, Erstellung von Admin-Benutzern, Reverse Shell, Supply-Chain-Angriffe über modifizierte Plugins/Themes und laterale Bewegung in verbundene Dienste. Der CVSS-9.2-Score spiegelt netzwerkausnutzbare, keine Authentifizierung erfordernde, hohe Auswirkungen auf Vertraulichkeit/Integrität/Verfügbarkeit wider. Die hohe Angriffskomplexität spiegelt die Theme- und Server-Voraussetzungen wider, aber auf typischem Shared Hosting sind diese Bedingungen häufig erfüllt.

Betroffene Versionen

• 4.7.0 – 4.7.37 – anfällig
• 4.8.0 – 4.8.32 – anfällig
• 4.9.0 – 4.9.33 – anfällig
• 5.0.0 – 5.0.29 – anfällig
• 5.1.0 – 5.1.26 – anfällig
• 5.2.0 – 5.2.28 – anfällig
• 5.3.0 – 5.3.25 – anfällig
• 5.4.0 – 5.4.23 – anfällig
• 5.5.0 – 5.5.22 – anfällig
• 5.6.0 – 5.6.21 – anfällig
• 5.7.0 – 5.7.19 – anfällig
• 5.8.0 – 5.8.17 – anfällig
• 5.9.0 – 5.9.18 – anfällig
• 6.0.0 – 6.0.16 – anfällig
• 6.1.0 – 6.1.14 – anfällig
• 6.2.0 – 6.2.13 – anfällig
• 6.3.0 – 6.3.12 – anfällig
• 6.4.0 – 6.4.12 – anfällig
• 6.5.0 – 6.5.12 – anfällig
• 6.6.0 – 6.6.9 – anfällig
• 6.7.0 – 6.7.9 – anfällig
• 6.8.0 – 6.8.10 – anfällig
• 6.9.0 – 6.9.9 – anfällig
• 7.0.0 – 7.0.6 – anfällig
• 7.1.0 – 7.1.1 – anfällig

Patch

• Aktualisieren Sie auf 4.7.37, 4.8.32, 4.9.33, 5.0.29, 5.1.26, 5.2.28, 5.3.25, 5.4.23, 5.5.22, 5.6.21, 5.7.19, 5.8.17, 5.9.18, 6.0.16, 6.1.14, 6.2.13, 6.3.12, 6.4.12, 6.5.12, 6.6.9, 6.7.9, 6.8.10, 6.9.9, 7.0.6 oder 7.1.2 oder neuer.
• Falls ein Upgrade nicht möglich ist, benennen Sie das page-*-Verzeichnis im aktiven Theme um oder entfernen Sie es, setzen Sie register_argc_argv=Off in php.ini und blockieren Sie doppelt kodiertes Traversal im pagename-Parameter auf WAF-Ebene.

[<->] Tools

[</>] Funktionsvergleich

[+] Zusammenfassung der Anwendungsfälle

[+] Installation

requirements.txt

[/] Parameter

exploit.py-Parameter

safecheck.py-Parameter

[>] Szenarien

🧪 Endpunkt- & Ausnutzungskette

Der Exploit verwendet die folgenden WordPress-Endpunkte und Ausnutzungsschritte:

Payload-Format

🛡️ Verantwortungsvolle Nutzung

• Verwenden Sie diese Tools nur auf Systemen, die Ihnen gehören oder für die Sie eine ausdrückliche schriftliche Testgenehmigung haben.
• Unbefugter Zugriff ist illegal und unethisch.
• Die Autoren sind nicht für jeglichen Missbrauch verantwortlich.
• Befolgen Sie stets die Gesetze und Vorschriften Ihres Landes.

Diese Software wird ausschließlich für Bildungszwecke und autorisierte Sicherheitstests bereitgestellt.