Jenkins è il sistema di orchestrazione CI/CD più diffuso al mondo, e una falla critica appena corretta riguarda proprio il canale di comunicazione tra il server centrale e i suoi agenti di build. CVE-2026-70426 permette di aggirare il filtro di deserializzazione che dal 2019 protegge Jenkins da uno dei suoi bug più classici, aprendo la strada all'esecuzione di codice arbitrario sul controller.

Cosa è successo

Il Jenkins Security Advisory del 5 agosto ha reso nota la vulnerabilità nella libreria Remoting, il protocollo che gestisce la comunicazione tra il controller Jenkins e gli agenti di build. Dal 2019 Jenkins applica un meccanismo noto come JEP-200, un filtro che limita le classi Java deserializzabili attraverso Remoting proprio per prevenire attacchi di deserializzazione — una delle famiglie di vulnerabilità più sfruttate nella storia della piattaforma. Il problema individuato ora è che questo filtro non viene applicato a un percorso di fallback usato dall'implementazione di deserializzazione: chiunque controlli un processo agente, o disponga del permesso Agent/Connect, può sfruttare quel percorso per bypassare il filtro e innescare una catena di gadget basata su classi del core Jenkins, ottenendo l'esecuzione di codice sul controller.

È una falla particolarmente insidiosa perché non richiede un accesso amministrativo: basta il controllo — anche solo temporaneo o parziale — di un agente di build, scenario tutt'altro che remoto in ambienti dove gli agenti sono container Kubernetes effimeri, macchine cloud auto-scalanti, o dipendenze di terze parti eseguite durante la build. La stessa tornata di aggiornamenti ha corretto altre tre vulnerabilità correlate: CVE-2026-70427, che consente di scrivere file in posizioni arbitrarie del file system del controller sfruttando un'errata gestione dei percorsi nei parametri file (con possibilità di eseguire codice depositando script in init.groovy.d o installando plugin malevoli), e le vulnerabilità CVE-2026-70428 e CVE-2026-70429, di gravità inferiore ma comunque rilevanti. Le versioni interessate sono Jenkins fino alla 2.575, Jenkins LTS fino alla 2.568.1 e Remoting fino alla 3384.v60d89463d9e0; la correzione è disponibile in Jenkins 2.576, LTS 2.568.2 e nelle versioni aggiornate di Remoting. Il CSIRT Italia ha diffuso un bollettino specifico raccomandando l'aggiornamento immediato.

Cosa significa per le aziende italiane

Jenkins è lo scheletro nascosto di una parte enorme dello sviluppo software italiano: software house, banche con team di sviluppo interni, aziende manifatturiere con software embedded, pubbliche amministrazioni impegnate nella trasformazione digitale. Compromettere il controller Jenkins non significa violare "un server di sviluppo": significa ottenere accesso al cuore della catena di fornitura del software, con visibilità sui segreti custoditi nel credential store (chiavi API, credenziali cloud, certificati di firma del codice) e, soprattutto, con la possibilità di inserire codice malevolo direttamente negli artefatti di build che finiscono in produzione o vengono distribuiti ai clienti a valle.

È un rischio di tipo supply chain, concettualmente simile a quanto accaduto con SolarWinds, ma interno: non serve compromettere un fornitore esterno se si può compromettere la pipeline di build della propria stessa azienda. Il fattore che rende questa falla specificamente pericolosa è che il permesso Agent/Connect, necessario per sfruttarla, è spesso concesso in modo ampio — a tutti gli agenti che si connettono, inclusi quelli effimeri creati automaticamente in ambienti cloud o Kubernetes. Un singolo agente compromesso, magari attraverso una dipendenza open source avvelenata eseguita durante una build (uno scenario che il sito ha già documentato più volte quest'anno con campagne come Shai-Hulud su npm), diventa il trampolino per prendere il controllo dell'intero sistema di continuous integration.

Per le aziende che rientrano nel perimetro NIS2, in particolare quelle il cui core business include lo sviluppo o la manutenzione di software distribuito a terzi, la sicurezza della pipeline CI/CD rientra a pieno titolo tra le misure di gestione del rischio richieste dalla direttiva: un controller Jenkins compromesso che comprometta l'integrità del software distribuito può configurare un incidente significativo, con i relativi obblighi di notifica a CSIRT Italia. Per i soggetti sottoposti a DORA, se Jenkins fa parte della catena ICT che produce o mantiene sistemi rilevanti per servizi finanziari, l'integrità della pipeline di build entra nel perimetro della gestione del rischio ICT di terze parti e interno.

Cosa fare subito

  • Aggiornare immediatamente a Jenkins 2.576, Jenkins LTS 2.568.2 o versioni successive, e verificare che la libreria Remoting sia allineata alla versione corretta.
  • Rivedere le assegnazioni del permesso Agent/Connect: limitarlo strettamente agli agenti effettivamente necessari, evitando concessioni ampie o ereditate da configurazioni datate.
  • Isolare gli agenti di build: usare container o macchine effimere con privilegi minimi, in modo che la compromissione di un singolo agente non si traduca automaticamente in accesso al controller.
  • Segmentare l'accesso di rete al controller: nessuna esposizione diretta a internet dell'interfaccia Jenkins; accesso limitato a rete interna o dietro VPN/reverse proxy con autenticazione forte.
  • Ruotare le credenziali custodite nel credential store Jenkins come misura precauzionale, soprattutto se l'aggiornamento non è stato applicato tempestivamente o se si sospetta un accesso non autorizzato pregresso.
  • Controllare i log del controller alla ricerca di errori di deserializzazione anomali, connessioni agente inattese o comportamenti di build non riconducibili a pipeline note.