WordPress-Sicherheitslücken 2026: Was Unternehmen nach 7.1.2 und 7.1.4 jetzt prüfen müssen

Stellen Sie sich vor, Ihre Unternehmenswebsite läuft auf WordPress — wie Millionen anderer Websites weltweit. Im WordPress-Dashboard ist unter „Aktualisierungen" nichts Rotes zu sehen, der Hoster hat automatische Sicherheitsupdates aktiviert, und im Tagesgeschäft denkt niemand weiter darüber nach. Dann erscheint eine Meldung in den IT-Newsfeeds: kritische Lücke im WordPress-Kern, bereits aktiv ausgenutzt, von US-Behörden offiziell gelistet.

Was jetzt? Welche Version läuft tatsächlich? Hat das automatische Update wirklich gegriffen? Und was bedeutet die zweite Lücke — die Sicherheitsforscher unterschiedlich bewerten — konkret für Ihre Website?

Dieser Artikel ordnet die zwei relevanten WordPress-Sicherheitslücken aus dem Herbst 2026 ein, erklärt, wer betroffen ist, und gibt einen praxistauglichen Handlungsplan — ohne Alarmismus, aber ohne Beschönigung.

---

CVE-2026-87902: Die kritische Lücke in WordPress 7.1.2

Was die Lücke ermöglicht

Am 22. September 2026 veröffentlichte WordPress das Sicherheitsrelease 7.1.2. Die zugehörige WordPress-Sicherheitslücke — CVE-2026-87902 — steckt in der Seitenvorlagen-Auflösung des Kerns. Ein nicht angemeldeter Angreifer kann diese Logik dazu bringen, eine lesbare lokale PHP-Datei außerhalb der Theme-Verzeichnisse einzubinden. Unter bestimmten Voraussetzungen führt das zur Ausführung von PHP-Code auf dem Server.

Das WordPress-Advisory GHSA-7hp8-65ch-5whp stuft die Lücke als kritisch ein und vergibt einen CVSS-v4.0-Basiswert von 9.2. Die Klassifikation CWE-98 steht für Remote File Inclusion. Gemeldet wurde die Lücke von Sicherheitsforscher Robert Ressl.

Voraussetzungen für eine Ausnutzung

Das Advisory benennt konkrete Bedingungen, die gleichzeitig erfüllt sein müssen:

• Das aktive (Child-)Theme hat ein Verzeichnis auf oberster Ebene, dessen Name mit „page-" beginnt. Betroffen sind laut Advisory unter anderem die älteren Standard-Themes Twenty Twelve und Twenty Fourteen sowie Themes wie Neve, Hestia und Sydney.
• Auf dem Server liegt eine geeignete, lesbare PHP-Datei. Als Beispiel nennt das Advisory pearcmd.php bei aktivem register_argc_argv — relevant bei offiziellen PHP-Docker-Images und Standard-cPanel-Konfigurationen mit PHP vor Version 8.5.

Das bedeutet: Nicht jede WordPress-Installation ist gleichermaßen angreifbar. Wer ein modernes Theme ohne solche Verzeichnisnamen betreibt und PHP aktuell hält, reduziert das Risiko erheblich. Die Lücke ist dennoch ernst zu nehmen.

Betroffen und behoben

Betroffen sind WordPress 4.7.0 bis 7.1.1. Behoben ist die Lücke in 7.1.2 und den zugehörigen Backports — etwa 7.0.6, 6.9.9, 6.8.10, 6.7.9 und weiteren bis hinunter zu 4.7.37.

Entscheidend: Die US-Behörde CISA hat CVE-2026-87902 am 25. September 2026 in ihren Katalog der bekannt ausgenutzten Schwachstellen (KEV) aufgenommen — mit dem Eintrag „WordPress Core Remote File Inclusion Vulnerability". Das bedeutet: Es gibt belegte aktive Ausnutzung dieser Lücke in freier Wildbahn. Wer noch auf WordPress 7.1.1 oder älter ist, hat ein offenes Problem.

---

CVE-2026-119977: Die Lücke im Update-Prozess selbst (WordPress 7.1.4)

Was beim Update-Prozess schieflief

Am 28. Oktober 2026 folgte WordPress 7.1.4 — dieses Mal mit 22 behobenen Sicherheitslücken. Die schwerste davon ist technisch ungewöhnlich: Die Lücke liegt nicht im laufenden WordPress-Betrieb, sondern im Update-Mechanismus selbst.

Wenn WordPress ein vollständiges Update-Paket entpackt, legt es die neuen Dateien vorübergehend in ein Verzeichnis unterhalb von wp-content/upgrade/ ab. Der Pfad dieses Staging-Verzeichnisses war auf den meisten Servern von außen erreichbar und enthielt eine temporäre Kopie des WordPress-Installers. Ein nicht angemeldeter Angreifer, der genau in diesem Zeitfenster den richtigen Pfad aufruft, konnte — theoretisch — zur Ausführung von PHP-Code gelangen.

Gemeldet wurde die Lücke von Umut Bayram. WordPress hat den Fehler behoben, indem das Staging-Verzeichnis jetzt einen zufälligen Namen erhält, ein Index-Schutz eingebaut wurde und Konfigurationsdaten aus dem Staging-Bereich nicht mehr unsicher übernommen werden können. Der betroffene Code geht laut Patchstack bis auf WordPress 2.8 zurück.

Warum die Bewertung uneinheitlich ist — und was das bedeutet

Für CVE-2026-119977 liegen zum Stand 3. November 2026 drei voneinander abweichende Bewertungen vor:

Quelle	Bewertung	Anmerkung
Wordfence (als CNA)	CVSS 3.1: 8.1 High (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)	Hohe Angriffskomplexität im Vektor ausgewiesen
WordPress GitHub Advisory (GHSA-4w3m-c66w-69mg)	„Low"	Veröffentlicht 29.10.2026, keine CVE-Nennung
NVD (CVE-Eintrag vom 31.10.2026)	Status „Deferred", keine eigene Bewertung	Stand 03.11.2026

Die Angriffskomplexität ist hoch: Das Zeitfenster bestand in Laborumgebungen laut Wordfence nur Sekunden. Nötig sind ein Update mit vollständigem Paket, öffentlicher Web- und PHP-Zugriff auf das Staging-Verzeichnis, ein vorhersagbarer oder gefundener Pfad sowie ausreichend Zeit vor dem Aufräumen. Patchstack hält die Lücke für nicht praktikabel ausnutzbar — weist aber darauf hin, dass sich das Fenster bei jedem Update öffnet, auch bei unbeaufsichtigten automatischen Updates.

Das ist der zentrale Punkt für die Praxis: Wer wp-content/upgrade/ nicht auf Webserver-Ebene sperrt, öffnet dieses Fenster bei jedem künftigen Update — auch wenn die aktuelle Lücke durch den Patch geschlossen ist.

Was Wordfence gemessen hat

Wordfence hat am 28. Oktober 2026 um 20:30 UTC eine Firewall-Regel für Premium-, Care- und Response-Kunden ausgerollt — rund drei Stunden nach dem Release von 7.1.4. Der erste Treffer auf Pfade des zwischengespeicherten Installers kam neun Minuten danach. In den ersten 21 Stunden zählte Wordfence mehr als 18.500 Anfragen auf diese Pfade. Zwei der größten Quellen fragten kleine Gruppen von Websites rund 14,5 Stunden lang wiederholt ab.

Wichtige Einschränkung, die Wordfence selbst macht: Es handelt sich um Ausnutzungsversuche, keine bestätigten erfolgreichen Angriffe. Die Firewall auf Plugin-Ebene wirkt zudem nur, wenn WordPress beim Request geladen wird — weil die Anfragen direkt auf PHP-Dateien zeigen, ist der sogenannte „Extended Protection"-Modus bei Wordfence Voraussetzung für den Schutz. Nutzer der kostenlosen Wordfence-Version erhalten die Regel erst am 27. November 2026.

Das Firewall-Plugin ersetzt das Update nicht.

Betroffen und behoben

Betroffen sind WordPress 4.7 bis 7.1.3. Behoben in 7.1.4 und in Backports für alle aktiv unterstützten Zweige bis hinunter zu 4.7: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34, 4.7.39. WordPress 4.6 und ältere Versionen erhalten keine Sicherheitsupdates mehr.

CVE-2026-119977 steht nicht im CISA-KEV-Katalog (geprüft am 3. November 2026, Katalogstand 30. Oktober 2026). Das französische CERT-FR hat am 29. Oktober 2026 die Meldung CERTFR-2026-AVI-1420 veröffentlicht und Risiken wie Remote-Codeausführung, XSS und Denial of Service genannt.

Weitere behobene Lücken in 7.1.4

Das Release enthält 22 Sicherheitskorrekturen. Neben der Race Condition im Update-Prozess wurden mehrere Stored-XSS-Lücken behoben — unter anderem in Blockbegrenzer, Kategorien-Block, Customizer Selective Refresh, Bild- und Playlist-Block sowie bei präparierten Benutzernamen. Mehrere Lücken in der Interactivity API wurden geschlossen, darunter eine Prototype-Pollution-Schwachstelle und eine dauerhafte Denial-of-Service-Bedingung. Nicht veröffentlichte Customizer-Änderungen waren ohne Anmeldung einsehbar — auch das ist jetzt behoben. Die meisten Lücken setzen ein angemeldetes Konto mit mindestens Mitarbeiter-Rechten (Contributor) voraus, was die Angriffsfläche im Vergleich zu CVE-2026-87902 deutlich einschränkt.

---

Was ein automatisches Update leistet — und was nicht

Websites mit aktivierten automatischen Hintergrund-Updates erhalten Sicherheitsreleases in der Regel automatisch. Das ist gut. Es reicht aber nicht als einzige Maßnahme — aus drei Gründen:

1. Das Update muss tatsächlich angekommen sein. Caching-Probleme, Konflikte mit Plugins oder inkompatible Hosting-Konfigurationen können automatische Updates still blockieren. Die laufende Version steht im Dashboard unter „Aktualisierungen" und lässt sich auch via wp-cli core version auslesen.

2. Das Upgrade-Verzeichnis bleibt offen. Auch nach dem Update auf 7.1.4 bleibt wp-content/upgrade/ auf vielen Servern aus dem Web erreichbar. Bei jedem künftigen Update öffnet sich dieses Fenster erneut — solange es nicht auf Webserver-Ebene gesperrt ist.

3. Wer zu spät war, muss Spuren prüfen. Wenn zwischen Erscheinen der Lücke und dem tatsächlichen Update Zeit verging, lässt sich nicht allein aus dem Versionsstatus ableiten, ob die Website in dieser Zeit kompromittiert wurde.

---

Praxisbeispiel: Was in einem typischen KMU-Szenario schiefgehen kann

Hypothetisches Beispiel: Ein mittelständischer Dienstleister betreibt seine WordPress-Website über einen Shared-Hosting-Tarif. Automatische Updates sind aktiviert. Am 29. Oktober 2026 — einen Tag nach dem 7.1.4-Release — wird das Dashboard aufgerufen, weil ein neues Bild hochgeladen werden soll. Die Versionsnummer im Dashboard zeigt 7.1.3. Das automatische Update hat zwar versucht zu starten, wurde aber durch einen Kompatibilitätskonflikt mit einem veralteten Plugin abgebrochen — ohne sichtbare Fehlermeldung im regulären Dashboard-Bereich.

wp-content/upgrade/ ist über den Hoster standardmäßig aus dem Web erreichbar. Wordfence ist in der kostenlosen Version installiert — und erhält die Schutzregel erst am 27. November.

Nichts davon ist konstruiert. Es ist die normale Ausgangslage für einen erheblichen Teil aller WordPress-Installationen in KMU. Die gute Nachricht: Die Lücke ist schwer auszunutzen, und ein gezieltes Update auf 7.1.4 mit anschließender Serverkonfiguration schließt das Problem vollständig.

---

Der Handlungsplan: Was jetzt zu tun ist

Schritt 1 — WordPress-Version prüfen

Rufen Sie im WordPress-Dashboard unter „Aktualisierungen" die aktuelle Version ab. Alternativ liefert wp-cli core version den genauen Stand. Ziel: WordPress 7.1.4 oder der Backport des jeweiligen Zweigs (vollständige Liste oben). Wer bereits auf 7.1.4 ist, hat sowohl CVE-2026-87902 als auch CVE-2026-119977 geschlossen.

Wer noch auf 7.1.1 oder älter ist, hat mit CVE-2026-87902 eine im CISA-KEV als aktiv ausgenutzt gelistete Lücke — das hat Priorität.

Schritt 2 — Update einspielen, aber kontrolliert

Bevor das Update eingespielt wird: Backup erstellen. Dann Update durchführen, Funktionstest im Anschluss. Besonders achten auf: Formulare, Warenkorb- und Buchungsfunktionen sowie angebundene Drittdienste. Ein Update, das Kernfunktionen bricht, ist kein Sicherheitsgewinn.

Schritt 3 — wp-content/upgrade/ auf Webserver-Ebene sperren

Diese Maßnahme ist unabhängig vom Update wichtig. In einer Apache-Konfiguration lässt sich der Zugriff auf das Verzeichnis über .htaccess oder die Server-Konfiguration sperren. Nginx-Server benötigen eine passende location-Direktive. Der Hosting-Anbieter oder ein technischer Dienstleister kann das in der Regel in wenigen Minuten einrichten. Zusätzlich sollte das Verzeichnis nicht auflistbar sein (Directory Listing deaktiviert).

Schritt 4 — Konten und Inhalte prüfen, wenn das Update verspätet war

Wer zwischen dem 22. September 2026 (7.1.2-Release) und dem Update-Zeitpunkt auf einer anfälligen Version lief, sollte die Website auf folgende Anzeichen prüfen:

• Unbekannte Administratorkonten im WordPress-Benutzerverwaltungs-Bereich
• Unerwartete Plugins, die nicht selbst installiert wurden
• Fremde PHP-Dateien in wp-content/, wp-content/uploads/ oder wp-content/upgrade/
• Ungewöhnliche Zugriffe in den Server-Logs auf PHP-Dateien außerhalb der normalen Request-Pfade

Diese Prüfung ist manuell möglich, aber zeitaufwendig. Spezialisierte Sicherheitsscanner können den Prozess beschleunigen.

Schritt 5 — Wartung dauerhaft regeln

Eine gepflegte WordPress-Website kann sicher betrieben werden. Das setzt voraus, dass Updates nicht dem Zufall überlassen werden. Dazu gehören:

• Regelmäßige Versionsprüfung (nicht nur Dashboard, sondern Bestätigung des tatsächlichen Rollouts)
• Automatisierte Backups mit getesteter Wiederherstellbarkeit
• Sicherheitsmonitoring, das auf neue Core-Lücken und verdächtige Aktivitäten reagiert
• Plugin- und Theme-Pflege, da viele Angriffsvektoren nicht im Core, sondern in veralteten Erweiterungen liegen

Einen Überblick über langfristige WordPress-Sicherheitsmaßnahmen — jenseits dieser konkreten Lücken — finden Sie in unserem Grundlagenartikel WordPress-Sicherheit: So schützen Sie Ihre Website zuverlässig.

---

Einordnung: Was diese Lücken über WordPress-Betrieb im Unternehmen aussagen

Weder CVE-2026-87902 noch CVE-2026-119977 sind Argumente für einen Plattformwechsel. WordPress ist und bleibt eine der meistgepflegten Open-Source-Plattformen weltweit. Kritische Lücken im Kern werden selten — aber wenn sie auftreten, reagiert das Team schnell. Der eigentliche Risikofaktor ist nicht das CMS, sondern fehlende Wartungsroutinen.

Unternehmen, die WordPress ohne definierten Wartungsprozess betreiben, stehen bei jedem neuen Sicherheitsrelease vor denselben Fragen: Welche Version läuft tatsächlich? Hat das Update gegriffen? Wer ist zuständig? Diese Fragen lassen sich ein für alle Mal beantworten — durch einen klar geregelten Prozess oder einen externen Dienstleister, der diese Aufgabe übernimmt.

Wer über einen grundlegenderen Wechsel nachdenkt, etwa hin zu headless Architekturen oder anderen Technologien, findet in unserem Vergleich Next.js vs. WordPress: Was ist besser für Ihre Unternehmenswebsite? eine sachliche Gegenüberstellung. Für die aktuelle Lücke ist ein Plattformwechsel aber keine Antwort — und kein Schutz, der schnell genug wirkt.

---

Was SW Business Solutions für Ihre WordPress-Website übernimmt

SW Business Solutions prüft WordPress-Installationen auf Version, Serverkonfiguration und mögliche Spuren einer Kompromittierung — kontrolliert, dokumentiert und mit Backup vor dem Update. Auf Wunsch übernehmen wir laufende Wartung, Sicherheitsmonitoring und die Koordination von Updates, sodass Sie beim nächsten Sicherheitsrelease nicht erneut manuell prüfen müssen.

Wenn Sie sich nicht sicher sind, welche Version Ihre Website aktuell ausführt oder ob das automatische Update tatsächlich gegriffen hat, ist das der sinnvollste erste Schritt: eine kurze Prüfung, bevor aus Unsicherheit ein Problem wird.

Mehr zu laufender IT-Betreuung für KMU erfahren Sie unter Managed IT-Services für den Mittelstand — einschließlich einer realistischen Einschätzung, wann sich externe Betreuung lohnt und wann nicht.

Nächster Schritt: WordPress-Sicherheitscheck anfragen — sprechen Sie uns direkt an, um Ihre WordPress-Installation prüfen zu lassen.

---

Auf einen Blick: Die beiden Lücken im Vergleich

	CVE-2026-87902	CVE-2026-119977
WordPress-Release	7.1.2 (22.09.2026)	7.1.4 (28.10.2026)
Schwere (Advisory)	Kritisch, CVSS v4.0: 9.2	Wordfence: High (8.1), WP Advisory: Low
Angriffsvektor	Remote, ohne Anmeldung	Remote, ohne Anmeldung, hohe Komplexität
Voraussetzung	Theme mit „page-"-Verzeichnis + lesbare PHP-Datei	Update läuft, wp-content/upgrade/ aus Web erreichbar
CISA KEV	Ja (25.09.2026)	Nein (Stand 03.11.2026)
Behoben ab	7.1.2 / Backports	7.1.4 / Backports
Aktive Ausnutzung	Belegt (CISA KEV)	Versuche laut Wordfence (>18.500 in 21 h), keine bestätigten Erfolge

Wer auf 7.1.4 oder dem Backport seines Zweigs ist, hat beide Lücken geschlossen. Das ist der einzige Zustand, der Sicherheit gibt — nicht das Vorhandensein eines Sicherheits-Plugins, nicht ein aktivierter Automatismus, dessen tatsächliche Ausführung nicht bestätigt wurde.