FlawOpen

flawopen.com/Incidents/bricksforge-pro-forms-upload-metadata-october-2026

● Bricksforge WordPress plugin · CVE-2026-85097 · 2026-10-07 · CVSS 9.8 · Kritisch
Sicherheitsforschung · FlawOpen

CVE-2026-85097 in Bricksforge: Uploadfehler in Pro Forms

CVE-2026-85097 ermöglichte nicht authentifizierten Anfragen, die Abweichung zwischen geprüften temporären Dateiinhalten und clientgesteuerten Zielmetadaten in Bricksforge Pro Forms auszunutzen. Patchstack meldet Ausnutzungsversuche; aktualisieren Sie das Plugin und untersuchen Sie exponierte Websites.[1], [2], [3], [4], [5]

💡 Einfache Erklärung (ELI5)

Stellen Sie sich eine Poststelle vor, die prüft, ob ein Paket ein harmloses Bild enthält, und dann dem Absender erlaubt, das Etikett zu ändern, bevor das Paket in ein Büro gelangt, das bestimmte Etiketten als Programme öffnet. Bricksforge prüfte den temporären Upload, doch die spätere Formularübermittlung konnte einen anderen Zielnamen angeben. Die Abwehr besteht darin, Dateiidentität und Ziel während der gesamten Speicherung serverseitig festzulegen.[3], [2]

Kernkonzepte & Begriffe

Temporärer Upload
Eine Datei, die zwischengespeichert wird, bevor eine Formularübermittlung abgeschlossen ist. Die Prüfung in diesem Schritt macht spätere clientseitige Metadaten nicht vertrauenswürdig.[2], [3]
CWE-434
Uneingeschränktes Hochladen eines gefährlichen Dateityps: Das System akzeptiert eine Datei, die gefährlich interpretiert oder ausgeführt werden kann.[1], [2]
Vertrauensgrenze für Metadaten
Der Punkt, an dem eine Anwendung entscheidet, ob Name, URL, MIME-Typ oder Pfad aus einem vertrauenswürdigen Serverdatensatz oder von einem nicht vertrauenswürdigen Client stammt.[2], [3]
CVE-Bewertung und Ausnutzung
Der CVE-Eintrag der Wordfence-CNA vergibt CVSS 3.1 9.8; die CISA-Anreicherung meldet keine Ausnutzung. Patchstack vergibt 10.0 und berichtet Telemetrie seit dem 7. Oktober 2026. Die Angaben sind getrennt zuzuordnen; keine davon bestätigt eine Aufnahme in CISA KEV.[1], [2], [3], [4]
Beispielcode
Der PHP-Vergleich modelliert die Validierungsgrenze allgemein. Er ist weder Bricksforge-Quellcode noch eine Rekonstruktion des Patches; das zitierte Änderungsprotokoll veröffentlicht diese Details nicht.[2], [3], [5]

Framework-Zuordnungen

  • CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-434

Gemeldeter Versionsstand und Maßnahmen

BelegquelleAussageAbwehrmaßnahme
Wordfence-CNA-/CVE-EintragBeschreibt einen nicht authentifizierten Upload beliebiger Dateien; der eingetragene betroffene Bereich endet bei 3.1.8.9.Als von der CNA dokumentierten Umfang behandeln, nicht als Beleg für ein sauberes System.
Patchstack (8. Okt. 2026)Meldet erstmals am 7. Oktober beobachtete Ausnutzungsversuche und nennt 3.1.8.10 als behoben.Als von Patchstack genannte Fehlerbehebungsgrenze behandeln; die tatsächlich installierte Plugin-Version auf jeder Website prüfen.
Öffentliches Bricksforge-ÄnderungsprotokollVersion 4.0.1 nennt eine Sicherheitskorrektur für Pro-Forms-Uploads, aber nicht die Grenze 3.1.8.10.Aus dem Änderungsprotokoll allein weder 4.0.1 als erste behobene Version noch eine bestimmte 3.x-Version als sicher ableiten.
Erreichbare Website oder Verdacht auf KompromittierungDie Quellen berichten von Ausnutzungsversuchen, nicht von einer bestätigten Kompromittierung jeder angegriffenen Website.Auf eine aktuell unterstützte Version aktualisieren; Upload- und Webserverprotokolle prüfen und unerwartete Dateien untersuchen, bevor die Wiederherstellung als abgeschlossen gilt.

Vorfall-Zeitstrahl

2026-10-07

Wordfence nennt den 7. Oktober als Datum der öffentlichen Veröffentlichung des Hinweises. Patchstack zufolge beobachtete die Telemetrie an diesem Tag um 21:47 UTC erstmals Angriffsversuche; Veröffentlichung des Hinweises und Telemetriebeobachtung sind getrennte Ereignisse.[2], [3]

2026-10-08

Der CVE-Datensatz nennt den 8. Oktober als datePublished, einen Tag nach dem von Wordfence genannten Datum der öffentlichen Veröffentlichung am 7. Oktober. Auch Patchstacks Kampagnenbericht trägt das Veröffentlichungsdatum 8. Oktober; es handelt sich um Daten verschiedener Datensätze und Veröffentlichungen.[1], [2], [3]

2026-10-08

Patchstacks Analyse vom 8. Oktober beschreibt die Abweichung bei der Validierung und die gemeldeten Versuche und nennt 3.1.8.10 als gepatcht. Das Changelog von Bricksforge führt separat eine Sicherheitskorrektur für Pro-Forms-Uploads in 4.0.1 auf, legt aber die genaue korrigierte 3.x-Version nicht fest.[3], [4], [5]

Schritt-für-Schritt Angriffsablauf

Schritt 1

Eine temporäre Datei besteht eine erste Prüfung

Die CNA beschreibt einen vorherigen temporären Upload, der die MIME-Prüfung besteht. Dadurch sind spätere beliebige Änderungen an Dateiname oder Ziel nicht autorisiert.[2], [1]

Schritt 2

Die Formularübermittlung liefert andere Metadaten

Laut Patchstack vertraute die spätere Verarbeitung vom Client gesendeten temporaryFileUploads-Metadaten, darunter einer URL, die nicht zur bereits geprüften Datei passen musste. Geprüfter Inhalt und ungeprüfte Zielmetadaten bildeten unterschiedliche Vertrauensgrenzen.[2], [3]

Schritt 3

Die Datei erhält einen gefährlichen Namen

Verwendet der Server dieses clientgesteuerte Ziel zum Abschließen des Uploads, kann eine gefährliche Erweiterung serverseitige Interpretation auslösen, wenn das Ziel ausführbar ist. Diese Beschreibung bleibt auf hoher Ebene; Anfrageformat und Payload sind dafür nicht erforderlich.[2], [3]

Schritt 4

Die Exposition kann den Server gefährden

Die CNA erklärt, dass das Problem beliebige PHP-Ausführung ermöglichen kann. Patchstack berichtet über Versuche und empfiehlt ein Update. Das beweist weder eine Kompromittierung jeder betroffenen Website noch die Identität eines Angreifers.[2], [3]

Quellcode: Verwundbar vs. Sicher

Dieses allgemeine Beispiel zeigt eine serverseitig verwaltete Upload-ID, benutzergebundene Suche, erneute Prüfung des Inhaltstyps, generierte Dateinamen und private Speicherung. Es ist weder Bricksforge-Code noch dessen tatsächlicher Patch. Produktivcode muss zusätzlich Größenlimits, sichere Berechtigungen, atomare Zustandswechsel und kontextgerechte Auslieferung erzwingen; betroffene Websites sollten Bricksforge auf eine unterstützte, korrigierte Version aktualisieren.[2], [3]

VERWUNDBARE IMPLEMENTIERUNG
function finalize_upload( array $item, string $stagedPath, string $uploadDir ): string {
    // Clientmetadaten bestimmen nach einer vorherigen MIME-Prüfung den endgültigen Namen.
    $name = basename( (string) parse_url( $item['file']['url'], PHP_URL_PATH ) );
    $destination = $uploadDir . DIRECTORY_SEPARATOR . $name;
    if ( ! rename( $stagedPath, $destination ) ) {
        throw new RuntimeException( 'Could not finalize upload' );
    }
    return $destination;
}
GEHÄRTETER SICHERHEITS-PATCH
function finalize_upload( string $uploadId, UploadRegistry $registry, string $privateDir ): string {
    // Ermitteln Sie Eigentümer und Pfad anhand eines serverseitigen Datensatzes, niemals anhand einer Client-URL.
    $upload = $registry->findPendingForCurrentUser( $uploadId );
    if ( $upload === null || ! is_file( $upload->path ) ) {
        throw new RuntimeException( 'Unknown pending upload' );
    }
    $types = [ 'image/jpeg' => 'jpg', 'image/png' => 'png' ];
    $mime = ( new finfo( FILEINFO_MIME_TYPE ) )->file( $upload->path );
    if ( ! isset( $types[ $mime ] ) ) {
        throw new RuntimeException( 'Unsupported file type' );
    }
    $destination = $privateDir . DIRECTORY_SEPARATOR . bin2hex( random_bytes( 16 ) ) . '.' . $types[ $mime ];
    if ( ! rename( $upload->path, $destination ) ) {
        throw new RuntimeException( 'Could not finalize upload' );
    }
    $registry->markConsumed( $uploadId );
    return $destination;
}

Checkliste für Engineering & Systemsicherheit

Quellen