Una falla nel caricamento dei file su WordPress consente agli aggressori di inserire file eseguibili
Secondo Patchstack, i siti WordPress che utilizzano versioni vulnerabili di Bricksforge sono bersaglio di tentativi in corso di trasformare le immagini caricate in file eseguibili. Il suo avviso dell’8 ottobre 2026 identifica CVE-2026-85097, una falla che non richiede all’aggressore di effettuare l’accesso e può consentire l’esecuzione di codice da remoto (RCE), permettendo a un soggetto esterno di eseguire istruzioni sul server del sito web. I proprietari dei siti dovrebbero aggiornare a Bricksforge 3.1.8.10 o a una versione successiva.
Sono interessate tutte le versioni fino alla 3.1.8.9 inclusa. Patchstack assegna alla vulnerabilità un punteggio Common Vulnerability Scoring System (CVSS) di 10,0, il massimo livello di gravità, e registra il primo tentativo di sfruttamento osservato il 7 ottobre 2026 alle 21:47:17 UTC. Il suo avviso rimanda al registro delle modifiche di Bricksforge per le informazioni del produttore sull’aggiornamento. L’attività segnalata dimostra che gli aggressori stanno cercando di sfruttare la falla, ma l’avviso non indica quanti siti web siano stati effettivamente compromessi.
Bricksforge amplia le funzionalità di Bricks Builder, uno strumento visuale per creare siti web WordPress. Le sue funzionalità comprendono moduli avanzati, animazioni, interazioni personalizzate, gestione dei dati dinamici e personalizzazione dell’area di amministrazione. La debolezza risiede nel modo in cui i suoi moduli gestiscono i file caricati; per sfruttarla, un aggressore non deve procurarsi un account WordPress.
Come un’immagine diventa eseguibile
Il plugin controlla inizialmente il tipo MIME di un file, un’etichetta che ne descrive il formato del contenuto. Tuttavia, quando viene successivamente inviato un modulo, si fida dei metadati, i campi descrittivi forniti insieme al file, provenienti dal browser del visitatore. In particolare, non convalida il campo url all’interno di temporaryFileUploads. Questo consente agli aggressori di fornire un’immagine come sorgente, specificando al contempo una destinazione con un’estensione PHP, il linguaggio di programmazione utilizzato da WordPress.
Patchstack descrive una catena in quattro fasi. Innanzitutto, un aggressore ottiene un nonce valido, un token per la convalida delle richieste, tramite bricksforge_regenerate_nonce. Questo endpoint AJAX, che gestisce le richieste in background del browser, è accessibile senza effettuare l’accesso. Successivamente, l’aggressore carica un file poliglotta GIF/PHP, un unico file che è sia un’immagine valida sia un contenitore di codice PHP. Il file supera il controllo iniziale sul tipo di contenuto e viene inserito nella cartella dei caricamenti temporanei. L’aggressore invia quindi un modulo che fa riferimento all’immagine accettata, ma fornisce un url che termina con un’estensione PHP. Bricksforge utilizza i metadati non attendibili per collocare il contenuto nella destinazione PHP. Una richiesta a quel file induce il server a eseguire il codice che contiene.
Patchstack identifica bricksforge/includes/elements/pro-forms/actions/init.php come il punto in cui i metadati temporaryFileUploads entrano nell’elaborazione, e bricksforge/includes/elements/pro-forms/actions/base.php come il punto del codice che successivamente permette caricamenti arbitrari. Lo sfruttamento riuscito può consentire l’installazione di web shell, script per controllare da remoto un sito web compromesso, oltre a modifiche dei contenuti, accesso a dati sensibili e accesso persistente da parte degli aggressori.
Cosa contengono le richieste di attacco
Tutti i tentativi registrati da Patchstack tranne uno utilizzavano richieste POST, che inviano dati a un sito web, dirette a /wp-json/bricksforge/v1/form_submit. Si tratta dell’endpoint REST API del plugin per l’invio dei moduli, un indirizzo web che accetta richieste strutturate. L’altra richiesta era diretta a /wp-admin/admin-ajax.php con l’azione bricksforge_form_submit. Ogni richiesta conteneva un parametro temporaryFileUploads appositamente manipolato.
Il segnale d’allarme importante è una discrepanza tra il percorso del file sorgente e l’URL, o indirizzo web, di destinazione. Nell’esempio normalizzato di Patchstack, il valore di field è form-field-file, il valore di file.file punta a /var/www/example.com/wp-content/uploads/bricksforge/tmp/img_example.gif, file.url punta al corrispondente indirizzo web img_example.php e file.type è image/gif. Si tratta di valori illustrativi, non dell’indirizzo di una vittima segnalata. Nel 95% delle richieste acquisite, il percorso sul server terminava con .gif o .png; nella maggior parte di questi casi era abbinato a una destinazione associata a PHP.
La maggior parte dei tentativi faceva riferimento a /wp-content/uploads/bricksforge/tmp/. Altri cercavano di inserire file eseguibili nelle normali cartelle di caricamento di WordPress, tra cui /wp-content/uploads/2026/10/, utilizzando nomi corrispondenti a login_admin_*.php, dove l’asterisco rappresenta una parte variabile del nome.
Patchstack ha osservato diversi tentativi di aggirare il filtro sulle estensioni dei file. I suffissi inviati comprendevano .php, .php5, .php7, .php8, .phtml, .pht, .phtm e .phps. Le varianti con lettere maiuscole e minuscole comprendevano .PHP, .Php, .pHp e .PHTML. Gli aggressori hanno inoltre utilizzato la codifica URL, che rappresenta i caratteri con sequenze speciali, e la doppia codifica, che applica tale trasformazione due volte: gli esempi comprendevano %2ephp, .%70hp e .%2570%2568%2570. Altre richieste modificavano o omettevano i campi path, name, originalFilename e url per verificare come venissero elaborati dal plugin.
Attività distribuita, ma nessuna attribuzione confermata
Il monitoraggio di Patchstack ha rilevato un gruppo di 44 indirizzi IP che ha inviato 56 richieste identiche nell’arco di pochi secondi, e un altro in cui tre indirizzi hanno provato 25 varianti di estensione PHP e codifica sullo stesso file temporaneo. Gli indirizzi IP identificano le connessioni di rete. Questi schemi suggeriscono attacchi automatizzati che utilizzano proxy a rotazione, connessioni intermediarie che cambiano la sorgente apparente, oppure un’infrastruttura distribuita. Non dimostrano che l’attività sia controllata da un unico aggressore.
Gli indirizzi IP sorgente unici erano 63, e i sei più attivi rappresentavano circa il 46% delle richieste. Patchstack elenca 177.75.57.20 su EXPLORERNET, un fornitore brasiliano di accesso a Internet su rete fissa, con 8 segnalazioni su AbuseIPDB e nessuna presenza nella lista di blocco di CleanTalk; 23.97.62.146 su Microsoft Azure con oltre 1.270 segnalazioni e nessuna presenza nella lista; 84.247.60.125 su HostRoyale con 12 segnalazioni e presenza nella lista; 38.154.185.97 su B2 Net Solutions con 11 segnalazioni e presenza nella lista; 150.109.16.166 su Tencent con 185 segnalazioni e presenza nella lista; e 153.75.90.146 su Cloudzy con 35 segnalazioni e presenza nella lista. Questi sono i controlli di reputazione riportati nell’avviso, non rilevazioni indipendenti aggiornate.
Le sorgenti comprendono data center, servizi cloud, reti private virtuali (VPN), che instradano il traffico attraverso un’altra connessione, servizi proxy e connessioni residenziali o su rete fissa. L’indirizzo più attivo, 177.75.57.20, si distingueva perché apparteneva a un fornitore di connessioni su rete fissa anziché a un data center e aveva pochi precedenti di abuso registrati.
Aggiornare, poi verificare eventuali intrusioni precedenti
Installate la versione corretta e chiedete a chi si occupa della manutenzione del sito di esaminare i registri delle richieste web e dell’applicazione. Tra i segnali rilevanti figurano richieste form_submit contenenti temporaryFileUploads, percorsi di immagini abbinati a destinazioni PHP, chiamate per la generazione di nonce seguite da caricamenti e invii di moduli, e modifiche ripetute alle estensioni o all’uso di maiuscole e minuscole. Controllate le cartelle di caricamento alla ricerca di file PHP inattesi, in particolare login_admin_*.php, e di richieste che accedono a file eseguibili appena creati. Anche i siti che in precedenza utilizzavano versioni vulnerabili senza protezione richiedono controlli retrospettivi per individuare attività insolite e modifiche non autorizzate.