Elementor Pro Datei-Upload-Schwachstelle ermöglicht Codeausführung

Elementor Pro, die kostenpflichtige Erweiterung des weit verbreiteten Elementor-Seitenerstellers für WordPress, enthielt eine kritische Datei-Upload-Schwachstelle, die es jedem ermöglichte, ein funktionierendes Programm auf einer Website zu platzieren und auszuführen. Der Fehler wird als CVE-2026-32475 geführt und mit 9,0 auf der CVSS-Skala bewertet, einer standardmäßigen Schweregradskala von 0 bis 10, bei der eine höhere Zahl eine gefährlichere Schwachstelle bedeutet. Er betrifft Elementor Pro Version 4.2.1 und früher, und die korrigierte Version 4.2.2 wurde am 19. August 2026 veröffentlicht. Die Schwachstelle wurde von Tin Pham, bekannt als TF1T, entdeckt und an Patchstack gemeldet, und Patchstack veröffentlichte seine technische Analyse des Problems am selben Tag, an dem nach eigenen Angaben der Patch ausgeliefert wurde. Patchstack gibt an, Abwehrregeln zum Schutz vor der Ausnutzung der Schwachstelle herausgegeben zu haben.

Für alle, die nicht täglich mit Websites arbeiten: WordPress ist die Software, die einen sehr großen Teil der weltweiten Websites betreibt, und ein Seitenersteller ist ein Plugin, also ein Zusatzsoftwarepaket, mit dem ein Besitzer Seiten visuell zusammenstellen kann, anstatt Code zu schreiben. Elementor ist einer der beliebtesten Seitenersteller, und Elementor Pro ist seine kommerzielle Edition. Zu den Funktionen, die Elementor Pro hinzufügt, gehört ein Formular-Widget, mit dem ein Website-Besitzer Kontaktformulare, Bewerbungsformulare und Support-Ticket-Formulare im Editor erstellen kann, einschließlich eines Datei-Upload-Felds, damit ein Besucher ein Dokument anhängen kann. In diesem Feld steckt die Schwachstelle, im Formularmodul des Plugins.

Die Analyse von Patchstack beschreibt den Fehler als eine Diskrepanz zwischen zwei Schleifen in der Datei modules/forms/fields/upload.php. Wenn ein Formular übermittelt wird, lesen zwei separate Durchläufe dieselbe Liste hochgeladener Dateieinträge. Der erste, eine Methode namens validation(), prüft die Dateiendung jedes Eintrags gegen eine Liste erlaubter Typen und gegen eine Sperrliste verbotener Typen. Der zweite, eine Methode namens process_field(), nimmt jeden gültigen Eintrag und verschiebt die Datei in ein öffentliches Verzeichnis. Die beiden Durchläufe sind sich uneinig darüber, was ein leerer Dateieintrag bedeutet. Ein leerer Eintrag ist ein Upload-Teil mit leerem Dateinamen, den PHP als UPLOAD_ERR_NO_FILE meldet. PHP ist die Programmiersprache, in der WordPress selbst geschrieben ist.

In der Validierungsschleife führt ein leerer Eintrag, der auftritt, während das Feld nicht als erforderlich markiert ist, dazu, dass die gesamte Methode abbricht und zurückkehrt, sodass jeder spätere Eintrag in derselben Übermittlung ungeprüft bleibt. In der Verarbeitungsschleife wird derselbe leere Eintrag einfach übersprungen und die Schleife läuft weiter. Ein Angreifer kann daher zwei Dateiteile für dasselbe Feld senden: einen leeren ersten Eintrag mit leerem Dateinamen, gefolgt von einer .php-Datei. Die Validierung hört beim ersten Eintrag auf zu lesen und meldet eine saubere Übermittlung. Der Verschieber überspringt diesen ersten Eintrag und verschiebt die .php-Datei trotzdem. Der Abstand zwischen einer funktionierenden Verteidigung und diesem Fehler ist, wie Patchstack es ausdrückt, ein einziges Schlüsselwort.

Der beabsichtigte Schutz ist eine Funktion namens is_file_type_valid(), die verlangt, dass die Endung einer hochgeladenen Datei auf einer erlaubten Liste erscheint, und sie ablehnt, wenn sie auch auf einer fest codierten Sperrliste steht. Diese Sperrliste nennt ausdrücklich php, php3, php4, php5, php6, phps, php7, phtml, shtml, pht, swf, html, asp, aspx, cmd, csh, bat, htm, hta, jar, exe und com, unter anderem. Patchstack merkt an, dass die Prüfung selbst solide ist. Sie wird nur nie ausgeführt.

Der Verschiebungsschritt ist, wo der Schaden entsteht. process_field() liest die Endung aus dem übermittelten Dateinamen, erstellt mit PHPs uniqid()-Funktion einen neuen Namen und verschiebt die Datei in das öffentliche Formularverzeichnis des Plugins. Der übermittelte Dateiname wird vollständig verworfen. Nur die Endung überlebt im gespeicherten Namen. Dieses Detail schließt mehrere andere Tricks aus. Eine doppelte Endung wie shell.php.jpg ist hier harmlos, weil die Datei als zufälliger Name mit der Endung .jpg gespeichert würde. Eine hochgeladene .htaccess-Datei ist ebenso wirkungslos, weil sie zu einer zufällig benannten .htaccess-Datei wird und nicht zu einer Verzeichniskonfigurationsdatei. Nur die letzte Endung zählt, und die Schleifen-Diskrepanz reicht aus, um sie an der Prüfung vorbeizuschmuggeln. Das Ergebnis ist eine .php-Datei, die in wp-content/uploads/elementor/forms/ liegt, einem Ordner, der über das Web öffentlich erreichbar ist. Jeder kann dann diese Adresse direkt anfordern und den Server die Datei ausführen lassen. Das ist Remote-Code-Ausführung: Der eigene Code des Angreifers wird auf dem Server der Website ausgeführt.

Die Anforderungen für einen Angriff sind minimal. Die Zielwebsite benötigt mindestens eine veröffentlichte Seite mit einem Elementor-Formular, das ein Datei-Upload-Feld enthält, was Patchstack als extrem häufige, alltägliche Konfiguration beschreibt. Bewerbungsformulare, Formulare, die nach einem Foto, Ausweis oder Beleg fragen, und Support-Ticket-Anhänge verwenden es alle. Die Required-Umschaltung des Felds ist standardmäßig aus, sodass keine gehärtete oder ungewöhnliche Einstellung erforderlich ist. Alles, was der Angreifer zum Erstellen der Anfrage benötigt – die post_id, die form_id (Elementors interner Bezeichner für das Formular-Widget) und der Eingabename des Upload-Felds –, ist im öffentlichen HTML der Seite für jeden Besucher sichtbar. Der Upload wird über die AJAX-Aktion elementor_pro_forms_send_form abgewickelt, ohne Cookies und ohne Nonce. Ein Nonce ist ein einmaliges Sicherheitstoken, das WordPress normalerweise verwendet, um zu überprüfen, dass eine Anfrage von einer legitimen Seite stammt.

Ein Detail erschwert den Angriff: Die Upload-Antwort gibt den Pfad der Datei nicht zurück, sodass der Name ermittelt werden muss. Das ist billiger, als es klingt, weil uniqid() nicht zufällig, sondern zeitbasiert ist. Es erzeugt 13 Hexadezimalzeichen, von denen acht den Unix-Zeitstempel in ganzen Sekunden und fünf Mikrosekunden kodieren. Da der Date-Response-Header des Servers die Sekunden direkt liefert, müssen nur die fünf Mikrosekundenzeichen erraten werden, und Patchstack merkt an, dass selbst dieser Raum auf das Fenster um die Exploit-Anfrage selbst eingegrenzt werden kann. Es gibt auch einen Weg, der überhaupt kein Raten erfordert. Die Standard-Benachrichtigungsvorlage von Elementor Pro, [all-fields], rendert jedes übermittelte Feld, einschließlich einer Zeile mit der genauen URL der hochgeladenen Datei. Wenn ein Formular zusätzlich eine zweite Autoresponder-E-Mail-Aktion aktiviert hat, was laut Patchstack gerade bei den Bewerbungs- und Support-Ticket-Formularen üblich ist, die Datei-Upload-Felder enthalten, wird diese E-Mail an die vom Angreifer übermittelte Adresse gesendet und gibt die genaue Upload-URL preis.

Der Fix in Version 4.2.2 sorgt dafür, dass die beiden Schleifen sich darüber einig sind, was ein leerer Dateieintrag bedeutet, sodass ein Eintrag nicht mehr vom Validator ignoriert und dennoch vom Verschieber aufgegriffen werden kann. Patchstack fügt hinzu, dass aktuelle Versionen die Endung auch innerhalb von process_field() selbst unmittelbar vor dem Verschieben der Datei erneut prüfen, sodass die Sperrliste nun direkt das Ziel schützt und nicht nur den Validierungsdurchlauf.

Da diese Schwachstelle nicht authentifiziert ist und eine Datei auf der Festplatte hinterlässt, schließt ein Update das Loch, macht aber einen bereits erfolgreichen Versuch nicht rückgängig. Websites, die eine anfällige Version mit einem öffentlichen Formular betrieben haben, das ein Datei-Upload-Feld enthält, sollten außerdem wp-content/uploads/elementor/forms/ nach allem durchsuchen, was nicht einem der Dokument- oder Bildtypen entspricht, die ihre Formulare tatsächlich akzeptieren, und insbesondere nach Dateien mit der Endung .php. Für Besitzer, die Plugin-Veröffentlichungen lieber nicht selbst verfolgen möchten, legt ein verwalteter WordPress-Hosting-Dienst wie AEU Hosting die Plattform und ihre regelmäßige Sicherheitspflege in die Hände eines Anbieters statt des Website-Besitzers.

Patchstack nennt dies einen textbook Desynchronisationsfehler: Der Code, der entscheidet, ob ein Upload erlaubt ist, und der Code, der den Upload verarbeitet, durchlaufen dieselben Daten mit unterschiedlichen Regeln. Keine der beiden Schleifen ist für sich genommen falsch, und das Lesen einer einzelnen zeigt nichts Alarmierendes. Der Fehler existiert nur in der Lücke zwischen ihnen. Ein leerer Dateiteil reicht aus, damit Validator und Verschieber sich uneinig sind, und diese Uneinigkeit verwandelt ein eingeschränktes Datei-Upload-Feld in eine Möglichkeit für einen Fremden, Code auf dem Server auszuführen. Die Ursachenbehebung besteht darin, dass beide Schleifen genau dieselbe Sicht darauf haben, welche Einträge echte Uploads und welche leer sind, sodass ein Eintrag niemals den Verschieber erreichen kann, ohne zuvor den Validator zu passieren.

Die veröffentlichte Zeitleiste von Patchstack zeichnet die Abfolge auf: Am 16. Juli 2026 erhielt es den Bericht des Forschers und bestätigte noch am selben Tag die Schwachstelle, kontaktierte den Hersteller und wies die CVE-Kennung CVE-2026-32475 zu. Am 17. Juli 2026 bereitete der Hersteller den Patch vor, wobei die Veröffentlichung noch ausstand. Am 3. August 2026 überprüfte Patchstack den Patch des Herstellers und bestätigte, dass er die Schwachstelle behebt. Am 19. August 2026 veröffentlichte der Hersteller den Patch in Version 4.2.2, und am selben Tag wurde die Sicherheitshinweis-Analyse veröffentlicht.