Mit CVE-2026-114432 ist seit dem 8. November 2026 eine kritische Lücke in Contact Form 7 offiziell erfasst – einem der meistgenutzten WordPress-Plugins überhaupt. Laut WordPress.org läuft es auf mehr als zehn Millionen Websites. Die Schwachstelle in den Versionen 6.2 bis 6.2.3 erlaubt es Angreifern ohne Anmeldung, beliebige Dateien auf den Server hochzuladen. Unter bestimmten Serverkonfigurationen kann daraus Remote Code Execution werden. Der Patch ist bereits seit dem 29. Oktober in Version 6.2.4 verfügbar.
Die Bewertung ist hoch: Im CVE-Datensatz steht ein CVSS-3.1-Wert von 9,8 (kritisch). Gleichzeitig ist die Lage weniger dramatisch, als die Zahl vermuten lässt – denn der schlimmste Fall setzt eine Serverkonfiguration voraus, die nicht jede Website hat. Ein Grund zum Abwarten ist das trotzdem nicht.
Was hinter CVE-2026-114432 steckt
Contact Form 7 erlaubt Formulare mit Datei-Upload-Feldern, etwa für Bewerbungen oder Anhänge. Laut der WPScan-Meldung prüft das Plugin in den betroffenen Versionen Typ und Endung hochgeladener Dateien nicht ausreichend. Zusätzlich sorgt ein Fehler in der Bereinigung temporärer Dateien dafür, dass die hochgeladene Datei auf der Festplatte liegen bleibt. WPScan führt die Lücke unter dem Titel „Unauthenticated Arbitrary File Upload via Invalid UTF-8 Filename“.
Der Plugin-Entwickler Takayuki Miyoshi beschreibt es in seinem Release-Beitrag zu 6.2.4 so: Angreifer können mehrere Fehler in 6.2 bis 6.2.3 kombinieren, um Dateien hochzuladen, die die Validierung eigentlich blockieren sollte, und Dateien zu behalten, die nach dem Absenden sofort gelöscht werden müssten. Theoretisch sei jedes Formular mit Upload-Feld auf einem Server betroffen, der Verzeichnisinhalte öffentlich auflistet.
Das französische CERT Santé, das am 9. November eine Warnung veröffentlicht hat, wird noch konkreter. Demnach wurde in Version 6.2 die Dateitypprüfung aus der Funktion wpcf7_unship_uploaded_file() entfernt. Dateien landen vor jeder Validierung in uploads/wpcf7_uploads/, abgelehnte Dateien werden nie gelöscht. Die verbleibende Sperrliste deckt die Endungen .phar, .pht, .phps und die Datei .htaccess nicht ab. Für den Angriff genüge eine einfache, nicht authentifizierte POST-Anfrage an die REST-Route des Formulars.
Wann aus dem Upload Codeausführung wird
Entscheidend ist die Serverkonfiguration. Laut CVE-Beschreibung lässt sich die abgelegte Datei auf einer Standard-Apache-Konfiguration unter Debian oder Ubuntu, die Verzeichnisinhalte auflistet und .phar dem PHP-Handler zuordnet, finden und ausführen – das führt zu Remote Code Execution.
Auf anderen Konfigurationen, etwa mit nginx oder mit Apache bei aktivierten .htaccess-Overrides, bleibt es laut Beschreibung bei einer beliebigen Datei im Upload-Verzeichnis. Auch das ist nicht harmlos: Solche Dateien können als aktiver Inhalt wie HTML oder SVG von der eigenen Domain ausgeliefert werden – ein möglicher Hebel für Phishing-Seiten oder Cross-Site-Scripting auf der eigenen Origin.
Eine Hürde für Angreifer: Das zufällig benannte Unterverzeichnis, in dem die Datei landet, wird laut CERT Santé nicht offengelegt. Deshalb habe Patchstack die Angriffskomplexität als hoch eingestuft. Die CVSS-Bewertung im CVE-Datensatz von CISA geht dagegen von niedriger Komplexität aus. Genau hier kommt das Directory Listing ins Spiel: Wo der Server Verzeichnisinhalte auflistet, ist der Zufallsname kein Hindernis mehr.
Wie ernst ist die Lage?
Stand 9. November gibt es keine Hinweise auf aktive Ausnutzung. Die SSVC-Bewertung von CISA im CVE-Datensatz lautet „exploitation: none“, „automatable: yes“, „technical impact: total“. Im Katalog der Known Exploited Vulnerabilities (KEV) von CISA ist die Lücke nicht gelistet. CERT Santé meldet ebenfalls keine Ausnutzung und keinen öffentlichen Proof of Concept.
Das kann sich ändern. WPScan hat angekündigt, den Proof of Concept am 19. November 2026 zu veröffentlichen, um Betreibern Zeit für das Update zu geben. Spätestens dann sinkt die Einstiegshürde für automatisierte Angriffe deutlich. Bei einem Plugin mit mehr als zehn Millionen Installationen und einem Angriff ohne Login lohnt sich der Aufwand für Angreifer.
Betroffene Versionen und Patch
- Betroffen: Contact Form 7 6.2 bis einschließlich 6.2.3
- Behoben: ab 6.2.4 (veröffentlicht am 29. Oktober 2026); im Plugin-Verzeichnis ist aktuell 6.2.4.1 erhältlich
- Voraussetzungen von 6.2.4: WordPress 7.1 oder neuer
- Workaround: laut CERT Santé keiner – das Update ist die Lösung
- Entdeckt von: Shinya Murakami und Jakub Herman, gemeldet über WPScan
Miyoshi empfiehlt das Update allen Nutzern, auch wenn die Lücke nur 6.2 bis 6.2.3 betrifft – die Sicherheitsverbesserungen gelten für alle Versionen.
Was Betreiber jetzt tun sollten
Die folgenden Schritte ergeben sich aus den Hersteller- und CERT-Angaben; Punkte zwei bis vier sind allgemeine Härtungspraxis, kein offizieller Workaround.
- Auf 6.2.4 oder neuer aktualisieren. Wer automatische Plugin-Updates nutzt, sollte trotzdem prüfen, ob das Update tatsächlich installiert ist.
- Das Verzeichnis
wp-content/uploads/wpcf7_uploads/kontrollieren. Da abgelehnte Dateien in den betroffenen Versionen nicht gelöscht wurden, können dort Altlasten liegen – insbesondere Dateien mit Endungen wie.phar,.phtoder.phpssowie unerwartete.htaccess-Dateien. - Directory Listing abschalten, falls aktiv (bei Apache etwa über
Options -Indexes). - PHP-Ausführung im Upload-Verzeichnis unterbinden und prüfen, ob
.pharauf dem Server dem PHP-Handler zugeordnet ist. - Eigenen Code prüfen: Mit 6.2.4 ist das zweite Argument von
wpcf7_unship_uploaded_file()verpflichtend, ein drittes kam hinzu. Wer die Funktion in eigenen Erweiterungen aufruft, muss nachziehen.
Eine Nebenwirkung des Patches sollten Formularbetreiber kennen: wpcf7_antiscript_file_name() arbeitet jetzt mit einer Safelist erlaubter Dateiendungen statt mit einer Sperrliste. Gängige Bild-, Audio-, Video-, PDF- und Textformate sind enthalten. Wer etwa ZIP-Dateien annehmen möchte, muss sie über den neuen Filter wpcf7_file_extension_safelist ergänzen – sonst wird die Endung automatisch in eine sichere Alternative umgewandelt. Dazu passt ein weiterer Punkt im Changelog: Vor regulären Ausdrücken mit UTF-8-Modifikator wird Text jetzt mit wp_scrub_utf8() bereinigt.
Einordnung
Der Fall zeigt ein bekanntes Muster: Eine Änderung in einer Minor-Version entfernt eine Prüfung, mehrere kleine Fehler addieren sich – und eine Standard-Serverkonfiguration macht daraus im schlimmsten Fall Codeausführung. Ähnlich war es zuletzt bei der CryptoPayment-Gateway-Lücke CVE-2026-81648, die aktiv ausgenutzt wurde, und beim WordPress-Updater, den CISA in den KEV-Katalog aufgenommen hat. Auch die SQL-Injection CVE-2026-123488 in Craft CMS zeigt, wie lange zwischen Patch und CVE vergehen kann.
Bei Contact Form 7 lagen zwischen Patch und CVE zehn Tage, bis zum angekündigten Proof of Concept bleiben ab heute (9. November) noch zehn Tage. Diese Zeit sollten Betreiber nutzen.
