Fremde konnten über das Cookie-Plugin iubenda Skripte in Seiten einschleusen, die danach bei jedem Besucher laufen, auch bei angemeldeten Administratoren. Die Ursache steckt in dem Parser, der Dienste wie Google Analytics vor der Einwilligung blockiert und dafür den HTML-Code der Seite neu ausgibt. Die US-Datenbank NVD bewertet die Sicherheitslücke mit 7,5 von 10 Punkten, Version 3.13.7 schließt sie.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenInhalt 5 Abschnitte
WPScan hat am 3. November eine Sicherheitslücke im WordPress-Plugin iubenda veröffentlicht, betroffen sind alle Versionen vor 3.13.7.[1] Laut wordpress.org läuft das Plugin des Herstellers iubenda auf mehr als 200.000 aktiven Installationen.[3] Für CVE-2026-86606 führt die NVD seit dem 6. November 7,5 von 10 Punkten (CVSS 3.1, Stufe hoch), vergeben von der US-Behörde CISA als Zusatzbewerterin.[2]
Das Wichtigste in Kürze
- Ein Angreifer braucht laut WPScan kein Konto: Das eingeschleuste Skript wird in der Seite gespeichert und läuft im Browser jedes Besuchers.
- Die NVD stuft den Angriff als aufwendig ein, denn ein Besucher muss die Seite aufrufen.
- Behoben ist die Sicherheitslücke in Version 3.13.7 vom 2. November, die Versionen 3.13.5 und 3.13.6 hatten den Parser schon nachgebessert und gelten weiter als betroffen.
- Angriffe sind nicht belegt, den Exploit-Code will WPScan am 3. Dezember zeigen.
Wie kommt ein Cookie-Banner zu einer Sicherheitslücke?
iubenda bündelt Cookie-Banner, Datenschutzerklärung und Einwilligungsnachweise in einem Plugin. Dazu gehört, fremde Dienste wie Google Analytics, YouTube oder Facebook-Widgets zu blockieren, bis der Besucher zustimmt.[3] Dafür verarbeitet ein Parser den HTML-Code jeder Seite, das Änderungsprotokoll nennt ihn den Native-Blocking-Parser. Genau dort setzt die Sicherheitslücke an: Laut WPScan gibt der Parser Inhalte nicht ausreichend bereinigt wieder aus, sodass Unbefugte Skripte in Seiten einschleusen können.[1]
Das Änderungsprotokoll verzeichnet drei Nachbesserungen am Parser in Folge. Version 3.13.5 und 3.13.6 härteten ihn schrittweise, 3.13.7 sorgt laut Protokoll dafür, dass wiederhergestellte Kommentar- und Code-Inhalte nicht mehr als aktiver HTML-Code gelten und Besucherkommentare der Parser nicht erneut verarbeitet. Die Entdecker meldeten die Sicherheitslücke unabhängig voneinander: Jakub Herman über WPScan, ein weiterer Forscher über Wordfence und Dthangws über Patchstack.[3] WPScan führt dennoch alle Versionen vor 3.13.7 als betroffen.[1]
Am 6. November liefen 14,0 Prozent der Installationen auf der Reihe 3.12, rechnerisch mehr als 28.000 von mehr als 200.000. Weitere 72,7 Prozent nutzten die Reihe 3.13, darin steckt sowohl die behobene Version 3.13.7 als auch 3.13.0 bis 3.13.6; die Statistik trennt die Einzelversionen nicht. Auf andere Reihen entfielen 13,2 Prozent.[3]
Warum ist ausgerechnet ein Consent-Plugin so heikel?
Ein Consent-Plugin greift auf jede öffentliche Seite eines Auftritts zu. Ein solches Plugin muss alles prüfen, was Besucher beisteuern können, denn schon ein einziges durchgelassenes Skript läuft im Browser jedes Besuchers. Läuft es bei einem angemeldeten Administrator, handelt es mit dessen Rechten.
Bei Plugins, die den Seitencode umbauen, tritt das Muster öfter auf. Bei Complianz betraf es im Oktober den Cookie-Blocker, bei WebP Express den Umbau des HTML-Codes.
Der Stand: Patch verfügbar, Exploit-Code nicht öffentlich, Angriffe nicht belegt. WPScan zeigt den Exploit-Code erst am 3. Dezember, damit Betreiber Zeit zum Aktualisieren haben. In der NVD-Ergänzung der CISA vom 6. November gilt die Ausnutzung als nicht beobachtet und nicht automatisierbar, der technische Schaden als vollständig. In CISAs Katalog ausgenutzter Schwachstellen steht der Eintrag nicht.[1][2]
Von der Nachbesserung bis zum Exploit-Termin
Auf welchen Versionsreihen die Installationen liefen
Orange: Reihe 3.12, durchweg vor 3.13.7. Die Reihe 3.13 enthält betroffene Versionen (3.13.0 bis 3.13.6) und die behobene 3.13.7. Die Statistik von wordpress.org zeigt Anteile je Versionsreihe, nicht je Einzelversion.
Ein Plugin, das den HTML-Code jeder öffentlichen Seite umschreibt, darf Besuchereingaben nie als Code behandeln. Bei iubenda dauerte die Korrektur drei Versionen.
Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Betreiber jetzt tun?
- Aktualisieren: Spielen Sie iubenda 3.13.7 oder neuer ein und schalten Sie automatische Updates für das Plugin ein.
- Inhalte sichten: Prüfen Sie Kommentare und andere Besuchereingaben auf Einträge mit Skript-Code, löschen Sie Verdächtiges und leeren Sie danach den Seiten-Cache.
- Konten kontrollieren: Ein Skript im Browser eines Administrators handelt mit dessen Rechten. Suchen Sie in der Benutzerliste nach unbekannten Administratoren und prüfen Sie kürzlich geänderte Plugin- und Theme-Dateien. Bei Verdacht setzen Sie Passwörter zurück und beenden alle Sitzungen.
- Übergangsweise abschalten: Lässt sich das Update nicht sofort einspielen, bleibt das Deaktivieren des Plugins. Dann blockiert niemand mehr Dienste vor der Einwilligung, deshalb schalten Sie zugleich alles ab, was ohne Zustimmung nicht laufen darf.
Agenturen mit vielen Kundenseiten filtern ihre Update-Werkzeuge nach dem Plugin und allen Versionen vor 3.13.7. Cookie-Plugins stehen auf vielen Websites, weil § 25 TDDDG für Cookies und ähnliche Technologien eine Einwilligung verlangt, deshalb lohnt der Blick in jede Installation. Bei Shops, Mitgliederbereichen und Formularen mit personenbezogenen Daten prüfen Betreiber bei Verdacht auf einen erfolgreichen Angriff die Meldepflicht nach Art. 33 DSGVO, die 72 Stunden nach Bekanntwerden gilt. Grundregeln fasst der Ratgeber zur WordPress-Sicherheit zusammen. Im WordPress-Hosting-Vergleich finden Betreiber passende Anbieter, die den Betrieb übernehmen.
FAQ: Schwere Sicherheitslücke bei iubenda
Welche Version von iubenda ist sicher?
Behoben ist die Sicherheitslücke laut WPScan in Version 3.13.7 vom 2. November 2026. Betroffen sind alle Versionen davor, auch 3.13.5 und 3.13.6. Prüfen Sie im Plugin-Bereich Ihres WordPress, welche Version läuft.
Braucht ein Angreifer ein Konto auf der Website?
Nein. Laut WPScan kann ein Unbekannter ohne Anmeldung Skripte einschleusen. Damit sie wirken, muss ein Besucher die Seite aufrufen; die NVD stuft den Angriff deshalb als aufwendig ein.
Wird die Sicherheitslücke schon ausgenutzt?
Angriffe sind bis zum 6. November 2026 nicht belegt. Die CISA wertet die Ausnutzung in der NVD als nicht beobachtet, ein Eintrag in ihrem Katalog ausgenutzter Schwachstellen fehlt. WPScan will den Exploit-Code am 3. Dezember 2026 zeigen.
Reicht Version 3.13.6, wenn ich schon aktualisiert habe?
Nein. Laut WPScan sind alle Versionen vor 3.13.7 betroffen, auch die Nachbesserungen 3.13.5 und 3.13.6. Erst 3.13.7 gilt als Behebung.
Quellen
3 Quellen anzeigenQuellen ausblenden
- WPScaniubenda < 3.13.7 – Unauthenticated Stored XSS via Cookie Block HTML Parser, öffentlich seit 3. November 2026, aktualisiert am 5. November
- NVDCVE-2026-86606, veröffentlicht am 6. November 2026, mit CISA-Ergänzung vom 6. November; CISA: Known Exploited Vulnerabilities Catalog, abgeglichen am 6. November 2026
- wordpress.orgiubenda, Änderungsprotokoll, aktive Installationen und Versionsstatistik, abgerufen am 6. November 2026
Mehr Newshunger?
- Complianz mit über 1 Million Installationen: zweite Lücke im Cookie-Blocker binnen eines Monats
- WebP Express mit über 300.000 Installationen: schwere Sicherheitslücke beim HTML-Umbau
- Prime Slider mit über 100.000 Installationen: Schwere Sicherheitslücke öffnet die Kommentarspalte für Schadcode
- CleanTalk mit über 200.000 Installationen: fünfte Lücke ohne Login seit Juni
- Sicherheitslücke bei MC4WP: Mailchimp for WordPress
