Redirection for Contact Form 7 mit über 200.000 Installationen: Fremde konnten Skripte einschleusen

Michael Dobler

Autor Dr. Web

22. Okt. 2026

3 Min. Lesezeit

Besucher ohne Konto konnten über ein Kontaktformular Skriptcode in Redirection for Contact Form 7 einschleusen. Der Code wird im Browser eines Administrators ausgeführt, sobald dieser den Eintrag öffnet, allerdings nur im Debug-Modus des Plugins, der ab Werk aus ist. Version 3.2.12 vom 8. September schließt die Lücke, öffentlich bekannt ist sie seit dem 19. Oktober.

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ügen

Seit August 2025 verzeichnet die NVD acht Lücken in der Erweiterung für Contact Form 7, sieben davon ohne Anmeldung ausnutzbar. Das Plugin von Themeisle hat laut wordpress.org mehr als 200.000 aktive Installationen (Stand 22. Oktober).^[1] Gemeldet hat die neue Lücke CVE-2026-111574 der Sicherheitsforscher Dmitrii Ignatyev von CleanTalk über die Schwachstellen-Datenbank WPScan.^[2]

Auf einen Blick

Das Wichtigste in Kürze

Betroffen sind die Versionen 2.2.7 bis 3.2.11, WPScan vergibt nach CVSS 3.1 den Wert 7,5 (hoch).
Der Angreifer braucht kein Konto, der Code läuft aber nur bei eingeschaltetem Debug-Modus.
Rund 10 Prozent der Installationen laufen laut wordpress.org noch auf dem vollständig betroffenen Versionszweig 3.1.
Angriffe sind nicht bekannt, den Beispielcode will WPScan am 19. November zeigen.

Wann greift die Lücke?

Eine weiße Schachtel mit einem Schalter und einem Briefumschlag mit einem gelben Aufkleber — Redirection for Contact Form 7 speichert Formulardaten im Backend. Bis Version 3.2.11 wurden sensible Rohdaten im Debug-Modus ungefiltert angezeigt

Redirection for Contact Form 7 erweitert Formulare um Aktionen: Weiterleitungen, Webhooks, E-Mails und das Speichern abgeschickter Formulare als Eintrag im Backend. Im Debug-Modus blendet das Plugin unter jedem Eintrag alle gespeicherten Rohdaten ein. Bis Version 3.2.11 gab es diese Daten ungefiltert aus, wie der Vergleich der Download-Archive von 3.2.11 und 3.2.12 zeigt.^[3] Version 3.2.12 maskiert die Ausgabe.

Ein Angreifer schickt also präparierten Text über ein Formular, dessen Eingaben das Plugin speichert. Der Code bleibt im Eintrag gespeichert. Öffnet ein Administrator den Eintrag, läuft der Code in dessen angemeldeter Sitzung, also mit allen Rechten des Administrators.^[4] Der CVSS-Vektor von WPScan nennt die Hürden: hohe Angriffskomplexität, ein Opfer, das den Eintrag selbst öffnet, aber kein Konto. Die US-Behörde CISA stuft die Ausnutzung bisher als nicht beobachtet ein.^[5]

Warum trifft es dieses Plugin immer wieder?

Jede Aktion des Plugins verarbeitet, was Fremde ins Formular tippen. Damit bildet jede Aktion eine eigene Angriffsfläche. Im August 2025 meldete Wordfence drei Lücken bis Version 3.2.4, darunter das Löschen beliebiger Dateien auf dem Server.^[6] Im Dezember folgte ein Fehler beim Datei-Upload, im September 2026 eine Lücke, über die eingegebene Shortcodes ausgeführt wurden.^[7]^[8]

Aus dem Änderungsprotokoll lässt sich die Dringlichkeit kaum ablesen. Für 3.2.12 steht dort nur „Enhanced Security“, ohne Hinweis auf Art und Schwere der Lücke.^[9] Betreiber, die Updates nach Wichtigkeit abarbeiten, übersehen den Patch dadurch leicht. Ähnliche Lücken, die sich ohne Anmeldung ausnutzen ließen, steckten zuletzt in den Formular-Plugins Forminator und MetForm.

Redirection for Contact Form 7 im Steckbrief

Reichweite, Schweregrad und Lückenserie, Stand 22. Oktober 2026

200.000+

aktive Installationen laut wordpress.org

7,5

Punkte nach CVSS 3.1 vergibt WPScan für CVE-2026-111574

Lücken seit August 2025 verzeichnet die NVD, 7 davon ohne Anmeldung

3.2.12

ist die erste Version, die die neue Lücke schließt

Eine Serie in sechs Schritten

August 2025

Dateien löschen

Wordfence meldet drei Lücken ohne Anmeldung bis Version 3.2.4

Dezember 2025

Datei-Upload

Fremde konnten bis 3.2.7 Dateien ohne Typprüfung auf den Server bringen

Juni 2026

Skripte einschleusen

Patchstack meldet eine XSS-Lücke ohne Anmeldung bis 3.2.8

8. September

Patch

Version 3.2.12 maskiert die Rohdaten in der Debug-Ansicht

19. Oktober

Offenlegung

WPScan veröffentlicht CVE-2026-111574 ohne technische Details

19. November

Beispielcode

WPScan will Beispielcode für einen Angriff veröffentlichen

Eine Debug-Ansicht für Entwickler hat im laufenden Betrieb nichts verloren, schon gar nicht mit Rohdaten aus einem öffentlichen Formular.
Markus Seyfferth, Chefredakteur Dr. Web

Was sollten Betreiber jetzt tun?

Aktualisieren: Bringen Sie das Plugin auf die aktuelle Version 3.2.14, mindestens auf 3.2.12.
Debug-Modus abschalten: Prüfen Sie in den Einstellungen des Plugins, ob der Debug-Modus aktiv ist, und schalten Sie ihn aus.
Konten prüfen: War der Modus eingeschaltet, suchen Sie nach unbekannten Administratoren und frisch installierten Plugins.
Meldepflicht klären: Gespeicherte Einträge enthalten Namen und E-Mail-Adressen. Bei einem Zugriff Fremder gilt die 72-Stunden-Frist nach Art. 33 DSGVO.^[10]

Auf dem Weg von der Offenlegung bis zur Angriffswelle steht die Lücke bei „Patch verfügbar“. Agenturen mit vielen Kundenseiten sollten sich den 19. November als Frist setzen. Grundregeln bündelt der Ratgeber zur WordPress-Sicherheit, Managed-Hoster aus dem WordPress-Hosting-Vergleich spielen Plugin-Updates teils automatisch ein.

FAQ: Redirection for Contact Form 7 mit über 200.000 Installationen: Fremde konnten Skripte einschleusen

Welche Version von Redirection for Contact Form 7 ist sicher?

Die Lücke CVE-2026-111574 schließt Version 3.2.12 vom 8. September 2026. Aktuell ist Version 3.2.14. Betroffen sind die Versionen 2.2.7 bis 3.2.11. Die installierte Version zeigt die Plugin-Übersicht im WordPress-Dashboard.

Ist meine Website betroffen, wenn der Debug-Modus aus ist?

Der Skriptcode wird nur ausgeführt, wenn der Debug-Modus des Plugins eingeschaltet ist und ein angemeldeter Nutzer einen gespeicherten Eintrag öffnet. Ab Werk ist der Modus aus. Präparierten Text kann ein Angreifer trotzdem einschleusen, deshalb gehört das Update auf jede Website.

Was ist persistentes Cross-Site-Scripting?

Beim persistenten Cross-Site-Scripting legt ein Angreifer Skriptcode dauerhaft auf der Website ab, hier in einem Formulareintrag. Der Code wird beim Aufruf im Browser des Betrachters ausgeführt und läuft mit dessen Rechten, bei einem Administrator also mit vollen Rechten.

Wird die Lücke schon ausgenutzt?

Bis zum 22. Oktober 2026 wurden keine Angriffe bekannt. Die US-Behörde CISA stuft die Ausnutzung als nicht beobachtet ein. WPScan will den Beispielcode am 19. November veröffentlichen, das Update sollte vorher eingespielt sein.