Atlassian CVE-2026-21589: lettura file non autenticata su 8 prodotti Data Center

Il 5 ottobre 2026 Atlassian ha divulgato la CVE-2026-21589: un'unica vulnerabilità di accesso arbitrario ai file, con punteggio 9.3, che consente a un attaccante senza alcun account di leggere file specifici dalla directory radice della web application su otto dei suoi prodotti self-hosted Data Center — Jira, Confluence, Bitbucket e altri cinque. L'attaccante deve conoscere nome e percorso esatti del file e non può elencare il contenuto della directory. Sembra un freno importante. Per software enterprise standardizzato, il cui layout dei file è di dominio pubblico, non lo è.

Notizia in evoluzione — pubblicata alle 14:36 (12:36 UTC) del 6 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-21589
Prodotto / versioni colpite	Bitbucket; Confluence; Jira Software; Jira Service Management; Bamboo; Crowd; Crucible; Fisheye — Data Center, tutte le versioni precedenti alle correzioni sotto
Corretta in	Bitbucket 9.4.26 · 10.2.8 · 10.5.1; Confluence 9.2.26 · 10.2.19; Jira Software 9.12.40 · 10.3.26 · 11.3.12; Jira Service Management 5.12.40 · 10.3.26 · 11.3.12; Bamboo 10.2.24 · 12.1.12; Crowd 6.3.7 · 7.0.3 · 7.1.7 · 7.2.4; Crucible/Fisheye 4.9.15
CVSS	9.3 Critica · CVSS 4.0 · assegnato da Atlassian (CNA); vettore CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H. Record NVD in stato Received (non ancora valutato in modo indipendente)
Sfruttata attivamente	Nessuna evidenza secondo Atlassian, che ha corretto i prodotti Cloud e indagato; nessuna dichiarazione sulle istanze self-hosted Data Center
CISA KEV	Non presente (versione catalogo 2026.10.04)
PoC pubblico	Nessuno citato da Atlassian o NVD al 2026-10-06
Advisory ufficiale	Advisory di sicurezza Atlassian, CVE-2026-21589

Cosa espone la CVE-2026-21589 su Atlassian Data Center

La falla appartiene alla classe del path traversal: l'applicazione restituisce un file sotto la propria web root in risposta a una richiesta non autenticata che esce dal percorso previsto. La formulazione di Atlassian è precisa sui limiti — "This Arbitrary File Access vulnerability allows an unauthenticated attacker to access specific files within the web application root directory" — richiedendo la conoscenza preventiva di nome e percorso esatti, senza possibilità di enumerare la directory.

Allora perché 9.3? Basta leggere il vettore CVSS 4.0. La riservatezza sul sistema vulnerabile è Alta (VC:H) e ogni dimensione subsequent-system è anch'essa Alta (SC:H/SI:H/SA:H). È il motore di scoring che dice cosa conta: il valore non è la lettura del file in sé, ma cosa contiene quel file e cosa consente di fare il contenuto trafugato. Una credenziale, un token API, una chiave di firma SAML, un segreto di sessione o una stringa di connessione al database estratti da un file di configurazione non sono un fastidio in sola lettura: sono il primo anello di una catena che finisce in accesso autenticato, movimento laterale e, nel caso peggiore, compromissione completa.

I prodotti coinvolti sono quelli che custodiscono il codice sorgente di un'organizzazione, i suoi runbook di incident, la documentazione interna e il collante delle identità:

• Bitbucket Data Center — repository sorgente, segreti CI, chiavi di deploy.
• Confluence Data Center — wiki interni, spesso con credenziali e diagrammi di architettura incorporati.
• Jira Software / Jira Service Management Data Center — ticketing, record di change, talvolta PII dei clienti.
• Crowd Data Center — la directory delle identità e l'hub di single sign-on per tutti gli altri.
• Bamboo, Crucible, Fisheye — pipeline di build e code review, adiacenti agli stessi segreti.

Ogni versione supportata è colpita finché non si raggiunge la build corretta. Non esiste alcuna esenzione per le "sole installazioni vecchie".

Perché "serve il percorso" frena pochissimo un attaccante

La precondizione si legge come un margine di sicurezza: non puoi elencare la directory, quindi devi già sapere cosa cerchi. Il problema è che per il software commerciale diffuso in massa i percorsi interessanti non sono un segreto — sono identici su ogni installazione del pianeta e documentati dal vendor.

"Gli attaccanti non possono enumerare, dovrebbero tirare a indovinare." Non tirano a indovinare. Scaricano lo stesso tarball di Confluence che hai scaricato tu, leggono dove scrive confluence.cfg.xml, annotano dove Tomcat tiene la sua configurazione e lanciano quei percorsi esatti contro ogni host esposto.

La storia stessa di Atlassian è la prova. Confluence e Jira Data Center/Server sono stati tra i prodotti enterprise più sistematicamente sfruttati in massa degli ultimi quattro anni — sia CVE-2023-22515 (un difetto di escalation di privilegi) sia CVE-2022-26134 (una injection OGNL) sono presenti nel catalogo Known Exploited Vulnerabilities di CISA, e ciascuna è passata da advisory a sfruttamento su scala internet in una finestra brevissima. Lo schema è costante: una falla Atlassian critica, non autenticata e raggiungibile dalla rete attira scansioni automatiche quasi subito, perché il parco installato è enorme e i bersagli si assomigliano tutti. "Nessuna evidenza di sfruttamento" alla data di divulgazione è lo stato della finestra, non una previsione.

Remediation

1. Sono esposto?

Controlla la build in esecuzione di ogni prodotto Atlassian Data Center che gestisci, non solo i tre famosi. Nella UI di amministrazione di ciascun prodotto la versione è in Amministrazione → Informazioni di sistema; da shell:

# Confluence / Jira / Bitbucket riportano la versione nell'installazione
grep -R "version" "$ATLASSIAN_HOME"/*/atlassian-*.properties 2>/dev/null
# oppure interroga il footer dell'istanza / REST:
curl -s https://tuo-host/rest/applinks/1.0/manifest | grep -i version

Sei vulnerabile su qualunque versione inferiore alla build corretta per quel prodotto. Inventaria in particolare Crowd, Bamboo, Crucible e Fisheye — sono quelli che i team dimenticano di avere ancora in funzione.

2. Patch — versioni corrette esatte

Aggiorna alla prima release corretta sul tuo branch, secondo l'advisory di Atlassian:

Prodotto	Versioni corrette
Bitbucket Data Center	9.4.26, 10.2.8, 10.5.1
Confluence Data Center	9.2.26, 10.2.19
Jira Software Data Center	9.12.40, 10.3.26, 11.3.12
Jira Service Management Data Center	5.12.40, 10.3.26, 11.3.12
Bamboo Data Center	10.2.24, 12.1.12
Crowd Data Center	6.3.7, 7.0.3, 7.1.7, 7.2.4
Crucible / Fisheye	4.9.15

La patch è l'unica vera correzione. Tutto ciò che segue serve a coprire l'intervallo prima di arrivarci.

3. Non puoi applicare la patch ora? Controlli compensativi

Atlassian è esplicita: sono limitati e non sostituiscono la patch. In ordine di efficacia:

• Togli l'istanza da internet. La prima raccomandazione dell'advisory è rimuovere l'istanza dalla rete pubblica finché non puoi applicare la patch. Un bug non autenticato raggiungibile solo dalla tua VPN o dalla rete di management è un'altra fascia di rischio.
• Blocca il traversal su WAF o reverse proxy. Rifiuta le richieste in cui .. è adiacente a /, \ o ::. Testa la regola contro le tue varianti codificate (%2e%2e%2f, doppia codifica, separatori misti) prima di fidartene.
• RewriteValve di Tomcat. Aggiungi regole di rewrite lato server in rewrite.config per scartare i pattern di traversal prima che raggiungano l'applicazione.
• Bitbucket in particolare — aggiungi la regola equivalente nel suo urlrewrite.xml.

4. Cerca segni di compromissione

L'accesso è non autenticato e chirurgico, quindi assomiglia a traffico ordinario. Mappa la caccia su ciò che puoi effettivamente vedere:

• Log di accesso web/proxy per richieste contenenti sequenze di traversal codificate o grezze (..%2f, ..\, ..::) verso i tuoi host Atlassian — è il segnale T1190 (Exploit Public-Facing Application).
• Richieste che risolvono su percorsi di file fuori dalle route previste dell'applicazione, soprattutto hit su nomi di file di configurazione (*.cfg.xml, *.properties, file keystore) che restituiscono 200.
• Poiché il vero bottino è un segreto trafugato — T1552.001 (Unsecured Credentials: Credentials In Files) — osserva il segnale di seconda fase: una sessione autenticata mai vista prima, l'uso di un token API o un login al database che segue una lettura non autenticata anomala.

5. Bonifica e verifica

Prima la patch, poi dai per scontato che qualsiasi cosa leggibile dalla web root possa essere trapelata. Ruota ogni segreto che risiedeva in un file di configurazione o nella home dell'applicazione — credenziali del database, password di bind SMTP e LDAP, token API, segreti dei client OAuth e chiavi di firma SAML/SSO tramite Crowd. Conferma la correzione dopo la patch: la versione in esecuzione deve essere pari o superiore alla build corretta e le richieste di traversal che prima funzionavano ora devono restituire 403/404.

Cosa non si sa ancora

• Se qualche istanza self-hosted Data Center sia stata sfruttata. La dichiarazione "nessuna evidenza" di Atlassian riguarda i prodotti Cloud; la telemetria del Data Center risiede presso ciascun operatore.
• Una valutazione CVSS da parte di NVD — il record è ancora in stato Received, quindi il 9.3 è il punteggio CNA di Atlassian, non ancora confermato in modo indipendente.
• L'esistenza di un proof-of-concept pubblico. Nessuno è citato dal vendor o da NVD mentre scriviamo; vista la storia del prodotto, aspettati che cambi in fretta.
• Se CISA aggiungerà la CVE al suo catalogo KEV (non presente alla versione 2026.10.04).

Dove ti lascia tutto questo

La parte difficile della CVE-2026-21589 non è la patch — è l'ordine e il raggio d'impatto: otto prodotti, ciascuno sul proprio branch, ciascuno che forse custodisce un segreto in grado di aprire gli altri, e un intervallo prima di poter prendere finestre di manutenzione su tutti. Quel problema di sequenziamento è esattamente ciò per cui è costruito l'AI Remediation Advisor di Zero Hunt. Ordina le correzioni per sfruttabilità reale, non per il solo CVSS — un bug non autenticato raggiungibile dalla rete su un Confluence esposto a internet viene prima della stessa CVE su un Crucible dietro la VPN — fornisce la build corretta esatta per prodotto con note di rollout e rollback, propone la regola WAF anti-traversal come controllo compensativo mentre pianifichi gli aggiornamenti, e poi ri-verifica ogni correzione con la stessa prova che ha dimostrato il problema, così "abbiamo applicato la patch" diventa un'evidenza e non un'affermazione.

Sotto quella classifica c'è la domanda a cui la tabella delle versioni non sa rispondere: quel file vulnerabile è davvero raggiungibile sulla tua build e topologia, e il segreto che trapela si concatena a qualcosa? Zero Hunt è un red team autonomo basato su AI che gira on-premise sui propri modelli, con un essere umano nel ciclo per ogni azione che tocca un sistema vivo. Il suo swarm di 10 agenti identifica prodotto e versione esatti, analizza quella versione per capire quali file sono raggiungibili da input e — black-box di default, gray-box con le tue credenziali — scrive un proof-of-concept per singolo bersaglio che dimostra se la fuga si concatena ad accesso reale oppure no, così spendi la finestra di manutenzione prima sulle istanze davvero sfruttabili. Ogni finding è firmato al momento della scrittura e concatenato per hash, per quella catena di prove che un supervisore testerà poi contro i tuoi stessi log.

Se il tuo parco include Atlassian Data Center, guarda come funziona la validazione continua attivata dai cambiamenti, e se c'è di mezzo l'orologio di un regolatore, la nostra guida al penetration testing automatizzato spiega dove si inserisce nel dovere di test.