Elementor Pro: Kritische Lücke gefährdet 6 Millionen WordPress-Seiten
Eine kritische Sicherheitslücke im WordPress-Plugin Elementor Pro (CVE-2026-32475, CVSS 9.0-9.8) erlaubt Angreifern ohne Anmeldung, über ein normales Kontaktformular eine PHP-Datei hochzuladen und auszuführen. Betroffen sind alle Versionen bis 4.2.1, geschätzt 6 Millionen WordPress-Installationen. Was betroffen ist, wie der Angriff technisch funktioniert und welche Schritte jetzt nötig sind.

Bin ich betroffen?
- Betroffen: Alle WordPress-Seiten mit dem Plugin Elementor Pro in Version 4.2.1 oder älter, sofern das Forms-Modul mit einem File-Upload-Feld genutzt wird (z. B. Kontakt-, Bewerbungs- oder Support-Formulare).
- Nicht betroffen: Seiten mit der kostenlosen Elementor-Basisversion ohne Pro-Erweiterung, sowie Elementor-Pro-Installationen, die bereits auf Version 4.2.2 oder neuer aktualisiert wurden.
- Handlungsfenster: Sofort, nicht im nächsten Wartungsfenster. Die Lücke ist unauthentifiziert ausnutzbar, es ist kein Login und keine Interaktion eines Nutzers nötig, ein einzelner HTTP-Request gegen ein öffentlich erreichbares Formular genügt.
Überblick
Elementor Pro, die kostenpflichtige Erweiterung des populären WordPress-Page-Builders Elementor, enthält eine kritische Schwachstelle im Forms-Modul. Sie wurde von Sicherheitsforscher Tin Pham (Onlinename TF1T) entdeckt und an den WordPress-Sicherheitsdienstleister Patchstack gemeldet. Elementor wurde am 16. Juli 2026 informiert und veröffentlichte am 19. August 2026 mit Version 4.2.2 den Fix. Die Lücke trägt die Kennung CVE-2026-32475 und wird je nach Quelle mit einem CVSS-Wert von 9,0 bis 9,8 als kritisch eingestuft. Schätzungen zufolge sind bis zu 6 Millionen WordPress-Installationen betroffen, da Elementor Pro zu den meistgenutzten Page-Buildern im WordPress-Ökosystem zählt.
Wie der Angriff funktioniert
Die Schwachstelle liegt im File-Upload-Feld des Forms-Widgets, implementiert in der Datei modules/forms/fields/upload.php. Wird ein Formular mit Datei-Anhang abgeschickt, durchläuft die hochgeladene Datei zwei getrennte Prüfschritte in zwei unterschiedlichen Programmschleifen:
- Die Methode
validation()prüft die Dateiendung jedes hochgeladenen Elements gegen eine Positivliste erlaubter Endungen und eine Sperrliste verbotener Endungen wiephp,phtml,pht,asp,exeund weitere ausführbare Formate. - Die Methode
process_field()verschiebt anschließend jede als gültig erkannte Datei in ein öffentlich erreichbares Uploads-Verzeichnis.
Das eigentliche Problem: Beide Schleifen behandeln leere Datei-Einträge (technisch: ein Upload-Teil mit leerem Dateinamen, von PHP als UPLOAD_ERR_NO_FILE gemeldet) unterschiedlich.
// validation() - bricht bei leerem Eintrag die GESAMTE Methode ab
foreach ( $files[$id] as $index => $file ) {
if ( ! $field['required'] && UPLOAD_ERR_NO_FILE === $file['error'] ) {
return; // spätere Einträge werden nie geprüft
}
// ...
if ( ! $this->is_file_type_valid( $field, $file ) ) { ... }
}
// process_field() - überspringt nur den EINEN leeren Eintrag
foreach ( $files[$id] as $index => $file ) {
if ( UPLOAD_ERR_NO_FILE === $file['error'] ) {
continue; // die Schleife läuft weiter
}
// Datei wird ins öffentliche Verzeichnis verschoben
}Ein Angreifer schickt dazu ein Formular mit zwei Datei-Teilen für dasselbe Upload-Feld: Der erste Teil ist leer, der zweite enthält die eigentliche PHP-Schaddatei. In validation() bricht die Prüfung bereits beim leeren ersten Eintrag komplett ab, sodass die nachfolgende PHP-Datei nie gegen die Sperrliste geprüft wird. In process_field() wird dagegen nur der leere erste Eintrag übersprungen, die Schleife läuft weiter und verschiebt die PHP-Datei anschließend regulär in das öffentliche Formular-Uploads-Verzeichnis. Von dort lässt sie sich direkt per HTTP-Aufruf ausführen, das entspricht einer vollständigen Remote Code Execution (RCE) auf dem Server.
Voraussetzungen für den Angriff
| Voraussetzung | Status |
|---|---|
| Authentifizierung nötig | Nein, unauthentifiziert ausnutzbar |
| Nutzerinteraktion nötig | Nein |
| Betroffenes Modul | Forms-Widget mit File-Upload-Feld (z. B. Kontakt-, Bewerbungsformular) |
| Betroffene Versionen | Elementor Pro bis einschließlich 4.2.1 |
| Behobene Version | Elementor Pro 4.2.2 (19. August 2026) |
Wichtig für die Risikoeinschätzung: Jede öffentlich erreichbare Seite mit einem Elementor-Pro-Formular, das ein Datei-Upload-Feld enthält, egal ob Kontaktformular, Bewerbungsportal oder Support-Ticket-System, ist ein potenzielles Angriffsziel. Ein Angreifer benötigt keinerlei Zugangsdaten und keine vorherige Interaktion mit dem Zielsystem.
Konkrete Maßnahmen
- Sofort aktualisieren: Elementor Pro auf Version 4.2.2 oder neuer aktualisieren. Das ist die einzige vollständige Absicherung gegen diese Schwachstelle.
- Wenn ein Update nicht sofort möglich ist: Das File-Upload-Feld in allen öffentlich erreichbaren Formularen vorübergehend deaktivieren oder die erlaubten Dateitypen auf eindeutig ungefährliche, nicht ausführbare Formate wie PDF oder JPG einschränken.
- Bestehende Kompromittierung prüfen: Das öffentliche Forms-Upload-Verzeichnis nach verdächtigen Dateien mit PHP-Endungen oder ungewöhnlichen Dateinamen durchsuchen, insbesondere Dateien, die nicht zu erwarteten Formular-Anhängen passen.
- Server-Logs kontrollieren: Zugriffe auf das Uploads-Verzeichnis der letzten Wochen (insbesondere seit dem 16. Juli 2026, dem Meldedatum an Elementor) auf ungewöhnliche POST-Requests mit mehreren Datei-Teilen im selben Formularfeld prüfen.
- Web Application Firewall (WAF) als Zwischenlösung: Sicherheitsanbieter wie Patchstack und Wordfence haben bereits Mitigationsregeln für ihre Kunden veröffentlicht, die vor der eigentlichen Aktualisierung schützen können, das Plugin-Update ersetzen sie aber nicht.
Einordnung
Die Kombination aus Elementor Pros großer Verbreitung, der fehlenden Authentifizierungsanforderung und der direkten Remote-Code-Execution macht CVE-2026-32475 zu einer der kritischsten WordPress-Plugin-Lücken des Jahres. Anders als bei vielen SQL-Injection- oder XSS-Schwachstellen führt die erfolgreiche Ausnutzung hier direkt zur vollständigen Kontrolle über den Webserver, nicht nur über die WordPress-Datenbank. Die Ursache selbst ist dabei technisch unspektakulär: keine kryptografische Schwäche, sondern zwei Codepfade, die bei einem Sonderfall (leerer Datei-Eintrag) unterschiedlich reagieren, ein klassisches Muster für kritische Sicherheitslücken, das sich auch in anderen Plugin-Ökosystemen wiederfindet und die Bedeutung von Code-Reviews bei sicherheitsrelevanten Upload-Funktionen unterstreicht.
Passende Anleitungen auf S-EDV
- WordPress Debug-Modus aktivieren: Logs richtig nutzen
- WordPress im netcup Webhosting per Toolkit installieren und aktuell halten