Schlagwort: Automatische Updates

  • 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