CVE-2026-82329: attività di sfruttamento del bypass dell’autenticazione di JFrog Artifactory

CVE-2026-82329 è una vulnerabilità critica (CVSS 9,8) nelle installazioni self-hosted di JFrog Artifactory che consente di aggirare l’autenticazione senza essere autenticati e permette a un hacker anonimo di generare un token di accesso con privilegi completi di amministratore della piattaforma tramite un’unica richiesta HTTP. Da quando JFrog ha divulgato la vulnerabilità il 28 agosto 2026, il team di ricerca sulle minacce di Fastly ha osservato che il traffico associato a questa CVE sulla nostra piattaforma globale è passato da un’attività iniziale di sondaggio limitata a scansioni di massa opportunistiche.

Per contribuire a mitigare i tentativi di sfruttamento della vulnerabilità, WAF Next-Gen di Fastly ha rilasciato una patch virtuale per CVE-2026-82329 che consente ai clienti di proteggere immediatamente le proprie istanze. Per le misure correttive e i dettagli sulle patch del fornitore, consulta la sezione Raccomandazioni operative alla fine di questo post. Raccomandiamo vivamente a tutti i clienti di applicare immediatamente le patch ai propri sistemi per risolvere questa vulnerabilità critica.

Contesto

JFrog Artifactory è uno dei repository aziendali di file binari e Pacchetti più ampiamente distribuiti, e conserva gli artefatti di costruire di una parte considerevole delle organizzazioni che producono software. Questo lo rende un bersaglio di grande valore. Un hacker che ottiene il controllo amministrativo di un registro degli artefatti si trova direttamente nella catena di fornitura del software e può accedere alle credenziali archiviate, creare utenti e repository e manomettere gli artefatti pubblicati.

La vulnerabilità

La vulnerabilità CVE-2026-82329 (CWE-287, autenticazione non corretta) si trova nel servizio JFrog Access che precede Artifactory. Quando Access costruisce l’insieme delle "chiavi di join" attendibili del cluster con cui può verificare le firme, suddivide una stringa di configurazione usando le virgole come delimitatori senza filtrare le voci vuote. In un’installazione predefinita, il valore di configurazione è vuoto, quindi una stringa vuota viene inserita tra le chiavi di join attendibili.

La chiave vuota è cruciale perché il suo segreto di firma è completamente deterministico: è un valore fisso di 32 byte derivato da un input vuoto. Qualsiasi hacker può quindi falsificare un JWT "join" HS256 valido, firmato con quel segreto noto. Il token falsificato contiene un ID della chiave (kid) uguale al valore SHA-256 della stringa vuota:

kid = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855   // SHA256("")

Presentando quel token all’endpoint cluster-join che non richiede autenticazione, quest’ultimo genera un token di accesso amministrativo limitato al servizio, che viene poi scambiato con un token della piattaforma con privilegi amministrativi completi e senza scadenza. L’intera catena ha inizio con una sola richiesta:

POST /access/api/v1/registry/join HTTP/1.1
Host: artifactory.example
Content-Type: application/json

{"token":"<forged HS256 JWT, kid = SHA256(\"\")>", ...}

Un peer legittimo del cluster usa lo stesso metodo e percorso, ma firma con una vera chiave di join (non vuota), quindi il suo kid è un hash diverso. Questo unico elemento distintivo, il kid della stringa vuota, è ciò che separa un attacco dal normale traffico tra nodi.

Un tentativo di sfruttamento riuscito si distingue dal traffico legittimo tra nodi. Sebbene l’endpoint di join senza autenticazione restituisca HTTP 201 in entrambi i casi, l’attacco si basa su un token contraffatto che utilizza uno specifico ID della chiave deterministico (l’hash SHA-256 di una stringa vuota). Pertanto, una risposta HTTP 201 associata a questo specifico ID della chiave costituisce una prova altamente affidabile della compromissione.

Attività delle minacce

Dopo la divulgazione pubblica della vulnerabilità da parte di JFrog, i tentativi di sfruttamento hanno seguito il consueto schema di impiego a fini offensivi, registrando un forte aumento non appena è diventato disponibile un exploit pubblico. Il giorno della divulgazione (28 agosto) non è stata rilevata alcuna attività di sfruttamento e il volume complessivo è rimasto minimo nelle 48 ore successive, con un numero di tentativi di sondaggio a una cifra tra il 29 e il 30 agosto. La prima attività di rilievo è emersa il 31 agosto, con circa 75.000 tentativi, sebbene la maggior parte di questo volume fosse riconducibile a servizi di sicurezza offensiva. L’escalation si è intensificata notevolmente il 1° settembre in seguito al rilascio di un exploit pubblico, portando il numero di tentativi a poco più di 171.000. L’attività ha raggiunto il picco il 2 settembre, con circa 406.000 tentativi: è stata la più alta concentrazione di Paesi di server di origine distinti e di Indirizzi IP utilizzati per gli attacchi nell’intero periodo osservato.

Oltre alla curva dei volumi, emergono due aspetti. 

• Innanzitutto, l’ampiezza dell’attività di targeting: il 1° e il 2 settembre, ciascuno degli indirizzi IP ha inviato richieste indiscriminatamente a migliaia di host distinti, effettuando scansioni anziché attacchi mirati.

• In secondo luogo, gli indirizzi IP dei server di origine degli attacchi sono aumentati rapidamente, passando dai pochi iniziali a quasi 1.400 in un solo giorno. Il traffico si è diffuso rapidamente dopo che il PoC è stato reso pubblico e gli strumenti sono diventati facilmente reperibili.

Il panorama degli attori delle minacce

L’analisi del traffico legato allo sfruttamento della vulnerabilità, osservato sulla nostra piattaforma globale dal 28 agosto al 2 settembre 2026, rivela tre categorie principali: i test iniziali di sicurezza offensiva, seguiti da due distinti livelli operativi degli attori delle minacce, ossia le scansioni di massa e i tentativi di sfruttamento mirati.

Prime attività: ricerca sulla sicurezza offensiva e test

Il traffico iniziale registrato il 31 agosto potrebbe facilmente essere scambiato per l’inizio di uno sfruttamento malevolo su larga scala. Tuttavia, quel giorno i fornitori di soluzioni per la sicurezza offensiva e i servizi di ricerca rappresentavano quasi il 98% del volume (circa 73.000 delle ~75.000 richieste totali) per la maggior parte degli indirizzi IP di origine. Entro il 1° settembre, l’attività dei ricercatori e dei fornitori si era ridotta a livelli trascurabili, mentre lo sfruttamento effettivo era diventato la principale causa del traffico.

Livello 1: scansione massiva ad alto volume

Le scansioni automatizzate su vasta scala costituiscono la stragrande maggioranza del traffico legato agli attacchi. Tra le 16:40 e le 19:48 UTC circa del 1° settembre, un gruppo coordinato di istanze VPS noleggiate presso reti di hosting in Francia e negli Stati Uniti ha preso di mira in modo aggressivo l’endpoint join. In questo intervallo di circa tre ore, ciascun host di origine ha sondato migliaia di sistemi distinti utilizzando la stringa User-Agent JFrogArtifactory/7.146.25 (corrispondente a una costruire notoriamente vulnerabile). Questa attività si è intensificata il 2 settembre, quando abbiamo osservato che un unico provider VPS ha generato la maggior parte dei tentativi registrati nell’arco della giornata, durante un’impennata prolungata nelle ore serali diretta verso migliaia di obiettivi, senza filtrare preventivamente quelli con distribuzioni attive di Artifactory.

Livello 2: sfruttamento mirato

A differenza di chi effettuava tentativi indiscriminati su larga scala, un gruppo più ristretto di attori ha condotto deliberatamente tentativi di exploit mirati. Diverse di queste fonti hanno utilizzato lo User-Agent predefinito fornito dall’exploit Proof of Concept pubblico: jfrt/0/7.161.19. Sebbene questi attori specializzati abbiano generato un volume di richieste notevolmente inferiore, la loro attività ha evidenziato una conoscenza precisa della vulnerabilità sottostante.

Raccomandazioni operative 

• Applica subito la patch. Aggiorna Artifactory ospitato in proprio a una costruire che risolve il problema: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20 (quella corrispondente al branch in uso).

• Se eri esposto, presumi che si sia verificata una compromissione. Una patch non revoca i token già generati. Ruota la chiave di join della piattaforma, revoca i token di accesso emessi dal 28 agosto 2026 ed esegui un audit per individuare eventuali utenti amministratori e repository non previsti, nonché modifiche inattese alla configurazione.

• Applica una patch virtuale. I clienti di WAF Next-Gen di Fastly dovrebbero abilitare la regola basata su modello per CVE-2026-82329.

• Esamina i tuoi log. Cerca tutte le richieste all’endpoint di join e considera una risposta HTTP 201 come conferma di una compromissione. Gli User-Agent usati dagli hacker nell’elenco degli indicatori di compromissione (IOC) sono un primo filtro poco costoso, ma non affidarti solo a questi: possono essere modificati con estrema facilità.

Conclusione

CVE-2026-82329 è un case study conciso sulla rapidità con cui si sviluppa oggi la catena di sfruttamento delle vulnerabilità. Una vulnerabilità critica sfruttabile senza autenticazione in un prodotto centrale per la catena di fornitura è passata dalla divulgazione a scansioni su scala Internet in circa 72 ore, fino a una compromissione confermata non appena è apparso un POC pubblico. Le misure difensive da adottare non sono particolarmente innovative, ma sono efficaci: applica rapidamente la patch, considera l’esposizione una compromissione fino a prova contraria e distribuisci una patch virtuale per guadagnare tempo. Fastly continuerà a monitorare le attività relative a questa CVE.

Indicatori di compromissione (IOC)

Varianti degli endpoint: 

• POST /access/api/v1/registry/join

• POST /access/api/v1/registry/join/router

• POST /access/api/v1/registry/join/router?override=true

Indicatore del payload: JWT kid = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Segnale di successo: risposta HTTP 201 da questi endpoint

User-Agent:

• jfrt/0/7.161.19

• JFrog-Access/7.141.17 

• JFrogArtifactory/7.146.25

Indirizzi IP di origine con elevati volumi di traffico (campione):

213.136.72[.]87, 89.117.49[.]147, 45.33.75[.]219, 23.92.20[.]11, 173.255.226[.]148, 195.154.157[.]234, 62.210.87[.]212, 45.79.190[.]169, 163.172.132[.]245

Documenti di riferimento

• Avviso ufficiale di JFrog: JFrog sicurezza Advisories 

• Documentazione della patch virtuale di Fastly: Patch virtuale per CVE-2026-82329 

• Template Nuclei per il rilevamento: Template Nuclei per CVE-2026-82329 

• Pubblicazioni della ricerca sulla sicurezza di Fastly: Fastly ricerca sulla sicurezza