Contact Form 7: Kritische Lücke beim Datei-Upload – welche WordPress-Seiten betroffen sind, warum du vor dem 19. November aktualisierst und warum Formulare jetzt Dateien umbenennen

01 / Die Lücke

Was an Contact Form 7 6.2 bis 6.2.3 kaputt ist.

Contact Form 7 ist eines der meistgenutzten Formular-Plugins für WordPress, laut wordpress.org mit mehr als 10 Millionen aktiven Installationen [7]. Der Entwickler Takayuki Miyoshi beschreibt das Problem so: Angreifer können mehrere Fehler in den Versionen 6.2 bis 6.2.3 kombinieren. Dadurch landen Dateien auf dem Server, die die Prüfung eigentlich blockieren müsste, und sie bleiben liegen, obwohl sie direkt nach dem Absenden gelöscht werden sollten [1]. Ein Login ist dafür nicht nötig.

Die Beschreibung in der US-Schwachstellendatenbank NVD wird konkreter [2]. Das Plugin prüft Typ und Endung hochgeladener Dateien nicht, und ein Fehler beim Aufräumen der temporären Dateien lässt die Datei auf der Festplatte liegen. Was daraus folgt, hängt vom Server ab:

• Apache in der Standardkonfiguration von Debian oder Ubuntu: Der Server listet Verzeichnisinhalte auf und führt .phar-Dateien als PHP aus. Ein Angreifer findet die Datei und kann sie starten. Das ist Codeausführung, also im schlimmsten Fall die Übernahme der Website [2].
• nginx oder Apache mit erlaubten .htaccess-Regeln: Hier bleibt es bei einer beliebigen Datei im Uploads-Ordner. Die kann aber trotzdem als HTML oder SVG von deiner eigenen Domain ausgeliefert werden, etwa für eine Phishing-Seite unter deiner Adresse [2].

Gefunden haben die Lücke Shinya Murakami und Jakub Herman, gemeldet über WPScan [1]. Bei der Schwere sind sich die Stellen nicht einig: WPScan stuft sie mit CVSS 7,5 als „hoch“ ein [4]. Die US-Behörde CISA hat in ihrer Ergänzung zum CVE-Eintrag 9,8 vergeben, also „kritisch“ [2]. Der Unterschied ändert nichts an der Empfehlung.

Die Zeitachse

• 5. bis 21. Oktober: Die betroffenen Versionen 6.2, 6.2.1, 6.2.2 und 6.2.3 erscheinen [5].
• 29. Oktober: Version 6.2.4 schließt die Lücke, rund zwei Stunden später folgt 6.2.4.1 mit einer kleinen Bibliotheks-Aktualisierung [1][5].
• 5. November: WPScan veröffentlicht den Eintrag, am 8. November folgt die CVE-Nummer in der NVD [2][3].
• 10. November: Version 6.2.5 behebt zwei weitere, laut Entwickler weniger gefährliche Datenlecks [6].
• 19. November: WPScan will den Proof of Concept zeigen, also die technische Anleitung zum Ausnutzen [3].

Ausnutzung in freier Wildbahn ist bisher nicht gemeldet. Im Katalog der aktiv ausgenutzten Schwachstellen der CISA stand die Lücke am 10. November nicht [9]. Das kann sich ändern, sobald die Anleitung öffentlich ist (Einschätzung). Wie schnell aus einer veröffentlichten Lücke ein echtes Risiko wird, habe ich bei PHP2Shell beschrieben.

02 / Betroffen oder nicht

Ist deine Website betroffen?

Drei Bedingungen grenzen das ein. Erstens die Version: Nur 6.2 bis 6.2.3 sind verwundbar [1][2]. Zweitens das Formular: Laut Entwickler kommen theoretisch alle Formulare mit Datei-Feld als Ziel in Frage [1]. Ein reines Kontaktformular mit Name, E-Mail und Nachricht ist nicht betroffen. Drittens der Server: Der Entwickler nennt Server, die Verzeichnisinhalte öffentlich auflisten, als Voraussetzung [1].

Das Ungewöhnliche an diesem Fall: Getroffen hat es gerade die Seiten, die fleißig aktualisieren. mySites.guru hat die Contact-Form-7-Installationen der von ihnen überwachten WordPress-Seiten am 29. Oktober ausgewertet. 54,6 Prozent liefen auf einer betroffenen Version, 36,8 Prozent noch auf 6.1.x und damit außerhalb der Lücke [5]. Das ist keine Statistik über alle WordPress-Seiten, zeigt aber das Muster.

Mein Rat: Aktualisiere in jedem Fall, auch wenn du kein Datei-Feld nutzt oder noch auf 6.1 bist. Der Entwickler empfiehlt das ausdrücklich allen, weil die Sicherheitsverbesserungen jede Version betreffen [1]. Und ob dein Hoster Verzeichnisse auflistet, weißt du erst, wenn du es geprüft hast.

03 / Checkliste

Was du bis zum 19. November erledigst.

1. Version prüfen und aktualisieren. Unter „Plugins“ im WordPress-Dashboard steht die installierte Version. Ziel ist 6.2.5, mindestens aber 6.2.4 [6][7]. Die aktuelle Version braucht WordPress 7.1 und PHP 8.3 [7]. Ist deine Seite älter, bekommst du das Update nicht angeboten. Dann ist das Plugin nicht das einzige Problem.
2. Formulare mit Datei-Feld finden. Öffne unter „Formulare“ jedes Formular und such im Formular-Tab nach [file. Das sind Bewerbungs-, Angebots- oder Support-Formulare mit Anhang. Diese Seiten prüfst du in den Schritten 3 bis 5 genauer.
3. Verzeichnisauflistung testen. Ruf im Browser https://deine-domain.de/wp-content/uploads/ auf. Eine 403-Fehlerseite oder eine leere Seite ist gut. Siehst du eine Liste mit Jahres- und Monatsordnern, ist die Auflistung an [5]. Bei Apache schaltet die Zeile Options -Indexes in der .htaccess sie ab [10], bei nginx die Einstellung autoindex off [11]. Bei nginx ist sie standardmäßig aus [11]. Bei Shared Hosting bittest du den Hoster, es für dich zu prüfen.
4. Upload-Ordner auf fremde Dateien prüfen. Contact Form 7 legt Anhänge kurz in wp-content/uploads/wpcf7_uploads ab und löscht sie nach dem Versand wieder [8]. Laut mySites.guru räumt das Plugin dort Dateien weg, die älter als 60 Sekunden sind [5]. Im Normalfall ist der Ordner also leer bis auf die Schutzdatei .htaccess, die das Plugin dort anlegt [5]. Schau per FTP oder Dateimanager des Hosters hinein. Dateien mit Endungen wie .php, .phtml, .phar, .html oder .svg gehören dort nicht hin.
5. Erlaubte Endungen festlegen. Gib im Datei-Feld die Option filetypes: und eine Größengrenze mit limit: ausdrücklich an, zum Beispiel [file lebenslauf filetypes:pdf limit:5mb]. Der Entwickler rät selbst dazu, weil sich die Standardwerte ändern können [8].

Wer SSH-Zugang hat, sucht im Hauptverzeichnis der Website nach Skriptdateien im Upload-Ordner. mySites.guru schlägt dafür diesen Befehl vor [5]:

find wp-content/uploads/wpcf7_uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \) -print

Eine saubere Seite liefert kein Ergebnis. Findest du etwas, behandle die Seite als möglicherweise kompromittiert, nicht nur als veraltet [5]. Eine abgelegte Datei bleibt selten allein. Dann sicherst du Logs und Dateien, bevor du löschst, und holst dir Hilfe. Haben Fremde Zugriff auf Bewerbungen oder Kundendaten bekommen, kann das eine meldepflichtige Datenschutzverletzung sein. Die Frist für die Meldung an die Aufsichtsbehörde beträgt 72 Stunden ab Kenntnis [12].

04 / Nebenwirkung

Warum aus der Bewerbung plötzlich .docx_.txt wird.

Der Fix hat eine Nebenwirkung, die du kennen solltest. Bis 6.2.3 arbeitete das Plugin mit einer Sperrliste gefährlicher Endungen. Seit 6.2.4 gilt eine Positivliste (Safelist): Nur bestimmte Endungen bleiben erhalten, alle anderen werden in eine sichere Form umgewandelt [1].

Auf der Liste stehen standardmäßig Audio-, Video- und Bildformate sowie pdf und txt [1]. Word, Excel, OpenDocument, RTF, CSV und ZIP fehlen. Eine solche Datei wird nicht abgelehnt, sondern umbenannt: Aus lebenslauf.docx wird lebenslauf.docx_.txt, aus unterlagen.zip wird unterlagen.zip_.txt [5]. Das Formular zeigt keinen Fehler. Du merkst es erst, wenn jemand den Anhang öffnen will.

Abhilfe schafft ein Filter, den der Entwickler selbst angibt. Er ergänzt die Liste, statt sie zu ersetzen [1]. Für ein Bewerbungsformular mit Word-Dateien sieht das so aus:

add_filter( 'wpcf7_file_extension_safelist', function ( $safelist ) {
    return array_merge( $safelist, ['doc', 'docx'] );
} );

Drei Hinweise dazu. Nimm nur die Endungen auf, die ein Formular wirklich braucht. Wer die Liste wieder für alles öffnet, macht den Fix zunichte [5]. Den Code legst du in ein kleines eigenes Plugin oder in die functions.php eines Child-Themes, damit ihn das nächste Theme-Update nicht überschreibt. Und danach testest du jedes Formular mit einer Datei jedes erlaubten Typs und schaust, was in der Benachrichtigungs-Mail ankommt.

Nach meinem Verständnis sind die Option filetypes: im Formular und die Safelist zwei getrennte Stufen: Die erste entscheidet, was das Formular annimmt, die zweite, ob die Endung beim Speichern erhalten bleibt (Einschätzung). Erlaubst du docx im Formular, aber nicht in der Safelist, kommt die Datei umbenannt an. Wer eigenen Code nutzt, der die Funktion wpcf7_unship_uploaded_file() aufruft, muss außerdem die Argumente anpassen [1]. Das betrifft fast nur individuell programmierte Seiten.

05 / Für die Zukunft

Was du aus dem Fall für deine Wartung mitnimmst.

Updates bleiben richtig. Die meisten Plugin-Lücken stecken in alten Versionen, und diese hier ist nur deshalb so schnell behoben, weil das Plugin aktiv gepflegt wird [5]. Der Fall zeigt aber, dass ein Update nicht mit dem Klick auf „Aktualisieren“ erledigt ist. Die Version, die du gerade installiert hast, kann eine Woche später die mit der Lücke sein.

Für kleine Unternehmen heißt das (Einschätzung): Automatische Updates für gut gepflegte Plugins einschalten, aber nach jedem Sicherheitsupdate die wichtigsten Formulare einmal selbst testen. Datei-Felder nur dort anbieten, wo du sie wirklich brauchst. Verzeichnisauflistung einmal beim Hoster abschalten lassen. Und wissen, auf welcher PHP-Version die Seite läuft, denn auch dort tauchen Lücken auf, gegen die kein Plugin-Update hilft. Wie du das alles in einen festen Rhythmus bringst, beschreibe ich in WordPress-Sicherheitsupdates.

Ein Hinweis zu 6.2.5 vom 10. November: Diese Version schließt zwei andere Probleme. Über bestimmte Mail-Tags konnten Daten nicht öffentlicher Beiträge nach außen gelangen, über Formular-Optionen mit default:user_* Benutzer-Metadaten [6]. Der Entwickler stuft das Risiko als nicht hoch ein, rät aber zum baldigen Update [6]. Wer ohnehin gerade aktualisiert, nimmt direkt 6.2.5.

FAQ

Häufige Fragen zur Contact-Form-7-Lücke.

Reicht 6.2.4, oder brauche ich 6.2.5?

Für die Upload-Lücke reicht 6.2.4 oder höher [1][3]. Version 6.2.5 behebt zusätzlich zwei Datenlecks, deshalb ist sie die bessere Wahl [6].

Mein Formular hat kein Datei-Feld. Muss ich trotzdem etwas tun?

Ja, aktualisieren. Laut Entwickler kommen theoretisch nur Formulare mit Datei-Feld als Ziel in Frage, er empfiehlt das Update aber allen Nutzern [1].

Warum kommen PDF-Dateien normal an, Word-Dateien aber nicht?

Weil pdf auf der Standard-Safelist steht, doc und docx aber nicht. Fehlende Endungen bekommen ein „_.txt“ angehängt [1][5]. Mit dem Filter wpcf7_file_extension_safelist fügst du sie hinzu.

Quellen

Quellen

1. Contact Form 7 (Takayuki Miyoshi): „Contact Form 7 6.2.4“, 29. Oktober 2026 – contactform7.com · abgerufen 10.11.2026.
2. NIST National Vulnerability Database: „CVE-2026-114432 Detail“, veröffentlicht 8. November 2026 – nvd.nist.gov · abgerufen 10.11.2026.
3. WPScan: „Contact Form 7 6.2 - 6.2.3 - Unauthenticated Arbitrary File Upload via Invalid UTF-8 Filename“, 5. November 2026 – wpscan.com · abgerufen 10.11.2026.
4. WPScan: Plugin-Übersicht „Contact Form 7“ (Schwachstellen und CVSS) – wpscan.com · abgerufen 10.11.2026.
5. mySites.guru (Phil Taylor): „Contact Form 7 6.2.4 Fixes an Unauthenticated File Upload in 6.2 to 6.2.3“, 29. Oktober 2026, aktualisiert 4. November 2026 – mysites.guru · abgerufen 10.11.2026.
6. Contact Form 7 (Takayuki Miyoshi): „Contact Form 7 6.2.5“, 10. November 2026 – contactform7.com · abgerufen 10.11.2026.
7. WordPress.org: Plugin-Verzeichnis „Contact Form 7“ (Version 6.2.5, Anforderungen, Changelog) – wordpress.org · abgerufen 10.11.2026.
8. Contact Form 7: „File uploading and attachment“ (Dokumentation) – contactform7.com · abgerufen 10.11.2026.
9. CISA: „Known Exploited Vulnerabilities Catalog“ – cisa.gov · abgerufen 10.11.2026.
10. Apache HTTP Server 2.4: Dokumentation „core – Options Directive“ – httpd.apache.org · abgerufen 10.11.2026.
11. nginx: Dokumentation „Module ngx_http_autoindex_module“ – nginx.org · abgerufen 10.11.2026.
12. DSGVO, Art. 33 Meldung von Verletzungen des Schutzes personenbezogener Daten an die Aufsichtsbehörde – dsgvo-gesetz.de · abgerufen 10.11.2026.

Alle Quellen am 10. November 2026 abgerufen. Aussagen ohne belastbare Quelle sind im Text als Einschätzung gekennzeichnet; die Ziffern in eckigen Klammern verweisen auf die Nummern dieser Liste.