WordPress 7.1.2 schließt eine kritische Sicherheitslücke im WordPress-Kern, über die Angreifer ohne Passwort fremde PHP-Dateien auf deinem Server ausführen können. Die Lücke wird bereits aktiv ausgenutzt, deshalb gehört das Update heute eingespielt und nicht erst beim nächsten Wartungstermin. Betroffen ist fast jede WordPress-Webseite, die seit 2016 ins Netz gegangen ist. Ich erkläre dir, was hinter der Lücke steckt, unter welchen Bedingungen daraus eine komplette Übernahme wird und wie du in wenigen Minuten prüfst, ob deine Seite schon sicher ist.
Letzte Aktualisierung: September 2026
Was WordPress 7.1.2 behebt und warum es so dringend ist
Das WordPress-Team hat die Version 7.1.2 am 22. September 2026 veröffentlicht. Es ist eine reine Sicherheitsveröffentlichung mit genau einer Korrektur. Das Release hat John Blackbourn geleitet, gemeldet hat die Lücke der Sicherheitsforscher Robert Ressl. In der offiziellen Ankündigung auf WordPress.org steht die übliche, aber diesmal ernst gemeinte Empfehlung: Seiten sofort aktualisieren.
Die Lücke trägt die Kennung CVE-2026-87902. WordPress selbst bewertet sie mit 9,2 von 10 Punkten auf der CVSS-Skala in Version 4. Das ist die Kategorie „kritisch“. Der Angreifer braucht dafür kein Benutzerkonto auf deiner Seite, und niemand aus deinem Team muss auf einen Link klicken.
Betroffen sind alle Versionen von 4.7.0 bis einschließlich 7.1.1. Das ist fast ein Jahrzehnt WordPress. Deshalb hat das Team die Korrektur zusätzlich in 24 ältere Versionszweige zurückportiert. Wer also noch auf WordPress 6.9 oder 6.8 läuft, bekommt eine eigene gepatchte Version.
Was ist eine Path-Traversal-Lücke?
Eine Path-Traversal-Lücke ist ein Fehler, bei dem eine Software Pfadangaben aus einer Anfrage ungeprüft übernimmt. Mit Zeichenfolgen wie „../“ springt der Angreifer dann aus dem vorgesehenen Ordner heraus und greift auf Dateien an anderer Stelle des Servers zu. Bei WordPress 7.1.2 geht es um genau so einen Sprung.
Konkret sitzt der Fehler in der Funktion get_page_template(). Sie entscheidet, welche Vorlagendatei deines Themes eine Seite darstellt. Einer der Dateinamen, die WordPress dabei durchprobiert, stammt direkt aus dem Parameter pagename in der Adresse. Diesen Wert hat WordPress bisher nicht sauber geprüft. Ein Angreifer kann so eine beliebige lesbare PHP-Datei auf dem Server einbinden, auch wenn sie gar nicht zu deinem Theme gehört. Eingebunden heißt bei PHP: ausgeführt.
Warum fünf Tage nach 7.1.1 schon wieder ein Update?
Erst am 17. September 2026 kam WordPress 7.1.1 mit elf Sicherheitskorrekturen heraus. Was darin steckt, habe ich im Artikel zum WordPress Sicherheitsupdate mit elf geschlossenen Lücken aufgeschrieben. Die neue Lücke gehört nicht zu diesen elf. Sie ist später gemeldet und separat geschlossen worden. Wer 7.1.1 eingespielt hat, ist also noch nicht sicher. Erst WordPress 7.1.2 schließt CVE-2026-87902.
Angriffe auf die Lücke laufen seit dem Tag der Veröffentlichung
Die Zeit zwischen Patch und Angriff war diesmal extrem kurz. Das Sicherheitsunternehmen Patchstack hat die ersten Tastversuche am 22. September um 11:49 Uhr UTC registriert, also wenige Stunden nach der Veröffentlichung. Um 15:34 Uhr UTC am selben Tag folgte der erste Versuch, über die Lücke eine Datei auf einen Server zu schreiben.
Am Folgetag lag der Angriffsverkehr um ein Vielfaches höher. Anfangs kamen die Anfragen aus einer kleinen Gruppe von Adressen, am 23. September verteilten sie sich bereits auf einige hundert. Inzwischen kursieren öffentliche Scan-Werkzeuge, die gezielt nach verwundbaren Seiten suchen.
Der Angriffsverkehr auf CVE-2026-87902 lag am 23. September 2026 mehr als zehnmal so hoch wie am ersten Abend nach der Veröffentlichung.
Quelle: Patchstack, Sicherheits-Analyse „CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch“, Auswertung der eigenen Angriffs-Telemetrie über die geschützten WordPress-Installationen, Beobachtungszeitraum 22. bis 23. September 2026
Das Muster kennst du vielleicht schon aus dem Sommer. Auch bei der Elementor Sicherheitslücke begannen die Angriffe am Tag des Patches. Angreifer lesen die Korrektur, vergleichen sie mit der alten Version und wissen danach, wo sie ansetzen müssen. Der Unterschied: Diesmal steckt die Lücke im WordPress-Kern, also auf jeder Installation.
Genau das macht die Meldung so ungewöhnlich. Lücken im Kern sind selten, und kritische noch seltener. Der Großteil der Probleme steckt normalerweise in Plugins.
Von 11.334 neu erfassten Schwachstellen im WordPress-Ökosystem entfielen 91 Prozent auf Plugins, 9 Prozent auf Themes und nur 6 auf den WordPress-Kern, alle mit niedriger Priorität.
Quelle: Patchstack, Whitepaper „State of WordPress Security in 2026“, Erhebungsjahr 2025, Auswertung aller im Jahr 2025 in der Patchstack-Schwachstellendatenbank erfassten Meldungen
Im ganzen Jahr 2025 gab es also keine einzige ernsthafte Lücke im Kern. Jetzt kommt eine mit 9,2 Punkten, die ohne Anmeldung funktioniert. Wer bisher dachte, „WordPress selbst ist sicher, nur die Plugins machen Ärger“, sollte diese Woche als Ausnahme im Kopf behalten.
Wann aus der Lücke eine komplette Übernahme wird
Jetzt die gute Nachricht, zumindest für viele Seiten. Das Einbinden fremder PHP-Dateien klappt auf jeder ungepatchten Installation. Damit ein Angreifer daraus eigenen Schadcode auf dem Server macht, müssen aber mehrere Bedingungen zusammenkommen. Sicherheitsforscher haben die Kette so beschrieben:
Die Webseite läuft auf einer WordPress-Version von 4.7.0 bis 7.1.1 ohne den zurückportierten Patch.
Das aktive Theme enthält einen Unterordner, dessen Name mit
page-beginnt.Die PHP-Einstellung
register_argc_argvist auf dem Server eingeschaltet.Die Datei
pearcmd.phpaus dem PHP-Paketsystem PEAR liegt lesbar auf dem Server.
Sind alle vier Punkte erfüllt, rufen Angreifer über die Lücke pearcmd.php auf und nutzen deren Konfigurationsbefehl, um eine eigene PHP-Datei auf die Festplatte zu schreiben. Ab diesem Moment gehört der Server faktisch ihnen. Sie können Spam-Seiten anlegen, Besucher umleiten oder Formulardaten mitlesen.
Laut dem IT-Sicherheitsmagazin Security Affairs sind die Bedingungen drei und vier keine Exoten. Die offiziellen PHP-Docker-Images und manche cPanel-Umgebungen bringen beides standardmäßig mit. Ob das bei deinem Hoster so ist, kann ich von außen nicht beurteilen. Das kann nur der Hoster selbst beantworten.
Bedingung | Was sie bedeutet | Wer sie prüfen kann |
|---|---|---|
Veraltete WordPress-Version | Der Patch fehlt, die Lücke ist offen | Du selbst im Dashboard |
Theme-Ordner mit „page-“ | Der Umweg über die Vorlagensuche funktioniert | Du selbst per FTP oder Dateimanager |
| Werte aus der Adresse landen als Befehle bei PHP-Skripten | Hoster oder Webdesigner |
| Ein Werkzeug zum Schreiben von Dateien steht bereit | Hoster |
Ehrlich gesagt halte ich es für keine gute Idee, diese Liste abzuarbeiten und sich bei einem fehlenden Punkt entspannt zurückzulehnen. Die Kette, die Patchstack beobachtet, ist die bekannteste. Es wäre nicht das erste Mal, dass ein zweiter Weg auftaucht. Das Update von WordPress 7.1.2 dauert Minuten. Die Analyse deines Servers dauert länger.
WordPress 7.1.2 installiert? So prüfst du es in fünf Minuten
Melde dich im WordPress-Dashboard an und öffne den Menüpunkt „Dashboard“ und dann „Aktualisierungen“. Oben steht die installierte Version. Alternativ findest du die Versionsnummer unten rechts auf jeder Admin-Seite.
Jetzt kommt der Teil, an dem viele stolpern. Nicht jede Seite muss auf 7.1.2 springen, um sicher zu sein. Entscheidend ist, dass du die gepatchte Version deines Versionszweigs hast. Die wichtigsten Stände:
Dein Versionszweig | Sichere Version ab |
|---|---|
7.1 | 7.1.2 |
7.0 | 7.0.6 |
6.9 | 6.9.9 |
6.8 | 6.8.10 |
4.7 (ältester Zweig mit Patch) | 4.7.37 |
Für die übrigen Zweige zwischen 4.7 und 6.8 gibt es ebenfalls eigene Patch-Versionen. Die genaue Nummer siehst du, wenn du im Dashboard auf „Aktualisierungen“ gehst und WordPress die Suche nach neuen Versionen neu anstößt. Offiziell unterstützt das WordPress-Team aber nur die jeweils aktuelle Version. Wer noch auf einem sehr alten Zweig sitzt, bekommt diesmal Glück, sollte sich darauf aber nicht verlassen.
Warum das automatische Update nicht immer greift
Kleine Sicherheitsversionen spielt WordPress normalerweise von selbst ein. Deshalb sind viele Seiten schon aktuell, ohne dass jemand etwas getan hat. Es gibt aber typische Gründe, warum das ausbleibt:
Ein Plugin oder eine Zeile in der
wp-config.phphat automatische Updates abgeschaltet, oft vor Jahren und aus Vorsicht.Die Dateirechte auf dem Server erlauben WordPress nicht, eigene Dateien zu ersetzen.
Die Seite läuft über eine Versionsverwaltung, bei der WordPress Updates grundsätzlich blockiert.
Der Hoster steuert Updates selbst und hat den Patch noch nicht verteilt.
Wenn deine Seite also nicht auf der sicheren Version steht, obwohl automatische Updates „eigentlich an“ sind, liegt es meist an einem dieser Punkte. Starte das Update dann manuell über den Knopf „Jetzt aktualisieren“. Vorher ein Backup, wie immer.
Was tun, wenn du nicht sofort aktualisieren kannst?
Manchmal hängt eine Seite an einer alten Version, weil ein Plugin mit neuen Versionen nicht klarkommt. Dann gibt es zwei Übergangslösungen. Erstens kann dein Hoster register_argc_argv ausschalten. Das unterbricht die bekannte Angriffskette über pearcmd.php. Zweitens kann eine Web Application Firewall Anfragen blockieren, bei denen im Parameter pagename Zeichenfolgen wie „../“ oder deren kodierte Varianten auftauchen. Beides ist nur eine Notbremse. Sicher bist du erst mit WordPress 7.1.2 oder der gepatchten Version deines Zweigs.
Woran du erkennst, ob deine WordPress-Webseite schon angegriffen wurde
Wenn deine Seite zwischen dem 22. September und deinem Update ungepatcht war, lohnt ein kurzer Blick auf mögliche Spuren. Patchstack hat mehrere Kennzeichen veröffentlicht. Die wichtigsten davon kannst du oder dein Hoster schnell prüfen:
Unerwartete PHP-Dateien in den Server-Ordnern
/tmpoder/var/tmp. Dort schreiben die bisher beobachteten Angriffe ihre Dateien hin.Dateinamen wie
wp-pear-rce-flag.php,poc87902.phpoder Dateien, die mitluci_oderzeta_beginnen.Einträge im Zugriffsprotokoll, bei denen der Parameter
pagenamekodierte Punkte wie%2e%2eenthält.Anfragen mit den Wörtern „pearcmd“, „config-show“ oder „config-create“ in der Adresse.
Auf die Ordner /tmp und die Server-Protokolle hast du bei einfachem Shared Hosting meist keinen direkten Zugriff. Schreib deinem Hoster dann eine kurze Mail mit der CVE-Nummer und bitte um eine Prüfung. Seriöse Hoster kennen die Meldung und antworten in der Regel schnell.
Findet sich etwas, reicht das Update allein nicht mehr. Dann gehört die Seite aus einem sauberen Backup von vor dem 22. September wiederhergestellt, alle Passwörter werden getauscht und die WordPress-Version wird direkt danach aktualisiert. Wie du deine Seite darüber hinaus absicherst, habe ich in der Anleitung WordPress sicher machen zusammengefasst.
Ein Beispiel aus dem Handwerk
Stell dir einen Malerbetrieb mit acht Mitarbeitern vor. Die Webseite wurde 2021 gebaut und läuft seitdem. Die damalige Agentur hat automatische Updates abgeschaltet, weil ein Galerie-Plugin nach einem Update einmal Bilder verloren hatte. Seitdem steht die Seite auf WordPress 6.8. Niemand im Betrieb schaut ins Dashboard, warum auch. Anfragen kommen ja rein.
Genau so eine Seite ist diese Woche angreifbar. Das Theme hat eine Vorlage mit einem page--Ordner, der Hoster nutzt eine Standard-PHP-Konfiguration. Ob der Server am Ende übernommen wird, hängt an Details, die der Inhaber gar nicht kennt. Der Aufwand, das zu verhindern: einmal auf 6.8.10 aktualisieren, oder besser gleich auf WordPress 7.1.2 und das Galerie-Plugin ersetzen.
Viele Handwerksbetriebe kennen diese Lage. Die Seite soll Anfragen bringen, mehr nicht. Genau deshalb wird sie liegen gelassen, solange sie funktioniert. Das ist verständlich, aber bei Lücken dieser Stärke teuer. Eine gehackte Seite verliert schnell ihre Google-Rankings, und Browser warnen Besucher vor dem Aufruf. Wie eine gepflegte Seite für diese Branche aussieht, liest du unter Webdesign für Maler.
Was diese Woche über WordPress-Wartung lehrt
Zwei Sicherheitsversionen in fünf Tagen sind kein Normalzustand, aber auch keine Ausnahme mehr. Dazu kommt eine weitere offene Baustelle. Laut einem Bericht von Borns IT- und Windows-Blog vom 22. September hat der österreichische Sicherheitsforscher Aria Akhavan Berichte zu 23 Schwachstellen veröffentlicht, die über die alten Schnittstellen xmlrpc.php und admin-ajax.php laufen sollen. Er gibt an, das WordPress-Team bereits im August informiert zu haben, ohne Antwort. Eine offizielle Bestätigung dieser Lücken gibt es bis heute nicht. Ich würde die Meldung deshalb nicht dramatisieren, aber ernst nehmen.
Praktisch heißt das: Wenn deine Seite XML-RPC nicht braucht, schalte die Schnittstelle ab. Die meisten Webseiten kleiner Betriebe nutzen sie nicht. Gebraucht wird sie fast nur von der alten WordPress-App und von einigen Veröffentlichungs-Werkzeugen.
Der größere Punkt ist die Reaktionszeit. Zwischen Patch und erstem Angriff lagen bei WordPress 7.1.2 nur Stunden. Eine Routine, die einmal im Monat nach Updates schaut, kommt da nicht mehr hinterher. Wie schnell du bei welchem Update handeln solltest, steht im Artikel WordPress Update: wie schnell du reagieren musst.
Vorgehen | Reaktion auf eine Lücke wie CVE-2026-87902 | Aufwand für dich |
|---|---|---|
Niemand kümmert sich | Nur, wenn das automatische Update zufällig greift | Keiner, bis zum Hack |
Du selbst, einmal im Monat | Bis zu vier Wochen offen | Etwa eine Stunde pro Monat |
Laufende Wartung mit Überwachung | Update innerhalb eines Tages, danach Funktionstest | Keiner |
Häufige Fragen zu WordPress 7.1.2
Muss ich WordPress 7.1.2 installieren, wenn ich gerade erst 7.1.1 eingespielt habe?
Ja. Die Lücke CVE-2026-87902 ist erst in WordPress 7.1.2 geschlossen, Version 7.1.1 ist weiterhin angreifbar. Das Update ist klein und ändert nichts an Design oder Funktionen.
Kann das Update meine Webseite kaputt machen?
Das Risiko ist sehr gering, weil WordPress 7.1.2 nur eine einzige Sicherheitskorrektur enthält. Ein Backup vor dem Update solltest du trotzdem anlegen, das gilt für jede Aktualisierung.
Ich nutze WordPress 6.9, muss ich jetzt auf 7.1 wechseln?
Für diese Lücke nicht. Die Version 6.9.9 enthält denselben Patch. Langfristig solltest du trotzdem auf den aktuellen Zweig wechseln, weil nur dieser offiziell unterstützt wird.
Schützt mich ein Sicherheits-Plugin wie Wordfence auch ohne Update?
Eine Firewall-Regel kann bekannte Angriffsmuster blockieren, schließt aber die Lücke nicht. Neue Varianten eines Angriffs rutschen unter Umständen durch, deshalb ersetzt kein Plugin das Update.
Woher weiß ich, ob mein Server die Bedingungen für eine Übernahme erfüllt?
Die PHP-Einstellung und die PEAR-Dateien kann nur dein Hoster sicher prüfen. Frag dort mit der Kennung CVE-2026-87902 nach, die Antwort kommt meist innerhalb eines Tages.
Fazit: WordPress 7.1.2 heute prüfen, nicht nächste Woche
WordPress 7.1.2 schließt die erste wirklich kritische Lücke im WordPress-Kern seit langer Zeit, und sie wird bereits ausgenutzt. Öffne heute dein Dashboard, prüf die Versionsnummer und vergleiche sie mit der Tabelle oben. Steht dort eine ältere Version, aktualisiere sofort und frag deinen Hoster nach Spuren in /tmp.
Die zweite Frage ist unbequemer: Wer hätte es bemerkt, wenn du diesen Artikel nicht gelesen hättest? Wenn die Antwort „niemand“ lautet, fehlt deiner Webseite eine Wartung. In unseren Wartungspaketen ab 49 € netto im Monat übernehmen wir WordPress- und Plugin-Updates, tägliche Backups, Malware-Scans und die Überwachung rund um die Uhr. Bei einer Meldung wie dieser ist deine Seite gepatcht, bevor du davon erfährst.
Du bist unsicher, ob deine Seite betroffen ist, oder weißt gar nicht, wer sie gerade betreut? Dann lass uns im kostenlosen Erstgespräch gemeinsam draufschauen. Du erfährst danach, auf welcher Version deine Seite läuft, welche Plugins veraltet sind und wie eine laufende Wartung für deinen Betrieb aussehen würde.
Die technischen Details zur Angriffskette hat Patchstack in einer ausführlichen Analyse veröffentlicht.
