Elementor Pro: Sicherheitslücke im Formular-Upload — wer wirklich betroffen ist

Q: Wie erkenne ich verdächtige Dateien, ohne Fachwissen?

An der Endung. Alles, was auf .php endet, gehört nicht in ein Verzeichnis für Formularanhänge — unabhängig davon, wie der Dateiname lautet oder wie gross die Datei ist. Auch Endungen wie .phtml oder .php5 gehören dort nicht hin. Bilder und PDF-Dateien sind unauffällig, selbst wenn Sie sie keiner Anfrage mehr zuordnen können.

Am 19. August 2026 hat Elementor die Version 4.2.2 seiner Pro-Erweiterung veröffentlicht und damit eine Schwachstelle geschlossen, über die ein Angreifer ohne Anmeldung eine ausführbare Datei auf den Server legen konnte — über ein gewöhnliches Kontaktformular mit Datei-Upload. Bemerkenswert ist an diesem Fall weniger die Lücke selbst als eine Frage, die offengeblieben ist: Der Hersteller und das Unternehmen, das die Schwachstelle koordiniert hat, machen unterschiedliche Angaben dazu, wer betroffen ist. Dieser Beitrag gibt beide Aussagen im Wortlaut wieder und zeigt, wie Sie Ihren eigenen Fall klären, ohne die Frage entscheiden zu müssen.

Das Wichtigste in Kürze

Betroffen ist Elementor Pro bis einschliesslich Version 4.2.1. Behoben ist die Lücke in 4.2.2, veröffentlicht am 19. August 2026. Sie wird als CVE-2026-32475 geführt und mit 9,0 von 10 Punkten bewertet.
Die kostenlose Version von Elementor ist nicht gemeint. Die Schwachstelle liegt im Formular-Baustein, den erst die kostenpflichtige Pro-Erweiterung mitbringt. Wer nur das freie Elementor einsetzt, hat den betroffenen Baustein nicht.
Hersteller und Forscher widersprechen sich beim Umfang. Patchstack nennt als einzige Voraussetzung ein veröffentlichtes Formular mit Datei-Upload-Feld. Elementor schreibt seinen Kunden, gefährdet seien nur Websites, bei denen zusätzlich der Mehrfach-Upload eingeschaltet ist — und der sei ab Werk aus. Zwischen beiden Lesarten liegt ein grosser Unterschied im Kreis der Betroffenen.
Angriffe sind bisher nicht beobachtet worden — auch wenn eine der Quellen das Gegenteil nahelegt. Die Schwachstellen-Datenbank von Patchstack führt zu diesem Eintrag ein Kennzeichen «Known to be exploited»; im Katalog bekannter ausgenutzter Schwachstellen der US-Behörde CISA steht die Lücke nicht. Der Abschnitt weiter unten ordnet das ein.
Das Update schliesst die Lücke, räumt aber nicht auf. Wer eine betroffene Fassung im Einsatz hatte, sollte zusätzlich das Verzeichnis wp-content/uploads/elementor/forms/ durchsehen. Die Anleitung dazu steht weiter unten.

Was am 19. August veröffentlicht wurde

Elementor ist der meistverwendete Seitenbaukasten für WordPress. Die kostenlose Fassung zählt nach Angaben von WordPress.org zehn Millionen aktive Installationen. Elementor Pro ist die kostenpflichtige Erweiterung dazu; sie steht nicht im offiziellen Plugin-Verzeichnis, weshalb es für sie keine öffentliche Installationszahl gibt. Jede Zahl, die für Pro genannt wird, ist deshalb eine Schätzung — auch die Zehn-Millionen-Angabe gehört der freien Version und nicht der Erweiterung.

Zu den Bausteinen, die erst Pro mitbringt, gehört das Formular. Es wird für Kontaktanfragen verwendet, für Bewerbungen, für Support-Anfragen mit Anhang — überall dort, wo Besucher eine Datei mitschicken sollen. Genau in diesem Datei-Upload-Feld lag die Schwachstelle.

Angabe	Wert
Kennung	CVE-2026-32475
Bewertung	CVSS 9,0 von 10 («kritisch»), vergeben von Patchstack als zuständiger Vergabestelle. Das NVD führt den Eintrag als «Deferred», eine eigene Einstufung liegt dort nicht vor.
Angriffskomplexität	im Bewertungsvektor als hoch geführt (`AC:H`)
Betroffen	Elementor Pro bis einschliesslich 4.2.1
Behoben in	4.2.2, veröffentlicht am 19. August 2026
Art	Hochladen beliebiger Dateien ohne Anmeldung, mit anschliessender Codeausführung
Gemeldet von	Tin Pham (TF1T), VietSunshine Cyber Security Services

Eckdaten laut Patchstack-Advisory und Schwachstellen-Datenbank vom 19. August 2026.

Was «ohne Anmeldung» bedeutet, ist der Kern der Sache: Es braucht kein Konto, kein Passwort und keine besondere Berechtigung. Es genügt, das öffentlich erreichbare Formular anzusprechen.

Die Zeile zur Angriffskomplexität fehlt in der Berichterstattung durchgängig, ist für die Einschätzung aber wichtig. Der Bewertungsvektor stuft sie als hoch ein. Das bedeutet nicht, dass der Angriff schwierig zu verstehen wäre, sondern dass er nicht in einem einzigen Aufruf gelingt: Der Angreifer muss zusätzlich herausfinden, unter welchem Namen die abgelegte Datei gespeichert wurde. Für ein automatisiertes Massen-Scanning ist das eine Hürde — für einen gezielten Angriff auf eine bestimmte Website ist es keine.

Wie der Fehler zustande kam

Ein Formular mit Datei-Upload muss zwei Dinge tun: prüfen, ob die hochgeladene Datei erlaubt ist, und sie anschliessend ablegen. In Elementor Pro erledigten das zwei getrennte Programmschleifen. Beide gingen dieselbe Liste hochgeladener Dateien durch — aber sie behandelten einen leeren Eintrag unterschiedlich.

Der Ablauf lässt sich an einem Vergleich nachvollziehen. Am Eingang steht eine Kontrolle, die jede Tasche einzeln prüft. Dahinter steht ein Träger, der jede Tasche einzeln ins Haus bringt. Beide arbeiten dieselbe Reihe ab. Trifft die Kontrolle auf eine leere Stelle in der Reihe, beendet sie ihre Arbeit vollständig und geht nach Hause. Der Träger dagegen überspringt die leere Stelle nur und trägt weiter. Alles, was nach der leeren Stelle kommt, gelangt ungeprüft ins Haus.

Genau das war der Fehler. Die Prüfroutine beendete sich beim ersten leeren Eintrag, die Ablageroutine übersprang ihn und arbeitete weiter. Die eigentliche Schutzvorrichtung — eine Sperrliste, die PHP-Dateien und andere ausführbare Formate ausdrücklich verwirft — war korrekt programmiert. Sie kam nur nicht mehr zum Zuge. Patchstack fasst es so zusammen: Der Fehler existiere allein in der Lücke zwischen den beiden Schleifen; für sich genommen sei keine der beiden falsch.

Die abgelegte Datei landet in wp-content/uploads/elementor/forms/. Dieses Verzeichnis ist über das Web erreichbar. Der ursprüngliche Dateiname wird dabei verworfen; nur die Endung bleibt erhalten. Deshalb hilft an dieser Stelle auch kein Trick mit doppelten Endungen — und deshalb ist die Endung das Einzige, worauf es ankam.

Der Widerspruch: Wer ist betroffen?

Beim Umfang gehen die Angaben auseinander. Beide Aussagen stammen von benannten Quellen und liegen im Wortlaut vor.

Quelle	Aussage zur Voraussetzung	Folge für den Kreis der Betroffenen
Patchstack Advisory vom 19.08.2026	«The only prerequisite is that the target site has at least one published Elementor page containing a Form widget with a File Upload field.» Ergänzend: Der Schalter «Required» sei ab Werk ausgeschaltet, es sei also keine ungewöhnliche Einstellung nötig.	Jede veröffentlichte Seite mit einem Formular, das ein Datei-Upload-Feld enthält.
Elementor Mitteilung an Kunden, zitiert am 20.08.2026	Gefährdet seien nur «websites that use an Elementor Pro Form with an upload file form field, and the multiple file upload option enabled (it is disabled by default)». Und: «Every other Elementor site is unaffected.»	Nur Websites, bei denen zusätzlich der Mehrfach-Upload eingeschaltet wurde.

Gegenüberstellung der beiden Aussagen. Quellen: Patchstack-Advisory vom 19. August 2026 und die von BleepingComputer am 20. August 2026 zitierte Kundenmitteilung von Elementor.

Der Unterschied ist erheblich. Nach der Darstellung von Patchstack genügt der Auslieferungszustand. Nach der Darstellung von Elementor braucht es eine Einstellung, die ausdrücklich abgeschaltet ausgeliefert wird und die eine Minderheit der Formulare überhaupt verwendet.

Wir entscheiden diese Frage hier nicht. Der veröffentlichte Auszug aus dem Programmcode zeigt, dass der Angriff zwei Dateieinträge für dasselbe Feld erfordert; ob die Schnittstelle das auch dann annimmt, wenn der Mehrfach-Upload im Formular ausgeschaltet ist, geht aus dem Auszug nicht hervor. Beide Aussagen können ohne Widerspruch nebeneinander bestehen, wenn die Prüfung an einer Stelle stattfindet, die im Advisory nicht abgebildet ist. Sie können sich aber auch tatsächlich widersprechen. Ohne den vollständigen Quelltext beider Fassungen wäre jede Festlegung eine Behauptung.

Für die Praxis bleibt die offene Frage folgenlos: Beide Lesarten führen zu derselben Handlung. Aktualisieren und nachsehen. Die Prüfung im nächsten Abschnitt ist so aufgebaut, dass sie unter beiden Annahmen ein belastbares Ergebnis liefert.

Wird die Lücke ausgenutzt? Auch hier widersprechen sich die Quellen

Wer die Schwachstellen-Datenbank von Patchstack aufruft, findet dort neben dem Eintrag ein Kennzeichen: «Known to be exploited! (KEV)». Übersetzt: bekanntermassen ausgenutzt. Wenige Zeilen darunter steht auf derselben Seite allerdings, die Schwachstelle sei «expected to become exploited» — es werde erwartet, dass sie ausgenutzt wird. Das ist eine Prognose und keine Beobachtung, und die beiden Angaben sagen nicht dasselbe.

Die Abkürzung KEV ist keine allgemeine Beschreibung, sondern der Name eines bestimmten Verzeichnisses: des Katalogs «Known Exploited Vulnerabilities» der US-Cybersicherheitsbehörde CISA. In diesen Katalog wird eine Schwachstelle erst aufgenommen, wenn eine Ausnutzung tatsächlich belegt ist. Der Katalog ist öffentlich und maschinenlesbar, die Prüfung dauert eine Minute.

Quelle	Aussage zur Ausnutzung
Patchstack, Datenbankeintrag	Kennzeichen «Known to be exploited! (KEV)»; im Fliesstext derselben Seite «expected to become exploited»
CISA, KEV-Katalog	Der Eintrag fehlt. Katalogstand 27. August 2026 mit 1’685 Schwachstellen — CVE-2026-32475 ist nicht darunter, und es findet sich überhaupt kein Eintrag zu Elementor.
NVD, Eintrag zur Schwachstelle	kein Vermerk zu einer Aufnahme in den KEV-Katalog
Berichterstattung vom 20. August	«no cases of active exploitation have been observed in the wild»

Eigene Prüfung am 28. August 2026 gegen den maschinenlesbaren KEV-Katalog der CISA und den NVD-Eintrag.

Für die Handlung ändert das nichts: Aktualisieren Sie unabhängig davon. Für die Beurteilung der Dringlichkeit ändert es einiges — zwischen «wird bereits angegriffen» und «könnte angegriffen werden» liegt der Unterschied zwischen einem Wochenendeinsatz und dem nächsten Wartungsfenster.

Daraus folgt ein Vorgehen, das sich auch bei anderen Meldungen bewährt: Wenn irgendwo steht, eine Lücke werde aktiv ausgenutzt, sehen Sie im KEV-Katalog nach, bevor Sie danach handeln. Er ist die einzige Quelle, bei der die Aufnahme an einen belegten Nachweis gebunden ist.

Die zweite Verteidigungslinie, über die selten gesprochen wird

Der Angriff besteht aus zwei Schritten, und nur der erste hängt vom Plugin ab. Die Datei wird abgelegt — das lässt sich mit der betroffenen Fassung nicht verhindern. Ob daraus eine Codeausführung wird, entscheidet dagegen allein die Serverkonfiguration: Eine abgelegte PHP-Datei richtet nur dann Schaden an, wenn der Server sie auch ausführt. Die Ausführbarkeit ist damit eine notwendige Bedingung für den schwerwiegenden Teil des Angriffs. Es gibt eine seit Jahren empfohlene Härtung, die genau hier ansetzt: Im Verzeichnis für hochgeladene Dateien wird die Ausführung von PHP unterbunden. Wo diese Regel greift, endet der beschriebene Angriff mit einer Datei, die auf der Festplatte liegt und nichts tut.

Ob die Härtung eingerichtet ist, unterscheidet sich von Anbieter zu Anbieter; nach unserer Erfahrung ist sie bei spezialisierten WordPress-Anbietern häufiger anzutreffen als in einfachen Standardpaketen. Sie kostet nichts, sie bremst nichts, und sie wirkt über diese eine Lücke hinaus gegen die gesamte Klasse von Schwachstellen, bei denen eine Datei im Upload-Verzeichnis landet. Wie schwer diese Klasse wiegt, beziffert Wordfence: Unter den als hochgefährlich eingestuften Schwachstellen des Jahrgangs 2024 war das Hochladen beliebiger Dateien die häufigste Art.

Einen ersten Hinweis bekommen Sie selbst, in einer halben Minute. Rufen Sie im Browser eine Adresse unter wp-content/uploads/ auf, die auf .php endet und die es nicht gibt — etwa ihre-domain.ch/wp-content/uploads/test-123.php. Wichtig ist dabei, in welche Richtung die Antwort etwas beweist, denn der Test ist einseitig.

Antwort	Was daraus folgt
404 oder 200	Eindeutig: Es blockt nichts. Die Anfrage ist bis zur WordPress-Installation durchgelaufen. Das ist der Befund, der eine Frage an den Anbieter auslöst.
403 «Forbidden»	Es blockt etwas — welche Schicht, sagt der Statuscode nicht. Liegt ein Schutzdienst oder ein Auslieferungsnetz vor Ihrer Website, kann die Sperre dort sitzen, während der eigentliche Server weiterhin ausführt. Für den Alltag genügt das; wer es genau wissen will, lässt zusätzlich am Server selbst messen.

Der Test ist ein Ausschlussverfahren: Er kann belegen, dass nichts blockt — nicht, dass an der richtigen Stelle blockiert wird.

Die Frage an den Anbieter lautet in beiden Fällen gleich: Wird im Verzeichnis wp-content/uploads/ die Ausführung von PHP unterbunden, und zwar auf dem Server selbst?

Aus der Werkstatt: die Gegenprobe auf dem eigenen Server

Wir haben diese Prüfung aus Anlass der Elementor-Meldung auf unserem eigenen Hosting durchgeführt, statt uns auf die Konfiguration zu verlassen, von der wir ausgingen — und zwar an zwei Messpunkten, weil ein einzelner die Frage nicht beantwortet.

Aufgerufene Adresse	Antwort	Bedeutung
`/wp-content/uploads/….php`	403	Die Sperre greift.
`/wp-content/uploads/2026/08/….php`	403	Sie greift auch in Unterverzeichnissen.
`/wp-content/uploads/….jpg`	404	Kontrolle: Bilder werden normal behandelt, die Sperre ist nicht zu breit gefasst.

Eigene Messung vom 28. August 2026 mit Adressen, die es nicht gibt — von aussen über die öffentliche Adresse und zusätzlich direkt gegen den Webserver hinter dem Zwischenspeicher. Beide Messpunkte liefern dasselbe Bild.

Der zweite Messpunkt war dabei nicht Gründlichkeit um ihrer selbst willen. Die Antwortköpfe zeigten, dass die 403 von aussen aus dem Zwischenspeicher stammte — an ihr allein war nicht ablesbar, ob die Sperre tatsächlich auf dem Webserver sitzt oder eine Schicht davor. Erst die Messung am Server selbst hat das geklärt. Genau diese Lücke bleibt bei der Prüfung offen, die Sie von aussen durchführen können; deshalb steht sie oben als Ausschlussverfahren beschrieben und nicht als Nachweis.

Der Aufwand für die Gegenprobe lag bei sechs Aufrufen. Eine Konfiguration, von der man annimmt, sie sei vorhanden, ist erst dann eine Massnahme, wenn sie gemessen wurde — und der Messpunkt entscheidet mit, was die Messung überhaupt beweist.

Selbst prüfen: vier Kontrollen

Die folgenden Schritte führen Sie ohne Zusatzsoftware durch. Für den dritten Schritt brauchen Sie einen Dateizugang — über den Dateimanager Ihres Hosting-Kundenbereichs, über FTP oder über ein Plugin, das Ihnen das Upload-Verzeichnis anzeigt.

Die eigene Version feststellen. Im Adminbereich unter «Plugins» nach «Elementor Pro» sehen. Steht dort 4.2.2 oder höher, ist die Lücke geschlossen. Steht dort 4.2.1 oder niedriger, aktualisieren Sie zuerst und führen danach die weiteren Schritte aus. Finden Sie keinen Eintrag «Elementor Pro», setzen Sie nur die freie Fassung ein und sind nicht betroffen.
Feststellen, ob überhaupt ein Datei-Upload im Einsatz ist. Gehen Sie die veröffentlichten Seiten durch, auf denen ein Formular steht — meist Kontakt, Bewerbung, Support. Enthält keines davon ein Feld zum Anhängen einer Datei, endet die Prüfung an dieser Stelle. Wo doch eines vorhanden ist, öffnen Sie das Feld im Elementor-Editor und sehen nach, ob der Mehrfach-Upload eingeschaltet ist. Damit haben Sie festgehalten, welche der beiden oben gegenübergestellten Lesarten auf Sie zutrifft.
Das Ablageverzeichnis durchsehen. Öffnen Sie wp-content/uploads/elementor/forms/. Dort gehören ausschliesslich Dateitypen hinein, die Ihre Formulare tatsächlich entgegennehmen: PDF, Bilder, allenfalls Office-Dokumente. Sortieren Sie nach Datum und sehen Sie auf die Endungen. Zwei Dateien sind dort normal und kein Befund: eine inhaltsleere index.php und eine .htaccess. Solche Platzhalter legen WordPress und zahlreiche Erweiterungen an, damit ein Verzeichnis nicht auflistbar ist. Auffällig ist eine weitere Datei mit der Endung .php, besonders mit einem Namen aus dreizehn Zeichen ohne erkennbaren Bezug zu einer Einsendung. Dasselbe gilt für Endungen wie .phtml oder .php5.
Gegen die Formulareinsendungen abgleichen. Zu jeder legitimen Datei im Verzeichnis gehört eine Einsendung im Formularprotokoll oder eine Benachrichtigungs-E-Mail vom selben Zeitpunkt. Findet sich zu einer Datei keine Einsendung, ist das der Punkt, an dem Sie fachliche Hilfe hinzuziehen sollten — nicht der Punkt, an dem Sie die Datei löschen.

Zur Einordnung der Fehlalarme: Das Verzeichnis enthält auf einer aktiv genutzten Website regelmässig Dateien, die niemand mehr zuordnen kann, weil die zugehörige Anfrage vor Jahren beantwortet wurde. Ein unbekanntes PDF ist kein Befund. Ein zusätzliches PHP-Skript ist einer.

Und die Grenze dieser Prüfung gehört dazu: Ein Nicht-Fund ist keine Entwarnung. Wer eine Datei abgelegt und ausgeführt hat, kann sie anschliessend entfernt haben — die Wirkung bleibt, die Spur ist weg. Die Prüfung kann einen Vorfall belegen, aber keinen ausschliessen. Wer sicher sein muss, kommt an einem Abgleich der Serverprotokolle nicht vorbei.

Wenn Sie fündig werden

Löschen Sie die Datei nicht als Erstes. Eine gefundene PHP-Datei ist der einzige Beleg dafür, wann und über welchen Weg etwas geschehen ist; sie ist zugleich der Ausgangspunkt für die Frage, was danach passiert ist. Die Reihenfolge, die sich bewährt hat:

Zugriff verhindern, statt zu löschen. Nehmen Sie die Website vorübergehend vom Netz oder sperren Sie den Zugriff auf das Verzeichnis. Damit ist die unmittelbare Gefahr gebannt, ohne dass Spuren verlorengehen.
Zeitstempel und Datei sichern. Änderungsdatum notieren, die Datei als Kopie ausserhalb der Website ablegen. Aus dem Zeitstempel ergibt sich der Zeitraum, den die Protokolle des Servers abdecken müssen.
Davon ausgehen, dass es nicht bei einer Datei blieb. Ein erfolgreicher Zugriff wird in aller Regel genutzt, um weitere Zugänge anzulegen: zusätzliche Administratorkonten, geänderte geplante Aufgaben, veränderte Kerndateien. Ein Update von Elementor Pro entfernt davon nichts.
Die Meldepflicht mitdenken. Sind über das Formular Personendaten eingegangen — und bei einem Bewerbungsformular ist das der Regelfall —, kann eine Kompromittierung meldepflichtig sein. Das ist eine Frage, die früh gestellt gehört und nicht am Ende der Bereinigung.

Das vollständige Vorgehen inklusive der Frage, wann eine Bereinigung sinnvoller ist als ein Neuaufbau, haben wir in einem eigenen Beitrag beschrieben: WordPress gehackt — so bereinigen Sie richtig.

Zur Zeitleiste: warum zwischen Korrektur und Auslieferung Wochen liegen

Patchstack veröffentlicht zu jeder Meldung eine Zeitleiste. Sie ist in diesem Fall aufschlussreich, weil sie leicht falsch gelesen wird.

Datum	Ereignis
16. Juli 2026	Meldung des Forschers; Patchstack bestätigt die Lücke, informiert den Hersteller und vergibt die Kennung
17. Juli 2026	Der Hersteller hat die Korrektur fertig — die Auslieferung steht noch aus
3. August 2026	Patchstack prüft die Korrektur und bestätigt, dass sie das Problem behebt
19. August 2026	Auslieferung als Version 4.2.2, Veröffentlichung des Advisorys am selben Tag

Zeitleiste laut Patchstack-Advisory vom 19. August 2026.

Zwischen der fertigen Korrektur und ihrer Auslieferung liegen 33 Tage. Diese Spanne wirkt zunächst wie ein Versäumnis, entspricht aber dem vorgesehenen Ablauf einer abgestimmten Offenlegung. Solange die Schwachstelle nicht öffentlich beschrieben ist, ist die Wahrscheinlichkeit gering, dass jemand sie unabhängig findet und ausnutzt. Wird das Advisory dagegen vor der Auslieferung veröffentlicht, entsteht ein Zeitfenster, in dem der Angriffsweg bekannt und die Korrektur nicht verfügbar ist. Die 33 Tage haben die Betreiber also nicht gefährdet, sondern geschützt.

Was daraus für den Betrieb folgt, ist etwas anderes: Der Tag, an dem eine Korrektur ausgeliefert wird, ist zugleich der Tag, an dem der Angriffsweg öffentlich beschrieben wird. Ab diesem Zeitpunkt zählt die Zeit bis zur Installation des Updates — nicht die Zeit seit dem Bekanntwerden. Wer alle vier Wochen aktualisiert, hat im ungünstigen Fall vier Wochen offen.

Für Agenturen und Entwickler

Drei Punkte, die über diesen Einzelfall hinausreichen.

Elementor Pro aktualisiert sich nicht wie ein Plugin aus dem Verzeichnis. Die Erweiterung bezieht Updates über einen Lizenzschlüssel. Läuft die Lizenz ab, bleiben die Updates aus — und zwar still. Bei betreuten Beständen gehört der Lizenzstatus deshalb in dieselbe Übersicht wie die Versionsnummer. Eine abgelaufene Lizenz ist im Ergebnis ein eingefrorenes Plugin.
Das Muster ist wiederverwendbar. Prüfung und Verarbeitung laufen getrennt über dieselben Daten und behandeln einen Randfall unterschiedlich — das ist keine Elementor-Eigenheit, sondern eine wiederkehrende Fehlerklasse. Wer eigenen Code mit Datei-Uploads betreut, prüft am besten dort zuerst, ob die Prüfung unmittelbar an der Stelle stattfindet, an der die Datei abgelegt wird. Genau das hat der Hersteller in der Korrektur ergänzt.
Härtung schlägt Reaktionsgeschwindigkeit. Ein Verbot der PHP-Ausführung im Upload-Verzeichnis hätte diesen Angriff unabhängig vom Update-Stand ins Leere laufen lassen. Solche Massnahmen wirken vorwärts, für Lücken, die noch niemand kennt. Ein schneller Update-Rhythmus wirkt nur rückwärts.

Häufige Fragen

Ich nutze nur das kostenlose Elementor. Bin ich betroffen?

Nein. Der Formular-Baustein mit Datei-Upload gehört zur kostenpflichtigen Pro-Erweiterung. Ohne diese Erweiterung ist der betroffene Programmteil auf Ihrer Website nicht vorhanden. Prüfen Sie im Zweifel unter «Plugins», ob dort ein Eintrag «Elementor Pro» aufgeführt ist.

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

Nach beiden vorliegenden Darstellungen sind Sie dann nicht betroffen. Die Aktualisierung auf 4.2.2 empfiehlt sich trotzdem — auch der Hersteller rät allen Kunden dazu. Ein Formular, das heute keinen Upload hat, kann ihn morgen bekommen.

Wurde die Lücke tatsächlich ausgenutzt?

Dafür gibt es bislang keinen Beleg. In der Berichterstattung vom 20. August heisst es, es seien bisher keine Fälle einer Ausnutzung in freier Wildbahn beobachtet worden. Das ist eine Momentaufnahme: Sie schliesst weder aus, dass etwas unbemerkt geschah, noch dass später Angriffe folgen. Nach der Veröffentlichung eines Advisorys steigt die Zahl der Versuche erfahrungsgemäss, weil die Beschreibung dann öffentlich vorliegt.

Reicht es, wenn ich einfach aktualisiere?

Um die Lücke zu schliessen: ja. Um zu klären, ob vorher etwas passiert ist: nein. Patchstack weist ausdrücklich darauf hin, dass die Aktualisierung eine bereits erfolgreiche Ablage nicht rückgängig macht. Wenn Sie längere Zeit auf einer betroffenen Fassung waren und ein öffentliches Upload-Formular betreiben, gehört der Blick ins Ablageverzeichnis dazu.

Warum widersprechen sich Hersteller und Forscher?

Das lässt sich von aussen nicht abschliessend beurteilen. Denkbar ist, dass die beiden Aussagen unterschiedliche Punkte im Ablauf beschreiben und sich nur scheinbar widersprechen. Denkbar ist auch, dass eine der beiden Einschätzungen unzutreffend ist. Belegt sind beide Formulierungen; entschieden ist die Frage nicht. Weil beide Lesarten zur selben Handlung führen, ist das für Ihre Website ohne praktische Folge.

Wie erkenne ich verdächtige Dateien, ohne Fachwissen?

An der Endung. Alles, was auf .php endet, gehört nicht in ein Verzeichnis für Formularanhänge — unabhängig davon, wie der Dateiname lautet oder wie gross die Datei ist. Auch Endungen wie .phtml oder .php5 gehören dort nicht hin. Bilder und PDF-Dateien sind unauffällig, selbst wenn Sie sie keiner Anfrage mehr zuordnen können.

Fazit

Die Handlung ist in diesem Fall unstrittig und schnell erledigt: auf Elementor Pro 4.2.2 oder neuer aktualisieren, und wer ein öffentliches Formular mit Datei-Upload betreibt, sieht anschliessend einmal ins Ablageverzeichnis. Beides zusammen kostet eine Viertelstunde.

Bemerkenswert ist der Umstand daneben: Zu einer Schwachstelle, die seit dem 19. August öffentlich beschrieben ist, existieren zwei widersprüchliche Angaben darüber, wer betroffen ist — von den beiden Stellen, die es am besten wissen müssten. Wer sich als Betreiber auf eine der beiden verlässt, trifft eine Entscheidung, die er nicht überprüfen kann. Das ist der Normalfall im Umgang mit Sicherheitsmeldungen, nicht die Ausnahme: Die Informationslage ist selten eindeutig, und Vorgehensweisen, die nur bei eindeutiger Lage funktionieren, funktionieren im Alltag nie.

Wenn Sie nicht beurteilen können, ob Ihre Website betroffen war, oder wenn Sie im Ablageverzeichnis etwas gefunden haben, das dort nicht hingehört: Schicken Sie uns die Adresse. Sie erhalten innert einem Werktag eine Einschätzung, auch dann, wenn sie lautet, dass alles in Ordnung ist. Wie wir Websites laufend absichern und aktuell halten, steht unter Support und Wartung; der direkte Weg führt über das Kontaktformular.

Quellen

Patchstack: Critical Unauthenticated File Upload to RCE in Elementor Pro Plugin ↗ — Advisory vom 19. August 2026 mit der technischen Beschreibung, der Voraussetzung im Wortlaut, dem Ablageort und der Zeitleiste
Patchstack: Datenbankeintrag zu CVE-2026-32475 ↗ — Bewertung, betroffene und behobene Version, Veröffentlichungsdatum
BleepingComputer: Critical Elementor Pro bug exposes WordPress sites to RCE attacks ↗ — Bericht vom 20. August 2026; Quelle für die zitierte Kundenmitteilung von Elementor und für die Angabe, dass keine Ausnutzung beobachtet wurde
Wordfence: 2024 Annual WordPress Vulnerability and Threat Report ↗ — Quelle für die Aussage, dass das Hochladen beliebiger Dateien die häufigste Art unter den hochgefährlichen Schwachstellen war
CISA: Known Exploited Vulnerabilities Catalog ↗ — am 28. August 2026 gegen den maschinenlesbaren Katalog geprüft (Stand 27. August 2026, 1’685 Einträge); CVE-2026-32475 ist nicht enthalten
NVD: CVE-2026-32475 ↗ — Bewertungsvektor mit hoher Angriffskomplexität, CWE-434; die Einstufung stammt von Patchstack als Vergabestelle, eine eigene Analyse des NVD liegt nicht vor
WordPress.org: Elementor Website Builder ↗ — Installationszahl der kostenlosen Fassung; die Pro-Erweiterung wird dort nicht geführt

Stand: 28. August 2026. Dieser Beitrag beschreibt die Wirkung der Schwachstelle und die Erkennung eines erfolgten Zugriffs; er enthält bewusst keine Angaben, mit denen sich ein Angriff nachbauen liesse. Sollte einer der beiden Beteiligten seine Angabe zum Kreis der Betroffenen präzisieren oder zurückziehen, ergänzen wir den Abschnitt zum Widerspruch entsprechend.