Atlassian ha pubblicato nei primi giorni di ottobre un avviso per la CVE-2026-21589, una vulnerabilità con punteggio CVSS 9.3 che riguarda otto prodotti self-hosted dell'azienda. La falla consente a un attaccante remoto, senza alcuna autenticazione, di leggere file specifici all'interno della cartella radice (web root) dell'applicazione. Al momento della scrittura, le fonti consultate non riportano sfruttamento attivo e il bug non risulta nel catalogo KEV della CISA. Ma i prodotti coinvolti sono tra i più diffusi negli ambienti di sviluppo e collaborazione aziendali, e questo basta a rendere l'aggiornamento una priorità.

Cosa è successo

Secondo le fonti, la vulnerabilità è di tipo path traversal: un utente non autenticato può raggiungere file della web root che non dovrebbe poter servire. Il limite, che spiega perché il punteggio non sia ancora più alto, è che l'attaccante deve conoscere il nome e il percorso esatti del file bersaglio: non è possibile elencare le directory. Non c'è, secondo quanto riportato, modifica di file né esecuzione di codice diretta.

I prodotti interessati sono Jira Software e Jira Service Management Data Center, Confluence Data Center, Bitbucket Data Center, Bamboo Data Center, Crowd Data Center, oltre a Crucible e Fisheye. Le versioni corrette indicate dalle fonti sono:

  • 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
  • Confluence Data Center: 9.2.26, 10.2.19
  • Bitbucket Data Center: 9.4.26, 10.2.8, 10.5.1
  • 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 e Fisheye: 4.9.15

Le istanze Atlassian Cloud erano già state corrette prima della divulgazione: i clienti cloud non devono fare nulla. Anche l'avviso del Canadian Centre for Cyber Security sui prodotti Atlassian (AV26-829) elenca la stessa famiglia di prodotti Data Center e Server tra quelli interessati, ma senza il dettaglio dei numeri di versione.

Perché un CVSS 9.3 per "solo" lettura di file

È legittimo chiedersi come mai una falla che non permette l'esecuzione di codice sia classificata come critica. La risposta sta in ciò che tipicamente si trova in una web root di un'applicazione Java: file di configurazione, descrittori dell'applicazione, risorse interne. Se una qualsiasi di queste contiene credenziali, token, stringhe di connessione o dettagli utili a una fase successiva dell'attacco, la lettura anonima diventa il primo anello di una catena. Il fatto che servano nome e percorso esatti riduce la superficie, ma non la annulla: i percorsi di prodotti commerciali molto diffusi sono prevedibili e documentati. Questa è una valutazione nostra, non un dato confermato dalle fonti: nessuna di esse descrive scenari di sfruttamento concreti.

Cosa significa per le aziende italiane

Jira e Confluence sono ovunque nelle imprese italiane: dalle software house ai reparti IT di banche, assicurazioni e manifattura, fino a molte PA che gestiscono ticketing e documentazione tecnica. Bitbucket e Bamboo, a loro volta, custodiscono il codice sorgente e le pipeline di rilascio. L'esposizione dipende da un solo fattore: avere un'istanza Data Center o Server raggiungibile da Internet. In moltissime PMI e studi professionali l'istanza è pubblicata "per comodità" (accesso di collaboratori e fornitori) senza VPN davanti. Quelle sono le più a rischio.

C'è poi un aspetto di governance. Per i soggetti NIS2 (essenziali e importanti), la gestione delle vulnerabilità e la sicurezza della catena di fornitura software rientrano tra le misure di gestione del rischio: tenere un sistema di sviluppo critico non aggiornato, sapendo che esiste una correzione, è difficile da difendere in sede di verifica. E se da quei file letti dovessero emergere dati personali o credenziali con accesso a dati personali, scatterebbe la valutazione dell'obbligo di notifica al Garante entro 72 ore ai sensi del GDPR. Il consiglio pratico è decidere prima chi valuta e chi decide: un incidente in un sistema di sviluppo si gestisce meglio con un ruolo già assegnato.

Infine, un punto di realismo: i prodotti Atlassian sono un bersaglio storico. Non c'è sfruttamento noto oggi, ma l'esperienza degli ultimi anni su falle analoghe nei software di collaborazione dice che la finestra tra la divulgazione e i primi tentativi di sfruttamento si misura spesso in giorni. Aspettare il prossimo ciclo di patching mensile è la scelta sbagliata.

Cosa fare subito

  • Inventario: individuare tutte le istanze Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible e Fisheye self-hosted, comprese quelle "dimenticate" o di test.
  • Aggiornare alle versioni corrette elencate sopra, dando priorità alle istanze raggiungibili da Internet.
  • Se non si può aggiornare subito: togliere l'istanza dall'esposizione pubblica (VPN, allowlist di IP) e applicare le mitigazioni temporanee indicate da Atlassian, come regole WAF o di reverse proxy contro i pattern di path traversal e la configurazione RewriteValve di Tomcat. Sono misure tampone, non sostituiscono la patch.
  • Controllare i log di accesso delle ultime settimane alla ricerca di richieste anomale con sequenze di traversal o richieste a percorsi di configurazione interni.
  • Ruotare i segreti che potrebbero trovarsi nella web root o in file raggiungibili (credenziali di database, token, chiavi), almeno per le istanze esposte e non protette da WAF.
  • Monitorare il catalogo KEV della CISA e i bollettini ACN/CSIRT Italia per eventuali segnalazioni di sfruttamento.

L'aggiornamento è, in questo caso, a basso costo e ad alto rendimento: un intervento programmato in finestra di manutenzione evita di dover gestire in emergenza un incidente su sistemi che contengono il codice e la conoscenza dell'azienda.