Bricksforge CVE-2026-85097 wird ausgenutzt: Pro Forms jetzt aktualisieren

#Ist meine Bricksforge-Website von CVE-2026-85097 betroffen

Betroffen ist jede Bricksforge-Installation mit Version 3.1.8.9 oder älter. So steht es im NVD-Eintrag und in der Wordfence-Datenbank. Der Angreifer braucht weder ein Login noch einen Klick von jemandem auf Ihrer Seite.

Ein Upload-Feld im Formular ist keine Voraussetzung. Im Changelog des Herstellers steht beim Eintrag 4.0.1 ausdrücklich: Betroffen ist jede Website mit aktivem Pro Forms, auch wenn die Formulare keine Upload-Felder verwenden. Der Gedanke “wir haben doch nur ein Kontaktformular” entbindet also nicht vom Update.

Die Einstufung hängt von der Quelle ab. Patchstack vergibt 10.0 und markiert die Lücke als bekannt ausgenutzt (KEV). Wordfence und NVD geben 9.8 mit CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H an. Für Betreiber ändert das nichts: Angriff über das Netz, keine Rechte nötig, volle Auswirkung.

Bricksforge ist ein kommerzielles Plugin. Die Plugin-API von WordPress.org antwortet mit “Plugin not found”. Das spielt unten zweimal eine Rolle: Updates kommen über die Herstellerlizenz, nicht aus dem Verzeichnis, und wp plugin verify-checksums hat keine Referenz zum Vergleichen.

#Wie funktioniert die Upload-Lücke in Bricksforge Pro Forms

Die CVE-Beschreibung und die Analyse von Patchstack beschreiben drei Schritte:

1. Der Angreifer holt sich eine gültige Nonce über die AJAX-Aktion bricksforge_regenerate_nonce, die ohne Anmeldung antwortet.
2. Er lädt eine Datei hoch, die zugleich ein gültiges GIF und gültiger PHP-Code ist, ein sogenanntes Polyglott. Die MIME-Prüfung beim ersten Upload greift nicht, weil die Datei tatsächlich wie ein Bild aussieht. Sie landet in einem temporären Verzeichnis.
3. Er sendet ein Formular mit manipuliertem Parameter temporaryFileUploads. Der serverseitige Pfad zeigt auf das geprüfte GIF, das Feld url endet aber auf .php. Das Plugin vertraut den vom Client gesendeten Metadaten und schreibt den Inhalt an einen PHP-Pfad.

Patchstack nennt zwei Einstiegspunkte: POST /wp-json/bricksforge/v1/form_submit und /wp-admin/admin-ajax.php mit der Aktion bricksforge_form_submit. Der betroffene Code liegt in includes/elements/pro-forms/actions/init.php und base.php. Laut CVE-Eintrag wurde der Hersteller am 3. September 2026 informiert, veröffentlicht wurde am 7. Oktober. Als Finder ist d.v4n_s3c genannt.

#Wie prüfe ich die Bricksforge-Version in wp-admin und mit WP-CLI

Im Dashboard: Plugins, Installierte Plugins, Zeile Bricksforge, die Version steht unter der Beschreibung. Ist die Lizenz abgelaufen, zeigt das Dashboard ein vorhandenes Update unter Umständen nicht an. Fehlt der Hinweis, heißt das also nicht, dass Sie aktuell sind.

Per SSH für eine einzelne Website:

wp plugin list --name=bricksforge --fields=name,status,version,update_version

Auf einem Plesk-Server mit vielen Kundenseiten liefert eine Schleife in Sekunden eine Übersicht:

for d in /var/www/vhosts/*/httpdocs; do
  printf '%s ' "$d"
  wp --path="$d" plugin get bricksforge --field=version 2>/dev/null || echo "nicht installiert"
done

Bei anderen Hostern passen Sie das Muster an, etwa /var/www/*/public_html. Alles mit 3.1.8.9 oder darunter kommt auf die Liste für Update und Prüfung.

#Auf welche Version Bricksforge aktualisieren: 3.1.8.10 oder 4.0.1

Die Quellen sind sich hier nicht einig, und das sollten Sie wissen, bevor Sie auf “Aktualisieren” klicken.

• Patchstack und Wordfence nennen beide 3.1.8.10 als gepatchte Version.
• Das Changelog des Herstellers hat Stand 10. Oktober 2026 keinen Eintrag 3.1.8.10. Es listet 3.1.8.9 (28. August), 4.0.0 (17. September) und 4.0.1 (8. Oktober), Letzteres mit dem Titel “Security fix for the Pro Forms file upload”.

Die Arbeitsregel: Nach dem Update muss die Version 3.1.8.10 lauten oder 4.0.1 und höher. Stehen Sie auf 4.0.0, wechseln Sie auf 4.0.1. Keine der genannten Quellen sagt ausdrücklich, ob 4.0.0 verwundbar ist, aber der Hersteller hat den Upload-Fix in 4.0.1 ausgeliefert. Es gibt also keinen Grund, auf 4.0.0 zu bleiben.

wp plugin update bricksforge
wp plugin get bricksforge --field=version

Sieht WP-CLI kein Update, laden Sie das ZIP aus Ihrem Kundenkonto beim Hersteller und installieren es aus der Datei: wp plugin install /tmp/bricksforge.zip --force. Der Sprung auf 4.x ist eine neue Hauptversion. Auf einer Website mit komplexen Formularen testen Sie ihn zuerst auf Staging, und zwar heute.

Geht das Update nicht sofort? Deaktivieren Sie das Plugin (wp plugin deactivate bricksforge) oder blockieren Sie beide Endpunkte in der WAF. Patchstack hat für seine Kunden eine RapidMitigate-Regel für dieses CVE ausgerollt. Patchstack selbst bezeichnet das als Übergangslösung, nicht als Ersatz für das Update.

#Was prüfen, wenn die Website mit Bricksforge 3.1.8.9 oder älter lief

Das Update schließt die Tür. Wer schon drin ist, bleibt drin. Der 7. Oktober ist die erste Sichtung in der Telemetrie von Patchstack, kein Beleg dafür, dass niemand es früher versucht hat. Prüfen Sie deshalb ein breiteres Zeitfenster, etwa ab dem 3. September, als der Hersteller informiert wurde.

#Neue Administratorkonten

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Gleichen Sie die Liste mit den Personen ab, die Sie kennen. Ein Konto aus den letzten Wochen, mit einer Adresse auf einer fremden Domain oder einem Login wie wp-support, ist der Auslöser für eine vollständige Untersuchung. Prüfen Sie auch Anwendungspasswörter: wp user application-password list <ID> für jeden Admin.

#PHP-Dateien im Upload-Verzeichnis

In wp-content/uploads hat ausführbares PHP nichts verloren. Patchstack fand Dateien namens login_admin_*.php in /wp-content/uploads/bricksforge/tmp/ und /wp-content/uploads/2026/10/.

find wp-content/uploads -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \) -ls
find wp-content/uploads -type f -name 'login_admin_*' -ls
ls -la wp-content/uploads/bricksforge/tmp/

Das Muster *.php* mit -iname erfasst auch .php5 und .PHP. Patchstack berichtet von Varianten bei Endungen, Groß- und Kleinschreibung und Kodierung, suchen Sie also nicht nur nach exakt .php. Achten Sie auch auf fremde .htaccess-Dateien in den Uploads, weil sie andere Endungen auf PHP umleiten können.

#Geänderte Dateien in Core, Themes und Plugins

wp core verify-checksums
find wp-content -type f -name '*.php' -newermt '2026-09-03' ! -path '*/cache/*' -ls

Den Core prüfen Sie per Prüfsumme. Bricksforge und Bricks stehen nicht auf WordPress.org, laden Sie also saubere Pakete beim Hersteller und vergleichen sie mit diff -r. Besonders wichtig sind wp-content/mu-plugins, wo Code immer geladen wird und nie in der Pluginliste auftaucht, sowie wp-config.php.

#Geplante Aufgaben

wp cron event list --fields=hook,next_run_relative,recurrence
crontab -l

Unbekannte Hooks im WP-Cron oder eine Crontab-Zeile, die etwas von einer externen Adresse nachlädt, sind der klassische Weg zurück, nachdem eine Webshell gelöscht wurde.

#Server-Logs

Suchen Sie nach den Endpunkten aus dem Bericht von Patchstack. Unter Plesk liegen die Logs in /var/www/vhosts/<domain>/logs/:

grep -E 'bricksforge/v1/form_submit|bricksforge_regenerate_nonce|bricksforge_form_submit' access_ssl_log*
zgrep -E 'bricksforge/v1/form_submit' access_ssl_log*.gz
grep -E '^(177\.75\.57\.20|23\.97\.62\.146|84\.247\.60\.125|38\.154\.185\.97|150\.109\.16\.166|153\.75\.90\.146) ' access_ssl_log*
grep -E 'GET /wp-content/uploads/.*\.php' access_ssl_log*

Die sechs Adressen sind die aktivsten der 63 eindeutigen IPs, die Patchstack in der Kampagne gezählt hat. Eine Einschränkung: Ein normales Zugriffslog speichert nur die URL, der Name der AJAX-Aktion steckt oft im POST-Body. Ein Aufruf von admin-ajax.php muss im Log also gar nicht “bricksforge” enthalten. Korrelieren Sie dann über IP und Uhrzeit. Das stärkste Signal ist ein erfolgreicher GET auf eine .php-Datei unter uploads mit Status 200.

#Wann WordPress aus dem Backup wiederherstellen

Eine PHP-Datei in den Uploads, die Sie nicht erklären können, oder ein unbekanntes Admin-Konto: Dann gilt die Website als kompromittiert. Code, der auf dem Server lief, hatte Zugriff auf Datenbank, Dateien und wp-config.php. Eine Datei von Hand zu löschen, sagt Ihnen nicht, ob es die einzige war.

Die Reihenfolge, die funktioniert:

1. Den aktuellen Stand sichern, Dateien und Datenbank, als Beweismaterial, bevor Sie irgendetwas löschen.
2. Dateien aus einem Backup vor dem ersten verdächtigen Logeintrag wiederherstellen. Reichen die Logs nicht so weit zurück, nehmen Sie ein Backup vor dem 3. September und tragen spätere Inhalte von Hand nach.
3. Bricksforge auf 3.1.8.10 oder 4.0.1 aktualisieren, bevor die Website wieder online geht. Das zurückgespielte Backup enthält die alte, verwundbare Version.
4. Passwörter für Datenbank, SFTP und alle Admins ändern, die Schlüssel in wp-config.php neu erzeugen (wp config shuffle-salts) und Anwendungspasswörter widerrufen.

Pro-Forms-Formulare sammeln meist Namen, E-Mail-Adressen und Nachrichten. Hatte der Angreifer Zugriff auf die Datenbank, kann das eine Datenschutzverletzung nach Art. 33 DSGVO sein, mit Meldung an die Aufsichtsbehörde binnen 72 Stunden ab Kenntnis, sofern ein Risiko für die Betroffenen besteht. Dokumentieren Sie den Befund, auch wenn Sie am Ende nicht melden müssen.

Findet die Prüfung nichts, ist keine Wiederherstellung nötig. Halten Sie fest, was Sie wann geprüft haben.

#Vierte Bricksforge-Lücke im Jahr 2026

Die Liste bei Wordfence zeigt frühere Einträge aus demselben Jahr: CVE-2026-14956 (bis 3.1.8.6, Rechteausweitung ohne Anmeldung über Pro Forms, 9.8), CVE-2026-18030 (bis 3.1.8.7, Rechteausweitung ohne Anmeldung über das Zurücksetzen des Passworts, 9.8) und CVE-2026-84814 (bis 3.1.8.8, Rechteausweitung ab Abonnent, 6.3). Drei der vier betreffen Formulare oder die Anmeldelogik.

Das ist kein Grund, das Plugin panisch zu entfernen. Es ist ein Grund, Bricksforge auf Kundenseiten jede Woche zu prüfen statt einmal im Quartal.

#Wie ein Wartungsvertrag so eine Lücke abfängt

Ein Exploit ohne Anmeldung lässt Ihnen Tage, manchmal Stunden. Ein Vertrag zur Wartung von WordPress-Websites sollte die drei Dinge abdecken, die hier über den Ausgang entscheiden:

• ein Verzeichnis aller Plugins und Versionen je Website, kommerzielle eingeschlossen, weil der Update-Hinweis aus dem Verzeichnis Plugins außerhalb von WordPress.org nicht erreicht,
• Schwachstellen-Feeds (Patchstack, Wordfence, NVD), die mit diesem Verzeichnis abgeglichen werden, damit der Bricksforge-Alarm bei jemandem landet, der weiß, dass Sie es einsetzen,
• Zugriffslogs, die länger als ein paar Tage aufbewahrt werden, weil sonst die Frage “war jemand vor dem Update drin” keine Antwort hat.

Sind Sie nicht sicher, ob Ihre Website diese Woche sauber überstanden hat: Ein Sicherheitsaudit für WordPress umfasst genau die Schritte dieser Liste, also Uploads, Konten, Cron, Prüfsummen und Logs.

Zuletzt aktualisiert am 10. Oktober 2026. Quellen: Artikel und Datenbankeintrag von Patchstack (7. und 8. Oktober 2026), Eintrag bei Wordfence Intelligence, NVD-Eintrag zu CVE-2026-85097, Changelog von Bricksforge, DSGVO Art. 33.