Artifactory, due falle che da sole non bastano: concatenate danno l'amministratore in meno di cinque minuti

Due settimane fa avevamo raccontato lo sfruttamento di CVE-2026-82329 su JFrog Artifactory, la falla da CVSS 9.8 che da sola consegna i privilegi di amministratore. La ricerca pubblicata da Wiz l'11 settembre aggiunge un capitolo diverso e, per certi versi, più interessante: due vulnerabilità separate, nessuna delle quali sufficiente da sola, che messe in fila producono lo stesso risultato. E che sono state usate in attacchi reali tra il 15 agosto e l'8 settembre 2026.

CISA ha aggiunto entrambe al catalogo Known Exploited Vulnerabilities l'11 settembre, con scadenza di rimedio per le agenzie federali statunitensi fissata al 25 settembre.

Come funziona la catena

Il meccanismo si spiega in due mosse.

CVE-2026-42018 (CVSS 7.5, autenticazione impropria) fa sì che Artifactory restituisca un token dell'utente anonimo interno a un chiamante che non ha effettuato alcun accesso — anche quando l'accesso anonimo è stato disattivato. È un token a bassi privilegi: da solo permette poco.

CVE-2026-42016 (CVSS 8.1, autorizzazione errata) consente di scambiare quel token a bassi privilegi con uno di scope amministrativo. La causa è precisa e vale la pena citarla, perché è un errore di progettazione ricorrente: Artifactory verifica la firma del token e chi lo ha emesso, ma non verifica cosa quel token sia autorizzato a fare. Autenticità sì, autorizzazione no.

Ogni caso osservato da Wiz segue lo stesso schema: richiesta non autenticata all'endpoint dei token, ricezione del token anonimo, scambio presso l'endpoint di creazione token con uno di scope amministrativo. In alcuni casi, dalla prima richiesta a un nuovo account amministratore sono passati meno di cinque minuti.

C'è un dettaglio che riguarda direttamente chi deve cercare tracce nei log. Il secondo token conserva lo username anonimo: le azioni amministrative compiute con esso compaiono nei log come token:anonymous, non sotto un account nominativo. Chi cerca «un amministratore che ha fatto qualcosa di strano» non lo trova, perché formalmente non c'è nessun amministratore.

Cosa hanno fatto con quei privilegi

Wiz precisa che non si tratta di un unico attore: attività diverse sui server compromessi, non tutte riconducibili alla stessa mano. L'insieme delle azioni osservate è comunque il catalogo completo di ciò che si fa a un repository di build:

• creazione di account amministratore lasciati sul sistema;
• installazione di plugin Groovy malevoli attraverso il framework di plugin di Artifactory, che equivale a esecuzione di codice sul server;
• esecuzione di comandi shell tramite l'endpoint di esecuzione dei plugin, per esplorare ed elencare file;
• un dropper che scarica un binario via HTTP, lo scrive in una directory scrivibile da tutti come /tmp e apre un canale di comando e controllo;
• una backdoor scritta in Rust con funzionalità C2, rilasciata in più casi.

Sui server compromessi attraverso CVE-2026-82329, inoltre, gli attaccanti hanno letto la configurazione di sistema e in diversi casi prelevato la cluster join key, il segreto condiviso con cui i nodi Artifactory si registrano tra loro.

La parte che l'aggiornamento non risolve

È il punto più importante dell'intera vicenda, e quello che con più facilità viene saltato.

Gli account amministratore creati dagli attaccanti non spariscono aggiornando il software. Non lo fanno i token già emessi: come ha scritto Fastly a proposito di CVE-2026-82329, «una patch non revoca i token già coniati». Non lo fa la join key eventualmente sottratta, che resta valida finché non viene ruotata.

Tradotto: chi ha applicato la patch la settimana scorsa e ha considerato chiusa la questione potrebbe avere ancora un amministratore ostile in sistema. Fastly consiglia di trattare come compromesso qualsiasi server esposto non aggiornato nella finestra rilevante, ruotare la join key di piattaforma, revocare gli access token emessi dopo il 28 agosto e passare in rassegna account amministratore, repository e modifiche di configurazione.

Sul dimensionamento della minaccia, Fastly ha contato circa 406.000 tentativi di sfruttamento di CVE-2026-82329 sulla propria piattaforma il 2 settembre, giornata di picco. Sono tentativi osservati nel traffico, non compromissioni: serve a capire l'intensità della scansione, non il numero di vittime.

Quali versioni, e un'ambiguità da tenere presente

La catena a due falle richiede che il server sia vulnerabile a entrambe: chiuderne una qualsiasi la spezza. Nelle fasce pubblicate da JFrog, CVE-2026-42016 si ferma alla 7.133.11, il che lascia i rami 7.146 e 7.161 fuori dalla catena — ma non da CVE-2026-82329, che arriva fino alla 7.161 ed è quindi il motivo per cui anche un server su un ramo recente può essere stato colpito.

Va segnalata un'ambiguità che al momento della pubblicazione resta aperta: JFrog indica per CVE-2026-42016 una sola versione corretta, la 7.133.11, senza un fix per ciascun ramo, e l'advisory non chiarisce se una build successiva su un ramo più vecchio (per esempio la 7.117.28) chiuda anche quella falla. In dubbio, conviene assumere di no e portarsi sulle versioni indicate per CVE-2026-82329, che sono comunque le più recenti di ogni ramo.

Per CVE-2026-82329 esiste una mitigazione temporanea per chi non può aggiornare subito: generare un valore casuale e aggiungerlo come join key aggiuntiva in system.yaml, in modo che solo le proprie chiavi vengano accettate al momento della registrazione di un servizio. Per le due falle concatenate non esiste alcun palliativo: o si aggiorna, o resta aperto. Le istanze cloud gestite da JFrog, secondo il fornitore, non richiedono interventi.

Cosa significa per le aziende italiane

Il primo punto è strutturale e riguarda il posto che Artifactory occupa nell'organizzazione. Non è un'applicazione di business: è il luogo da cui le pipeline di build prendono ciò che finisce in produzione. Chi controlla il repository può sostituire un artefatto firmato con uno alterato e lasciare che sia la catena di integrazione continua a distribuirlo, con tutte le credenziali e la fiducia che quella catena porta con sé. Una compromissione qui non produce un incidente confinato: produce un incidente che si propaga a valle, verso i clienti, con il marchio del fornitore sopra.

Questo dovrebbe far scattare un secondo ragionamento, quello sulla catena di fornitura. Molte software house italiane di media dimensione sviluppano per banche, sanità, utility e pubbliche amministrazioni: soggetti che, nella maggior parte dei casi, rientrano nel perimetro NIS2 come essenziali o importanti. L'articolo 21 della direttiva impone a quei soggetti misure sulla sicurezza della catena di approvvigionamento, e quelle misure si traducono in obblighi contrattuali verso i fornitori. Il fornitore di software che ha avuto un Artifactory compromesso non ha solo un problema tecnico: ha un problema di rapporto con clienti che devono, a loro volta, dimostrare come gestiscono il rischio dei propri fornitori. Ed è una conversazione che conviene aprire per primi, non subire.

Il terzo punto è il più operativo. La percezione diffusa è che un repository di artefatti sia infrastruttura interna, quindi non esposta. Nella pratica, i server Artifactory self-hosted finiscono pubblici con una certa regolarità: perché li usano sviluppatori esterni, perché li raggiungono runner CI su cloud, perché una regola di firewall doveva essere temporanea. La domanda da porsi oggi non è «è esposto?» ma «qualcuno può dimostrare che non lo era il 15 agosto?».

C'è infine una riflessione sul tempo. JFrog ha corretto CVE-2026-42018 sul ramo 7.146 il 28 aprile e sul ramo 7.133 il 12 agosto, tre giorni prima dell'inizio degli attacchi osservati da Wiz. Tre giorni. Non stiamo più in un mondo in cui la finestra tra patch e sfruttamento si misura in settimane, ed è questa la ragione per cui il tempo di aggiornamento sui sistemi che stanno nella catena di build va trattato con la stessa urgenza dei sistemi perimetrali — che di solito, nelle procedure aziendali, hanno un canale di emergenza dedicato, mentre gli strumenti DevOps no.

Merita una nota anche la provenienza di CVE-2026-42016, pubblicata il 27 luglio in un lotto di advisory Artifactory, diversi dei quali accreditano ricercatori di OpenAI. È lo stesso filone di cui avevamo scritto a proposito degli agenti AI che identificano e sfruttano falle in autonomia: la ricerca automatizzata sta aumentando il ritmo di scoperta, e il ritmo di correzione lato utente non si è mosso di conseguenza.

Cosa fare subito

• Aggiornare Artifactory self-hosted alla build corretta del proprio ramo, verificandola negli advisory ufficiali JFrog. In dubbio sulla copertura di CVE-2026-42016, portarsi sulla versione più recente del ramo.
• Non fermarsi alla patch. Passare in rassegna l'elenco degli account amministratore e cercare quelli che nessuno ricorda di aver creato. Nei casi osservati da Wiz i nomi erano di due tipi: espliciti da proof-of-concept, come 0xTerror, oppure mimetici, come jfrog-distribution, jfrog-insight, repo-service, e prefissi svc_ e labadmin_ seguiti da caratteri casuali.
• Cercare nei log l'anomalia caratteristica: l'utente anonimo interno — o qualsiasi account a bassi privilegi — che crea token, elenca utenti, legge o scrive plugin. È il segnale più pulito disponibile, perché descrive un'azione che quei privilegi non dovrebbero consentire.
• Ruotare la cluster join key e revocare gli access token emessi dal 28 agosto in poi, se l'istanza era raggiungibile nella finestra di attacco.
• Ispezionare i plugin Groovy installati e rimuovere quelli non riconducibili a un'installazione deliberata. E controllare /tmp e le altre directory scrivibili da tutti alla ricerca di binari estranei.
• Verificare l'integrità degli artefatti pubblicati o aggiornati nella finestra 15 agosto - 8 settembre, confrontando gli hash con quelli attesi dalla pipeline di build.
• Togliere il repository da internet se non c'è un requisito esplicito per l'esposizione, mettendolo dietro VPN o accesso a rete zero-trust. È la misura che rende irrilevante il prossimo bypass di autenticazione, e ce ne sarà uno.
• Se si sviluppa software per soggetti NIS2, documentare la verifica svolta: la controparte, prima o poi, la chiederà, e averla già pronta cambia il tono della conversazione.