CVE-2026-34197 ActiveMQ Classic Lab

Questo repository contiene un laboratorio locale per lo studio di CVE-2026-34197 in Apache ActiveMQ Classic e per confrontare un'istanza vulnerabile con una build corretta.

Il repository è organizzato per supportare due obiettivi:

• Riprodurre il problema in un ambiente strettamente controllato e isolato.
• Convalidare il comportamento della correzione con una build patchata di ActiveMQ Classic.

Disclaimer

Questo repository è fornito esclusivamente per ricerche di sicurezza difensive legali e autorizzate, in ambienti di laboratorio isolati di tua proprietà o per i quali hai il permesso esplicito di testare.

Utilizzando qualsiasi materiale in questo repository, accetti che:

• Non lo utilizzerai contro sistemi di terze parti, target pubblici, ambienti clienti, infrastrutture condivise o qualsiasi sistema senza autorizzazione scritta esplicita.
• Non lo utilizzerai per accessi non autorizzati, persistenza, interruzione, movimento laterale, accesso ai dati o qualsiasi attività che violi leggi, policy, contratti o requisiti di uso accettabile.
• Comprendi che la ricerca di sicurezza proof-of-concept può causare interruzioni del servizio, crash di processo, corruzione dei dati, compromissione dei container, accesso alla shell e propagazione indesiderata se gestita con noncuranza.
• Sei l'unico responsabile della conformità con tutte le leggi, normative, contratti e policy interne applicabili.
• Eseguirai questo materiale solo in sistemi di laboratorio monouso con adeguato isolamento di rete, monitoraggio e capacità di ripristino.

Questo repository non è destinato a operazioni offensive. È destinato esclusivamente a validazione, formazione, ingegneria del rilevamento, verifica delle patch e dimostrazione controllata.

Se non sei sicuro di essere autorizzato a eseguire questo materiale, non eseguirlo.

Scopo

Questo laboratorio si concentra sul comportamento di Apache ActiveMQ Classic relativo a CVE-2026-34197:

• Un container vulnerabile basato su apache/activemq-classic:5.19.2
• Un container corretto costruito localmente da ActiveMQ Classic 5.19.4
• Un semplice file XML payload utilizzato per la validazione del laboratorio
• Note per verificare il comportamento previsto vulnerabile vs corretto

Struttura del repository

.
├── activemq-patched
│   ├── docker-compose.yml
│   ├── Dockerfile
│   ├── instructions.txt
│   └── poc.xml
├── docker-compose.yml
├── instructions.txt
└── poc.xml

Laboratorio vulnerabile

La radice di questo repository contiene il laboratorio vulnerabile:

• docker-compose.yml avvia un container ActiveMQ Classic 5.19.2 con la console web e Jolokia esposti su localhost.
• instructions.txt contiene il flusso di lavoro del laboratorio locale utilizzato per validare il comportamento vulnerabile.
• poc.xml è il template del payload XML utilizzato nel laboratorio.

Porte tipicamente esposte nel file compose vulnerabile:

• 8161 - Web Console / Jolokia
• 61616 - OpenWire
• 61613 - STOMP
• 1883 - MQTT
• 5672 - AMQP

Avvia il laboratorio vulnerabile:

docker compose up -d

Laboratorio corretto

La directory activemq-patched/ contiene un ambiente di confronto corretto:

• Una build Docker locale basata su ActiveMQ Classic 5.19.4
• Un Dockerfile che aggiorna il binding di Jetty in modo che la console web sia raggiungibile dall'host
• Un file compose separato che pubblica il broker corretto su porte localhost diverse

Porte tipicamente esposte nel file compose corretto:

• 8261 - Web Console / Jolokia
• 62616 - OpenWire

Costruisci l'immagine corretta

Scarica il tarball archiviato della release 5.19.4:

cd activemq-patched
wget https://archive.apache.org/dist/activemq/5.19.4/apache-activemq-5.19.4-bin.tar.gz

Costruisci l'immagine locale:

docker build \
  -t pssec/activemq-classic:5.19.4 \
  --build-arg ACTIVEMQ_VERSION=5.19.4 \
  -f Dockerfile .

Avvia il laboratorio corretto:

docker compose up -d

Guida alla validazione

Utilizza i file instructions.txt forniti per il flusso del laboratorio.

Risultato previsto di alto livello:

• L'ambiente vulnerabile dovrebbe consentire il path del connettore non sicuro nel flusso di lavoro del laboratorio.
• L'ambiente corretto dovrebbe rifiutare lo schema basato su VM non sicuro e restituire un errore simile a VM scheme is not allowed.

Validazione non distruttiva consigliata

In un test interno reale, preferisci un comando sicuro, osservabile e non distruttivo invece di qualsiasi cosa invasiva.

Un semplice esempio è creare un file temporaneo come:

touch /tmp/pssec_validation_marker

Poi verifica il risultato dall'host:

docker exec -it cve-2026-34197-activemq ls -l /tmp/pssec_validation_marker

Per l'ambiente corretto, la validazione equivalente dovrebbe fallire nel creare il file quando la correzione funziona come previsto.

Questo è più sicuro rispetto all'uso di un payload interattivo e solitamente è sufficiente per dimostrare:

• se il path vulnerabile è ancora raggiungibile, o
• se il broker corretto blocca il comportamento pericoloso del connettore.

Note

• Mantieni il laboratorio vincolato a 127.0.0.1 dove possibile.
• Utilizza container monouso e reti isolate.
• Reimposta o ricostruisci i container tra un test e l'altro.
• Esamina i log dei container e le risposte di Jolokia come parte della validazione.
• Preferisci controlli non distruttivi basati su file rispetto a shell interattive durante la verifica interna.

Business

PSsec: https://pssec.io