Schlagwort: WordPress

  • Sicherheitsupdates Ende Oktober: WordPress-Plugins, Drupal Commerce, TYPO3, nginx, Symfony und Brotli
    Symbolbild, KI-generiert

    Sicherheitsupdates Ende Oktober: WordPress-Plugins, Drupal Commerce, TYPO3, nginx, Symfony und Brotli

    „This vulnerability is being actively exploited in the wild.“ Dieser Satz steht in der Sicherheitsmeldung SA-CONTRIB-2026-254, die das Drupal-Sicherheitsteam am 28. Oktober 2026 für das Shop-Modul Commerce Core veröffentlicht hat. Unter den Meldungen, die wir für diese Übersicht geprüft haben, ist das die einzige, in der ein Hersteller selbst von laufenden Angriffen spricht. Eine zweite steht seit dem 27. Oktober im Katalog der US-Cybersicherheitsbehörde CISA für ausgenutzte Schwachstellen: eine Lücke im Brotli-Decoder von Google.

    Der Rest ist Pflege. Plugin-Updates für WordPress, Erweiterungen für TYPO3, ein Webserver-Update für nginx, eine Korrektur im PHP-Framework Symfony. Nichts davon ist spektakulär, einiges davon ist ohne Anmeldung ausnutzbar.

    Zur Lücke im WordPress-Kern selbst gibt es einen eigenen Beitrag: WordPress 7.1.4: aktiv ausgenutzte Core-Lücke. Hier geht es um alles, was drumherum läuft.

    Das Wichtigste in Kürze

    • Drupal Commerce Core: laut Drupal aktiv ausgenutzt. Behoben in 3.3.13 und 8.x-2.41.
    • Brotli: seit 27.10.2026 im CISA-Katalog ausgenutzter Schwachstellen. Betrifft Software, die Brotli-Daten entpackt, etwa Node.js, eine Python-Bibliothek und .NET.
    • WordPress: Für Royal Elementor Addons, Meta Box, WP User Manager, ACF Extended und Profile Builder gibt es Updates. Für das Theme Your Dress nennt Patchstack keinen offiziellen Patch. Für DiviGear Carousel nennt keine der geprüften Quellen eine behobene Version.
    • TYPO3: Mehrere Erweiterungen von Drittanbietern mit Lücken, darunter eine SQL-Injection ohne Anmeldung. Zum TYPO3-Kern gab es in diesem Zeitraum keine Meldung.
    • nginx und Symfony: Server- und Framework-Updates. Das ist meist Sache des Hosters oder der Entwickler, fragen sollten Sie trotzdem.

    Wie wir geprüft haben

    Jede Kennung in diesem Beitrag haben wir am 7. November 2026 in der US-Schwachstellendatenbank NVD nachgeschlagen und mit der Meldung des Herstellers oder einer Plugin-Sicherheitsdatenbank (Patchstack, WPScan) abgeglichen. Wo eine Angabe nur in einer Quelle steht, sagen wir das dazu.

    Kurzer Einschub, weil die Frage oft kommt: Warum stehen bei manchen Lücken zwei Bewertungen? Den CVSS-Wert vergibt meist nicht die NVD selbst, sondern die Stelle, die die Kennung vergeben hat, bei WordPress-Plugins häufig Patchstack, WPScan oder Wordfence. Manche Hersteller rechnen nach CVSS 3.1, andere nach CVSS 4.0, und Drupal benutzt ein eigenes Punkteschema. Die Zahlen sind deshalb nicht direkt vergleichbar. Wir nennen jeweils, von wem sie stammen.

    WordPress: Plugins und ein Theme

    ProduktCVECVSS (Quelle)BetroffenBehobenHandlung
    Royal Elementor AddonsCVE-2026-111851 (Codeausführung)7,6 (Patchstack)bis 1.7.10681.7.1069Auf aktuelle Version, mindestens 1.7.1070
    Royal Elementor AddonsCVE-2026-112865, CVE-2026-97254 (XSS)je 6,5 (Patchstack)bis 1.7.10691.7.1070Wie oben
    Royal Elementor AddonsCVE-2026-97255 (fremde Daten über geänderte Kennung)5,3 (Patchstack)bis 1.7.10691.7.1070Wie oben
    Meta BoxCVE-2026-109700 (fehlende Rechteprüfung)6,5 (Patchstack)bis 5.15.25.15.3Aktualisieren
    WP User ManagerCVE-2026-112823 (fehlende Rechteprüfung)4,3 (Patchstack)bis 2.9.252.9.26Aktualisieren
    DiviGear CarouselCVE-2026-93878 (XSS)6,4 (Wordfence)bis 5.2.0in den geprüften Quellen nicht genanntBeim Hersteller nach einer korrigierten Version fragen
    Advanced Custom Fields: Extended (free und PRO)CVE-2026-94263 (Shortcodes ohne Anmeldung)4,8 (WPScan)0.9.2.4 bis 0.9.2.70.9.2.8Aktualisieren
    Profile BuilderCVE-2026-111965 (reCAPTCHA umgehbar)4,3 (WPScan)4.0.0 bis 4.0.44.0.5Aktualisieren
    Your Dress (Theme)CVE-2026-112850 (LFI ohne Anmeldung)8,1 (Patchstack)bis 1.4.1laut Patchstack kein offizieller PatchTheme-Wechsel planen, bis dahin Schutzregel beim Hoster oder Sicherheitsdienst

    Royal Elementor Addons hat in drei Wochen mehrere Kennungen gesammelt. Die schwerste, CVE-2026-111851, erlaubt laut NVD das Einschleusen von Programmcode, setzt aber ein angemeldetes Konto voraus, nach Patchstack ab der Rolle Mitarbeiter (englisch Contributor). Patchstack stuft sie mit hoher Priorität ein und schreibt: „This vulnerability is highly dangerous and expected to become exploited.“ Belegte Angriffe nennt Patchstack nicht, und in der NVD steht in der Einschätzung der CISA vom 22. Oktober „exploitation: none“. Beides kann stimmen, es beschreibt verschiedene Zeitpunkte und verschiedene Fragen. Am 28. Oktober hat Patchstack weitere Einträge bis Version 1.7.1069 nachgetragen, darunter das Auslesen nicht öffentlicher Beitragsinhalte ohne Anmeldung, in der Übersicht ohne CVE-Nummer. Die aktuelle Version 1.7.1070 ist laut Patchstack von keinem der bisher gemeldeten Einträge betroffen (Stand 7. November).

    Your Dress ist der Fall, bei dem ein Update nicht hilft, weil es keines gibt. Das Theme von AncoraThemes lässt in allen Versionen bis 1.4.1 das Einbinden lokaler Dateien zu, ohne Anmeldung (NVD: Local File Inclusion, CVSS 8,1 von Patchstack, mit „hoher Angriffskomplexität“). Patchstack meldet „No official patch available“ und hat nach eigener Angabe eine Schutzregel für seine Kunden. Wenn Ihre Seite dieses Theme nutzt, planen Sie den Wechsel jetzt.

    ACF Extended ist eine Wiederholung. WPScan beschreibt CVE-2026-94263 als unvollständige Korrektur der Vorgängerlücke CVE-2025-15463: Die damalige Änderung galt nur für neu gespeicherte Formulare. Ältere Frontend-Formulare ohne die passende Einstellung führen Shortcodes in der Bestätigungsmeldung weiter aus, auch für Besucher ohne Konto. Die Bewertung ist mittel (4,8), weil die Ausnutzung von der gespeicherten Formularkonfiguration abhängt.

    DiviGear Carousel betrifft Seiten mit offener Registrierung: Schon ein Konto mit der Rolle Abonnent reicht laut NVD, um Skriptcode zu speichern, der beim Aufruf der Aktivierungsseite des Plugins im Browser des Administrators läuft. Eine korrigierte Version haben wir weder in der NVD noch auf der Herstellerseite gefunden; der Eintrag bei Wordfence war für uns nicht abrufbar.

    Meta Box, WP User Manager und Profile Builder setzen ein angemeldetes Konto voraus. Patchstack stuft Meta Box und WP User Manager mit niedriger Priorität ein. Bei Profile Builder geht es um den Spamschutz der Kommentare, nicht um Daten.

    Eine Frage, die Sie sich bei mehreren dieser Einträge stellen sollten: Kann sich auf Ihrer Seite jeder ein Konto anlegen? Wenn ja, ist „nur für angemeldete Nutzer“ eine kleinere Hürde, als es klingt.

    Drupal: Commerce Core

    ProduktKennungBewertung (Quelle)BetroffenBehobenHandlung
    Commerce CoreSA-CONTRIB-2026-254, CVE-2026-118539 (Zugriffsumgehung)21 von 25, „Highly critical“ (Drupal); 6,5 nach CVSS 3.1 (CISA in der NVD)vor 8.x-2.41, 3.0.0 bis vor 3.3.133.3.13 und 8.x-2.41Sofort aktualisieren, danach Bestellungen auf Unstimmigkeiten prüfen

    Commerce Core schützt laut Drupal „certain routes and entity fields“ nicht ausreichend. Das Sicherheitsteam weist darauf hin, dass das dem Shopbetreiber finanziell schaden kann. Gemeldet haben die Lücke Dan Puccetti, Marcus Johansson und Robert Snyder. Weil die Lücke bereits ausgenutzt wird, rät Drupal, nach dem Update die Bestellungen auf Unstimmigkeiten zu prüfen.

    Die Bewertungen gehen hier weit auseinander. Drupal vergibt 21 von 25 Punkten und spricht von aktiver Ausnutzung. Die CISA hat in der NVD am 30. Oktober einen CVSS-Wert von 6,5 hinterlegt und bei der Ausnutzung „none“ eingetragen. Im CISA-Katalog ausgenutzter Schwachstellen (Stand 6. November) steht die Kennung nicht. Wir halten uns an den Hersteller: Er kennt sein Modul, und er schreibt „actively exploited“.

    TYPO3: Erweiterungen von Drittanbietern

    Eine Meldung zum TYPO3-Kern enthält die Übersicht des TYPO3-Sicherheitsteams für diesen Zeitraum nicht. Zwischen dem 20. Oktober und dem 3. November erschienen dort Meldungen zu neun Erweiterungen, die nicht zur Standardinstallation gehören. Drei davon haben wir im Einzelnen geprüft:

    ErweiterungCVECVSS 4.0 (TYPO3, CVE-Eintrag)BetroffenBehobenHandlung
    File manager (ameos_filemanager), TYPO3-EXT-SA-2026-034CVE-2026-112238 (SQL-Injection ohne Anmeldung)8,7, hochbis 3.1.23.1.3Aktualisieren
    Frontend User Registration (sf_register), TYPO3-EXT-SA-2026-038CVE-2026-120333 (Aktionen für fremde Konten)8,8, hochbis 13.2.4, 14.0.0 bis 14.0.213.2.5, 14.0.3Aktualisieren
    TYPO3 Shop by coding.ms (shop), TYPO3-EXT-SA-2026-036CVE-2026-112071, CVE-2026-113468 (Bestellungen stornieren, PayPal-Benachrichtigung überschreiben)je 6,9, mittelbis 4.9.3, 5.0.0 bis 5.21.0, 6.0.0 bis 6.2.04.9.4, 5.21.1, 6.3.0Aktualisieren

    Bei sf_register sind die Links in den Systemmails das Problem: Bestätigen oder Löschen eines Kontos funktioniert laut TYPO3 auch ohne gültigen Prüfwert. Angreifer ohne Konto können so E-Mail-Adressen und Benutzernamen aller aktiven Frontend-Nutzer abrufen und Konten löschen. Bei der Shop-Erweiterung sind nur unbezahlte Bestellungen betroffen.

    Die übrigen Meldungen betreffen die Erweiterungen Mail (mail), TYPO3 AI Integration Extension (ns_t3ai), TYPO3 Fluid-Form (fluid_form), Kitodo.Presentation (dlf), Analytics (analytics) und Accessible Form Captcha (bw_captcha). Die Einzelheiten stehen in den Meldungen TYPO3-EXT-SA-2026-030 bis -033, -035 und -037; diese haben wir nicht im Einzelnen gelesen. Welche Erweiterungen Ihre Seite nutzt, steht in der Erweiterungsliste im TYPO3-Backend oder, bei Installationen über Composer, in der Datei composer.lock.

    Am 21. Oktober hat das TYPO3-Team außerdem in einer allgemeinen Mitteilung (TYPO3-PSA-2026-001) auf ein kritisches PHP-Update hingewiesen, das alle TYPO3-Installationen betrifft. Das gilt für WordPress und Drupal genauso, denn es geht um PHP selbst. Die CISA führt die beiden PHP-Lücken seit dem 26. Oktober in ihrem Katalog ausgenutzter Schwachstellen. Was das für WordPress-Seiten heißt, steht in unserem Beitrag zu PHP2Shell.

    nginx: Session-Tickets und ein Überlauf

    ProduktCVECVSS (Quelle)BetroffenBehobenHandlung
    nginxCVE-2026-97629 (Session-Fälschung bei TLS-Session-Tickets)8,3 nach CVSS 4.0, 6,5 nach CVSS 3.1 (F5); nginx: „medium“1.23.2 bis 1.31.61.30.6 (stable), 1.31.7 (mainline)Hoster nach Version fragen
    nginxCVE-2026-15176 (Pufferüberlauf bei alias mit rewrite)9,2 nach CVSS 4.0, 8,1 nach CVSS 3.1 (F5); nginx: „medium“0.1.29 bis 1.31.61.30.6, 1.31.7Wie oben

    CVE-2026-97629 greift laut F5, dem Hersteller hinter nginx, nur bei einer bestimmten Einstellung: einem gemeinsamen Sitzungsspeicher (ssl_session_cache mit der Option shared) ohne eigene Schlüsseldatei für Session-Tickets. Dann lassen sich Sitzungen fälschen, und die Prüfung von Client-Zertifikaten kann umgangen werden. Nach unserer Lesart betrifft das vor allem Server, die solche Zertifikate verlangen, etwa für geschützte Schnittstellen. Eine normale Firmenwebsite tut das selten.

    CVE-2026-15176 braucht ebenfalls eine bestimmte Konfiguration (alias zusammen mit rewrite und der Variablen $request_filename). Folge ist laut F5 ein Neustart des Arbeitsprozesses, Codeausführung nur, wenn ASLR, ein Schutzmechanismus des Betriebssystems, abgeschaltet ist oder umgangen wird.

    Beide sind in 1.30.6 und 1.31.7 behoben. Dieselben Versionen schließen laut nginx.org drei weitere Lücken mittlerer Schwere, unter anderem im HTTP/3-Modul. Ob Ihr Server nginx nutzt und in welcher Version, beantwortet Ihr Hoster. Linux-Distributionen wie Debian, Ubuntu oder Red Hat spielen Korrekturen oft in ältere Versionsnummern zurück; eine niedrige Nummer allein heißt deshalb nicht, dass der Server ungeschützt ist.

    Symfony: eine Kopfzeile, eine Sekunde Rechenzeit

    ProduktCVECVSS (Quelle)BetroffenBehobenHandlung
    Symfony HttpFoundationCVE-2026-108082 (ReDoS über die Kopfzeile Cache-Control)8,7 nach CVSS 4.0 (CVE-Eintrag)5.4.1 bis vor 5.4.54, 6.0.1 bis vor 6.4.46, 7.0 bis vor 7.4.19, 8.0 bis vor 8.1.75.4.54; wegen eines Folgefehlers 6.4.48, 7.4.21, 8.1.9Entwickler um Update bitten

    Eine präparierte Kopfzeile Cache-Control mit vielen Leerzeichen lässt einen regulären Ausdruck in Symfony exponentiell viele Wege durchprobieren. Symfony nennt 813 Millisekunden Rechenzeit für eine einzige Anfrage mit 17 Leerzeichen, jedes weitere verdoppelt den Wert. Anmelden muss sich dafür niemand. Die erste Korrektur hatte einen Fehler beim Trennen an Leerzeichen; Symfony empfiehlt deshalb für die Zweige 6.4, 7.4 und 8.1 die Versionen 6.4.48, 7.4.21 und 8.1.9. Der CVE-Eintrag nennt als betroffen schon die Zweige ab 4.1; Korrekturen gibt es nur für 5.4, 6.4, 7.4 und 8.1.

    Viele PHP-Anwendungen nutzen Symfony-Komponenten, ohne dass das auf der Website sichtbar wäre. Ob Ihre dazugehört, steht in der composer.lock Ihres Projekts.

    Brotli: die Lücke im Entpacker

    ProduktCVECVSS (Quelle)BetroffenBehobenHandlung
    Google BrotliCVE-2026-111497 (Schreiben außerhalb des Puffers)9,8 nach CVSS 3.1 (NVD); 9,2 nach CVSS 4.0 (Google)1.0.3 bis 1.2.01.0.10, 1.1.1, 1.2.1Abhängigkeiten aktualisieren
    Node.jsCVE-2026-111497Node.js: „high“Zweige 22, 24, 2622.23.4, 24.22.1, 26.12.1Node.js aktualisieren

    Brotli ist ein Kompressionsverfahren, das Webserver und Browser für schnellere Seiten nutzen. Die Lücke steckt im Decoder, also im Teil, der Daten wieder entpackt. Ein präparierter Datenstrom kann laut NVD ohne Anmeldung Speicher beschädigen, Speicherinhalte preisgeben, das Programm abstürzen lassen und möglicherweise Code ausführen. Die NVD führt eine lange Liste betroffener Produkte, darunter Node.js, eine Python-Bibliothek, .NET 8 bis 10, Envoy und Istio. Die CISA hat die Lücke am 27. Oktober in ihren Katalog ausgenutzter Schwachstellen aufgenommen, mit Frist für US-Bundesbehörden bis 10. November. Ob Erpressergruppen sie nutzen, ist dort als „Unknown“ vermerkt.

    Für eine klassische WordPress-Seite heißt das: Entscheidend ist, ob ein Programm auf Ihrem Server Brotli-Daten von außen entgegennimmt und entpackt. Bei Anwendungen auf Basis von Node.js oder .NET ist das eine Frage an Ihre Entwickler, bei gemieteten Servern an den Hoster.

    In welcher Reihenfolge

    1. Drupal Commerce Core, wenn Sie einen Drupal-Shop betreiben. Hier spricht der Hersteller von Angriffen. Nach dem Update die Bestellungen prüfen.
    1. PHP auf dem Server, falls noch nicht geschehen. Die CISA führt zwei PHP-Lücken als ausgenutzt; ob das PHP-Update eingespielt ist, beantwortet Ihr Hoster.
    2. Brotli in eigenen Anwendungen (Node.js, Python, .NET). Die CISA führt die Lücke als ausgenutzt.
    3. Theme Your Dress ersetzen. Ohne Patch hilft nur der Wechsel.
    4. Alles, was ohne Anmeldung ausnutzbar ist: die TYPO3-Erweiterungen ameos_filemanager, sf_register und shop, Royal Elementor Addons, ACF Extended, nginx und Symfony.
    5. Der Rest, der ein Konto voraussetzt: Meta Box, WP User Manager, DiviGear Carousel, Profile Builder. Wenn sich auf Ihrer Seite jeder registrieren kann, rücken diese Punkte nach oben.

    Vor jedem Update gilt: Sicherung anlegen, und wenn vorhanden, erst auf einer Testkopie der Seite einspielen. In WordPress zeigt die Plugin-Übersicht im Dashboard die installierte Version jedes Plugins. Automatische Updates für einzelne Plugins lassen sich dort ebenfalls einschalten; ob das für Ihre Seite passt, hängt davon ab, wie viel an den Plugins hängt.

    Diese Übersicht beschreibt öffentlich gemeldete Lücken. Welche davon Ihre Installation betreffen und wann Sie welches Update einspielen, entscheiden Sie oder Ihr technischer Dienstleister. Unser Website-Check gleicht installierte WordPress-Plugins mit öffentlich gemeldeten Sicherheitslücken ab. Die Versionen von Webserver und PHP sowie Drupal- oder TYPO3-Installationen prüft er nicht.

    Quellen (Abrufdatum: 07.11.2026)

    • NVD (National Vulnerability Database, NIST), Einträge CVE-2026-97629, CVE-2026-15176, CVE-2026-118539, CVE-2026-94263, CVE-2026-111965, CVE-2026-112850, CVE-2026-111497, CVE-2026-111851, CVE-2026-112865, CVE-2026-97254, CVE-2026-97255, CVE-2026-109700, CVE-2026-112823, CVE-2026-93878, CVE-2026-108082, CVE-2026-112238, CVE-2026-112071, CVE-2026-113468, CVE-2026-120333, abgerufen über die NVD-Schnittstelle.
    • nginx.org, Seite „nginx security advisories“, Einträge „Session forgery when using TLS session tickets“ und „Buffer overflow when using alias with rewrite“.
    • Drupal.org, Sicherheitsmeldung SA-CONTRIB-2026-254, Commerce Core, 28.10.2026.
    • TYPO3, Sicherheitsmeldungen TYPO3-EXT-SA-2026-034 (20.10.2026), TYPO3-EXT-SA-2026-036 (20.10.2026), TYPO3-EXT-SA-2026-038 (03.11.2026), Übersicht der Sicherheitsmeldungen und Mitteilung TYPO3-PSA-2026-001 (21.10.2026).
    • Symfony, Blogbeitrag „CVE-2026-108082 ReDoS in HeaderUtils::split() Reachable Through the Cache-Control Request Header“, 15.10.2026.
    • Google Brotli, Release-Hinweise zu v1.0.10, v1.1.1 und v1.2.1 auf GitHub.
    • Node.js, „Wednesday, October 21, 2026 Security Releases“.
    • CISA, Katalog bekannter ausgenutzter Schwachstellen (JSON-Fassung, Katalogstand 2026.11.06), Eintrag CVE-2026-111497.
    • Patchstack, Datenbankeinträge zu Royal Elementor Addons (CVE-2026-111851, CVE-2026-112865, CVE-2026-97255 sowie Plugin-Übersicht), Meta Box (CVE-2026-109700), WP User Manager (CVE-2026-112823) und Your Dress (CVE-2026-112850).
    • WPScan, Einträge zu Advanced Custom Fields: Extended (CVE-2026-94263) und Profile Builder (CVE-2026-111965).

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Fach- und Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keine einzelne Installation und ersetzt keine Beratung im Einzelfall. Für Vollständigkeit und Aktualität der Angaben übernehmen wir keine Gewähr. Maßgeblich sind die Meldungen der jeweiligen Hersteller in ihrer aktuellen Fassung; Stand: 07.11.2026.

  • WordPress 7.1.4: aktiv ausgenutzte Core-Lücke, was Website-Betreiber jetzt tun sollten
    Symbolbild, KI-generiert

    WordPress 7.1.4: aktiv ausgenutzte Core-Lücke, was Website-Betreiber jetzt tun sollten

    Am Mittwoch, dem 28. Oktober 2026, erschien WordPress 7.1.4. Zwei Tage später berichteten heise online und The Hacker News, der Sicherheitsanbieter Wordfence sehe bereits Angriffsversuche auf eine der darin geschlossenen Lücken. Am 3. November nahm die US-Cybersicherheitsbehörde CISA sie in ihren Katalog bekannter ausgenutzter Schwachstellen auf. Gemeint ist ein Fehler im Update-Vorgang des WordPress-Kerns selbst.

    Das Wichtigste in Kürze

    • WordPress 7.1.4 ist ein Sicherheitsrelease. Die Versionsseite von WordPress.org zählt 22 Schwachstellen, darunter eine Race Condition (ein Wettlauf um ein kurzes Zeitfenster) beim Core-Update, die zu Codeausführung auf dem Server führen kann.
    • Betroffen sind laut CVE-Eintrag alle Versionen von 4.7 bis 7.1.3. Angreifbar ist die Seite nur, solange ein vollständiges Core-Update läuft.
    • Wordfence meldet Angriffsversuche, die CISA führt die Lücke seit 3. November als ausgenutzt. Wie viele Seiten tatsächlich übernommen wurden, nennt keine der gelesenen Quellen.
    • Jetzt anstehen: Version prüfen, auf 7.1.4 oder die zurückportierte Korrektur Ihres Zweigs aktualisieren, Auto-Updates und Hoster-Zuständigkeit klären, Sicherung bereithalten.

    Was die Lücke ist

    Ein vollständiges Core-Update entpackt die neuen WordPress-Dateien zunächst in einen Arbeitsordner unter wp-content/upgrade. Bis 7.1.3 lag dort für wenige Sekunden eine Arbeitskopie von WordPress samt Installer, in einem Ordner mit vorhersagbarem Namen, der aus dem Internet erreichbar sein kann. Wer ohne Anmeldung genau in diesem Moment die Installer-Dateien aufruft, kann laut CVE-Eintrag Programmcode auf dem Server ausführen. WordPress.org beschreibt den Fehler knapp: „A race condition during core updates that could lead to remote code execution“, gemeldet von Umut Bayram.

    Der CVE-Eintrag CVE-2026-119977 wurde am 31.10.2026 angelegt, vergeben von Wordfence. Die Bewertung nach CVSS 3.1 lautet 8,1 („hoch“), mit der Einstufung „hohe Komplexität“, weil das Zeitfenster so schmal ist; sie stammt von Wordfence, eine eigene Bewertung der NVD liegt noch nicht vor (Stand 04.11.2026: „Undergoing Analysis“). Als Schwachstellenart führt die CISA einen Wettlauf zwischen Prüfung und Nutzung (CWE-367, englisch Time-of-check Time-of-use). WordPress.org selbst nennt in seinen Release-Hinweisen keine CVE-Nummern.

    Wer betroffen ist

    Für diese Lücke nennt der CVE-Eintrag die Versionen 4.7 bis 7.1.3. WordPress.org führt auf der Versionsseite zurückportierte Korrekturen für alle Zweige bis 4.7. Die wichtigsten Stände:

    • 7.1.x: 7.1.4
    • 7.0: 7.0.8
    • 6.9: 6.9.11
    • 6.8: 6.8.12
    • 4.7: 4.7.39 (Liste aller Zweige bei WordPress.org)

    Wer auf 4.6 oder älter ist, bekommt keine Sicherheitsupdates mehr und muss auf eine unterstützte Version umziehen. Auch WordPress.org betont: Aktiv unterstützt wird nur die jeweils neueste Version.

    Wird sie ausgenutzt?

    Das hängt davon ab, was „ausgenutzt“ heißt. Angriffsversuche sind nach Angaben von Wordfence belegt (die Wordfence-Originalseiten ließen sich bei unserer Prüfung nicht abrufen, wir stützen uns auf die Berichte von heise und The Hacker News): In den ersten 21 Stunden nach Einführung einer Firewall-Regel zählte das Unternehmen laut heise mehr als 18.500 Anfragen, die nach anfälligen Installationspfaden wie setup-config.php suchten. The Hacker News nennt 62.969 geblockte Angriffe in 24 Stunden. Beide Zahlen gehen auf Wordfence zurück, die Zeiträume und Zählweisen unterscheiden sich, wir können sie nicht auf einen Nenner bringen. Zwei der größten Quellen fragten nach beiden Berichten rund 14,5 Stunden lang kleine Gruppen von Seiten ab.

    Dazu kommt die CISA: Sie hat die Lücke am 3. November 2026 in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen. Für Bundesbehörden der USA gilt dort eine Frist bis 6. November; eine Nutzung durch Erpressungsgruppen vermerkt der Eintrag als „unbekannt“. Der Katalogeintrag sagt nichts darüber, wie viele Seiten betroffen waren. Bestätigte Kompromittierungen einzelner Seiten nennt keiner der gelesenen Berichte. Patchstack stuft die Ausnutzung als wenig praktikabel ein, weist aber darauf hin, dass das Zeitfenster bei jedem Update zurückkehrt, auch bei automatischen.

    Kurzer Einschub, weil das oft gefragt wird: Ein Fenster von wenigen Sekunden klingt harmlos. Wer allerdings viele Seiten dauernd abfragt, muss es nur bei einer davon treffen. Wie oft das schon gelungen ist, lässt sich aus den Berichten nicht ablesen.

    Was jetzt zu tun ist

    1. Version prüfen. Im WordPress-Dashboard zeigt die Seite „Aktualisierungen“, ob Sie die neueste Version haben. Die Versionsnummer steht auch unter „Werkzeuge“, „Site Health“, Reiter „Info“, Abschnitt „WordPress“, Eintrag „Version“. Die deutschen Menübezeichnungen können je nach Sprachpaket abweichen. Steht dort eine Zahl unter 7.1.4 (oder unter der zurückportierten Korrektur Ihres Zweigs), ist die Seite nicht auf dem Stand.
    2. Aktualisieren. Über die Seite „Aktualisierungen“, oder durch Ihre Agentur beziehungsweise Ihren Hoster. WordPress.org empfiehlt das Update ausdrücklich „immediately“.
    3. Auto-Updates prüfen. Kleine Core-Updates, also Wartungs- und Sicherheitsreleases, laufen laut WordPress-Entwicklerdokumentation auf den meisten Websites standardmäßig automatisch. Abschalten lässt sich das in der Konfigurationsdatei wp-config.php (WP_AUTO_UPDATE_CORE oder AUTOMATIC_UPDATER_DISABLED); die Dokumentation rät davon ausdrücklich ab. Fragen Sie Ihre Betreuer, ob das bei Ihnen so gesetzt ist.
    4. Hoster fragen. Wenn ein Hoster die Seite verwaltet, lassen Sie sich die installierte Version nennen. Einzelne Hoster haben Schutzregeln eingeführt, etwa Pantheon, das Update ersetzen sie dort nach eigener Angabe nicht. Patchstack empfiehlt außerdem, den Webzugriff auf wp-content/upgrade/ auf Serverebene zu sperren, weil eine PHP-Firewall in der entpackten Kopie nicht greift.
    5. Sicherung bereithalten. Die WordPress-Dokumentation rät vor einem Upgrade zu einer Sicherung der Website. Wir empfehlen zusätzlich, die Wiederherstellung einmal zu testen. Haben Sie die Wiederherstellung je getestet?

    Wer bis jetzt nicht aktualisiert hatte, sollte laut heise auch nach Spuren suchen: unerwartete PHP-Dateien unter wp-content/upgrade, unbekannte Administratorkonten, unerwartete Plugins, Zugriffe in den Logdateien. Plugins sind ein eigenes Kapitel: 7.1.4 repariert den Kern, nicht die Erweiterungen.

    Und 7.1.3?

    Am 6. Oktober 2026 erschien WordPress 7.1.3 mit sieben Sicherheits- und vier Fehlerkorrekturen. Darunter: eine SQL-Injection zweiter Ordnung im Export, ein gespeichertes Cross-Site-Scripting im Kommentarbereich der Verwaltung und die Offenlegung von Kommentaren zu privaten und unveröffentlichten Beiträgen ohne Anmeldung. Wer von 7.1.2 oder älter kommt, spielt direkt 7.1.4 ein.

    Einordnung DSGVO

    Art. 32 Abs. 1 DSGVO verlangt von Verantwortlichen „unter Berücksichtigung des Stands der Technik“ geeignete technische und organisatorische Maßnahmen für ein dem Risiko angemessenes Schutzniveau. Lit. d nennt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit dieser Maßnahmen. Eine Update-Frist enthält die Norm nicht. Ob eine Seite mit Kontaktformular, die Wochen nach einem Sicherheitsrelease noch auf dem alten Stand läuft, den Maßstab verfehlt, hängt vom Risiko und vom Einzelfall ab. Eine Entscheidung einer Aufsichtsbehörde zu genau dieser Konstellation kennen wir nicht.

    Der Website-Check von Experto Mundi umfasst laut Leistungsbeschreibung unter anderem einen Abgleich der Plugins mit bekannten Sicherheitslücken, die Sicherheits-Header und die Verschlüsselung (TLS) Ihrer Seite. Die Version des WordPress-Kerns nennt die Leistungsbeschreibung nicht als Prüfpunkt. Zu den technischen Anforderungen von NIS2 und DORA an eine Website: NIS2 und DORA technisch.

    Quellen

    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 04.11.2026.

WhatsApp