WPFORMS-ALARM! CVE-2026-4633 lässt JETZT Author-User PHP-Shells hochschieben — DEIN Blog ist mit EINEM schwachen Passwort weg

WP-ADMINS, ZWEITER WORDPRESS-HAMMER innerhalb von Stunden: Nach Funnel-Builder reißt jetzt auch der WPForms ein Loch — CVE-2026-4633, eine Lücke beim Datei-Upload. Im Gegensatz zum Funnel-Builder-Skimmer braucht der Angreifer hier zumindest einen Login. Aber: Schon ein einfacher Author-User mit der upload_files-Capability reicht, um beliebige Dateitypen hochzuschieben.

WAS GENAU geht da kaputt?

WPForms erlaubt in seinen Datei-Upload-Feldern normalerweise nur eine Whitelist von Dateitypen (PDF, JPG, ZIP usw.). Doch die Lücke umgeht diese Whitelist über eine fehlende Validierung. Ein eingeloggter Author kann etwa eine shell.php verkleidet als shell.php.jpg oder via MIME-Trick hochladen. Liegt die Datei dann unter /wp-content/uploads/, ist sie direkt aufrufbar — und der Server führt den PHP-Code aus. Spätestens dann ist die Site GEKAPERT.

WARUM das brisanter ist als es klingt

Klar, Author-Rollen sind nicht jedermanns Zugang. Aber: Viele Multi-Author-Blogs haben Dutzende Author-Accounts. Wenn EINER davon ein schwaches Passwort hat oder per Phishing kompromittiert wird, kann der Angreifer über die WPForms-Lücke sofort eine PHP-Shell hochladen. Und WordPress hat zudem ein Plugin-Ökosystem, das Gastautoren oder externe Schreiber-Pools mit Author-Rechten ausstattet — alles Einfallstore.

SOFORT-MASSNAHME für dich

1. Im WP-Admin unter Plugins → Installierte Plugins nach WPForms suchen.
2. Update einspielen — Hersteller hat den Patch in der jüngsten Version drin.
3. Unter Benutzer → Alle Benutzer die Author- und Editor-Liste durchgehen: Wer braucht WIRKLICH den Zugang?
4. Inaktive Accounts deaktivieren oder downgraden.

EXTRA-Härtung: Apache/Nginx PHP-Execution sperren

Ein bewährter Defense-in-Depth-Trick: Verbiete deinem Webserver, in /wp-content/uploads/ überhaupt PHP-Dateien auszuführen. Bei Apache reicht ein .htaccess:

<Files *.php>
  deny from all
</Files>

Bei Nginx in der Server-Block-Config:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

Damit kann ein hochgeschobenes Skript schlicht NICHT mehr ausgeführt werden — egal welcher Trick.

PRÜF deine Logs RÜCKWIRKEND

Falls der Verdacht besteht, dass das Loch schon ausgenutzt wurde: Im Webserver-Log nach POST-Requests an WPForms-Endpoints suchen, die auf untypische Dateiendungen verweisen. Und im Uploads-Ordner per SSH:

find wp-content/uploads -type f -name "*.php" -o -name "*.phtml" -o -name "*.phar"

Wenn da Treffer kommen, die du nicht selbst hochgeladen hast: SOFORT löschen, Passwörter aller Author-Accounts neu setzen, und das Site-Backup vor den Befunden ziehen — am besten parallel einen Malware-Scan mit Wordfence oder Sucuri durchziehen.

FAZIT: Update + Rollen aufräumen

WPForms ist nicht so „kalt-kritisch“ wie der Funnel-Builder-Skimmer von gerade eben, weil ein Login nötig ist. Aber gerade bei Sites mit mehreren Author-Accounts ist die Lücke ein potenter Angriffsvektor. Update einspielen, Rollen aufräumen, PHP-Execution in Uploads sperren — und du bist sauber raus. Diese drei Schritte sollten bei JEDEM WP-Setup eh Standard sein.

Quellen:

• WP Vanguard — WordPress Vulnerability Roundup
• Wordfence Blog