WordPress-Lücke CVE-2026-87902 wird ausgenutzt: Welche Version Ihre Website braucht

Was am 22. September 2026 geschlossen wurde

Am 22. September 2026 hat WordPress die Version 7.1.2 veröffentlicht, eine Sicherheitsversion. Die Lücke, die damit geschlossen wird, stuft WordPress selbst als kritisch ein. Drei Tage später, am 25. September 2026, hat die US-Behörde CISA sie in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen. Grundlage sind nach Angabe der Behörde Belege für aktive Ausnutzung.

Ihre Kennung lautet CVE-2026-87902. Sie steckt nicht in einem Plugin, sondern im Kern von WordPress, also in dem Teil, den jede Installation mitbringt. Und sie reicht weit zurück: Betroffen sind die Versionen 4.7.0 bis 7.1.1, und zwar in jedem Versionszweig bis unter die jeweilige Korrekturversion.

Läuft Ihre Firmenwebsite auf WordPress, vielleicht vor Jahren von einer Agentur gebaut und seither kaum angefasst? Dann ist dieser Beitrag für Sie. Sie brauchen zweierlei: die genaue Versionsnummer und eine klare Antwort auf die Frage, wer bei Ihnen Updates einspielt.

Was die Lücke ist, in Alltagssprache

Wenn jemand eine Seite Ihrer Website aufruft, entscheidet WordPress unter anderem, welche Seitenvorlage des Designs dafür verwendet wird. Das Design heißt bei WordPress Theme. Genau bei dieser Auswahl liegt der Fehler.

Ein Angreifer, der sich nicht anmelden muss, kann die Auswahl unter bestimmten Bedingungen dazu bringen, eine Datei einzubinden, die gar nicht zum Theme gehört: eine lesbare PHP-Datei, also eine Programmdatei, die an anderer Stelle auf dem Server liegt. Der Sicherheitshinweis (Advisory), den WordPress auf GitHub veröffentlicht hat, spricht von Pfad-Traversal. Gemeint ist, dass die Software auf einen Dateipfad gelenkt wird, der aus dem vorgesehenen Ordner herausführt. CISA führt die Lücke unter dem Namen „WordPress Core Remote File Inclusion Vulnerability“.

Am Ende kann Programmcode laufen, den ein Fremder bestimmt hat. Das Advisory beschreibt diese Codeausführung allerdings ausdrücklich als bedingt.

Nötig sind dafür Voraussetzungen sowohl beim Server als auch beim aktiven Theme. Beim Theme, oder bei dem Theme, auf dem es aufbaut, muss es einen Ordner auf oberster Ebene geben, dessen Name mit „page-“ beginnt. Beim Server müssen für die gezeigte Codeausführung eine Hilfsdatei namens pearcmd.php lesbar und die PHP-Einstellung register_argc_argv eingeschaltet sein. Laut Advisory trifft das unter anderem auf das offizielle Docker-Image für PHP und auf Standardkonfigurationen der Hosting-Software cPanel mit PHP vor Version 8.5 zu. Ob diese Bedingungen bei Ihrer Seite vorliegen, ist ohne Fachprüfung nicht zu sagen; die Maßnahme des Herstellers ist das Update.

Welche Version ist korrigiert?

Entscheidend ist nicht, ob Ihre Version neu aussieht, sondern auf welchem Zweig sie steht. Den Zweig bilden die ersten beiden Stellen der Versionsnummer, bei 6.8.4 also 6.8. Jeder Zweig hat seine eigene Korrekturversion. Darin steckt eine Falle: 6.7.5 ist neuer als 6.6.9 und trotzdem betroffen, weil im Zweig 6.7 erst 6.7.9 korrigiert ist.

Ältere Zweige bis 4.7 haben eigene Korrekturversionen (zum Beispiel 4.7.37). Vollständig sind das, jeweils für den Zweig mit denselben ersten beiden Stellen: 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 und 4.7.37. Laut Versionsarchiv von WordPress sind alle Korrekturversionen von 7.1.2 bis 4.7.37 am 22. September 2026 erschienen.

Beim Abgleich helfen drei Hinweise:

• Ein Update im September 2026 reicht nicht automatisch. Laut Versionsarchiv von WordPress erschienen 7.1.1 und 7.0.5 am 17. September 2026, also fünf Tage vor der Korrektur. Beide sind betroffen.
• Die Tabelle aus dem Juli gilt hier nicht. In unserem Beitrag zu den beiden Kern-Lücken vom Juli 2026 ging es um zwei andere Schwachstellen; die dortige Tabelle gilt nur für jene. Für CVE-2026-87902 zählen die Angaben oben.
• Vor 4.7 gibt es keine Korrektur. Laut der Meldung vom 22. September 2026 erhalten Zweige bis zurück zu 4.7 Sicherheitskorrekturen. Ob noch ältere Versionen von dieser Lücke betroffen sind, sagen die Quellen nicht. Daraus folgt aber, dass sie keine Sicherheitskorrekturen mehr bekommen, und das allein ist Grund genug, sich um die Seite zu kümmern.

Kommt das Update von allein?

Möglicherweise, aber darauf sollten Sie sich nicht verlassen. WordPress schreibt in der Meldung vom 22. September 2026: Bei Seiten, die automatische Hintergrund-Updates unterstützen, beginnt das Update von selbst. Hintergrund-Updates sind Aktualisierungen, die WordPress ohne Ihr Zutun einspielt.

Laut Entwicklerdokumentation von WordPress gibt es sie seit Version 3.7. Kleinere Kern-Updates innerhalb eines Zweigs, wie der Schritt von 7.1.1 auf 7.1.2, laufen standardmäßig automatisch, und auf den meisten Seiten ist das so eingestellt. Die Automatik lässt sich aber abschalten, zum Beispiel mit einem Eintrag namens AUTOMATIC_UPDATER_DISABLED in der Konfigurationsdatei wp-config.php. Ob sie bei Ihnen läuft, hängt also davon ab, wie die Seite eingerichtet wurde und wer sie seither verwaltet. Ob die Korrekturen der älteren Zweige ebenfalls automatisch verteilt wurden, ist offen (siehe unten).

Daraus folgt eine Prüfung, keine Entwarnung: Sind automatische Kern-Updates aktiv, und ist die Korrekturversion tatsächlich angekommen? Die zweite Frage wiegt schwerer. Eine eingeschaltete Automatik beweist nicht, dass das Update durchgelaufen ist.

Was Sie Ihre Agentur oder Ihren Hoster fragen

Sie müssen dafür nicht selbst an die Website. Diese Fragen können Sie wörtlich an Agentur, Hoster oder IT weitergeben:

1. Welche WordPress-Version läuft genau? Bitte mit allen Stellen, also etwa 6.8.10 und nicht nur 6.8.
2. Liegt diese Version im eigenen Zweig auf oder über der Korrekturversion? Die Zuordnung steht oben.
3. Sind automatische Kern-Updates aktiv? Falls nicht: Wer hat sie abgeschaltet, aus welchem Grund, und wer spielt Sicherheitsupdates stattdessen ein?
4. Seit wann steht der korrigierte Stand? Ein Datum ist eine bessere Antwort als „das läuft automatisch“.
5. Ist auf dem Server die PHP-Einstellung register_argc_argv eingeschaltet? Der Forscher, der die Lücke gemeldet hat, nennt das Update als wichtigste Maßnahme. Ergänzend empfiehlt er, diese Einstellung abzuschalten, ungenutzte Einstiegspunkte von PEAR (einem Zusatzpaket für PHP, zu dem auch die oben genannte Datei pearcmd.php gehört) zu entfernen und die Dateirechte des Kontos zu begrenzen, unter dem PHP läuft. Das ist Sache des Hosters, nicht Ihre.
6. Wurde die Seite nach dem Update auf Auffälligkeiten durchgesehen, und wenn ja, worauf?

Zur letzten Frage eine Einordnung: Ein eingespieltes Update schließt die Lücke, es sagt aber nichts über die Zeit davor. Das ist allgemeine Betriebslogik und keine Aussage des Herstellers über diesen Fall. Konkrete Spuren dieses Angriffs nennt keine der Quellen, auf die sich dieser Beitrag stützt. Lief Ihre Seite über längere Zeit ohne Pflege, ist eine Durchsicht trotzdem sinnvoll, zum Beispiel nach Administratorkonten, die niemand zuordnen kann, oder nach Dateien, die niemand angelegt hat.

Wie ernst ist es? Die Einordnungen nebeneinander

WordPress selbst stuft die Lücke als kritisch ein und empfiehlt, die eigenen Seiten sofort zu aktualisieren. Bei den Punktzahlen nennen zwei Stellen unterschiedliche Werte. Im Advisory von WordPress auf GitHub steht 9,2 nach CVSS 4.0. CVSS ist ein Punkteschema zur Bewertung von Schwachstellen, 4.0 ist seine Version. Die Cyber Security Agency of Singapore nennt 8,1 nach CVSS 3.1 und spricht im Titel ihrer Warnung von hoher Schwere. Die beiden Zahlen beruhen also auf verschiedenen Versionen des Schemas. Wir bilden daraus keinen Mittelwert und erklären keine der beiden Zahlen zur allein gültigen Bewertung.

Mehr Gewicht als jede Punktzahl hat die Frage, ob die Lücke ausgenutzt wird. Die Behörde aus Singapur schrieb am 24. September 2026, die Lücke werde Berichten zufolge aktiv ausgenutzt, und ein Proof of Concept, also ein öffentlich gezeigter Angriffsweg, sei verfügbar. Am 25. September 2026 nahm CISA die Lücke in ihren Katalog auf, ausdrücklich auf Grundlage von Belegen aktiver Ausnutzung. CISA setzte eine Frist bis zum 28. September 2026. Sie bindet US-Bundesbehörden, nicht deutsche Unternehmen; als Hinweis auf die Dringlichkeit taugt eine Frist von drei Tagen trotzdem.

Gemeldet hat die Lücke der Sicherheitsforscher Robert Ressl, am 20. Juli 2026 über das HackerOne-Programm von WordPress. Bis zur Korrektur am 22. September 2026 vergingen 64 Tage. Ressl hat nach eigener Angabe keine fremden oder produktiven Seiten getestet. Seine Untersuchung ist also kein Beleg für Angriffe; den liefert die Aufnahme bei CISA.

Was offen ist

Einiges ist nicht geklärt. Wir füllen das nicht mit Vermutungen.

• Ausmaß der Angriffe: Wie viele Seiten angegriffen wurden, in welchen Branchen oder Ländern und von wem, nennt keine der Quellen.
• Stand der Aktualisierung: Wie viele Seiten bereits auf einer Korrekturversion stehen, ist nicht bekannt.
• Erpressungssoftware: Im CISA-Katalog steht bei der Frage, ob Ransomware-Kampagnen die Lücke nutzen, „Unknown“, also unbekannt. Das ist weder ein Beleg noch eine Entwarnung.
• Ältere Zweige: Auch die Korrekturversionen unterhalb von 7.0 sind laut Versionsarchiv am 22. September 2026 erschienen. Ob sie ebenfalls automatisch verteilt wurden, sagen die Quellen nicht.
• Ihre eigene Seite: Ob die Bedingungen für eine Codeausführung bei Ihnen erfüllt sind, lässt sich nur im Einzelfall prüfen. Deshalb ist das Update die Maßnahme, nicht die Suche nach Gründen, es aufzuschieben.

Die eigentliche Frage hinter der Versionsnummer

Die Versionsnummer lässt sich klären. Schwieriger ist oft die Frage dahinter: Wer ist für Ihre Website eigentlich zuständig? Die Agentur, die sie gebaut hat, der Hoster, eine Mitarbeiterin, die sich einmal darum gekümmert hat? Wenn sich Version, Update-Weg und Zuständigkeit nicht mit einer kurzen Nachricht klären lassen, liegt dort die Baustelle, nicht bei dieser einen Kennung.

Wenn Sie die Antworten auf die Fragen oben nicht einordnen können oder nicht wissen, an wen Sie sie richten sollen, sprechen Sie uns an.