Il 5 agosto 2026 i ricercatori di Novee guidati da Lidor Ben Shitrit hanno presentato al Black Hat USA un lavoro che ha rivelato dodici vulnerabilità in quattro piattaforme Java enterprise, tra cui due catene critiche che consentono di eseguire codice sul server senza alcun login, nella piattaforma di workflow Bonita BPM e in Apache OFBiz, l'ERP open source. La conclusione pratica per qualsiasi imprenditore: il sistema che consideri protetto perché è interno può essere raggiunto con due richieste dal browser se è esposto e non aggiornato. La vera protezione comincia con un inventario di ciò che usi e una routine di patch, non con la fiducia nel perimetro di rete.

Cosa hanno trovato davvero i ricercatori

La ricerca non si è basata su un singolo bug spettacolare. È stata costruita combinando piccoli errori comuni del middleware: differenze nel modo in cui viene interpretato un URL, protezione incompleta nel livello che gestisce le richieste, chiavi crittografiche scritte direttamente nel codice sorgente e valutazione non sicura dei template. Presi singolarmente, nessuno di questi sembra pericoloso, ed è proprio per questo che superano la revisione del codice e vengono archiviati come bassa priorità. Concatenati, producono un percorso completo da un visitatore anonimo all'esecuzione di comandi sul server. Delle dodici vulnerabilità, quattro funzionano prima dell'autenticazione e una rompe l'isolamento all'interno della sandbox di esecuzione.

La catena BadBonita: tre punti deboli formano una compromissione totale

La prima catena riguarda la versione 10.4.3 di Bonita BPM. Inizia con un aggiramento dell'autenticazione costruito su tre debolezze collegate: un path traversal che usa la notazione ..;, un filtro di sicurezza che confronta una sottostringa invece del percorso completo e la logica interna di inoltro delle richieste. Il risultato è che una richiesta arriva a un'API interna che nessuno dall'esterno avrebbe mai dovuto vedere. Quell'API accetta XML non attendibile e lo passa direttamente alla libreria XStream, che lo deserializza, e attraverso una nota catena di gadget di Commons Collections il percorso si conclude con comandi Groovy eseguiti sul server.

Nota che nessuno di questi passaggi richiede una password trapelata, ingegneria sociale o un accesso precedente. All'attaccante basta che il sistema sia raggiungibile attraverso la rete.

OFBiz: una chiave di firma pubblicata in un repository aperto

Il secondo problema, catalogato come CVE-2026-31986 e classificato come critico, riguarda la versione 24.09.05 di Apache OFBiz quando il single sign-on è attivo. Il problema è che le chiavi di firma predefinite si trovano nel codice sorgente pubblicato apertamente e, poiché molte installazioni non toccano i valori predefiniti, un attaccante può falsificare un token SSO valido a nome di un account amministratore. Da lì la richiesta supera una lista di blocco che cercava di fermare parole come java, process e import, ma la lista distingueva tra maiuscole e minuscole e controllava schemi specifici, quindi basta cambiare una lettera in maiuscola o usare un altro nome di classe importata automaticamente per passare. Il risultato finale: due richieste GET non autenticate sono sufficienti per arrivare all'esecuzione di codice su qualsiasi installazione che usa SSO.

Perché ti riguarda direttamente

Perché nessuno dei due è uno strumento marginale. OFBiz è un ERP open source che molte aziende usano per gestire magazzino, acquisti e fatturazione, e Bonita è un motore di workflow che guida approvazioni e procedure interne. Chi arriva in quei due punti non si limita a leggere dati: si trova nel mezzo del tuo ciclo operativo, tra ordini di acquisto, prezzi dei fornitori, fascicoli dei dipendenti e storico dei clienti. I ricercatori hanno riferito che entrambi i fornitori hanno rilasciato versioni corrette entro la consueta finestra di divulgazione di novanta giorni, il che significa che l'aggiornamento esiste e la responsabilità ora è di chi gestisce il sistema, non di chi lo ha costruito.

La vera lacuna del mercato non è la mancanza di patch, ma la mancanza di inventario. Molte organizzazioni non hanno un elenco aggiornato di ciò che usano davvero, in quale versione e su quale dominio. Così una vecchia copia di staging resta appesa per due anni su un sottodominio dimenticato e diventa la porta a cui nessuno aveva pensato.

Cosa fare questa settimana

  • Fai l'inventario dei tuoi sistemi: un elenco scritto di ogni sistema che usi, la sua versione, se è esposto a internet e chi ne è responsabile, con nome e cognome.
  • Aggiorna subito Bonita e OFBiz alle versioni corrette se usi uno dei due, e leggi la pagina ufficiale sulla sicurezza di Apache prima dell'aggiornamento.
  • Sostituisci ogni chiave di cifratura o di firma predefinita fornita con il prodotto. Nessun valore stampato nella documentazione è un segreto.
  • Chiudi i gateway di amministrazione verso internet aperto e raggiungili tramite una rete privata o un breve elenco di indirizzi autorizzati.
  • Dismetti le vecchie copie di staging e i sottodomini inutilizzati. Sono il bersaglio più facile e il meno monitorato.
  • Attiva la registrazione degli accessi e conservala. Senza log non potrai rispondere in seguito alla domanda se qualcuno sia entrato davvero.

La lezione di ingegneria: la rete interna non è un confine di sicurezza

La raccomandazione più importante che emerge da questa ricerca è che l'instradamento interno va trattato con controlli di livello internet. La vecchia idea che tutto ciò che sta dietro il firewall sia sicuro ha fallito nella pratica: una sola falla di aggiramento dell'autenticazione trasforma ogni endpoint interno in un endpoint pubblico. Ne derivano tre regole di ingegneria, che devono far parte dei tuoi standard di sviluppo:

Non affidarti mai a una lista di blocco per proteggere un'operazione pericolosa. Se la valutazione delle espressioni non è necessaria in un percorso di codice, eliminala del tutto invece di provare a filtrarla.

La seconda regola è non subordinare mai un'operazione sensibile a un flag di configurazione o a una preferenza dell'utente che può essere modificata dall'interno del sistema. La terza è verificare la logica dei filtri di autenticazione alla ricerca di qualsiasi confronto per sottostringa, perché è l'errore più ricorrente e più facile da sfruttare di questa categoria. Quando costruiamo nuovi sistemi aziendali in Origami lo applichiamo di default: autorizzazione esplicita su ogni endpoint e nessuna fiducia basata sulla posizione di una richiesta nella rete.

L'aspetto normativo in Arabia Saudita

Se il sistema compromesso contiene dati personali di persone che si trovano nel Regno, la questione smette di essere puramente tecnica. La Legge sulla protezione dei dati personali (PDPL) obbliga il titolare del trattamento ad adottare le misure necessarie per proteggere tali dati e a notificare gli incidenti che ne compromettono la riservatezza. L'Autorità nazionale per la sicurezza informatica (NCA) pubblica controlli essenziali che riguardano la gestione delle vulnerabilità, l'applicazione delle patch e la gestione degli asset, cioè proprio i controlli che avrebbero fermato questa catena. Usare una vecchia versione di un prodotto con una vulnerabilità nota e già corretta è una posizione difficile da difendere in qualsiasi audit.

La regola semplice: tratta gli aggiornamenti di sicurezza come un impegno operativo mensile con un responsabile e una data, non come un'attività di emergenza svolta dopo un incidente.

Fonti

  • Help Net Security — dettagli sulle catene di RCE senza autenticazione e su CVE-2026-31986: helpnetsecurity.com
  • Pagina ufficiale sulla sicurezza di Apache OFBiz: ofbiz.apache.org/security.html
  • Autorità nazionale per la sicurezza informatica (NCA) — controlli e quadri normativi: nca.gov.sa
  • Autorità saudita per i dati e l'intelligenza artificiale (SDAIA) — Legge sulla protezione dei dati personali: sdaia.gov.sa