WordPress-Kernlücke CVE-2026-87902: Angriffe seit dem Patch-Tag

Eine Lücke im WordPress-Kern mit der Bewertung 9,2 erlaubt es Angreifern ohne Anmeldung, eigenen PHP-Code ausführen zu lassen. Die Ausnutzung begann am Tag der Veröffentlichung des Updates — keine zwölf Stunden nach dem Patch.

Anders als bei den üblichen WordPress-Meldungen ist diesmal nicht ein Plugin schuld, das sich vor drei Jahren jemand installiert und dann vergessen hat. Es ist der Kern selbst. Die gute Nachricht steckt allerdings im Kleingedruckten: Für einen erfolgreichen Angriff müssen zwei Bedingungen gleichzeitig erfüllt sein, und die zweite davon ist auf vielen Servern gar nicht gegeben.

Das Wichtigste in Kürze

• CVE-2026-87902, CVSS 9,2: Codeausführung aus der Ferne, ohne Anmeldung, im WordPress-Kern.
• Gepatcht in 7.1.2, 7.0.6, 6.9.9 und 6.8.10.
• Erste Ausnutzung am 22. September 2026 um 11:49 UTC — am Tag des Patches. Bis zum 23. September zählte ein Honeypot-Betreiber 68 Versuche.
• Zwei Voraussetzungen müssen zusammenkommen: ein Theme mit einem Verzeichnis, dessen Name mit page- beginnt, und eine lesbare PHP-Datei auf dem Server, die sich missbrauchen lässt.
• Automatische Updates sind bei WordPress standardmäßig aktiv und dürften die Masse der Installationen bereits versorgt haben.

Wie der Angriff funktioniert

Im Zentrum steht die Funktion get_page_template(). Sie entscheidet, welche Vorlagendatei WordPress für eine Seite lädt. Durch den Fehler lässt sich diese Auflösung so manipulieren, dass sie eine beliebige lesbare PHP-Datei außerhalb der Theme-Verzeichnisse einbindet. WordPress selbst formuliert es so: Ein nicht angemeldeter Angreifer könne die Vorlagenauflösung dazu bringen, eine gewählte lesbare lokale PHP-Datei einzubinden.

Damit das klappt, braucht es zwei Dinge.

Erstens muss das aktive Theme ein Verzeichnis auf oberster Ebene besitzen, dessen Name mit page- beginnt — etwa page-templates. Das ist nicht exotisch; viele kommerzielle Themes legen so etwas an.

Zweitens muss auf dem Server eine PHP-Datei liegen, die sich zum Ausführen von Befehlen eignet. Der Klassiker dafür ist pearcmd.php, ein Überbleibsel des PEAR-Paketmanagers, das auf manchen Servern und in vielen Docker-Images herumliegt, ohne dass jemand es je gebraucht hätte.

Beides zusammen ergibt Codeausführung. Fehlt eines davon, läuft der Angriff ins Leere.

Was die Angreifer hinterlassen

In den beobachteten Angriffen wurden Dateien in /tmp/ und /var/tmp/ abgelegt. Diese Namen tauchten auf:

• wp-pear-rce-flag.php
• poc87902.php
• luci_<zufall>.php
• zeta_<zufall>.php

Die ersten beiden Namen verraten, dass hier zunächst vor allem getestet wurde, ob eine Installation überhaupt verwundbar ist. Solche Markierungsdateien legt man an, um verwundbare Ziele für später zu katalogisieren. Das ist keine Entwarnung, sondern das übliche erste Kapitel.

Als Herkunft der Zugriffe wurden unter anderem diese Adressen genannt: 104.194.9.227, 43.250.53.42, 180.251.159.243, 195.178.110.247, 107.189.14.87, 45.61.184.170 und 92.246.130.76.

Was jetzt zu tun ist

1. Version prüfen und aktualisieren auf 7.1.2, 7.0.6, 6.9.9 oder 6.8.10 — je nach eingesetztem Zweig. Im Dashboard unter „Updates“, auf der Kommandozeile mit wp core version.
2. Automatische Updates kontrollieren. Sie sind standardmäßig an, werden aber gern von Hosting-Paketen oder Optimierungs-Plugins deaktiviert.
3. Nach den genannten Dateien suchen in /tmp und /var/tmp, dazu nach unerwarteten PHP-Dateien im Web-Verzeichnis.
4. Prüfen, ob pearcmd.php überhaupt existiert. Wenn ja und PEAR nicht gebraucht wird: entfernen. Das schließt gleich eine ganze Familie ähnlicher Angriffe.

Zur Einordnung ein Blick auf die eigene Installation: Diese Seite lief zum Zeitpunkt der Meldung bereits auf 7.1.2, automatische Updates sind aktiv, und das eingesetzte Theme hat kein Verzeichnis, das mit page- beginnt. Damit fehlt die Voraussetzung gleich doppelt. Genau diese drei Punkte sind es, die man bei sich selbst in zwei Minuten nachsehen kann.

Einordnung

Dass eine Lücke am Tag ihrer Veröffentlichung ausgenutzt wird, ist inzwischen der Normalfall. Sobald ein Patch erscheint, ist er auch eine Beschreibung des Fehlers: Wer den Codeunterschied liest, weiß, wo er suchen muss. Zwischen „Update ist da“ und „Angriff läuft“ liegen heute Stunden, nicht Wochen.

Bemerkenswert ist eher, wie unspektakulär die zweite Zutat ist. pearcmd.php ist keine Schwachstelle im eigentlichen Sinn, sondern eine harmlose Datei, die auf vielen Systemen seit Jahren sinnlos herumliegt. Erst in Kombination mit einem Fehler an ganz anderer Stelle wird sie zum Werkzeug. Das ist ein gutes Argument dafür, Server aufgeräumt zu halten: Was nicht da ist, kann auch nicht missbraucht werden.

Häufige Fragen

Ich nutze ein Standard-Theme. Bin ich betroffen?

Die mitgelieferten Twenty-Themes bringen kein Verzeichnis mit, dessen Name mit page- beginnt. Damit fehlt die erste Voraussetzung. Verlassen sollte man sich darauf trotzdem nicht — aktualisieren ist in jedem Fall der richtige Weg.

Wie prüfe ich, ob mein Theme betroffen ist?

Ein Blick in das Theme-Verzeichnis genügt: Gibt es dort einen Ordner, der mit page- anfängt? Auf der Kommandozeile etwa mit ls wp-content/themes/DEIN-THEME/ | grep '^page-'.

Meine Seite läuft bei einem Hoster. Muss ich etwas tun?

Nachsehen auf jeden Fall. Viele Hoster spielen Kernupdates automatisch ein, manche verzögern sie aber, um eigene Tests zu fahren. Die angezeigte Version im Dashboard ist die verlässliche Auskunft.

Woran erkenne ich, ob jemand erfolgreich war?

An den oben genannten Dateinamen in den Temp-Verzeichnissen, an unbekannten PHP-Dateien im Webspace und an Zugriffen aus den genannten Adressbereichen im Server-Log. Bei einem Fund gilt das Übliche: Zugangsdaten tauschen, Installation gründlich prüfen und im Zweifel sauber neu aufsetzen.

Quellen: WordPress-Sicherheitsmitteilung zu den Versionen 7.1.2, 7.0.6, 6.9.9 und 6.8.10, Telemetriedaten von Previdian und Patchstack, Berichterstattung von The Hacker News (24.09.2026). Abgerufen am 24.09.2026.