Eine kritische Sicherheitslücke im WordPress-Plugin Bricksforge wird aktiv ausgenutzt. Über CVE-2026-85097 können nicht angemeldete Angreifer beliebigen PHP-Code auf dem Server platzieren und ausführen. Das kann bis zur vollständigen Übernahme einer Website, zum Auslesen von Daten und zur Installation dauerhaft erreichbarer Webshells führen.
Betroffen sind Bricksforge-Versionen bis einschließlich 3.1.8.9. Eine Korrektur erschien zunächst mit Version 3.1.8.10; Betreiber sollen nach den vorliegenden Sicherheitshinweisen auf die aktuelle Version 4.0.1 aktualisieren. Patchstack registrierte erste Ausnutzungsversuche am 7. Oktober 2026 um 21:47 Uhr UTC.
Die Einschränkung ist wichtig: Die Lücke betrifft nicht WordPress allgemein, sondern Websites, auf denen eine verwundbare Bricksforge-Version eingesetzt wird. Dort ist die Gefährdung allerdings hoch, weil weder ein Benutzerkonto noch Administratorrechte erforderlich sind. Ein für den Angriff benötigter Nonce lässt sich über einen öffentlich erreichbaren AJAX-Endpunkt beschaffen.
Die Upload-Prüfung greift nur im ersten Schritt
Bricksforge erweitert den visuellen WordPress-Builder Bricks unter anderem um Formulare, Animationen und weitere Funktionen. Die Schwachstelle steckt in der Verarbeitung temporärer Datei-Uploads bei Formularübermittlungen.
Angriffskette bei CVE-2026-85097
Die Grafik zeigt, wie ein öffentlich beschaffter Nonce, ein Bild-PHP-Polyglot und manipulierte Upload-Metadaten zur Ausführung von PHP-Code führen.
Beim ersten Upload prüft das Plugin den MIME-Typ einer Datei. Angreifer können deshalb eine Polyglot-Datei verwenden, die gleichzeitig als gültiges GIF oder PNG erkannt wird und eingebetteten PHP-Code enthält. Diese Datei besteht die vorgesehene Prüfung und landet im temporären Upload-Verzeichnis.
Das eigentliche Problem folgt beim Absenden des Formulars. Bricksforge übernimmt dabei vom Client gelieferte Metadaten aus dem Parameter temporaryFileUploads, ohne das darin enthaltene URL-Feld ausreichend zu validieren. Der serverseitige Dateipfad kann weiterhin auf die zuvor geprüfte Bilddatei zeigen, während die angegebene URL auf eine Datei mit PHP-Endung verweist. Das Plugin vertraut dieser Kombination und legt den Inhalt an einem Ort ab, an dem er als PHP ausgeführt werden kann.
Damit liegt keine simple vollständig ungeprüfte Upload-Funktion vor. Die Sicherheitskontrolle existiert, gilt aber nicht für die gesamte Verarbeitungskette. Die erste Prüfung verliert ihren Wert, weil ein späterer Schritt veränderbare Metadaten des Clients als verlässlich behandelt.
Angriffe laufen über zwei Formular-Endpunkte
Beobachtete Angriffe richteten sich gegen den REST-Endpunkt /wp-json/bricksforge/v1/form_submit sowie gegen /wp-admin/admin-ajax.php mit der Aktion bricksforge_form_submit. Zuvor können Angreifer über den nicht authentifizierten AJAX-Endpunkt bricksforge_regenerate_nonce einen gültigen Nonce anfordern.
Um einfache Filter für Dateiendungen zu umgehen, wurden laut den Sicherheitshinweisen verschiedene Schreibweisen erprobt. Dazu zählen alternative PHP-Endungen wie .php5, .php7 und .phtml, abweichende Groß- und Kleinschreibung wie .PHP sowie URL-kodierte Varianten.
Patchstack erfasste Anfragen von 63 unterschiedlichen Quell-IP-Adressen. Sechs davon verursachten rund 46 Prozent der beobachteten Requests. In einem Cluster schickten 44 IP-Adressen innerhalb weniger Sekunden 56 Anfragen mit identischen Nutzdaten. Ein weiterer Cluster testete über drei IP-Adressen 25 unterschiedliche Endungen und Kodierungen gegen dieselbe temporäre Datei.
Dieses Muster spricht für automatisierte Ausnutzung über rotierende Proxys oder verteilte Infrastruktur. Eine Zuordnung zu einem bestimmten Angreifer lässt sich daraus nicht ableiten. Für Betreiber bedeutet die Automatisierung vor allem, dass eine verwundbare öffentlich erreichbare Installation nicht erst individuell ausgewählt werden muss.
10,0 oder 9,8 ändert die Priorität nicht
Patchstack bewertet CVE-2026-85097 mit dem maximalen CVSS-Wert von 10,0. Wordfence und die NVD führen einen CVSS-v3.1-Basiswert von 9,8. Die Differenz sollte nicht darüber hinwegtäuschen, dass alle Bewertungen die Schwachstelle als kritisch einstufen.
Entscheidender als die Nachkommastelle sind die praktischen Bedingungen: Der Angriff funktioniert ohne Anmeldung, führt zur Ausführung von Servercode und wird nicht nur theoretisch beschrieben, sondern bereits in realen Anfragen beobachtet. Damit ist die Lücke für betroffene Betreiber kein Fall für den nächsten regulären Wartungstermin.
Was Betreiber jetzt kontrollieren sollten
Die vorrangige Maßnahme ist das Update auf Bricksforge 4.0.1. Wer zunächst nur prüft, ob die ursprüngliche Fehlerkorrektur vorhanden ist, muss mindestens Version 3.1.8.10 einsetzen. Die aktuell empfohlene Fassung vermeidet jedoch Unklarheiten über ältere Patch-Stände.
Zusätzlich sollten Webserver-, WordPress- und Sicherheitsprotokolle nach Aufrufen der beiden Formular-Endpunkte durchsucht werden. Besonders relevant sind Requests mit dem Parameter temporaryFileUploads, wiederholte Formularübermittlungen und Varianten kodierter PHP-Endungen. Im Verzeichnis /wp-content/uploads/bricksforge/tmp/ sollten keine unerwarteten PHP-, PHP5-, PHP7- oder PHTML-Dateien liegen.
Ein Update schließt die Lücke für weitere Angriffe, beseitigt aber nicht automatisch Dateien oder Zugänge, die zuvor über eine erfolgreiche Codeausführung angelegt wurden. Bei verdächtigen Funden reicht es deshalb nicht, nur das Plugin zu aktualisieren. Dann sind eine Prüfung des Dateisystems, der installierten Plugins, administrativer Konten und weiterer Persistenzmechanismen sowie gegebenenfalls eine Wiederherstellung aus einem nachweislich sauberen Stand erforderlich.
Der kritische Punkt liegt zwischen zwei Prüfungen
CVE-2026-85097 zeigt ein operatives Problem, das bei Upload-Funktionen leicht übersehen wird: Eine Datei kann beim Eingang korrekt geprüft und später trotzdem unsicher verarbeitet werden. Maßgeblich ist nicht nur, ob eine MIME-Prüfung existiert, sondern ob Pfad, URL, Erweiterung und Inhalt bei jedem sicherheitsrelevanten Verarbeitungsschritt konsistent serverseitig kontrolliert werden.
Für Bricksforge-Betreiber ist diese Unterscheidung inzwischen praktisch statt theoretisch. Die Angreifer setzen genau an der Lücke zwischen der geprüften Bilddatei und den später vertrauten Metadaten an. Deshalb besteht die Arbeit nach dem Update aus zwei getrennten Aufgaben: den verwundbaren Code ersetzen und feststellen, ob die frühere Version bereits zur Codeausführung genutzt wurde.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
