Fremde konnten über das Übersetzungs-Plugin TranslatePress Skripte in Seiten einschleusen, die danach im Browser jedes Besuchers laufen, auch bei angemeldeten Administratoren. Ein Konto auf der Website brauchten sie nicht. Das Plugin zählt mehr als 400.000 aktive Installationen, Version 3.3.9 schließt beide Sicherheitslücken.
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
Die Sicherheitsfirma Wordfence hat zwei Sicherheitslücken im WordPress-Plugin TranslatePress gemeldet, die US-Datenbank NVD führt sie seit dem 7. November als CVE-2026-119167 und CVE-2026-120537.[1] Betroffen sind alle Versionen bis 3.3.8, der Hersteller Cozmoslabs hat am 3. November Version 3.3.9 veröffentlicht.[2] Laut wordpress.org hat das Plugin mehr als 400.000 aktive Installationen.[2] Beide Einträge bewertet Wordfence mit 7,2 von 10 Punkten (CVSS 3.1, Stufe hoch).[1]
Das Wichtigste in Kürze
- Ein Angreifer braucht laut Wordfence kein Konto: Das eingeschleuste Skript wird in der Seite gespeichert und läuft bei jedem Besucher.
- Beim ersten Eintrag muss zuvor ein Kommentar des Absenders freigegeben sein und eine zweite Sprache laufen, der zweite Eintrag nennt keine solche Voraussetzung.
- Das Änderungsprotokoll von Version 3.3.9 führt zwei Korrekturen gegen Cross-Site-Scripting.
- Angriffe und öffentlicher Exploit-Code sind nicht belegt.
Warum ist ein Übersetzungs-Plugin so heikel?
TranslatePress sitzt zwischen Server und Browser. Es nimmt den fertigen HTML-Code jeder Seite, tauscht die Texte gegen gespeicherte Übersetzungen aus und gibt das Ergebnis aus. Dabei läuft alles durch das Plugin, was Besucher beisteuern können, etwa Kommentare. Wird davon auch nur ein Stück als Code behandelt, ist die Folge ein gespeichertes Cross-Site-Scripting: Das Skript liegt dauerhaft in der Seite und läuft bei jedem Aufruf im Browser, bei einem Administrator mit dessen Rechten.
Der erste Eintrag, CVE-2026-119167, verlangt laut Wordfence, dass zuvor ein Kommentar desselben Absenders freigegeben wurde und eine zweite Sprache eingerichtet ist.[1] Die Hürde ist niedriger, als sie klingt: WordPress gibt Kommentare von Absendern mit freigegebenem Kommentar standardmäßig ohne weitere Prüfung frei. Beim zweiten Eintrag, CVE-2026-120537, nennt Wordfence keine solche Voraussetzung.[1]
Das Änderungsprotokoll von Version 3.3.9 verzeichnet zwei Korrekturen, die Cross-Site-Scripting betreffen. Eine davon lässt die Antworten der Ajax-Schnittstelle des Plugins nur noch als reines JSON ausliefern.[2] Die NVD-Einträge nennen keine Entdecker, als meldende Stelle steht Wordfence darin.[1]
Am 7. November liefen 23,8 Prozent der Installationen auf den Reihen 2.9 bis 3.2, rechnerisch rund 95.000 von mehr als 400.000. Weitere 60,9 Prozent nutzten die Reihe 3.3, darin stecken sowohl die betroffenen Versionen bis 3.3.8 als auch die korrigierte 3.3.9; die Statistik trennt die Einzelversionen nicht. Auf andere Reihen entfielen 15,2 Prozent.[2]
Ist das ein Einzelfall?
Nein. In denselben Stunden führte die NVD gleichartige Einträge von Wordfence zu gespeichertem Cross-Site-Scripting ohne Anmeldung auch für Optimole (über 200.000 Installationen) und FV Flowplayer (über 10.000). Besucherinhalte als Einfallstor gab es schon bei Prime Slider und bei CleanTalk, am Vortag traf es mit iubenda ein Plugin, das ebenfalls den HTML-Code jeder Seite umbaut.
Der Stand: Patch verfügbar, Exploit-Code nicht öffentlich, Angriffe nicht belegt. Im Katalog der CISA für ausgenutzte Schwachstellen stehen die beiden Einträge nicht, abgeglichen am 7. November.[1]
Vom Update bis zum NVD-Eintrag
Auf welchen Versionsreihen die Installationen liefen
Orange: Reihen 2.9 bis 3.2, durchweg vor 3.3.9, zusammen 23,8 Prozent. Die Reihe 3.3 enthält betroffene Versionen (bis 3.3.8) und die korrigierte 3.3.9. Die Statistik von wordpress.org zeigt Anteile je Versionsreihe, nicht je Einzelversion.
Ein Übersetzungs-Plugin schreibt jede Seite um, bevor Besucher sie sehen. Dann darf es nichts davon als Code behandeln.
Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Betreiber jetzt tun?
- Aktualisieren: Spielen Sie TranslatePress 3.3.9 oder neuer ein und schalten Sie automatische Updates für das Plugin ein.
- Kommentare sichten: Prüfen Sie freigegebene Kommentare auf Einträge mit Skript-Code, löschen Sie Verdächtiges und leeren Sie danach den Seiten-Cache.
- Freigabe verschärfen: Stellen Sie unter „Einstellungen“ und „Diskussion“ übergangsweise ein, dass jeder Kommentar von Hand freigegeben wird.
- 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.
Agenturen mit vielen Kundenseiten filtern ihre Update-Werkzeuge nach dem Plugin und allen Versionen bis 3.3.8. Mehrsprachige Auftritte laufen oft in Shops und Unternehmensseiten mit Kunden- und Formulardaten, deshalb prüfen Betreiber bei Verdacht auf einen erfolgreichen Angriff die Meldepflicht nach Art. 33 DSGVO, die 72 Stunden nach Bekanntwerden gilt. Alternativen zu Übersetzungs-Plugins nennt der Ratgeber zur mehrsprachigen WordPress-Seite. Grundregeln fasst der Ratgeber zur WordPress-Sicherheit zusammen, im WordPress-Hosting-Vergleich finden Betreiber Anbieter, die den Betrieb übernehmen.
FAQ: Schwere Sicherheitslücke bei TranslatePress
Welche Version von TranslatePress ist sicher?
Die Korrekturen stecken laut Änderungsprotokoll in Version 3.3.9 vom 3. November 2026. Betroffen sind laut Wordfence alle Versionen bis 3.3.8. Prüfen Sie im Plugin-Bereich Ihres WordPress, welche Version läuft.
Braucht ein Angreifer ein Konto auf der Website?
Nein. Laut Wordfence kann ein Unbekannter ohne Anmeldung Skripte einschleusen. Bei CVE-2026-119167 muss zuvor ein Kommentar des Absenders freigegeben worden sein, außerdem muss eine zweite Sprache eingerichtet sein.
Wird die Sicherheitslücke schon ausgenutzt?
Angriffe sind bis zum 7. November 2026 nicht belegt. Ein Eintrag im Katalog der CISA für ausgenutzte Schwachstellen fehlt, öffentlichen Exploit-Code nennt keine der geprüften Quellen.
Reicht es, die Kommentarfreigabe zu verschärfen?
Nur als Übergang. Die Freigabe jedes Kommentars von Hand schließt den ersten Weg, den der Eintrag CVE-2026-119167 beschreibt. Der zweite Eintrag nennt diese Voraussetzung nicht, deshalb bleibt das Update nötig.
Quellen
2 Quellen anzeigenQuellen ausblenden
- NVDCVE-2026-119167 und CVE-2026-120537, veröffentlicht am 7. November 2026; CISA: Known Exploited Vulnerabilities Catalog, abgeglichen am 7. November 2026
- wordpress.orgTranslatePress, Änderungsprotokoll, aktive Installationen und Versionsstatistik, abgerufen am 7. November 2026
Mehr Newshunger?
- Schwere Sicherheitslücke bei iubenda im Cookie-Plugin
- 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
- WP Fastest Cache mit über 1 Million Installationen: Cache legte Zugangsdaten neuer Nutzer offen
- Ad Inserter mit über 300.000 Installationen: Shortcodes ließen sich über die Suche ausführen
