Fallati JFrog Artifactory corretti e concatenati per accesso admin e backdoor

Due vulnerabilità di JFrog Artifactory, entrambe già corrette, sono state concatenate dagli attaccanti per assumere il controllo amministratore di server self-hosted e installare backdoor, ha dichiarato la società di sicurezza cloud Wiz. Artifactory è una piattaforma di repository, ovvero un server che archivia pacchetti software e artefatti di build che gli sviluppatori scaricano durante le build automatizzate. Wiz ha osservato gli attacchi tra il 15 agosto e l'8 settembre. JFrog aveva corretto entrambe le falle prima di quel periodo, quindi solo le installazioni che non avevano applicato gli aggiornamenti erano esposte all'attacco. Nessuna delle due falle da sola concede diritti di amministratore, ma usate insieme hanno permesso una compromissione completa.

La prima falla, tracciata come CVE-2026-42018, fa sì che Artifactory consegni un token interno per il suo utente anonimo integrato a un chiamante che non ha effettuato l'accesso, anche quando l'accesso anonimo è disabilitato. Un token è una credenziale digitale che prova chi sei o cosa puoi fare. La seconda falla, CVE-2026-42016, consente poi di scambiare quel token a bassi privilegi con uno che porta con sé lo scope di amministratore. Artifactory controlla la firma crittografica di un token e quale autorità lo ha emesso, ha spiegato Wiz, ma non controlla cosa il token sia effettivamente autorizzato a fare. In ogni caso osservato dalla società di sicurezza, l'attaccante ha prima inviato una richiesta non autenticata a un endpoint dei token e ha ricevuto un token per l'utente anonimo interno. Poi, l'attaccante ha scambiato quel token sull'endpoint di creazione dei token di Artifactory con un token con scope di amministratore. Quel secondo token mantiene il nome utente anonimo, quindi le azioni di amministratore compiute con esso appaiono nei log del server come token:anonymous anziché sotto un account con nome. In alcuni attacchi, il tempo dalla richiesta iniziale alla creazione di un nuovo account amministratore è stato inferiore a cinque minuti. La catena raggiunge solo i server vulnerabili a entrambe le falle. Gli intervalli pubblicati da JFrog mostrano che CVE-2026-42016 è corretto fino alla versione 7.133.11, mentre i rami 7.146 e 7.161 cadono al di fuori di tale intervallo. JFrog ha distribuito la correzione per CVE-2026-42018 sul ramo 7.146 il 28 aprile e sul ramo 7.133 il 12 agosto, tre giorni prima che iniziassero gli attacchi osservati da Wiz.

Con il controllo di amministratore, gli attaccanti non hanno seguito uno script identico. Wiz ha notato che nessun singolo attore ha eseguito ogni passo osservato. Sui server compromessi, gli attaccanti hanno creato account amministratore e li hanno lasciati in essere. Hanno anche installato plugin Groovy malevoli, piccoli programmi scritti nel linguaggio Groovy che Artifactory può caricare per eseguire azioni personalizzate, attraverso il framework di plugin di Artifactory, il che ha permesso loro di eseguire codice sul server. Alcuni attaccanti hanno eseguito comandi shell attraverso l'endpoint di esecuzione dei plugin per esplorare directory e listare file. Un dropper ha scaricato un binario via HTTP, lo ha scritto in una directory scrivibile da tutti come /tmp, una cartella temporanea in cui qualsiasi utente del server può scrivere, e ha aperto un canale di command-and-control, la connessione che una macchina compromessa usa per ricevere istruzioni. Wiz ha detto di aver anche trovato una backdoor personalizzata in Rust, un modo nascosto per un attaccante di rientrare in un sistema in seguito, con funzionalità di command-and-control depositata in più casi.

Una terza falla di JFrog Artifactory, CVE-2026-82329, è stata sfruttata separatamente tra il 1° e l'8 settembre. Si tratta di un bypass di autenticazione critico valutato 9.8 sulla scala di gravità CVSS, dove 10 è il massimo, e colpisce la configurazione predefinita di Artifactory, non richiedendo una seconda falla. Un attaccante non autenticato con accesso alla rete può ottenere privilegi di amministratore attraverso di essa da sola su sei rami di rilascio fino alla versione 7.161. The Hacker News ha riportato il 1° settembre che gli attaccanti avevano iniziato a creare token di amministratore attraverso quella falla pochi giorni dopo che JFrog l'aveva divulgata. La Cybersecurity and Infrastructure Security Agency statunitense, CISA, l'ha aggiunta al suo catalogo delle vulnerabilità note come sfruttate il 2 settembre e ha fissato una scadenza al 5 settembre per l'intervento delle agenzie federali. La content delivery network Fastly ha dichiarato in un'analisi che un exploit pubblico è apparso il 1° settembre e che sono seguite le scansioni. Fastly ha contato circa 406.000 tentativi di sfruttamento sulla sua piattaforma il 2 settembre, il suo giorno più intenso, anche se si tratta di tentativi visti nel traffico e non di compromissioni confermate. Sui server compromessi tramite quella falla, Wiz ha visto gli attaccanti leggere la configurazione di sistema e, in diversi casi, prendere la join key del cluster, il segreto condiviso che i nodi di Artifactory usano per registrarsi tra loro.

Gli avvisi di sicurezza di JFrog elencano build corrette per ciascun ramo di rilascio, ovvero una linea di versioni che ricevono correzioni per quella serie. Per CVE-2026-42018, le versioni corrette sono 7.111.20, 7.117.27, 7.125.19, 7.133.28 e 7.146.8. Per CVE-2026-42016, l'unica versione corretta elencata da JFrog è 7.133.11, senza una correzione separata per ciascun ramo. L'avviso non dice se una build successiva su un ramo più vecchio, come 7.117.28, chiuda anch'essa quella falla; The Hacker News ha chiesto chiarimenti a JFrog e Wiz. Per CVE-2026-82329, le versioni corrette sono 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 e 7.161.20. JFrog pubblica una soluzione alternativa per quella terza falla per chi non può aggiornare rapidamente: generare un valore casuale e aggiungerlo come join key aggiuntiva nel file di configurazione system.yaml, così che solo le chiavi fornite da te siano accettate quando un servizio si registra. Non esiste un'opzione intermedia per le due falle concatenate in alcun avviso o report consultato.

Un punto importante per gli amministratori è che installare una patch non annulla le modifiche degli attaccanti. Gli account amministratore creati dagli attaccanti non scompaiono quando il software viene aggiornato. Wiz ha visto quegli account creati sia attraverso la catena delle due falle sia attraverso CVE-2026-82329. Per CVE-2026-82329, Fastly consiglia di trattare qualsiasi server esposto come compromesso. Fastly ha detto che una patch non revoca i token già emessi. Un aggiornamento non cambia nemmeno una join key che gli attaccanti hanno già preso. Fastly raccomanda di ruotare la join key della piattaforma, revocare i token di accesso emessi dal 28 agosto e rivedere gli account amministratore, i repository e le modifiche di configurazione.

Per rilevare se un'installazione è stata colpita, osserva account che fanno cose che i loro privilegi non dovrebbero permettere. Il segnale più chiaro è l'utente anonimo interno, o qualsiasi account a bassi privilegi, che crea token, elenca utenti o legge e scrive plugin. Poi, cerca account amministratore che nessuno ha creato di proposito. La maggior parte di quelli visti da Wiz ha nomi da proof-of-concept come 0xTerror, o nomi che iniziano con svc_ e labadmin_ seguiti da caratteri casuali. Alcuni erano progettati per mimetizzarsi, con nomi come jfrog-distribution, jfrog-insight e repo-service. Il report di Wiz elenca indirizzi degli attaccanti e un hash del payload che i difensori possono cercare.

CVE-2026-42016 è stata pubblicata il 27 luglio come parte di un lotto di avvisi di Artifactory, diversi dei quali attribuiscono il merito a ricercatori di OpenAI, inclusa questa. The Hacker News ha riportato a luglio che JFrog aveva confermato che modelli OpenAI hanno sfruttato uno zero-day di Artifactory durante una valutazione interna, e che nessuna delle due società aveva detto quali record CVE corrispondono alle falle usate. Questo incidente illustra come gli attaccanti possano concatenare piccoli passi falsi fino al controllo completo quando una correzione nota viene lasciata non applicata. Per i proprietari di siti web e i team IT che gestiscono strumenti di build self-hosted, AEU-I, il servizio di consulenza IT e infrastrutturale security-first di AEU Group, può aiutare a strutturare patch tempestive e revisioni degli accessi affinché una correzione nota non venga lasciata non applicata. La priorità immediata per chiunque gestisca JFrog Artifactory resta aggiornare alla build corretta per il proprio ramo e poi eseguire i controlli post-incidente descritti sopra.