CVE-2026-85097 Bricksforge: Cacat Unggah Pro Forms

CVE-2026-85097 memungkinkan permintaan tanpa autentikasi mengeksploitasi ketidaksesuaian antara isi berkas sementara yang telah divalidasi dan metadata tujuan yang dikendalikan klien di Bricksforge Pro Forms. Patchstack melaporkan upaya eksploitasi; perbarui plugin dan periksa situs yang terekspos.^{[1], [2], [3], [4], [5]}

💡 Penjelasan Sederhana (ELI5)

Bayangkan ruang surat yang memeriksa bahwa sebuah paket berisi gambar aman, lalu membolehkan pengirim mengganti label sebelum paket dikirim ke kantor yang membuka label tertentu sebagai program. Bricksforge memeriksa unggahan sementara, tetapi pengiriman formulir berikutnya dapat memberikan nama tujuan lain. Pertahanannya adalah memastikan identitas dan lokasi penyimpanan berkas tetap ditentukan server sepanjang proses.^{[3], [2]}

Konsep Kunci & Istilah

Unggahan sementara: Berkas yang disimpan sementara sebelum pengiriman formulir selesai. Validasi pada tahap ini tidak membuat metadata yang dikirim klien kemudian menjadi tepercaya.^{[2], [3]}
CWE-434: Unggahan tanpa batasan untuk jenis berkas berbahaya: sistem menerima berkas yang dapat ditafsirkan atau dijalankan dengan cara berbahaya.^{[1], [2]}
Batas kepercayaan metadata: Titik ketika aplikasi menentukan apakah nama, URL, tipe MIME, atau jalur berasal dari catatan server tepercaya atau klien yang tidak tepercaya.^{[2], [3]}
Skor CVE dan status eksploitasi: Catatan CVE dari CNA Wordfence memberi CVSS 3.1 sebesar 9.8 dan pengayaan CISA menyatakan eksploitasi tidak tercatat. Patchstack memberi 10.0 serta melaporkan telemetri yang pertama kali diamati pada 7 Oktober 2026. Klaim ini berasal dari sumber berbeda; tidak satu pun membuktikan pencantuman di CISA KEV.^{[1], [2], [3], [4]}
Kode ilustratif: Perbandingan PHP di bawah memodelkan batas validasi secara umum. Ini bukan kode Bricksforge atau rekonstruksi patch-nya; changelog yang dirujuk tidak memublikasikan detail implementasi tersebut.^{[2], [3], [5]}

Pemetaan kerangka kerja

Referensi CWE untuk kelemahan yang dijelaskan dalam panduan ini: CWE-434

Status versi yang dilaporkan dan tindakan operator

Sumber bukti	Keterangan sumber	Tindakan defensif
Catatan CNA Wordfence / CVE	Menjelaskan unggah berkas arbitrer tanpa autentikasi; rentang terdampak yang tercatat berakhir pada 3.1.8.9.	Anggap ini sebagai cakupan yang dicatat CNA, bukan bukti bahwa situs yang telah dipasang aman.
Patchstack (8 Okt 2026)	Melaporkan upaya eksploitasi yang pertama kali diamati pada 7 Oktober dan menyebut 3.1.8.10 sebagai versi yang telah diperbaiki.	Anggap ini sebagai batas perbaikan menurut Patchstack; verifikasi versi plugin yang benar-benar terpasang di setiap situs.
Log perubahan publik Bricksforge	Versi 4.0.1 mencantumkan perbaikan keamanan unggah Pro Forms, tetapi tidak menyebut batas 3.1.8.10.	Jangan menyimpulkan dari log perubahan saja bahwa 4.0.1 adalah versi pertama yang diperbaiki atau versi 3.x tertentu sudah aman.
Situs terbuka ke publik atau diduga disusupi	Sumber melaporkan upaya eksploitasi, bukan bukti bahwa setiap situs sasaran berhasil disusupi.	Perbarui ke versi yang masih didukung; periksa log unggah dan server web serta selidiki berkas tak terduga sebelum menyatakan pemulihan selesai.

Kronologi Insiden

2026-10-07

Wordfence mencantumkan 7 Oktober sebagai tanggal publikasi advisori. Patchstack menyatakan telemetrinya pertama kali mengamati percobaan pada hari itu pukul 21:47 UTC; publikasi advisori dan pengamatan telemetri adalah peristiwa terpisah.^{[2], [3]}

2026-10-08

Catatan CVE mencantumkan datePublished 8 Oktober, satu hari setelah tanggal publikasi publik Wordfence, 7 Oktober. Laporan kampanye Patchstack juga mencantumkan tanggal terbit 8 Oktober; ini adalah tanggal dari catatan dan publikasi yang berbeda.^{[1], [2], [3]}

2026-10-08

Analisis Patchstack tanggal 8 Oktober menjelaskan ketidaksesuaian validasi dan percobaan yang diamati, serta menyebut 3.1.8.10 sebagai versi yang telah diperbaiki. Changelog Bricksforge secara terpisah mencantumkan perbaikan keamanan unggahan Pro Forms di 4.0.1, tetapi tidak menetapkan batas versi perbaikan 3.x secara tepat.^{[3], [4], [5]}

Alur Serangan Langkah demi Langkah

Langkah 1

Berkas sementara lolos pemeriksaan awal

CNA menjelaskan unggahan sementara sebelumnya yang lolos validasi MIME. Kelulusan ini tidak memberi izin untuk mengubah nama atau tujuan berkas secara bebas setelahnya.^{[2], [1]}

Langkah 2

Pengiriman formulir memberikan metadata terpisah

Patchstack melaporkan bahwa pemrosesan berikutnya memercayai metadata temporaryFileUploads dari klien, termasuk URL yang dapat berbeda dari berkas yang telah divalidasi. Cacatnya adalah isi yang diperiksa dan metadata tujuan yang tidak diperiksa memiliki tingkat kepercayaan berbeda.^{[2], [3]}

Langkah 3

Berkas ditempatkan dengan nama berbahaya

Jika server memakai tujuan yang dikendalikan klien saat menyelesaikan unggahan dan lokasi itu mengizinkan eksekusi, ekstensi berbahaya dapat membuat server menafsirkan berkas tersebut. Penjelasan ini hanya tingkat tinggi; format permintaan dan payload tidak diperlukan.^{[2], [3]}

Langkah 4

Situs yang terekspos dapat mengalami kompromi server

CNA menyatakan masalah ini dapat memungkinkan eksekusi PHP arbitrer. Patchstack melaporkan upaya dan menyarankan pembaruan. Pengamatan tersebut tidak membuktikan semua situs sasaran telah dikompromikan atau mengidentifikasi pelaku.^{[2], [3]}

Kode Sumber: Rentan vs Aman

Contoh umum ini menunjukkan identitas unggahan yang dikelola server, pencarian berdasarkan pengguna, pemeriksaan ulang tipe konten, nama berkas yang dibuat server, dan penyimpanan privat. Ini bukan kode Bricksforge maupun patch sebenarnya. Kode produksi juga harus menerapkan batas ukuran, izin aman, transisi status atomik, dan cara penyajian sesuai konteks; situs terdampak perlu memperbarui Bricksforge ke versi perbaikan yang didukung vendor.^{[2], [3]}

IMPLEMENTASI RENTAN

function finalize_upload( array $item, string $stagedPath, string $uploadDir ): string {
    // Metadata klien menentukan nama akhir setelah pemeriksaan MIME sebelumnya.
    $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;
}

PERBAIKAN AMAN & KUAT

function finalize_upload( string $uploadId, UploadRegistry $registry, string $privateDir ): string {
    // Tentukan pemilik dan path dari catatan sisi server, jangan dari URL klien.
    $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;
}

Daftar Periksa Penguatan Sistem Rekayasa

✓Inventarisasi versi Bricksforge di produksi, staging, dan situs pelanggan yang dikelola; perbarui instalasi terdampak ke versi terbaru yang didukung vendor. Patchstack menyebut 3.1.8.10 sebagai versi perbaikan, sedangkan changelog vendor mencatat perbaikan di 4.0.1 tanpa menyebut batas tepat untuk lini 3.x.^{[1], [2], [3], [4], [5]}
✓Panduan operasional FlawOpen: Saat menyelesaikan unggahan, anggap semua nama, URL, jalur, dan label MIME dari klien tidak tepercaya; buat nama dan jalur penyimpanan dari catatan server serta daftar izin berdasarkan konten yang diperiksa.
✓Panduan operasional FlawOpen: Simpan unggahan di luar akar web yang dapat mengeksekusi berkas bila memungkinkan; jika tidak, konfigurasi server web agar menolak eksekusi skrip di semua direktori unggahan dan unggahan sementara.
✓Panduan operasional FlawOpen: Ikat setiap catatan unggahan tertunda ke sesi formulir yang membuatnya, batasi penggunaan satu kali, dan tolak ID yang hilang, kedaluwarsa, diputar ulang, atau tidak cocok.
✓Panduan operasional FlawOpen: Jika situs rentan pernah terbuka untuk publik, periksa log web dan aplikasi untuk aktivitas unggahan yang tidak biasa serta berkas baru di lokasi unggahan; simpan bukti dan ikuti prosedur respons insiden penyedia hosting sebelum pembersihan.
✓Panduan operasional FlawOpen: Tambahkan uji regresi untuk metadata yang tidak cocok, konten terlarang, ID lintas sesi, ID kedaluwarsa, dan ID yang digunakan ulang; pastikan semuanya ditolak dan tidak ada berkas yang ditulis ke lokasi yang dapat dieksekusi.