Bricksforge, nginx und die SCHUFA-Revisionen: drei Meldungen der Woche für Betreiber

Am 7. Oktober 2026, abends um 21:47 Uhr UTC, sah der Sicherheitsanbieter Patchstack nach eigenen Angaben den ersten Angriff auf ein WordPress-Plugin namens Bricksforge. Insgesamt zählte der Anbieter 63 verschiedene IP-Adressen. Drei Meldungen sollten Sie als Betreiber einer Website kennen: diese Plugin-Lücke, einen Fehler im Webserver nginx und ein Urteil des Bundesgerichtshofs zur SCHUFA.

1. Bricksforge: Dateien hochladen ohne Anmeldung (CVE-2026-85097)

Was ist passiert?

Bricksforge ist ein Zusatz für den WordPress-Seitenbaukasten Bricks. In älteren Versionen kann ein Angreifer ohne Anmeldung beliebige Dateien auf den Server laden. Lädt er eine PHP-Datei hoch und ruft sie auf, läuft sein Code auf Ihrem Server. Die Fehlernummer lautet CVE-2026-85097. Streng genommen ist das keine „Codeausführung per Fernzugriff“ in einem Schritt, sondern ein Upload, der danach die Ausführung möglich macht. Für Sie macht das praktisch keinen Unterschied.

Die Schwachstelle liegt im Parameter temporaryFileUploads, genauer in dessen Feld url. Laut Patchstack holt sich der Angreifer zuerst einen Sicherheitsschlüssel von einem Endpunkt, der ohne Anmeldung antwortet, und schickt dann eine Datei hoch.

Die Bewertung: Wordfence, das die Nummer vergeben hat, bewertet mit CVSS 3.1 und 9,8 von 10. Die US-Datenbank NVD hat den Eintrag am 8. Oktober 2026 veröffentlicht und führt die Wertung von Wordfence mit 9,8 von 10 auf (eine eigene Analyse der NVD steht noch aus). Patchstack kommt auf 10,0. Die Anbieter bewerten unterschiedlich, beide Werte liegen in der Stufe „kritisch“.

Wer ist betroffen?

Alle Seiten, auf denen Bricksforge in der Version 3.1.8.9 oder älter installiert ist. Wer das Plugin nicht nutzt, ist nicht betroffen. Seiten mit 4.0.0 oder 3.1.8.10 sind von dieser Nummer nicht mehr erfasst. Laut Changelog schließt 4.0.1 aber eine Lücke im Datei-Upload der Pro Forms, die jede Seite mit aktivem Pro Forms betrifft, deshalb empfehlen wir mindestens 4.0.1. Ist es installiert, gehört es aktualisiert oder entfernt.

Wie ist der Stand der Updates?

Laut Patchstack ist die Lücke in Version 3.1.8.10 behoben. Der Changelog des Herstellers nennt 3.1.8.10 nur im Eintrag zu Version 4.0.1, ohne eigenen Eintrag und ohne Datum, und führt dort aus, dass die Lücke bereits in 3.1.8.10 und im 4er-Zweig mit Version 4.0.0 vom 17. September 2026 behoben wurde. Version 4.0.1 vom 8. Oktober 2026 schließt nach Angabe des Herstellers eine Sicherheitslücke im Datei-Upload der Pro Forms. Betroffen ist jede Seite mit aktivem Pro Forms, auch wenn die Formulare keine Upload-Felder haben, ein Update wird ausdrücklich empfohlen. Am 13. Oktober 2026 erschien 4.0.2, die unter anderem Bilder wieder annimmt, die die Prüfung aus 4.0.1 fälschlich abgelehnt hatte, und gespeicherte Zugangsdaten stärker filtert. Aktualisieren Sie deshalb auf 4.0.2 oder neuer, mindestens auf 4.0.1.

Dass die Lücke tatsächlich ausgenutzt wird, stammt aus einer einzigen Quelle: Patchstack selbst. Danach gingen die Angriffe an die Adressen /wp-json/bricksforge/v1/form_submit und admin-ajax.php. Eine unabhängige Bestätigung haben wir nicht gefunden. Der SSVC-Eintrag der US-Behörde CISA in der NVD führt die Ausnutzung (Stand 8. Oktober, bei unserer Prüfung am 25. Oktober 2026 unverändert) mit „none“. Das widerspricht der Patchstack-Meldung nicht zwingend, die Einstufungen stammen aus unterschiedlichen Quellen und Zeitpunkten.

Was Sie tun

Prüfen Sie im WordPress-Backend unter „Plugins“, ob Bricksforge installiert ist und in welcher Version.

Aktualisieren Sie auf Version 4.0.2 oder neuer, mindestens auf 4.0.1. Vorher eine Sicherung ziehen, nachher die Seite testen, denn der Sprung von 3.x auf 4.x ist ein Hauptversionswechsel. (Sicherung und Test: eigene Einschätzung.)
Lassen Sie Anfragen an /wp-json/bricksforge/v1/form_submit und admin-ajax.php im Zugriffsprotokoll prüfen, möglichst weiter zurück als bis zum 7. Oktober. Ob der Parameter temporaryFileUploads im Anfragekörper stand, zeigt ein übliches Zugriffsprotokoll meist nicht. Das klären Sie mit dem Hoster oder einer Firewall, die auch den Körper protokolliert. Kein Treffer im Protokoll ist keine Entwarnung. (Eigene Einschätzung, nicht Inhalt der Quellen.)
Lassen Sie mindestens das Verzeichnis /wp-content/uploads/bricksforge/tmp/ auf PHP-Dateien durchsehen, besser den ganzen Ordner wp-content/uploads (auch auf Endungen wie .php5 oder .phtml). Unerwartete PHP-Dateien sind ein Warnzeichen. Ein Fund wird nicht selbst gelöscht, sondern erst gesichert und dokumentiert. Können dadurch personenbezogene Daten betroffen sein, läuft die Meldefrist von 72 Stunden nach Art. 33 DSGVO. (Eigene Einschätzung.)
Laut Changelog zu 4.0.2 werden im Plugin gespeicherte Zugangsdaten nun stärker gefiltert. Wer dort API-Schlüssel hinterlegt hat, soll sie vorsorglich bei den Anbietern erneuern. Das gilt erst recht, wenn Sie nicht ausschließen können, dass die Lücke vor dem Update ausgenutzt wurde. Erst Seite bereinigen und aktualisieren, dann die Schlüssel erneuern, sonst landet der neue Schlüssel wieder in einer möglicherweise kompromittierten Umgebung. (Reihenfolge: eigene Einschätzung.)

2. nginx: Speicherfehler bei alias und rewrite (CVE-2026-15176)

Kurzer Einschub: Die Einstufung dieser Lücke fällt je nach Quelle sehr unterschiedlich aus. Am 14. Oktober 2026 hat das nginx-Projekt die Versionen 1.31.7 (Mainline) und 1.30.6 (Stable) veröffentlicht. 1.31.7 schließt insgesamt fünf Sicherheitsfehler. Einer davon ist CVE-2026-15176, ein Überlauf im Speicher eines Arbeitsprozesses.

Was ist passiert?

Der Fehler tritt auf, wenn die Konfiguration mehrere Dinge zugleich enthält: einen location-Block mit alias, ein rewrite, das die Adresse ändert, und die Variable $request_filename in einer der Anweisungen set oder return oder im Log-Format. Dann reicht eine präparierte Anfrage ohne Anmeldung. Die Folge ist in der Regel, dass der Arbeitsprozess abstürzt und neu startet (Dienst kurz gestört). Fremden Code auszuführen ist laut NVD nur möglich, wenn der Speicherschutz ASLR deaktiviert oder umgangen ist. Das ist nach unserer Einschätzung auf gängigen Servern eher die Ausnahme.

Die Einstufung ist uneinheitlich. Im NVD-Eintrag (Wertung durch den Hersteller F5) stehen CVSS 3.1 mit 8,1 und CVSS 4.0 mit 9,2. Das nginx-Projekt selbst stuft den Fehler als „Medium“ ein. Eine mögliche Erklärung sind unterschiedliche Maßstäbe.

Wer ist betroffen?

Betroffen sind laut nginx.org die Versionen 0.1.29 bis 1.31.6. Gefixt sind 1.31.7 und 1.30.6, in der Stable-Reihe sind also die Versionen bis 1.30.5 betroffen. Das gilt nur bei der Kombination aus der Konfiguration oben. Auch NGINX Plus ist laut NVD betroffen, die Fixstände dazu haben wir nicht geprüft, sie erfragen Sie beim Hersteller. Wir gehen davon aus, dass viele Installationen die Kombination nie enthalten. Wer nur Webspace mietet, kann die Konfiguration meist nicht selbst ändern, dann ist der Hoster am Zug. Wer einen eigenen Server oder einen Docker-Container mit nginx betreibt, sollte nachsehen.

Hinweis: Linux-Distributionen übernehmen Sicherheitskorrekturen oft in ältere Versionen, ohne die Nummer zu ändern. Dass bei Ihnen „1.24“ steht, heißt deshalb nicht automatisch „nicht gefixt“. Ob Ihr Paket den Fix enthält, steht im Sicherheitsverzeichnis der Distribution. Das haben wir nicht für einzelne Distributionen geprüft.

Was Sie tun

Eigener Server: auf 1.31.7 oder 1.30.6 oder neuer aktualisieren. Wer nicht sofort kann, sucht in der Konfiguration nach der Kombination aus alias, rewrite und $request_filename, auch in eingebundenen Dateien (nginx -T zeigt die gesamte wirksame Konfiguration). Das ist eine Prüfung, kein Schutz: Workarounds nennt nginx.org nicht.
Webspace beim Hoster: nachfragen, ob nginx dort eingesetzt wird und ob der Fix eingespielt ist.

3. BGH zur SCHUFA: Revisionen erfolgreich, Beweiserleichterung für Betroffene

Am 21. Oktober 2026 hat der Bundesgerichtshof in vier Verfahren (I ZR 227/25 bis I ZR 230/25) über Klagen von Privatpersonen gegen die SCHUFA entschieden. Es ging um Auskunft über die Berechnung der Scorewerte und um die Erstattung außergerichtlicher Rechtsanwaltskosten. Das betrifft Sie als Website-Betreiber, wenn Ihr Shop Bonitätsauskünfte einholt, etwa für den Kauf auf Rechnung. Die Landgerichte Chemnitz, Leipzig und Görlitz hatten die Auskunftsanträge abgewiesen. Das Oberlandesgericht Dresden hatte am 7. Oktober 2025 teilweise Auskunft und die Erstattung außergerichtlicher Kosten zugesprochen.

Der BGH hat den Revisionen der SCHUFA stattgegeben, die Berufungsurteile in diesem Punkt aufgehoben und die Sachen an das OLG Dresden zurückverwiesen. Einen Auskunftsanspruch aus Art. 15 Abs. 1 Buchst. h DSGVO (Information über die Logik hinter automatisierten Entscheidungen) gibt es danach nur, wenn alle Voraussetzungen von Art. 22 Abs. 1 DSGVO erfüllt sind. Das folgt der Linie des Europäischen Gerichtshofs, der in der Rechtssache C-634/21 (Urteil vom 7. Dezember 2023) die Berechnung eines Scorewerts unter Umständen als automatisierte Entscheidung ansieht.

Zwei Punkte aus der Pressemitteilung (Nr. 198/2026) sind für die Praxis wichtig:

Ein Scorewert kann eine automatisierte Entscheidung sein, wenn die Entscheidung eines Dritten (unsere Beispiele: ein Vermieter, eine Bank oder ein Händler) maßgeblich davon abhängt. Ob die Betroffenen dadurch erheblich beeinträchtigt wurden, hat der BGH mangels Feststellungen nicht beurteilt.
Die Betroffenen müssen darlegen und beweisen, dass die Entscheidung des Dritten maßgeblich auf dem Score beruht. Dafür gibt es nach der Pressemitteilung erhebliche Erleichterungen. Es genügt vorzutragen, dass der Score übermittelt wurde und danach eine nachteilige Entscheidung folgte. Dann besteht eine tatsächliche Vermutung dafür, dass sie auf dem Score beruhte.

Wie sich das für Betroffene auswirkt, entscheidet nun das OLG Dresden. Zu den vier Entscheidungen liegen inzwischen Volltexte als PDF vor (verlinkt auf der Seite der Pressemitteilung). Die Pressemitteilung nennt keine Leitsätze. Wir haben die Volltexte bisher nicht ausgewertet und stützen uns auf die Pressemitteilung.

Was das für Betreiber heißt

Der BGH hat über den Auskunftsanspruch gegen die SCHUFA entschieden, nicht über Pflichten von Unternehmen, die Scorewerte einholen. Folgendes ist unsere Einschätzung und nicht Inhalt der Entscheidung: Für solche Unternehmen kann die Frage wichtig sein, ob eine Entscheidung ausschließlich automatisiert und maßgeblich auf dem Score beruht, denn nur dann greift Art. 22 Abs. 1 DSGVO. Entscheidet bei Ihnen am Ende ein Mensch, ist das möglicherweise anders zu beurteilen. Das ist keine Rechtsberatung. Lassen Sie Ihre Praxis von einer Fachperson für Datenschutzrecht prüfen.

Wen Sie fragen

Bricksforge und andere WordPress-Plugins: Ihr Webdesigner oder die Agentur, die die Seite pflegt.
nginx: Ihr Hoster oder die Person, die den Server betreut.
Scoring und DSGVO: Ihre Datenschutzbeauftragte oder Ihr Anwalt.