Bricksforge RCE sfruttata in wild: exploit automatizzato in ore dal 7 ottobre

Il 7 ottobre 2026 alle 21:47 UTC, appena ore dopo la disclosure pubblica, la telemetria di Patchstack ha registrato i primi exploit attivi contro CVE-2026-85097, vulnerabilità critica nel plugin WordPress Bricksforge. Il record ufficiale CVE assegna un punteggio di 9.8, non il 10.0 rimbalzato tra le testate tecniche. La differenza numerica conta meno della velocità di weaponization: 63 indirizzi IP unici, pattern automatizzati, varianti di estensioni PHP testate in sequenza contro lo stesso bersaglio.

Il plugin, utilizzato per estendere le funzionalità del builder Bricks con moduli di form e logica condizionale, si è trasformato in vettore di esecuzione remota non autenticata. La causa è una violazione del trust boundary: la validazione del MIME type avviene in fase di upload iniziale, ma il percorso finale del file viene derivato da un campo client-controllato.

Come funziona il trust boundary violation

Il flusso di attacco si articola in quattro fasi, entrambe documentate da Patchstack e confermate da Wordfence. L'attaccante ottiene prima un nonce valido tramite l'endpoint bricksforge_regenerate_nonce, quindi carica un file polyglot GIF/PHP nella directory temporanea. A questo stadio la validazione del MIME type è corretta: il file passa come immagine.

Il passaggio critico avviene nella fase di submission del form. Il campo url dentro il parametro temporaryFileUploads non viene ri-validato server-side. L'attaccante può indicare il percorso del file precedentemente caricato — con estensione .gif — ma farlo puntare a un'estensione eseguibile .php, .php5, .php7 o .phtml. Il server scrive il file nel percorso finale usando l'estensione client-controllata.

"Bricksforge validates a file's MIME type when it is first uploaded. When a form is later submitted, however, it trusts the file metadata the client sends. In particular, it does not validate the 'url' field inside the 'temporaryFileUploads' parameter."

Secondo Patchstack, circa il 95% delle richieste di exploit osservate presenta questo pattern: path sorgente con estensione immagine (.gif o .png), destinazione con estensione PHP. La coerenza del payload suggerisce codice di exploit condiviso o commoditizzato, non attacchi artigianali.

I numeri dell'automazione: 63 IP e due cluster distinti

La telemetria rivela una campagna strutturata, non sporadici tentativi isolati. Patchstack ha identificato 63 IP unici, con 6 indirizzi che concentrano circa il 46% delle richieste totali. Due pattern di automazione emergono con chiarezza dal traffico analizzato.

Nel primo cluster, 44 IP hanno inviato 56 richieste con payload identici in lassi di tempo misurati in secondi. Nel secondo, 3 IP hanno testato 25 varianti di estensioni e codifiche URL contro lo stesso file temporaneo — inclusa manipolazione del case e doppio encoding. Entrambi i pattern, osserva Patchstack, indicano "automated exploitation over rotating proxies or distributed infrastructure" e non consentono, da soli, di attribuire l'attività a un singolo threat actor.

Le tecniche di evasione osservate includono estensioni alternative (.php5, .php7, .phtml), variazione del case delle estensioni, e encoding URL singolo o doppio. Gli endpoint bersaglio sono /wp-json/bricksforge/v1/form_submit e /wp-admin/admin-ajax.php con action bricksforge_form_submit.

Il CVSS 9.8 ufficiale contro il 10.0 delle headline

Una discrepanza numerica attraversa le prime segnalazioni. The Hacker News e blog.netmanageit.com riportano entrambi CVSS 10.0 per CVE-2026-85097. Il record ufficiale su cve.org indica invece 9.8, con vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H e classificazione CWE-434 (Unrestricted Upload of File with Dangerous Type).

La differenza non è semantica. Un 10.0 richiederebbe nessuna interazione utente, nessun privilegio, accesso di rete, impatto completo su tutte le dimensioni della triade CIA — condizioni che il vettore 9.8 soddisfa quasi interamente, con l'eccezione dello scope unchanged (S:U). La mediazione del punteggio da parte delle testate editoriali rischia di erodere la capacità dei difensori di calibrare le priorità: quando ogni vulnerabilità è "massima", nessuna lo è davvero.

Cosa fare adesso

Gli amministratori di siti WordPress con Bricksforge installato devono verificare la versione attiva. Il vendor ha rilasciato la versione 3.1.8.10 che chiude la vulnerabilità; è disponibile anche la versione 4.0.1. Il dossier non specifica se 4.0.1 introduca correzioni aggiuntive oltre quella applicata in 3.1.8.10.

Per i sistemi dove l'aggiornamento immediato non è applicabile, è necessario analizzare i log di accesso alle due route documentate — REST API e admin-ajax — con particolare attenzione a parametri temporaryFileUploads con mismatch tra estensione sorgente e destinazione. La telemetria Patchstack indica che la campagna è attiva e in espansione: il margine temporale per il patching si misura in ore, non in giorni.

L'audit dei file presenti nelle directory di upload temporaneo deve includere la ricerca di polyglot con doppia estensione o estensioni PHP non standard (.php5, .php7, .phtml). La persistenza post-exploit — web shell, accessi ricorrenti, movimento laterale — non è quantificata nelle fonti disponibili, ma rappresenta il scenario di rischio plausibile dopo esecuzione di codice arbitrario.

Pattern ricorrente, velocità crescente

Questo caso rientra in una tipologia che il settore security osserva con frequenza crescente: plugin form-builder che delegano al client la specifica del percorso finale, dopo una validazione iniziale che non viene replicata in fase di commitment. La logica di Bricksforge — verifica del MIME in upload, trust del campo URL in submission — non è un'architettura isolata. La commoditizzazione dell'exploit, misurata qui in decine di IP e richieste identiche in secondi, indica che il tempo tra disclosure e weaponizzazione massiccia si è contratto a una scala che le operazioni di patching manuali faticano a sostenere.

La discrepanza sul punteggio CVSS, infine, solleva una questione editoriale e operativa: quando la gravità tecnica viene amplificata in trasmissione, i team di risposta perdono il segnale rumore che serve a triage efficace. Il 9.8 del record ufficiale è già critico. Non aveva bisogno di diventare 10.0 per essere pericoloso.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://thehackernews.com/2026/10/attackers-exploit-cvss-100-bricksforge.html
• https://www.infosecurity-magazine.com/news/critical-cisco-catalyst-sdwan/
• https://www.darkreading.com/application-security/unsloth-studio-flaw-model-inspection-code-execution
• https://blog.netmanageit.com/attackers-exploit-cvss-10-0-bricksforge-wordpress-flaw-enabling-unauthenticated-rce/
• https://patchstack.com/articles/critical-unauthenticated-arbitrary-file-upload-vulnerability-exploited-in-bricksforge-plugin/
• https://www.cve.org/CVERecord?id=CVE-2026-76460
• https://www.cve.org/CVERecord?id=CVE-2026-85097
• https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-webauth-xr8beuuU
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog