Warum sollte ausgerechnet ein Update, das erst fünf Tage alt ist, schon wieder ein Sicherheitsupdate brauchen? Genau das ist am 22. September passiert: WordPress hat mit Version 7.1.2 eine kritische Lücke geschlossen, die komplett unabhängig vom Patch vom 17. September ist – und die betrifft praktisch jede WordPress-Seite, die seit 2016 existiert.
Was ist passiert?
WordPress hat mit CVE-2026-87902 eine Schwachstelle mit dem CVSS-Wert 9,2 geschlossen – als „kritisch“ eingestuft [Help Net Security]. Der Fehler steckt in der Funktion, die WordPress benutzt, um die passende Theme-Datei für eine Seite auszuwählen (get_page_template()). Ein Teil des Dateinamens wird aus der aufgerufenen Web-Adresse gebaut, und ausgerechnet dabei hat WordPress bislang nicht geprüft, ob sich darin „../“-Sprünge verstecken – die übliche Prüfung, die an anderer Stelle im Code längst vorhanden war [The Hacker News].
Das Ergebnis: Ein Angreifer kann ganz ohne Benutzerkonto und ohne dass jemand eingeloggt sein muss, WordPress dazu bringen, eine beliebige lesbare PHP-Datei außerhalb des eigentlichen Theme-Ordners zu laden.
Wer ist betroffen?
Jede Version von WordPress 4.7.0 bis 7.1.1 – also auch die Version, die erst vor fünf Tagen als Sicherheitsupdate erschienen ist [WordPress.org]. Die passende Update-Version je nach Branch:
- 7.1.x → 7.1.2
- 7.0.x → 7.0.6
- 6.9.x → 6.9.9
- 6.8.x → 6.8.10
- 6.7.x → 6.7.9
- 6.6.x → 6.6.9
WordPress hat den Fix sogar bis zurück auf Version 4.7.37 portiert – für ganz alte Installationen, die aus welchen Gründen auch immer noch laufen. Wenn bei dir automatische Hintergrund-Updates aktiv sind, hat sich deine Seite vermutlich schon selbst aktualisiert. Wenn nicht: im Dashboard unter „Aktualisierungen“ nachsehen, nicht erst morgen.
Reicht das Laden der Datei für eine komplette Server-Übernahme?
Nicht automatisch – und genau das macht die Einschätzung etwas komplizierter, als „kritisch“ auf den ersten Blick klingt. Das bloße Laden einer fremden PHP-Datei führt erstmal nur das aus, was diese Datei ohnehin tut. Damit daraus echter, vom Angreifer frei wählbarer Code wird, braucht es zwei zusätzliche Bedingungen [Patchstack]:
- Das aktive Theme muss einen Ordner auf oberster Ebene haben, dessen Name mit „page-“ beginnt (einige ältere Standard-Themes bringen das mit, aktuelle WordPress-Standard-Themes nicht).
- Auf dem Server muss die PHP-Einstellung register_argc_argv aktiv sein – bei PHP 8.5 ist das standardmäßig aus, bei älteren PHP-Versionen oft noch an.
Sind beide Bedingungen erfüllt, wird aus der Datei-Einbindung eine waschechte Remote Code Execution. Sind sie es nicht, bleibt es bei einem ernsten, aber begrenzteren Risiko. Ich würde mich darauf trotzdem nicht verlassen – die Kombination lässt sich in mehr Standard-Setups finden, als man zunächst denkt.
Was du jetzt tun solltest
- WordPress-Kern auf die für deinen Branch passende Version aktualisieren (Tabelle oben) – es gibt keinen Workaround, nur das Update selbst schließt die Lücke.
- Falls ein sofortiges Update nicht möglich ist: register_argc_argv für Web-Requests deaktivieren und ungenutzte PEAR-Komponenten entfernen – das behebt die Lücke nicht, verkleinert aber den Weg zur Codeausführung [Ressl.ch].
- Prüfen, ob dein aktives Theme einen Ordner hat, der mit „page-“ beginnt – wenn ja, ist das ein zusätzlicher Grund, das Update nicht aufzuschieben.
- Automatische Kern-Updates aktivieren, falls noch nicht geschehen. Genau für solche Fälle sind sie gedacht.
Stand 22. September gibt es keine Berichte über aktive Ausnutzung, und die Lücke steht auch nicht in der CISA-Liste bekannter ausgenutzter Schwachstellen [The Hacker News]. Das kann sich schnell ändern, sobald genug Details öffentlich sind – der Sicherheitsforscher Robert Ressl, der die Lücke im Juli über HackerOne gemeldet hat, hat bereits einen technischen Blogbeitrag samt Proof-of-Concept veröffentlicht.
Warum das kein Einzelfall ist
7.1.2 ist bereits die fünfte Kern-Sicherheitsveröffentlichung seit Anfang Juli – in nur 67 Tagen. Insgesamt wurden 2026 bislang 27 Sicherheitslücken im WordPress-Kern geschlossen, 2025 waren es über das ganze Jahr gerechnet sechs [WP Care]. Der Satz „Kern ist stabil, aufpassen muss man nur bei Plugins“ beschreibt 2026 also nicht mehr die Realität. Schonmal daran gedacht, dass „WordPress aktualisiert sich schon automatisch“ nicht für jede Installation stimmt? Bei Kunden, die ich betreue, prüfe ich das regelmäßig mit – automatische Updates lassen sich nämlich auch durch eine vergessene Konfigurationskonstante oder einen liegen gebliebenen Versionskontroll-Ordner stillschweigend deaktivieren.
Häufige Fragen
Muss ich sofort handeln, auch wenn ich erst am 17. September aktualisiert habe?
Ja. Die beiden Lücken sind komplett unabhängig voneinander – Version 7.1.1 vom 17. September ist von dieser neuen Lücke ebenfalls betroffen.
Reicht ein Sicherheits-Plugin, um mich zu schützen?
Ein gutes Sicherheits-Plugin kann Angriffsversuche erschweren, ersetzt aber kein Update. WordPress selbst bietet keinen Workaround an – nur die aktualisierte Version schließt die Lücke tatsächlich.
Woher weiß ich, welche WordPress-Version meine Seite hat?
Im Dashboard unter „Werkzeuge“ → „Website-Zustand“ oder ganz unten auf der Übersichtsseite. Wer sich unsicher ist, kann mich auch einfach kurz fragen.
Ich hoffe, das hilft dir, die Lücke richtig einzuordnen und nicht in Panik zu verfallen – aber auch nicht abzuwarten. Wer seine WordPress-Wartung lieber abgibt, statt jede Woche neue CVE-Nummern zu verfolgen: ich biete WordPress-Wartung genau für solche Fälle an, inklusive laufender Update-Kontrolle. Und wenn du einfach nur wissen willst, ob deine Seite gerade betroffen ist: schreib mir, das schauen wir uns gemeinsam an.
Quellen
- The Hacker News: „WordPress Issues Patch for Critical Flaw That Can Enable Code Execution on Some Servers“ (22.09.2026)
- Patchstack: „WordPress 7.1.2 Security Release: Unauthenticated LFI to RCE“ (22.09.2026)
- Help Net Security: „WordPress 7.1.2 fixes critical unauthenticated path traversal vulnerability (CVE-2026-87902)“ (23.09.2026)
- WordPress.org: „WordPress 7.1.2 Release“ (22.09.2026)
- WP Care: „WordPress 7.1.2: Fifth Core Security Release Since July“ (22.09.2026)