WordPress 7.1.2: Worum es geht
Wenn Sie eine WordPress-Seite betreiben, schauen Sie heute bitte als Erstes ins Dashboard. Am 22. September 2026 ist WordPress 7.1.2 erschienen, und dieses Update enthält genau eine Korrektur: für CVE-2026-87902, eine kritische Lücke im WordPress-Kern mit 9,2 von 10 Punkten. Ein Angreifer braucht dafür kein Konto und keinen Klick von Ihnen. Eine präparierte Anfrage an Ihre Website genügt.
Betroffen sind alle Versionen von 4.7.0 bis 7.1.1. Das sind fast zehn Jahre WordPress. Und die Lücke wird schon ausgenutzt: Keine fünf Stunden nach dem Update liefen die ersten Angriffe, einen Tag später legten Angreifer bereits eigene Dateien auf fremden Servern ab.
Was Sie jetzt tun sollten: Aktualisieren Sie auf WordPress 7.1.2 oder auf die korrigierte Version Ihres Versionszweigs, etwa 7.0.6, 6.9.9 oder 6.8.10. Sie finden das Update im Dashboard unter "Aktualisierungen". Schauen Sie danach nach, ob die neue Version wirklich installiert ist.
| Merkmal | Details |
|---|---|
| Kennung | CVE-2026-87902, GHSA-7hp8-65ch-5whp (öffnet in neuem Tab) |
| Schweregrad | Kritisch, CVSS 4.0: 9,2 |
| Typ | CWE-98, Local File Inclusion mit möglicher Codeausführung |
| Betroffen | WordPress 4.7.0 bis 7.1.1 |
| Behoben in | 7.1.2 sowie Korrekturen für alle Zweige bis 4.7 |
| Anmeldung nötig | Nein |
| Aktiv ausgenutzt | Ja, seit dem 22. September 2026 |
| Entdeckt von | Robert Ressl |
Was ist CVE-2026-87902?
CVE-2026-87902 ist ein Fehler in der Funktion get_page_template(), mit der WordPress für jede Seite die passende Designvorlage aus dem Theme heraussucht. Angreifer können diese Suche umlenken. WordPress lädt dann statt einer Vorlage eine ganz andere PHP-Datei vom Server und führt sie aus. Auf manchen Servern reicht das, um die Kontrolle über die gesamte Website zu übernehmen.
Man kann sich das wie einen Botengang vorstellen. WordPress fragt: "Welche Vorlage soll ich für diese Seite holen?" Normalerweise steht die Antwort im Theme-Ordner, zum Beispiel page-kontakt.php. Der Angreifer schmuggelt aber eine Wegbeschreibung in seine Anfrage: drei Ordner nach oben, dann in den Keller des Servers, dort die Datei XY. WordPress prüft nur, ob es die Datei gibt. Ob sie überhaupt im Theme liegt, prüft es nicht. Also holt der Bote, was ihm gesagt wird.
Technisch steckt ein Trick mit doppelt kodierten Zeichen dahinter. Ein Schrägstrich wird als %252f verschickt, übersteht so die erste Kontrolle unbeschadet und wird erst später zu einem echten /. Aus dem harmlos wirkenden Seitennamen wird dann ein Pfad wie dieser:
page-templates/../../../../../../../usr/local/lib/php/pearcmd.php
Die Fachwelt nennt diese Fehlerklasse CWE-98: Eine Anwendung lässt sich von außen vorschreiben, welche Datei sie per include einbindet. In PHP ist das besonders heikel, weil PHP eingebundene Dateien sofort ausführt.
Wie wird daraus eine Übernahme des Servers?
Der Weg zur Übernahme führt über eine Datei namens pearcmd.php. Sie gehört zum alten PHP-Paketsystem PEAR und liegt auf vielen Servern einfach mit herum, weil sie bei der PHP-Installation dabei war. Ist die PHP-Einstellung register_argc_argv aktiv, nimmt diese Datei Befehle direkt aus der Adresszeile entgegen. Genau das nutzen Angreifer aus.
Der Angriff braucht zwei Anfragen, beide ohne Anmeldung. Mit der ersten bindet der Angreifer über die Lücke pearcmd.php ein und lässt sie eine kleine Datei mit eigenem PHP-Code nach /tmp schreiben. Mit der zweiten bindet er genau diese Datei ein. Ab diesem Moment läuft sein Code auf Ihrem Server, mit denselben Rechten wie WordPress selbst. Er kann Inhalte ändern, die Zugangsdaten zur Datenbank auslesen und weitere Schadsoftware nachladen.
Der Trick mit pearcmd.php ist übrigens nicht neu. Sicherheitsforscher kennen ihn seit Jahren. Neu ist, dass er diesmal im WordPress-Kern ansetzt und nicht in irgendeinem Plugin.
Ist meine WordPress-Seite betroffen?
Ihre Seite ist angreifbar, wenn drei Dinge zusammenkommen: eine WordPress-Version zwischen 4.7.0 und 7.1.1, ein aktives Theme mit einem Ordner, dessen Name mit page- beginnt, und mindestens eine öffentliche Seite ohne eigens zugewiesene Vorlage. Für die komplette Übernahme des Servers braucht es außerdem die passende PHP-Konfiguration. Diese Lücke trifft also nicht jede Installation gleich hart.
Das klingt zunächst nach vielen Bedingungen. In der Praxis sind sie schnell erfüllt. Einen Ordner namens page-templates haben laut WordPress-Advisory (öffnet in neuem Tab) zum Beispiel die älteren Standard-Themes Twenty Twelve und Twenty Fourteen sowie beliebte Themes wie Neve, Hestia und Sydney. Viele andere Themes sortieren ihre Vorlagen genauso. Und register_argc_argv ist bei allen PHP-Versionen vor 8.5 von Haus aus eingeschaltet, auch im offiziellen PHP-Docker-Image und in vielen cPanel-Hostings.
So können Sie Ihr Risiko grob einordnen:
| Ihre Situation | Was ein Angreifer tun kann |
|---|---|
Update installiert, oder Ihr Theme hat keinen page--Ordner | Nichts, die Lücke lässt sich nicht auslösen |
Alte Version, Theme mit page--Ordner | Vorhandene PHP-Dateien auf Ihrem Server ausführen lassen |
Zusätzlich pearcmd.php vorhanden und register_argc_argv aktiv | Eigenen Code einschleusen und den Server übernehmen |
Kurzcheck zum Weitergeben an Ihre IT oder Agentur
- Welche WordPress-Version läuft? 7.1.2 oder ein korrigierter älterer Zweig?
- Hat das aktive Theme (oder sein Parent-Theme) unter
wp-content/themes/einen Ordner, der mitpage-beginnt? - Welche PHP-Version läuft, und ist
register_argc_argvaktiv? Der Wert lässt sich perphpinfo()prüfen oder beim Hoster erfragen. - Liegt irgendwo eine
pearcmd.php, typischerweise unter/usr/local/lib/php/oder/usr/share/php/? - Tauchen seit dem 22. September in den Server-Logs Anfragen mit
%252f,%2e%2e,pearcmdoderconfig-createauf?
Wird CVE-2026-87902 schon ausgenutzt?
Ja, und das ging sehr schnell. Der Sicherheitsdienstleister Patchstack sah die ersten bösartigen Anfragen am 22. September um 17:44 Uhr UTC (öffnet in neuem Tab), keine fünf Stunden nachdem WordPress 7.1.2 veröffentlicht war. Sie kamen von einer kleinen Gruppe von IP-Adressen und richteten sich gegen mehrere Websites gleichzeitig.
Zuerst tasteten sich die Angreifer vor. Sie ließen harmlose WordPress-Dateien wie wp-cron.php oder wp-links-opml.php über die Lücke laden. Damit richteten sie keinen Schaden an, erfuhren aber, welche Seiten verwundbar sind. Am 23. September wurde aus dem Abtasten Ernst: Nun schrieben die Anfragen über pearcmd.php PHP-Code nach /tmp und /var/tmp. Das Angriffsvolumen lag laut Patchstack beim Zehnfachen des ersten Abends. Auch BleepingComputer (öffnet in neuem Tab) und The Hacker News (öffnet in neuem Tab) berichten über die laufenden Angriffe.
Ein Detail finden wir dabei besonders aufschlussreich. Die Anfragen nutzten exakt die Kodierung, die der Patch unterbindet. Patchstack schließt daraus, dass die Angreifer die Lücke nicht selbst gefunden haben. Sie haben sich angesehen, was das Update am Code ändert, und daraus in wenigen Stunden einen Angriff gebaut. Der Patch wurde so selbst zur Bauanleitung. Das ist bei Open-Source-Software unvermeidlich, und genau deshalb zählt jede Stunde zwischen Veröffentlichung und Update.
Ein Update schließt die Lücke, räumt aber nicht auf. Wenn Ihre Seite zwischen dem 22. September und Ihrem Update angreifbar war, lassen Sie /tmp, /var/tmp und die Upload-Ordner auf unbekannte PHP-Dateien prüfen. Die Zugangsdaten aus der wp-config.php sollten Sie vorsorglich erneuern.
Was sollten Betreiber jetzt tun?
Zuerst das Update, dann die Aufräumarbeiten. Für diese Lücke reicht das Update. Die übrigen Schritte machen Ihren Server aber auch für die nächste Lücke dieser Art unattraktiv.
- Update einspielen und nachsehen. WordPress installiert Sicherheitsupdates normalerweise von selbst. Das klappt aber nicht, wenn Sie, ein Plugin oder Ihr Hoster die automatischen Updates abgeschaltet haben. Verlassen Sie sich also nicht auf die Automatik, sondern prüfen Sie die Versionsnummer.
- Auch alte Versionszweige aktualisieren. WordPress hat die Korrektur bis zur Version 4.7 zurück bereitgestellt. Wer bewusst auf einem älteren Zweig bleibt, bekommt sie also auch, muss sie aber oft von Hand anstoßen.
register_argc_argvabschalten. Ein Webserver braucht diese Einstellung nicht. Mitregister_argc_argv = Offin derphp.iniist der bekannte Weg zur Codeausführung versperrt.- PEAR vom Produktivserver entfernen. Die Datei
pearcmd.phphat auf einem Webserver nichts verloren. In Docker-Images lässt sie sich beim Bauen löschen. - Logs durchsehen. Wer nicht sofort aktualisiert hat, sollte nach den Spuren aus dem Kurzcheck suchen.
Fünf Sicherheitsupdates in 67 Tagen
Für viele WordPress-Betreiber fühlt sich dieser Sommer wie ein Dauerlauf an, und die Zahlen bestätigen das. Erst am 17. Juli hatte WordPress mit Version 7.0.2 die Lückenkette "wp2shell" geschlossen, bestehend aus CVE-2026-63030 und CVE-2026-60137 (öffnet in neuem Tab). Auch sie erlaubte Codeausführung ohne Anmeldung, bewertet mit 9,8 Punkten. WordPress 7.1.1 kam am 17. September mit 11 Sicherheitskorrekturen, fünf Tage vor 7.1.2.
Der WordPress-Dienstleister WP Care hat mitgezählt: fünf Sicherheitsupdates für den Kern in 67 Tagen, 27 behobene Kern-Lücken allein 2026 (öffnet in neuem Tab).
Lange galt in WordPress-Diskussionen die Faustregel: Der Kern ist solide, die Probleme kommen aus den Plugins. In der Masse stimmt das weiterhin, denn laut Patchstack stammen 96 Prozent aller neuen WordPress-Lücken aus Plugins (öffnet in neuem Tab). Aber 2026 zeigt auch, dass zwanzig Jahre gewachsener Code im Kern ihre Spuren hinterlassen. Und wenn der Kern eine Lücke hat, hilft auch die sorgfältigste Plugin-Auswahl nichts.
Unsere Einschätzung
Erst einmal ein Lob. Das WordPress-Sicherheitsteam hat hier ordentlich gearbeitet. Robert Ressl meldete die Lücke am 20. Juli über HackerOne, schon am nächsten Tag kam die Bestätigung, am 22. September der Patch für jeden unterstützten Versionszweig. Das Advisory beschreibt die Bedingungen so genau, dass Betreiber ihr eigenes Risiko einschätzen können. So soll es laufen.
Was uns mehr beschäftigt, ist das Tempo auf der anderen Seite. Zwischen Patch und erstem Angriff lagen keine fünf Stunden, bei wp2shell im Juli war es ähnlich. Viele Unternehmen spielen Updates aber im Rahmen eines monatlichen Wartungstermins ein, oder wenn eben jemand Zeit hat. Bei Lücken dieser Klasse bedeutet das: Die Website steht im Zweifel wochenlang offen. Wer WordPress betreibt, braucht jemanden, der Sicherheitsupdates innerhalb von Stunden einspielt. Nebenbei in der Marketingabteilung funktioniert das nicht.
Und dann ist da noch die Frage, woran dieser Angriff eigentlich hängt. Keines der Einzelteile ist für sich genommen ein Skandal: ein sinnvoll benannter Theme-Ordner, eine PHP-Standardeinstellung, ein altes Werkzeug, das niemand gelöscht hat. Erst zusammen öffnen sie den Server. Das zeigt gut, warum WordPress-Hosting anspruchsvoller ist, als es aussieht. Ob eine Seite sicher ist, entscheidet sich im CMS und in jeder Schicht darunter.
Wir raten deshalb nicht pauschal von WordPress ab. Für viele Websites ist es weiterhin eine vernünftige Wahl, solange klar ist, wer sich um Updates, Server und Überwachung kümmert. Wenn Sie aber ohnehin über einen Relaunch nachdenken, gehört die Sicherheitslage 2026 mit in die Rechnung. Wie sich Wartung und Risiko gegen eine eigene Lösung rechnen, zeigen wir in unserem Vergleich von eigenem CMS und WordPress. Warum die Abhängigkeit von der WordPress-Infrastruktur auch organisatorisch ein Thema ist, lesen Sie in unserem Rückblick auf das WordPress-Drama.
Lösungen von SymbolicLabs
Individuelle CMS-Entwicklung
Wir entwickeln Content-Management-Systeme ohne Plugin-Wildwuchs und mit kleiner Angriffsfläche, gehostet in Deutschland und mit klarer Zuständigkeit für Updates.
CMS-Entwicklung bei SymbolicLabs
Sicherer Umzug von WordPress
Wenn Sie WordPress ablösen möchten, begleiten wir die Migration so, dass Inhalte und Google-Rankings erhalten bleiben.
WordPress-Migration ohne Rankingverlust
Webentwicklung und Betrieb
Von der Serverkonfiguration bis zur Überwachung: Wir bauen und betreiben Websites, bei denen Sicherheitsupdates nicht auf den nächsten Wartungstermin warten.
Webentwicklung bei SymbolicLabs
Häufig gestellte Fragen (FAQ)
Was ist CVE-2026-87902?
CVE-2026-87902 ist eine kritische Sicherheitslücke im WordPress-Kern mit einem CVSS-Wert von 9,2. Angreifer können damit ohne Anmeldung erreichen, dass WordPress beliebige PHP-Dateien vom Server lädt und ausführt. Auf manchen Servern führt das bis zur vollständigen Übernahme der Website.
Welche WordPress-Versionen sind betroffen?
Betroffen sind alle Versionen von 4.7.0 bis einschließlich 7.1.1. Behoben ist die Lücke in WordPress 7.1.2 und in korrigierten Versionen der älteren Zweige, darunter 7.0.6, 6.9.9, 6.8.10 und 4.7.37.
Muss ich WordPress 7.1.2 selbst installieren?
Meistens nicht, denn WordPress spielt Sicherheitsupdates normalerweise automatisch ein. Sind automatische Updates abgeschaltet, etwa durch Ihren Hoster oder ein Plugin, müssen Sie das Update im Dashboard unter "Aktualisierungen" selbst starten. Werfen Sie in jedem Fall einen Blick auf die installierte Version.
Ist meine Seite sicher, wenn mein Theme keinen page-Ordner hat?
Ja, nach aktuellem Stand lässt sich CVE-2026-87902 ohne einen Theme-Ordner, der mit page- beginnt, nicht auslösen. Das gilt für das aktive Theme und für ein eventuelles Parent-Theme. Installieren Sie das Update trotzdem, denn mit dem nächsten Theme-Wechsel kann sich das ändern.
Wird die Lücke schon aktiv ausgenutzt?
Ja. Patchstack beobachtete die ersten Angriffsversuche am 22. September 2026, keine fünf Stunden nach Erscheinen des Updates. Seit dem 23. September schreiben Angreifer auf verwundbaren Servern eigene PHP-Dateien, um sich dort festzusetzen.
Was ist pearcmd.php, und warum ist die Datei gefährlich?
pearcmd.php ist ein Kommandozeilenwerkzeug des PHP-Paketsystems PEAR, das auf vielen Servern mitinstalliert ist. Ist register_argc_argv aktiv, nimmt es Befehle aus der Adresszeile einer Webanfrage entgegen. Über eine Lücke wie CVE-2026-87902 eingebunden, können Angreifer damit eigenen Code auf den Server schreiben.
Was ist der Unterschied zu wp2shell?
wp2shell (CVE-2026-63030 und CVE-2026-60137) war eine Lückenkette in der REST-Schnittstelle und in WP_Query, die WordPress im Juli 2026 mit Version 7.0.2 geschlossen hat. Sie traf Standardinstallationen ohne weitere Bedingungen und wurde mit 9,8 Punkten bewertet. Bei CVE-2026-87902 müssen dagegen Theme und PHP-Konfiguration zusammenpassen, damit der Server übernommen werden kann.
Reicht ein Update, wenn meine Seite schon angegriffen wurde?
Nein. Das Update schließt die Lücke, entfernt aber keine Dateien, die Angreifer bereits abgelegt haben. Wurde Ihre Seite vor dem Update angegriffen, müssen das Dateisystem geprüft, Zugangsdaten erneuert und im Zweifel ein sauberes Backup eingespielt werden.
