Bricksforge sotto attacco, GoBalance espone chiavi .onion e AWS corregge due falle

🛡️ Executive Summary

• Patchstack osserva sfruttamento attivo di CVE-2026-85097 in Bricksforge: un upload apparentemente valido può diventare codice PHP eseguibile senza autenticazione.
• Searchlight Labs mostra che GoBalance può esporre la chiave master di alcuni servizi .onion partendo da un descriptor pubblico; Tor e Onionbalance originali non sono coinvolti.
• AWS corregge un bypass di autorizzazione in Amplify e la possibile esposizione in chiaro di password IAM nei log di AWS Tools for PowerShell.

Bricksforge, GoBalance e due componenti AWS mostrano quattro modi diversi in cui un controllo di sicurezza può diventare esso stesso il punto di rottura. Nel plugin WordPress il problema nasce dalla fiducia accordata ai metadati di un upload e viene già sfruttato contro siti reali; in GoBalance la gestione della chiave di un servizio .onion può compromettere l’identità pubblica del servizio; in AWS Amplify l’autorizzazione generata nei resolver può esporre record appartenenti ad altri utenti; negli AWS Tools for PowerShell una funzione di conferma può lasciare password IAM nei log. Il denominatore comune non è il punteggio CVSS, ma il confine nel quale un dato considerato innocuo eredita privilegi che non dovrebbe avere.

Bricksforge dimostra quanto poco tempo resta tra disclosure e attacco

Il caso operativo più urgente è Bricksforge, plugin WordPress per Bricks Builder. L’analisi tecnica pubblicata da Patchstack documenta CVE-2026-85097, vulnerabilità senza autenticazione che interessa le versioni fino alla 3.1.8.9 e che risulta già sfruttata in attacchi osservati dal 7 ottobre; la correzione è disponibile nella 3.1.8.10. Il difetto non consiste semplicemente nel consentire qualsiasi upload: il primo controllo può accettare un file sulla base del tipo dichiarato, ma la successiva elaborazione si fida di metadati controllabili nella struttura temporaryFileUploads e permette di modificare la destinazione fino a ottenere un file PHP eseguibile. L’attaccante può inoltre ottenere il nonce necessario attraverso una funzione AJAX esposta senza autenticazione. Per chi gestisce installazioni Bricksforge la priorità non è quindi soltanto aggiornare, ma verificare richieste anomale verso l’endpoint di form submission e la presenza di file PHP nelle directory di upload. Elementor Pro aveva già mostrato quanto un campo di caricamento pubblico possa diventare un percorso verso il controllo del server: il problema decisivo è la distanza tra ciò che viene validato all’ingresso e ciò che viene realmente scritto o interpretato a valle.

Leggi anche: Ahsay, SonicWall e Atlassian sotto attacco: Cisco corregge Nexus

GoBalance e Amplify rompono il confine tra identità e autorizzazione

Il secondo fronte riguarda controlli che dovrebbero proteggere identità e separazione dei dati. Per GoBalance, la ricostruzione tecnica di The Hacker News basata sulla ricerca di Searchlight Labs descrive una configurazione nella quale l’implementazione in Go usata da alcuni servizi .onion gestisce in modo incompleto la chiave master in formato Tor e può rendere ricostruibile il segreto a partire da un descriptor pubblico firmato. Tor e l’Onionbalance originale non risultano coinvolti e il possesso della chiave dell’indirizzo non equivale automaticamente all’accesso al database o al filesystem del servizio: consente però di firmare descriptor validi e quindi impersonare l’identità .onion o reindirizzare i visitatori. È una distinzione importante rispetto ai precedenti attacchi che hanno messo sotto pressione l’anonimato della rete Tor, perché qui il problema non è deanonimizzare la rete ma perdere la chiave che dimostra chi controlla un determinato servizio. Sul cloud la logica è simile ma applicata ai dati: il bollettino di sicurezza AWS su CVE-2026-108096 spiega che alcuni query resolver generati da Amplify per modelli SQL possono permettere a un utente remoto già autenticato di leggere record appartenenti ad altri utenti della stessa applicazione. AWS ha corretto graphql-index-transformer 3.1.2, graphql-api-construct 1.21.4 e data-construct 1.17.4 e specifica che non esiste workaround: serve aggiornare e ridistribuire il backend. Il precedente su Ninja Forms e AWS AgentCore aveva già mostrato quanto componenti considerati fidati possano ereditare privilegi superiori a quelli previsti quando il confine tra input e autorizzazione viene progettato male.

PowerShell trasforma il logging in una seconda superficie per le credenziali AWS

CVE-2026-107783 ha un profilo meno esposto rispetto a Bricksforge, ma è particolarmente rilevante negli ambienti amministrativi perché colpisce AWS Tools for PowerShell V5 fino alla 5.0.305. Il bollettino AWS dedicato agli strumenti PowerShell spiega che, in determinate operazioni, l’uso delle funzioni di conferma o simulazione può lasciare nell’output e negli artefatti di log informazioni sensibili, fino alla password in chiaro della AWS Management Console associata a un utente IAM. Lo sfruttamento richiede accesso locale ai log o all’output e non va quindi descritto come compromissione remota dell’account AWS, ma il rischio aumenta drasticamente quando una workstation amministrativa è già stata raggiunta attraverso un altro vettore. La versione 5.0.306 corregge il problema; in attesa dell’upgrade AWS raccomanda di evitare -WhatIf e -Confirm con cmdlet che ricevono argomenti sensibili. L’aggiornamento, però, non cancella eventuali credenziali registrate prima della patch: dove esiste il sospetto che log o transcript abbiano conservato password, la risposta deve includere ricerca degli artefatti e rotazione del segreto. Le precedenti correzioni AWS a Kiro, projen e altri strumenti di sviluppo mostrano lo stesso punto: la superficie cloud non coincide con il servizio remoto, ma comprende anche SDK, CLI e tool amministrativi installati sulle macchine degli operatori.

Continua con:

Click2Shell trasforma un clic in una shell WordPress: patch urgente su Core

SonicWall, RabbitMQ, ShareFile, AWS e SAP colpiti da falle critiche

La priorità dipende da exploitation, persistenza e segreti già esposti

Mettere sullo stesso piano i quattro casi soltanto perché contengono una CVE produrrebbe una graduatoria sbagliata. Bricksforge viene prima perché esiste exploitation osservata e la falla può portare direttamente all’esecuzione sul server; GoBalance richiede di verificare la configurazione e, se un descriptor vulnerabile ha già reso recuperabile la chiave, la semplice patch non può restituire segretezza a un’identità ormai compromettibile e diventa necessaria la rotazione verso una nuova identità .onion. Amplify richiede aggiornamento e redeploy perché il codice corretto deve arrivare realmente nei resolver attivi; PowerShell richiede invece di trattare i log storici come possibile deposito di credenziali. È la stessa distinzione che rendeva prioritario AnyPwn contro AnyDesk Linux dopo la pubblicazione di una catena funzionante rispetto a un bug soltanto teorico: il rischio operativo dipende da ciò che un attaccante può fare oggi, dalle condizioni necessarie e da ciò che resta compromesso dopo la patch. Il punto comune è netto: validazione, firma, autorizzazione e logging non sono controlli secondari. Sono i luoghi nei quali un sistema decide di chi fidarsi, e basta che uno di quei confini venga implementato male perché il resto dell’architettura erediti una fiducia che non merita.