WordPress 7.1.2: kritische Lücke ohne Anmeldung ausnutzbar, Angreifer scannten schon Stunden nach dem Patch. Was jetzt zu tun ist

Fünf Tage nach dem Sicherheitsrelease 7.1.1 hat WordPress am 22. September 2026 nachgelegt: Version 7.1.2 schließt eine einzige Lücke, aber eine kritische. Ein Angreifer kann ohne Anmeldung dafür sorgen, dass WordPress bei der Auflösung der Seitenvorlage eine lesbare PHP-Datei außerhalb des Theme-Ordners einbindet. Treffen bestimmte Voraussetzungen bei Server und aktivem Theme zu, führt das zur Ausführung fremden Codes. Patchstack beobachtete die ersten Suchanfragen nach verwundbaren Seiten laut eigener Angabe bereits am Vormittag des 22. September, wenige Stunden nach der Veröffentlichung, und meldete einen Tag später, dass Angreifer inzwischen Dateien auf die Festplatte schreiben. Wer noch nicht aktualisiert hat, sollte das jetzt tun.

Was die Lücke ist

Gemeldet hat sie Robert Ressl, geführt wird sie als CVE-2026-87902 mit der Einstufung kritisch. Betroffen sind laut Patchstack alle Versionen von 4.7.0 bis 7.1.1, also praktisch jede Installation der letzten Jahre. Das Sicherheitsteam hat die Korrektur auf alle noch versorgten Zweige zurückportiert: 7.1.2, 7.0.6, 6.9.9, 6.8.10 und weiter bis 4.7.37. Wer aus irgendeinem Grund auf einer älteren Hauptversion festhängt, bekommt die Korrektur also ebenfalls, sofern die Hintergrund-Updates laufen.

Technisch handelt es sich um eine Pfadüberschreitung, die in eine Local File Inclusion mündet. Das Ausmaß hängt von Voraussetzungen ab: Der Server muss bestimmte Dateien lesbar bereithalten, das aktive Theme muss sich auf eine bestimmte Weise verhalten. Patchstack beschreibt, dass die Angreifer anfangs nur harmlose Kerndateien einbanden, um verwundbare Seiten zu erkennen, und dann auf die Datei pearcmd.php umschwenkten, die auf vielen Servern mit der PHP-Installation mitkommt und sich zum Schreiben von Dateien missbrauchen lässt. Öffentliche Scan-Werkzeuge für die Lücke sind seitdem im Umlauf. Das ist der Grund, warum die Frist zwischen Patch und Angriff keine Tage mehr beträgt, sondern Stunden.

Schritt 1: Version prüfen

Im Dashboard unter „Aktualisierungen“ nachsehen. Steht dort 7.1.2 oder auf einem älteren Zweig 7.0.6, 6.9.9 oder 6.8.10, ist der Kern geschlossen. Installationen mit aktiven Hintergrund-Updates haben das in der Regel am 22. September selbst erledigt. Prüfen Sie es trotzdem. Manche Hoster und Plugins schalten automatische Updates ab, und genau diese Seiten stehen jetzt auf den Scanlisten. Wer mehrere Websites betreut, prüft alle, auch die vergessene Landingpage und die Testinstallation im Unterordner: Scanner unterscheiden nicht nach Bedeutung, sondern nach Erreichbarkeit.

Schritt 2: Spuren suchen

• Server-Logs: Wenn Ihr Hoster Zugriffsprotokolle anbietet, nach Aufrufen mit pearcmd oder mit auffälligen Vorlagen-Parametern ab dem 22. September suchen.
• Neue PHP-Dateien: Ordner wp-content/uploads/, das Wurzelverzeichnis und wp-content/mu-plugins/ auf Dateien prüfen, die seit dem 22. September entstanden sind.
• Scanner laufen lassen: Wordfence, Patchstack oder das Werkzeug des Hosters auf geänderte Kerndateien prüfen lassen.
• Benutzer: Unbekannte Administratoren sind das eindeutigste Zeichen.

Findet sich etwas, gilt die Reihenfolge aus meinem Beitrag zum Release 7.1.1: sauberes Backup, Update, alle Zugangsdaten und Schlüssel erneuern.

Schritt 3: Die Lehre aus zwei Releases in einer Woche

7.1.1 und 7.1.2 haben innerhalb von fünf Tagen gezeigt, was ein Update-Rhythmus „einmal im Monat“ wert ist: wenig, wenn dazwischen eine kritische Lücke öffentlich wird. Meine Empfehlung hat sich damit nicht geändert, nur ihre Dringlichkeit:

1. Hintergrund-Updates für Sicherheits- und Wartungsversionen eingeschaltet lassen. Sie sind der einzige Mechanismus, der schneller ist als die Scanner.
2. Eine Firewall mit virtuellen Patches einsetzen. Patchstack und Wordfence hatten Regeln, bevor viele Seiten das Update hatten.
3. Die Theme-Frage klären: Ein aktuelles, gepflegtes Theme schließt eine der Voraussetzungen für die Ausnutzung. Verwaiste Themes gehören gelöscht.
4. Jemanden benennen, der Sicherheitsmeldungen liest. Bei Kunden in meiner WordPress-Betreuung bin das ich, und 7.1.2 war am Nachmittag des 22. September überall eingespielt.

Quellen

• WordPress.org: WordPress 7.1.2 Release
• Patchstack: CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch

Kurz beantwortet

Welche WordPress-Versionen sind von CVE-2026-87902 betroffen?

Laut Patchstack alle Versionen von 4.7.0 bis 7.1.1. Geschlossen ist die Lücke in 7.1.2 sowie in den zurückportierten Versionen 7.0.6, 6.9.9, 6.8.10 und älteren Zweigen bis 4.7.37.

Wird die Lücke aktiv ausgenutzt?

Ja. Patchstack meldete erste Scans wenige Stunden nach dem Patch und am 23. September Versuche, über pearcmd.php Dateien auf den Server zu schreiben. Scan-Werkzeuge sind öffentlich verfügbar.

Reicht das Update?

Das Update schließt die Lücke. Wer nach dem 22. September verzögert aktualisiert hat, sollte zusätzlich Logs, Upload-Ordner und Benutzerliste prüfen.