1. Startseite
  2. Sicherheitshinweise

WordPress Sicherheitslücke CVE-2026-87902 wird aktiv ausgenutzt

Sicherheitshinweis Kritisch 6 Min. Lesezeit

Dieser Artikel ist auch verfügbar auf: TürkçeEnglish

WordPress Sicherheitslücke CVE-2026-87902 wird aktiv ausgenutzt
CVECVE-2026-87902
SchweregradKritisch
CVSS-Wert 9,2
StatusPatch verfügbar
Betroffene ProdukteWordPress-Core 4.7.0 – 7.1.1 (korrigiert in 7.1.2, 7.0.6, 6.9.9, 6.8.10 und zurückportiert in alle Zweige bis 4.7.37)

Die kritische WordPress Sicherheitslücke CVE-2026-87902 (CVSS 9,2) wurde wenige Stunden nach dem Patch ausgenutzt. Betroffene Versionen, Prüfschritte für Ihre Website, IoCs und Sofortmaßnahmen.

Zusammenfassung

Die kritische WordPress Sicherheitslücke CVE-2026-87902 wurde nur wenige Stunden nach Erscheinen des Patches am 22. September 2026 aktiv ausgenutzt. Die Lücke im WordPress-Core erlaubt es Angreifern ohne Anmeldung, eine lesbare .php-Datei auf dem Server als Seitentemplate ausführen zu lassen (Local File Inclusion, LFI). Unter bestimmten Voraussetzungen wird daraus eine Remotecodeausführung (RCE). Laut offiziellem Advisory erfüllt die Standardkonfiguration von cPanel mit PHP-Versionen vor 8.5 eine dieser Voraussetzungen – für Unternehmenswebsites im Shared Hosting ist das Thema daher dringend.

  • CVSS 4.0: 9,2 (kritisch) – weder Anmeldung noch Benutzerinteraktion erforderlich.
  • Betroffene Versionen: WordPress 4.7.0 bis 7.1.1. Die Korrektur erschien mit WordPress 7.1.2 und wurde in alle Versionszweige bis 4.7.37 zurückportiert.
  • Aktiv ausgenutzt: Patchstack registrierte die ersten Angriffsversuche am 22. September um 13:49 Uhr MESZ; noch am selben Tag folgten Versuche, über pearcmd.php PHP-Dateien auf die Festplatte zu schreiben. Seit dem 23. September kursiert ein fertiges Nuclei-Template.
  • CISA KEV: Am 25. September 2026 in den Katalog aufgenommen; Frist für US-Bundesbehörden ist der 28. September.

WordPress Sicherheitslücke: technische Details

Der Fehler steckt in get_page_template(), der Funktion, die festlegt, welche Template-Datei WordPress für eine Seite verwendet. Mit kodierten Path-Traversal-Sequenzen (%2e%2e) im Parameter pagename können Angreifer WordPress dazu bringen, eine lesbare .php-Datei außerhalb der aktiven Theme-Verzeichnisse einzubinden. Laut Patchstack enthalten die Anfragen zusätzlich eine page_id, die auf eine echte Seite verweist; ohne sie liefert WordPress einen 404-Fehler und der verwundbare Code wird nie erreicht.

Zwei Voraussetzungen machen aus der Dateieinbindung eine Codeausführung:

  1. Theme: Das aktive Theme (Child- oder Parent-Theme) enthält im Hauptverzeichnis einen Ordner, dessen Name mit page- beginnt, etwa page-templates. Das Advisory nennt die älteren Themes Twenty Twelve und Twenty Fourteen sowie beliebte Drittanbieter-Themes wie Neve, Hestia und Sydney.
  2. Server: Auf dem Server liegt eine geeignete, für den Webserver-Account lesbare .php-Datei. Angreifer nutzen dafür pearcmd.php aus dem PHP-Paketmanager PEAR. Ist in PHP register_argc_argv aktiviert, wird der Query-String als Kommandozeilenargument an pearcmd übergeben – so können Angreifer eine PHP-Datei mit beliebigem Inhalt auf die Festplatte schreiben. Laut Advisory sind das offizielle php-Docker-Image und die Standardkonfiguration von cPanel mit PHP vor 8.5 betroffen.

Patchstack beschreibt drei Angriffsphasen: Zuerst wird mit harmlosen Core-Dateien wie wp-links-opml.php getestet, ob die Einbindung funktioniert. Danach prüfen Anfragen mit +config-show, ob pearcmd erreichbar ist. In der dritten Phase schreiben Anfragen mit +config-create PHP-Dateien nach /tmp oder /var/tmp – das entspricht einer Codeausführung. Auch die Honeypots von Previdian verzeichneten Anfragen, die einen auf GitHub gehosteten Webshell-Uploader nachladen wollten.

Betroffene und korrigierte Versionen

WordPress-ZweigBetroffenKorrigiert
7.17.1.0 – 7.1.17.1.2
7.07.0.0 – 7.0.57.0.6
6.96.9.0 – 6.9.86.9.9
6.86.8.0 – 6.8.96.8.10
6.76.7.0 – 6.7.86.7.9
4.7 – 6.6Alle Versionen vor der korrigierten Version des Zweigs6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32, 4.7.37

Da WordPress Sicherheitsupdates standardmäßig automatisch installiert, dürften viele Websites bereits gepatcht sein; Previdian rechnet deshalb mit vielen Angriffsversuchen, aber vergleichsweise wenigen erfolgreichen Kompromittierungen. Websites mit deaktivierten automatischen Updates oder fehlgeschlagenen Updates bleiben jedoch angreifbar.

Ist meine WordPress-Website betroffen? Checkliste

  1. WordPress-Version: Prüfen Sie unter Dashboard › Aktualisierungen die installierte Version. Entspricht sie der korrigierten Version Ihres Zweigs aus der Tabelle oder ist sie neuer, ist diese Lücke geschlossen.
  2. Theme-Verzeichnis: Öffnen Sie im cPanel-Dateimanager den Ordner wp-content/themes/ und prüfen Sie, ob das aktive Theme (bei Child-Themes auch das Parent-Theme) im Hauptverzeichnis einen Ordner hat, der mit page- beginnt.
  3. PEAR: Prüfen Sie, ob pearcmd.php auf dem Server vorhanden ist. Angreifer testen die Pfade /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php und /usr/share/pear/pearcmd.php. Im Shared Hosting fragen Sie Ihren Hoster, wenn Sie diese Ordner nicht einsehen können.
  4. register_argc_argv: Prüfen Sie im MultiPHP INI Editor bzw. in den PHP-Optionen von cPanel oder in der Ausgabe von phpinfo(), ob diese Einstellung auf On steht. Löschen Sie eine dafür angelegte phpinfo-Datei anschließend wieder.
  5. Kompromittierungsindikatoren (IoCs): Suchen Sie in /tmp und /var/tmp nach unerwarteten .php-Dateien, insbesondere poc87902.php, wp-pear-rce-flag.php, luci_*.php und zeta_*.php. Laut Patchstack bedeutet ihr Vorhandensein, dass ein Schreibangriff erfolgreich war – der Server ist dann als kompromittiert zu behandeln, nicht nur als gescannt. Ohne Zugriff auf diese Ordner bitten Sie Ihren Hoster um die Prüfung.
  6. Zugriffsprotokolle: Durchsuchen Sie die Raw-Access-Logs nach %2e%2e oder %252e%252e im Parameter pagename, nach pagename-Werten, die mit templates%2f beginnen, nach pagename und page_id in derselben Anfrage, nach pearcmd, +config-show und +config-create sowie nach den User-Agents cve-2026-87902-poc/1.0 und nuclei-cve-2026-87902/1.0. Eine 200-Antwort mit OPML- oder RSS-Inhalt auf eine normale Seiten-URL zeigt, dass die Einbindung auf Ihrer Website funktioniert hat.

Empfohlene Maßnahmen

  1. Sofort updaten: Aktualisieren Sie WordPress auf 7.1.2 oder die korrigierte Version Ihres Zweigs (7.0.6, 6.9.9, 6.8.10 … 4.7.37). Erstellen Sie vorher ein Backup. Da die Korrektur in alle Zweige zurückportiert wurde, lassen sich auch ältere Websites ohne großes Versions-Upgrade absichern.
  2. /tmp und /var/tmp prüfen: Suchen Sie nach den oben genannten IoC-Dateien und werten Sie die Logs rückwirkend bis zum 22. September aus.
  3. Bei Hinweisen auf eine Kompromittierung: Ändern Sie alle WordPress-Administratorpasswörter, cPanel-/FTP- und Datenbankpasswörter und erneuern Sie die Sicherheitsschlüssel (Salts) in der wp-config.php. Prüfen Sie unbekannte Administratorkonten und Dateien und stellen Sie bei Bedarf ein sauberes Backup wieder her.
  4. Meldepflicht nach DSGVO beachten: Wurde auf personenbezogene Daten wie Kunden- oder Mitarbeiterdaten zugegriffen, muss die Datenschutzverletzung nach Art. 33 DSGVO in der Regel innerhalb von 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde gemeldet werden.
  5. Automatische Updates aktiviert lassen: Stellen Sie sicher, dass die automatischen Sicherheitsupdates für den WordPress-Core nicht deaktiviert sind.

Kein sofortiges Update möglich? Übergangslösungen

Diese Maßnahmen ersetzen den Patch nicht, sie senken nur das Risiko bis zum Update:

  • Deaktivieren Sie register_argc_argv in PHP. Das schließt die Lücke nicht, unterbricht aber die Kette über pearcmd zur Codeausführung.
  • Entfernen Sie PEAR, wenn Sie es nicht benötigen; im Shared Hosting über Ihren Hoster.
  • Blockieren Sie in Ihrer Web Application Firewall (WAF) Anfragen mit %2e%2e oder %252e%252e im Parameter pagename. Da POST-Anfragen im Angriffsverkehr inzwischen häufiger sind als GET, muss die Regel Query-String und POST-Body abdecken. Echte Seiten-Slugs enthalten diese Sequenzen nie, der normale Verkehr bleibt also unberührt.

Zeitlicher Ablauf (MESZ)

  • 22. September 2026: WordPress 7.1.2 und zurückportierte Korrekturen veröffentlicht; Advisory GHSA-7hp8-65ch-5whp erschienen.
  • 22. September, 13:49 Uhr: Patchstack registriert den ersten Angriffsversuch (Erkundung mit harmlosen Core-Dateien).
  • 22. September, 17:34 Uhr: Erster Versuch, über pearcmd.php eine Datei auf die Festplatte zu schreiben.
  • 23. September: Öffentliche Scan-Tools, darunter ein benanntes Nuclei-Template, im Umlauf; das Angriffsvolumen erreicht gegen 14 Uhr seinen Höhepunkt.
  • 25. September: CISA nimmt CVE-2026-87902 in den Katalog der Known Exploited Vulnerabilities (KEV) auf.
  • 28. September: Frist für US-Bundesbehörden.

Außerdem: Elementor auf 4.3.2 aktualisieren

Die Versionen 4.3.0 und 4.3.1 des Plugins Elementor Website Builder enthalten eine CSRF-Lücke: Öffnet ein angemeldeter Administrator einen präparierten Link, können Angreifer ein neues Administratorkonto anlegen. Die Lücke hat noch keine CVE-Nummer und ist in Elementor 4.3.2 behoben. Wenn Sie Elementor nutzen, aktualisieren Sie auch dieses Plugin und prüfen Sie Ihre Benutzerliste auf unbekannte Administratorkonten.

Wie Doğa Network Sie unterstützen kann

Unser Team unterstützt Sie bei der Prüfung von WordPress-Version und Theme, sicheren Updates, PHP-Einstellungen, WAF-Regeln und der Suche nach Kompromittierungsspuren. Rufen Sie uns an unter +90 850 888 3642 oder schreiben Sie an hi@doga.network.

Quellen

#WordPress#WordPress Sicherheit#WordPress Update#cPanel#PEAR#CVE-2026-87902
Newsletter

Von kritischen Schwachstellen als Erste erfahren.

Erhalten Sie unsere Sicherheitshinweise, Praxisleitfäden und Ankündigungen per E-Mail. Wenige E-Mails im Monat, keine Werbung.

Zu welchen Themen möchten Sie E-Mails erhalten?