CVE-2026-87902: kritische WordPress-Lücke wird aktiv ausgenutzt, so prüfen Sie Ihre Website auf Webshells

Von CMS ADMINS Redaktion · Aktualisiert am 26. September 2026

Veröffentlicht: 22.09.2026 · Letzte Aktualisierung: 26.09.2026

Was ist passiert

Die kritische WordPress-Lücke CVE-2026-87902 wird seit dem 22.09.2026 aktiv angegriffen, also seit dem Tag, an dem der Patch erschienen ist. Am 25.09.2026 hat die US-Cybersicherheitsbehörde CISA die Schwachstelle in ihren Katalog der nachweislich ausgenutzten Sicherheitslücken (Known Exploited Vulnerabilities, KEV) aufgenommen. Was am Patch-Tag noch eine dringende Update-Empfehlung war, ist damit ein laufender Sicherheitsvorfall.

Zum Hintergrund: WordPress hat am 22.09.2026 die Version 7.1.2 veröffentlicht, nur fünf Tage nach 7.1.1. Es handelt sich um ein reines Sicherheitsrelease mit einem einzigen Fix, und dieser eine Fix hat es in sich: eine unauthentifizierte Local File Inclusion in der Template-Auflösung des Core, die unter verbreiteten Hosting-Bedingungen bis zur Remote Code Execution reicht. Die Lücke trägt die Kennung CVE-2026-87902 und wurde von Robert Ressl gemeldet, die technische Analyse stammt von Patchstack, die offizielle Ankündigung kommt von WordPress selbst.

Zwei Punkte heben diese Lücke von den meisten Core-Fixes der letzten Jahre ab. Erstens der Versionsbereich: Betroffen ist jede WordPress-Version von 4.7.0 bis einschließlich 7.1.1, das sind fast zehn Jahre an Releases. Zweitens die Zugangshürde: Es gibt keine. Der Angreifer braucht kein Konto, keinen eingeloggten Administrator und keinen Klick von irgendjemandem, ein präparierter Seitenaufruf genügt. Bei Click2Shell am 21.09.2026 musste immerhin noch ein Administrator einen Link öffnen. Hier entfällt auch das.

Wie die Lücke seit dem Patch ausgenutzt wird

Die ersten Angriffsversuche begannen am 22.09.2026, wenige Stunden nach dem Release von WordPress 7.1.2. Patchstack registrierte die ersten Probes um 11:49 UTC, Bleeping Computer nennt für die erste eindeutig bösartige Recon 17:44 UTC desselben Tages. Die beiden Angaben liegen knapp sechs Stunden auseinander, was daran liegt, dass frühe Scans nicht immer sauber von Sicherheitsforschern zu unterscheiden sind. In beiden Lesarten gilt: Zwischen Patch und Angriff lag nicht einmal ein Arbeitstag.

Ab dem 23.09.2026 stieg das Angriffsvolumen um das Zehnfache. Bemerkenswert ist, wie die Angreifer an ihr Wissen gekommen sind: Sie haben die Lücke nicht selbst gefunden, sondern aus dem veröffentlichten Patch-Diff rekonstruiert. Der Fix zeigt, wo geprüft wird, und damit auch, wo vorher nicht geprüft wurde. Seitdem kursieren öffentliche Scanner-Templates, darunter ein Template für das verbreitete Open-Source-Werkzeug Nuclei, mit denen sich verwundbare Installationen automatisiert aufspüren lassen.

Als wiederkehrende Quell-IPs der Angriffswellen sind bislang 169.58.48.193, 169.58.48.195 und 2001:df1:e8c0::106b dokumentiert. Eine IP-Blockliste ist damit trotzdem kein verlässlicher Schutz, weil die Quellen laufend wechseln und neue Infrastruktur nachrückt. Community-Plattformen wie ReportedIP sammeln Meldungen zu solchen Angriffs-IPs und helfen bei der Einordnung, ersetzen aber weder Patch noch Prüfung.

Die drei Angriffsstufen

Die beobachteten Angriffe laufen in drei Stufen ab. Stufe 1 ist das Fingerprinting: Über den Parameter pagename rufen die Angreifer harmlose Core-Dateien wie wp-links-opml.php ab. Antwortet der Server mit dem Inhalt der Datei, ist die Installation verwundbar, ohne dass dabei schon Schaden entsteht.

Stufe 2 ist der PEAR-Check: Die Angreifer testen, ob die Datei pearcmd.php auf dem Server lesbar ist. Geprüft werden dabei die üblichen Installationspfade /usr/local/lib/php, /usr/share/php und /usr/share/pear. Ist pearcmd.php erreichbar, steht der Weg zur Codeausführung offen.

Stufe 3 ist die Ablage: Über die config-create-Funktion von pearcmd schreiben die Angreifer PHP-Dateien nach /tmp und /var/tmp. Diese Dateien führen beim Aufruf Shell-Befehle aus, sie funktionieren also als Webshell. Warum genau diese Kette funktioniert, erklärt weiter unten der Abschnitt „Vom Datei-Einbinden zur Codeausführung“. Dort steht die Theorie, hier steht, was seit dem 22.09.2026 tatsächlich auf realen Servern beobachtet wird.

Die Schwachstelle im Detail

Wenn WordPress eine Seite rendert, baut die Funktion get_page_template() eine Liste von Template-Dateinamen zusammen, die der Reihe nach ausprobiert werden. Einer dieser Kandidaten wird direkt aus dem URL-Parameter pagename gebildet, also aus einem Wert, den der Besucher der Website selbst bestimmt.

Der Fehler ist von der unangenehm banalen Sorte: WordPress prüft Template-Kandidaten eigentlich mit der hauseigenen Funktion validate_file() auf Verzeichniswechsel-Tricks. Beim Kandidaten aus dem pagename-Parameter fehlte genau diese Prüfung, und zwar nur bei der URL-dekodierten Variante des Werts. Der Schutz stand im Code drei Zeilen über der Stelle, an der er gefehlt hat. Ein zusätzlicher urldecode()-Aufruf macht aus einem harmlos aussehenden Seitennamen einen echten Pfad mit Verzeichniswechseln, und schon bindet WordPress eine Datei ein, die der Angreifer bestimmt.

Zwei Einschränkungen begrenzen den Spielraum. Der Dateiname wird als page-{pagename}.php zusammengesetzt, der Angriffspfad muss also in einem Verzeichnis beginnen, das tatsächlich mit page- anfängt, und die Zieldatei muss auf .php enden. In der Praxis heißt das: Das aktive Theme braucht ein Verzeichnis wie page-templates auf oberster Ebene. Genau so ein Verzeichnis bringen ältere WordPress-Standard-Themes und eine ganze Reihe populärer Dritt-Themes mit.

Vom Datei-Einbinden zur Codeausführung

Eine Local File Inclusion führt zunächst nur den Code aus, der in der eingebundenen Datei steht. Für eine echte Übernahme braucht der Angreifer eine PHP-Datei auf dem Server, die sich beim Einbinden nützlich verhält. Der bekannte Kandidat dafür ist pearcmd.php aus der PEAR-Distribution, und der funktioniert immer dann, wenn PHP mit der Einstellung register_argc_argv läuft. Diese Einstellung ist in den offiziellen PHP-Docker-Images und in cPanel-Umgebungen mit PHP unter 8.5 standardmäßig aktiv. Von einer exotischen Konfiguration kann also keine Rede sein.

Die ehrliche Einordnung lautet damit: Die Dateieinbindung ohne Login funktioniert auf jeder betroffenen Installation mit passendem Theme, die Codeausführung zusätzlich überall dort, wo der Hosting-Stack mitspielt. Und das tut er häufig. Wer seinen eigenen Stack nicht im Detail geprüft hat, behandelt die Lücke besser als das, was ihre Bewertung sagt: kritisch.

Was WordPress geändert hat

Der Patch besteht aus zwei Teilen, und der zweite ist der interessantere. Zunächst bekommt der betroffene Codezweig dieselbe validate_file()-Prüfung, die der Nachbarzweig schon immer hatte, damit ist die gemeldete Lücke geschlossen. Zusätzlich führt 7.1.2 aber eine neue Sicherung ein: Jeder aufgelöste Template-Pfad muss künftig innerhalb der erlaubten Theme-Verzeichnisse liegen, egal über welchen Codepfad er zustande kam.

Diese zweite Änderung sagt mehr, als in der Sicherheitsmeldung steht. Für den gemeldeten Fehler hätte die Ein-Zeilen-Korrektur gereicht. Dass das Sicherheitsteam die Template-Auflösung stattdessen als ganze Problemklasse absichert, ist die richtige Entscheidung, und sie deutet an, dass man dort nicht darauf wetten wollte, dass der gemeldete Pfad der einzige verwundbare war.

Wer ist betroffen

Betroffen ist praktisch jede WordPress-Installation, die nicht bereits auf 7.1.2 oder einem gepatchten Backport-Release läuft. Ob aus der Lücke im Einzelfall mehr als eine Dateieinbindung wird, hängt an zwei Fragen: Hat das aktive Theme ein Verzeichnis, dessen Name mit page- beginnt, etwa page-templates? Und läuft PHP mit register_argc_argv? Zwei Mal Ja bedeutet: Der Weg bis zur Codeausführung ist frei.

Wichtig für ältere Installationen: WordPress hat Backport-Fixes für alle noch unterstützten Versionszweige bis hinunter zu 4.7 veröffentlicht. Auch eine Website, die aus guten oder schlechten Gründen noch auf einem alten Zweig läuft, kann den Fix ohne Major-Update einspielen. Offiziell unterstützt bleibt trotzdem nur die jeweils aktuelle Version, und das ist seit dem 22.09.2026 die 7.1.2.

Was Sie jetzt tun sollten

1. Sofort auf 7.1.2 aktualisieren. Das Update steht im Dashboard unter Aktualisierungen bereit. Websites mit aktivierten automatischen Hintergrund-Updates sollten es bereits erhalten haben, verlassen Sie sich darauf aber nicht, sondern prüfen Sie die installierte Version.

2. Wenn Sie nicht sofort updaten können, prüfen Sie Ihre Exponierung. Schauen Sie nach, ob Ihr aktives Theme ein Verzeichnis mit dem Namensanfang page- enthält, und ob PHP bei Ihrem Hoster mit register_argc_argv läuft. Beides ersetzt kein Update, aber es sagt Ihnen, wie nah Ihre Website am Worst Case steht.

3. Nach dem Update auf Kompromittierung prüfen. Diese Prüfung ist keine Option mehr für Verdachtsfälle, sondern Pflicht für jede Installation, die erst nach dem 22.09.2026 gepatcht wurde. Die Angriffe laufen seit dem Patch-Tag, und ein Update ist keine Bereinigung: Eine Webshell, die vor dem Update abgelegt wurde, bleibt nach dem Update funktionsfähig liegen. Wie Sie konkret vorgehen, beschreibt der Abschnitt „So prüfen Sie Ihre Website auf Kompromittierung“ weiter unten in diesem Artikel.

Für unsere Wartungskunden gilt wie immer: Wir spielen das Update zeitnah auf allen betreuten Websites ein und prüfen die Installationen auf die genannten Risikofaktoren. Wenn Sie Ihre WordPress-Website noch selbst aktualisieren, ist spätestens dieser Vorfall ein guter Anlass, das zu ändern: Unsere WordPress-Wartung gibt es ab 9,50 € im Monat, inklusive Updates, 60-Tage-Backups und Sicherheits-Monitoring auf Servern in Deutschland.

So prüfen Sie Ihre Website auf Kompromittierung

Ein Update auf 7.1.2 schließt die Lücke, entfernt aber keine Datei, die vorher abgelegt wurde. Wer erst nach dem 22.09.2026 gepatcht hat, muss deshalb prüfen, ob die eigene Installation in der Zwischenzeit angegriffen wurde. Die folgenden vier Schritte liefern jeweils ein prüfbares Ergebnis, sie sind bewusst so gehalten, dass sie auch ohne Spezialwerkzeuge machbar sind. Einen breiteren Überblick über Absicherungsmaßnahmen gibt unsere Seite zur WordPress-Sicherheit.

Schritt 1: Access-Logs auf Angriffsmuster prüfen

Gesucht werden Requests mit dem Parameter pagename, der die kodierten Verzeichniswechsel %2e%2e oder %252e%252e enthält, sowie die beiden bekannten Scanner-User-Agents cve-2026-87902-poc/1.0 und nuclei-cve-2026-87902/1.0. Für nginx und Apache sehen die Suchbefehle so aus:

# nginx
grep -iE 'pagename=[^" ]*(%2e%2e|%252e%252e)' /var/log/nginx/access.log*

# Apache
grep -iE 'pagename=[^" ]*(%2e%2e|%252e%252e)' /var/log/apache2/access.log*

# Scanner-User-Agents (beide Server)
grep -iE 'cve-2026-87902-poc|nuclei-cve-2026-87902' /var/log/nginx/access.log* /var/log/apache2/access.log*

Ergebnis dieses Schritts: eine Liste der Angriffsversuche gegen Ihre Website, mit Zeitstempel und Quell-IP. Wichtig für die Einordnung: Ein Treffer belegt einen Versuch, nicht zwingend einen Erfolg.

Schritt 2: Temporäre Verzeichnisse prüfen (der wichtigste Schritt)

Dieser Schritt ist der wichtigste der gesamten Prüfung. Die beobachteten Webshells landen in /tmp und /var/tmp, also außerhalb des Webroots. Die übliche Suche im Theme- und Upload-Verzeichnis, die auch die erste Fassung dieses Artikels in der FAQ empfohlen hat, läuft bei diesem Angriff deshalb ins Leere. Diese Korrektur sprechen wir ausdrücklich aus: Wer nur den Webroot durchsucht, findet bei diesem Angriffsmuster nichts und wiegt sich zu Unrecht in Sicherheit.

Bekannte Dateinamen aus den bisherigen Angriffswellen sind wp-pear-rce-flag.php, poc87902.php sowie Dateien nach den Mustern luci_*.php und zeta_*.php. Der folgende Befehl listet alle PHP-Dateien in den beiden Verzeichnissen:

find /tmp /var/tmp -maxdepth 2 -type f -name '*.php' -ls

Ergebnis dieses Schritts: entweder eine leere Ausgabe oder eine Liste konkreter Fundstücke mit Zeitstempel. Auf Shared Hosting haben Sie auf /tmp und /var/tmp oft keinen Zugriff, dann ist das eine Aufgabe für Ihren Hoster: Fragen Sie ausdrücklich nach PHP-Dateien in den temporären Verzeichnissen mit Erstellungsdatum ab dem 22.09.2026.

Schritt 3: WordPress-Installation auf Veränderungen prüfen

Prüfen Sie die Installation selbst auf Spuren einer Übernahme: unbekannte Administratorkonten unter Benutzer, veränderte Core-Dateien per Checksummen-Abgleich (etwa mit dem WP-CLI-Befehl wp core verify-checksums), neue oder unbekannte Cronjobs sowie kürzlich geänderte PHP-Dateien im Webroot. Ergebnis dieses Schritts: die Gewissheit, ob über die abgelegte Datei hinaus bereits in die Installation eingegriffen wurde.

Schritt 4: PHP-Konfiguration härten

Drei Maßnahmen brechen die beobachtete Angriffskette unabhängig vom WordPress-Update: register_argc_argv in der PHP-Konfiguration deaktivieren, pearcmd.php entfernen oder ihr die Leserechte entziehen, und open_basedir so setzen, dass PHP nur auf die tatsächlich benötigten Verzeichnisse zugreifen darf. Das lohnt sich über diesen CVE hinaus, denn dieselbe Kette macht auch künftige LFI-Lücken zur Codeausführung. Ergebnis dieses Schritts: ein Hosting-Stack, auf dem eine Dateieinbindung nicht mehr automatisch zur Übernahme führt. Auf unserem WordPress-Hosting sind diese Härtungen Teil der Standardkonfiguration.

Was tun, wenn Sie fündig werden

Ein Fund ist kein Grund zur Panik, aber ein Grund zu einer festen Reihenfolge. Und die wichtigste Regel vorweg, weil sie in der Praxis am häufigsten missachtet wird: Ein Update ist keine Bereinigung.

1. Website isolieren, nicht sofort löschen. Nehmen Sie die Website vom Netz oder schalten Sie sie in den Wartungsmodus, aber vernichten Sie nichts.

2. Beweise sichern, bevor Sie bereinigen. Kopieren Sie die Access-Logs und die verdächtigen Dateien an einen sicheren Ort. Ohne diese Spuren lässt sich später weder der Hergang rekonstruieren noch der Umfang des Schadens belegen.

3. Zugangsdaten rotieren. Ändern Sie alle WordPress-Passwörter, die Datenbank-Zugangsdaten und die Security-Keys in der wp-config.php. Eine Webshell mit Codeausführung konnte all das mitlesen.

4. Sauberes Backup von vor dem 22.09.2026 einspielen statt manuell zu säubern. Eine gefundene Webshell ist selten die einzige, Angreifer legen routinemäßig mehrere Hintertüren an. Ein Restore auf einen Stand vor dem ersten Angriffstag ist verlässlicher als jede manuelle Suche.

5. Danach vollständig updaten. Das eingespielte Backup ist verwundbar, sonst wäre es nicht kompromittiert worden. Direkt nach dem Restore WordPress auf 7.1.2 bringen, ebenso Themes und Plugins.

6. Monitoring für die Folgewochen. Beobachten Sie Logs, Dateisystem und Benutzerkonten in den Wochen nach dem Vorfall besonders aufmerksam, denn wer einmal Ziel war, steht auf den Listen der Angreifer.

Wenn Ihnen für diese Schritte die Zeit, der Zugriff oder die Routine fehlt: Unsere Notfall-Bereinigung für gehackte WordPress-Websites übernimmt genau diesen Ablauf, inklusive Beweissicherung und Wiederherstellung.

Einordnung: dritte Core-Lücke mit RCE-Potenzial in diesem Jahr

Nach wp2shell im Juli und Click2Shell am 21.09.2026 ist dies bereits die dritte Schwachstelle im WordPress Core innerhalb weniger Monate, die bis zur Codeausführung reicht. Das ist ungewöhnlich, denn der Core gehört zu den am besten geprüften Komponenten des Ökosystems, die große Mehrheit aller Sicherheitsvorfälle geht auf Plugins und Themes zurück.

Ein Muster verbindet die drei Fälle: Es sind keine spektakulären neuen Angriffstechniken, sondern alte, gut verstandene Fehlerklassen an Stellen, an denen die vorhandenen Schutzmechanismen schlicht nicht angewendet wurden. Die aktuelle Lücke existierte fast zehn Jahre lang neben der Funktion, die sie verhindert hätte. Für Website-Betreiber folgt daraus eine unbequeme, aber praktische Konsequenz: Die Frage ist nicht, ob die nächste Core-Lücke kommt, sondern wie schnell die eigene Website gepatcht wird, wenn sie kommt. Genau diese Reaktionszeit ist der Unterschied zwischen einer Randnotiz und einem Sicherheitsvorfall.

Timeline

Datum	Ereignis	Quelle
22.09.2026	WordPress 7.1.2 veröffentlicht	WordPress.org
22.09.2026, 11:49 UTC	Erste Probes registriert	Patchstack
22.09.2026, 17:44 UTC	Erste eindeutig bösartige Recon	Bleeping Computer
23.09.2026	Angriffsvolumen verzehnfacht, erste Webshells beobachtet	Patchstack
25.09.2026	Aufnahme in den CISA-KEV-Katalog	CISA
28.09.2026	Frist für US-Bundesbehörden	CISA

Wer mehrere Kundeninstallationen betreut, kennt das Problem dieser Timeline: Zwischen Patch und Angriff lagen Stunden, und die Prüfung auf Kompromittierung skaliert manuell nicht über Dutzende Websites. Für Agenturen haben wir dafür ein eigenes Angebot: White-Label-Wartung für Digital- und Marketing-Agenturen.

Häufige Fragen

Woran erkenne ich, ob meine Website betroffen ist?

Prüfen Sie die installierte WordPress-Version im Dashboard unter Aktualisierungen. Jede Version von 4.7.0 bis 7.1.1 ist verwundbar, sicher sind 7.1.2 und die offiziellen Backport-Releases der älteren Zweige. Ob aus der Dateieinbindung im Einzelfall Codeausführung wird, hängt zusätzlich am aktiven Theme (Verzeichnis mit Namensanfang page-) und an der PHP-Einstellung register_argc_argv.

Reicht das automatische Hintergrund-Update von WordPress?

In den meisten Fällen ja, denn Sicherheitsreleases wie 7.1.2 werden standardmäßig automatisch verteilt. Verlassen Sie sich aber nicht darauf: Auf manchen Installationen sind automatische Updates deaktiviert, etwa durch Hoster-Einstellungen oder Konstanten in der wp-config.php. Kontrollieren Sie die Versionsnummer nach dem angeblichen Update selbst.

Ich kann nicht sofort updaten, was kann ich übergangsweise tun?

Prüfen Sie zuerst Ihre Exponierung: Enthält das aktive Theme ein Verzeichnis, dessen Name mit page- beginnt, und läuft PHP mit register_argc_argv? Wenn ja, sollte das Update Vorrang vor allem anderen haben. Eine Web Application Firewall kann typische Angriffsmuster mit Verzeichniswechseln im pagename-Parameter abfangen, ersetzt das Update aber nicht.

Woran merke ich, ob meine Website bereits angegriffen wurde?

Prüfen Sie zwei Orte: die Access-Logs auf Aufrufe mit pagename-Parametern, die %2e%2e oder %252e%252e enthalten, sowie die User-Agents cve-2026-87902-poc/1.0 und nuclei-cve-2026-87902/1.0, und die Verzeichnisse /tmp und /var/tmp auf PHP-Dateien wie wp-pear-rce-flag.php, poc87902.php, luci_*.php oder zeta_*.php. Die Webshells dieses Angriffs liegen nicht im Theme- oder Upload-Verzeichnis, sondern außerhalb des Webroots. Die genaue Anleitung mit kopierbaren Befehlen steht im Abschnitt „So prüfen Sie Ihre Website auf Kompromittierung“ in diesem Artikel.

Schützt mich ein Security-Plugin vor dieser Lücke?

Nur bedingt. Security-Plugins mit Firewall-Funktion können bekannte Angriffsmuster blockieren, sobald deren Regeln aktualisiert sind, und die großen Anbieter haben entsprechende Regeln inzwischen ausgerollt. Das blockiert aber nur neue Angriffe und ändert nichts an einer Datei, die bereits vor dem Ausrollen abgelegt wurde. Behandeln Sie Firewall-Regeln als Zeitpuffer, nicht als Lösung.

Reicht das Update auf 7.1.2, wenn meine Website bereits kompromittiert wurde?

Nein. Das Update auf 7.1.2 schließt die Lücke, entfernt aber keine Webshell, die vorher nach /tmp oder /var/tmp geschrieben wurde. Eine bereits abgelegte Datei bleibt nach dem Update funktionsfähig und gibt dem Angreifer weiter Zugriff. Nach einem späten Update gehören deshalb immer die Prüfung der temporären Verzeichnisse und der Access-Logs dazu, ein Update ist keine Bereinigung.

Was bedeutet die Aufnahme in den CISA-KEV-Katalog für deutsche Unternehmen?

Rechtlich nichts, die Frist zum 28.09.2026 gilt nur für US-Bundesbehörden. Praktisch ist die Aufnahme in den KEV-Katalog das belastbarste öffentliche Signal dafür, dass eine Lücke real und breit ausgenutzt wird, denn CISA nimmt nur Schwachstellen mit nachgewiesener Ausnutzung auf. Viele Versicherer und Auditoren ziehen den Katalog zudem als Referenz heran, ein Eintrag kann also mittelbar auch für deutsche Unternehmen relevant werden.

Quellen

• WordPress.org: WordPress 7.1.2 Security Release (22.09.2026)
• Patchstack: Technische Analyse der LFI-zu-RCE-Kette in CVE-2026-87902
• GitHub Security Advisory GHSA-7hp8-65ch-5whp
• Patchstack: CVE-2026-87902, Attackers Started Probing WordPress Sites Hours After the Patch
• Bleeping Computer: Hackers start exploiting critical WordPress flaw for code execution (23.09.2026)
• CISA: Adds One Known Exploited Vulnerability to Catalog (25.09.2026)
• Help Net Security: WordPress 7.1.2 fixes critical unauthenticated path traversal vulnerability (23.09.2026)