La risposta breve
Apache ActiveMQ Artemis contiene una falla critica di dirottamento di sessione non autenticato — CVE-2026-57967, CVSS 9.8 — che consente a un attaccante remoto senza credenziali di assumere il controllo di una sessione autenticata esistente del broker. La causa principale è l'autenticazione mancante (CWE-306) nel percorso di riaggancio della sessione del protocollo CORE: il broker accetta un pacchetto SESSION_REATTACH senza confermare che il richiedente possieda davvero la sessione. Sono interessati Apache Artemis dalla 2.50.0 alla 2.56.0 e la vecchia linea ActiveMQ Artemis dalla 1.0.0 alla 2.44.0, e la correzione è nella versione 2.57.0.
In pratica: qualsiasi broker Artemis il cui acceptor CORE (di norma TCP 61616) sia raggiungibile da una rete non fidata è esposto. Aggiornate a 2.57.0 come intervento prioritario. Se non potete applicare subito la patch, limitate gli acceptor del broker alle sottoreti applicative fidate e imponete TLS. Trattare i broker come infrastruttura cloud e DevOps interna e sicura per impostazione predefinita è la correzione duratura dietro la patch immediata.
Che cos'è CVE-2026-57967?
Apache ActiveMQ Artemis è il broker di messaggi ad alte prestazioni al cuore di molti sistemi event-driven e a microservizi — la spina dorsale JMS e multiprotocollo che sposta ordini, pagamenti, variazioni di magazzino ed eventi di audit tra i servizi. Il 10 settembre 2026 la Apache Software Foundation ha divulgato una serie di avvisi Artemis, e CVE-2026-57967 è il più grave: una falla critica di autenticazione mancante (CWE-306) con punteggio CVSS 9.8.
La falla risiede nel protocollo CORE del broker, il protocollo di rete nativo che i client Artemis usano per parlare con il server. CORE supporta il riaggancio della sessione — una funzione di resilienza che permette a un client di riprendere in modo trasparente una sessione esistente dopo una breve caduta della connessione anziché riautenticarsi da zero. Il bug: il broker accetta una richiesta SESSION_REATTACH senza verificare adeguatamente che il richiedente sia il legittimo proprietario della sessione da riagganciare. Un attaccante che può raggiungere il broker e riferirsi a un identificatore di sessione valido può quindi rivendicare la proprietà della sessione autenticata altrui. Poiché si tratta di infrastruttura lato broker, il suo irrobustimento è una questione DevOps e di piattaforma tanto quanto applicativa.
Le metriche di gravità parlano chiaro: raggiungibile via rete, bassa complessità di attacco, nessun privilegio e nessuna interazione utente richiesta, con impatto elevato su riservatezza, integrità e disponibilità. In altre parole, un attaccante non autenticato su un percorso di rete raggiungibile può assumere il controllo di una sessione privilegiata, già autenticata, e agire con i suoi diritti. Il progetto Apache ha corretto la logica di riaggancio in Artemis 2.57.0, che ora convalida una richiesta di riaggancio rispetto allo stato di autenticazione corrente prima di onorarla.
Come funziona il dirottamento di sessione
Il riaggancio della sessione esiste per una buona ragione. In un deployment Artemis molto carico le connessioni TCP cadono e si ristabiliscono di continuo, e forzare una riautenticazione completa e una ricostruzione dello stato a ogni interruzione sarebbe lento e fragile. Perciò il protocollo CORE consente a un client che si riconnette di presentare un pacchetto SESSION_REATTACH che riferisce una sessione lato server esistente e riprende da dove si era interrotto — stessa identità autenticata, stessi producer e consumer aperti, stesso stato in transito.
CVE-2026-57967 rompe l'assunto di fiducia sotto questa comodità. Il broker non conferma adeguatamente che chi invia la richiesta di riaggancio sia il proprietario originale e autenticato della sessione riferita. Un attaccante che può indovinare o osservare un identificatore di sessione valido da una connessione autenticata precedente può inviare il proprio pacchetto SESSION_REATTACH rivendicando quella sessione — e il broker concede l'accesso a tutto ciò che vi è associato. Nessuna password, nessun token, nessuna richiesta all'utente: raggiungibilità di rete più un riferimento di sessione valido diventano presa di controllo della sessione.
Da lì l'attaccante eredita i permessi della sessione dirottata sul broker. A seconda di ciò che quella sessione era autorizzata a fare, questo può significare leggere i messaggi in transito, iniettare o riprodurre messaggi verso i consumer a valle, manomettere o svuotare le code, o interrompere del tutto il flusso dei messaggi. Alla pubblicazione non vi è conferma di sfruttamento diffuso in circolazione, e Apache la descrive come una falla divulgata anziché nota per essere sfruttata. È magra consolazione: il percorso di attacco è non autenticato e a bassa complessità, e una volta pubblici i dettagli tecnici di un bug CVSS 9.8, la scansione opportunistica dei broker esposti è l'aspettativa realistica, non quella remota.
Cosa significa per i team software in Italia
Tolte le specificità del protocollo, restano tre lezioni durature. Primo, il vostro broker di messaggi è infrastruttura di produzione, non tubatura da dimenticare. I team riempiono di autenticazione e rate-limiting le loro API HTTP pubbliche, poi eseguono Artemis con un acceptor permissivo perché «è interno». Un broker che instrada pagamenti ed eventi di audit merita lo stesso modello di minaccia del vostro edge. CVE-2026-57967 ricorda che il livello di messaggistica è una parte di primo piano della vostra superficie di attacco.
Secondo, le funzioni di resilienza sono superficie di sicurezza. Riaggancio della sessione, riconnessione automatica, failover e meccanismi di replay esistono tutti per rendere i sistemi più robusti — e ciascuno è un punto in cui l'identità può essere presunta anziché provata. Quando costruite o commissionate sistemi event-driven, ogni percorso «riprendi da dove hai lasciato» deve rispondere a una domanda in modo esplicito: come verifichiamo che si tratti dello stesso principal? Integrare questo controllo nel design è molto meno costoso che aggiungerlo dopo un CVE.
Terzo, l'esposizione di rete è il moltiplicatore. La differenza tra «CVE critico patchato con calma» e «incidente» dipende quasi sempre dal fatto che la porta vulnerabile fosse raggiungibile da dove si trova l'attaccante. Per i team italiani, una presa di controllo non autenticata di un broker che trasporta dati personali o finanziari rientra chiaramente in GDPR, nel recepimento di NIS2 (D.Lgs. 138/2024) e, nella finanza, in DORA — il tipo di esposizione che autorità come il Garante e l'ACN si aspettano sia stata segregata per progettazione. Sapere esattamente quali broker, pannelli di amministrazione e servizi interni sono raggiungibili, e da dove, è qui il controllo a maggior leva.
Cosa fare ora
- Aggiornate ad Artemis 2.57.0. Portate qualsiasi broker su una versione interessata — Apache Artemis 2.50.0–2.56.0 o vecchio ActiveMQ Artemis 1.0.0–2.44.0 — alla 2.57.0. Trattatelo come un intervento prioritario, non come manutenzione ordinaria.
- Togliete le porte del broker dalle reti non fidate. L'acceptor CORE (di norma TCP 61616) e l'interfaccia di gestione dovrebbero essere raggiungibili solo da sottoreti applicative fidate. Nulla di un broker di messaggi va esposto su Internet pubblica.
- Imponete TLS e autenticazione su ogni acceptor. Richiedete connessioni cifrate e autenticate per tutto il traffico client e inter-broker, e applicate ruoli a privilegio minimo su indirizzi e code affinché una singola sessione compromessa non possa toccare tutto.
- Cacciate le anomalie. Esaminate i log del broker per individuare un turnover di connessioni insolito e attività di riaggancio, indirizzi sorgente inattesi sull'acceptor CORE e consumer che non riuscite a giustificare. Allertate sugli schemi di riaggancio che non corrispondono alla vostra flotta di client.
- Includete la messaggistica nell'ambito del penetration test. I broker vengono regolarmente esclusi dai test di sicurezza pur trasportando il traffico più sensibile. Aggiungete il livello di messaggistica al vostro prossimo penetration test e verificate i servizi interni adiacenti alla ricerca di percorsi simili di «identità presunta».
Domande frequenti
Che cos'è CVE-2026-57967 in Apache ActiveMQ Artemis?
CVE-2026-57967 è una vulnerabilità critica di autenticazione mancante (CWE-306) in Apache ActiveMQ Artemis, con punteggio CVSS 9.8. Il protocollo CORE accetta un pacchetto SESSION_REATTACH senza verificare adeguatamente che il richiedente possieda la sessione da riagganciare. Un attaccante remoto non autenticato che può raggiungere il broker e riferirsi a un identificatore di sessione valido può dirottare una sessione autenticata esistente e assumerne i privilegi — senza credenziali né interazione utente.
Quali versioni sono interessate e qual è la correzione?
Sono interessati Apache Artemis dalla 2.50.0 alla 2.56.0 e la vecchia linea Apache ActiveMQ Artemis dalla 1.0.0 alla 2.44.0. La correzione è in Apache ActiveMQ Artemis 2.57.0, che convalida una richiesta di riaggancio della sessione rispetto allo stato di autenticazione corrente. Aggiornate i broker interessati a 2.57.0; se non potete applicare subito la patch, limitate l'acceptor CORE (di norma TCP 61616) alle reti fidate.
CVE-2026-57967 viene sfruttata in circolazione?
Alla pubblicazione non risulta alcuno sfruttamento diffuso confermato, e gli avvisi dei fornitori la trattano come una vulnerabilità divulgata anziché nota per essere sfruttata. Dato il percorso di attacco non autenticato e poco complesso e il valore dei broker di messaggi, la weaponizzazione dovrebbe seguire rapidamente la divulgazione pubblica. Applicate la patch con urgenza e presupponete la scansione opportunistica dei broker esposti.
Perché un dirottamento di sessione non autenticato è valutato CVSS 9.8?
Il vettore CVSS è raggiungibile via rete, bassa complessità di attacco, nessun privilegio e nessuna interazione utente, con impatto elevato su riservatezza, integrità e disponibilità. Una sessione del broker dirottata consente a un attaccante di leggere i messaggi, iniettarli o riprodurli verso i consumer, manomettere le code o interrompere l'elaborazione — su infrastruttura che trasporta ordini, pagamenti ed eventi di audit. Questa combinazione di accesso banale e impatto grave produce il punteggio quasi massimo.
Come irrobustire Artemis oltre alla patch?
Dopo l'aggiornamento a 2.57.0: segmentate il broker affinché i suoi acceptor CORE e di gestione siano raggiungibili solo da sottoreti applicative fidate, imponete TLS su ogni acceptor, richiedete l'autenticazione per tutte le connessioni e applicate ruoli a privilegio minimo su indirizzi e code. Monitorate schemi anomali di connessione e riaggancio e includete il livello di messaggistica nei test di penetrazione regolari.
Fonti
SecurityOnline — Apache Artemis Vulnerabilities Expose ActiveMQ Artemis Flaws
VulDB — CVE-2026-57967 in ActiveMQ Artemis (CVSS, versioni interessate, correzione)
Apache Software Foundation — ActiveMQ Security Advisories