Vulnerabilità Atlassian Data Center in Jira, Confluence o Bitbucket: la procedura per proteggere il server

Quando viene annunciata una vulnerabilità Atlassian Data Center critica in Jira, Confluence o Bitbucket, la reazione giusta si riduce a tre mosse, in quest’ordine: togliere al server l’accesso da Internet, installare la versione corretta indicata da Atlassian, poi passare al setaccio i log per capire se qualcuno è arrivato prima di voi. La patch chiude la porta. Non dice nulla di ciò che è successo mentre era aperta.

Questa guida prende come caso pratico la CVE-2026-21589, una vulnerabilità con punteggio 9,3 su 10 che riguarda tutta la gamma self-hosted del produttore. Il metodo resta lo stesso per gli avvisi dello stesso tipo, e ne arrivano con regolarità.

In breve: la soluzione rapida

• Verificate la vostra edizione. I prodotti Cloud vengono corretti da Atlassian senza alcun intervento da parte vostra. Le installazioni Data Center, quelle che ospitate in proprio, vanno gestite.
• Togliete subito il server da Internet: accesso limitato alla rete interna o alla VPN, anche se una pagina di login protegge già l’istanza.
• Fate uno snapshot della macchina e un backup del database, poi passate alla versione corretta del vostro ramo.
• Se l’aggiornamento deve aspettare, applicate la regola di blocco temporanea pubblicata da Atlassian.
• Esaminate i log di accesso e, al minimo dubbio, rinnovate tutti i segreti conservati sul server.

Riconoscere una vulnerabilità Atlassian Data Center

Sullo schermo non compare nulla. È la prima trappola di questo genere di falla: Jira risponde normalmente, i ticket si aprono, Confluence mostra le sue pagine. Nessun banner rosso, nessun rallentamento. Lo venite a sapere da un’email di Atlassian, da un bollettino del CSIRT nazionale, da un collega, o dal vostro scanner di vulnerabilità che diventa rosso.

Siete coinvolti se rientrate in entrambi i casi seguenti.

Primo caso, l’edizione. La CVE-2026-21589 colpisce i prodotti Data Center: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, oltre a Fisheye e Crucible. Atlassian indica che sono interessate tutte le versioni, comprese quelle non più mantenute. Se l’indirizzo del vostro Jira termina con atlassian.net, siete su Cloud: il produttore ha già corretto la propria piattaforma e dichiara di non avervi trovato alcuna traccia di sfruttamento.

Secondo caso, la versione. Si legge nell’amministrazione di ciascun prodotto, nella pagina delle informazioni di sistema, e il più delle volte nel piè di pagina dell’interfaccia. In Jira, la stessa pagina delle informazioni di sistema contiene una sezione con i percorsi dei file che vi servirà più avanti per ritrovare i log. Annotate il numero completo a tre cifre, per esempio 10.3.25: è l’ultima quella che conta.

Le vecchie edizioni Server meritano una riga a parte. Non ricevono più correzioni di sicurezza. L’avviso di Atlassian non le cita, ma la scheda CVE le colloca tra le versioni interessate senza correzione disponibile, secondo la lettura che ne dà The Hacker News. Considerate un’istanza Server vulnerabile e non riparabile.

Perché succede

La CVE-2026-21589 è una vulnerabilità di accesso arbitrario ai file. In parole semplici: una persona non autenticata, senza account, può chiedere al server di consegnarle alcuni file che si trovano nella directory radice dell’applicazione web e che non dovrebbero mai uscirne. La falla rientra nella categoria CWE-552, quella dei file accessibili a soggetti esterni.

Atlassian aggiunge due precisazioni. L’aggressore deve conoscere in anticipo il nome e il percorso esatti del file preso di mira, e non può elencare il contenuto delle cartelle. Questo limita i danni, senza per questo rassicurare: la struttura delle directory di un prodotto Atlassian è pubblica, identica da un’installazione all’altra, e documentata. Il produttore riconosce del resto che alcune configurazioni contengono file sensibili che aggravano il rischio.

Il punteggio di 9,3 in CVSS 4.0 dipende dai danni a cascata. Un file di configurazione letto significa a volte una password del database o un token API, quindi una porta verso qualcos’altro.

Prima di iniziare

Aprite un file di testo e annotate l’ora di ogni azione. In caso di incidente accertato, questa cronologia vi verrà chiesta dalla direzione, dall’assicurazione o dall’autorità per la protezione dei dati.

Non eliminate nulla. Né log, né file sospetti, né account strani. Una pulizia affrettata cancella le prove.

Soluzione 1: isolare il server da Internet

È la mossa della prima ora, e non rompe nulla. Atlassian chiede di limitare l’accesso esterno alle istanze raggiungibili da Internet, comprese quelle che richiedono l’autenticazione. La precisazione conta: la falla si sfrutta senza account, quindi la pagina di login non protegge da nulla.

1. Chiudere l’accesso pubblico

Sul firewall perimetrale o nel gruppo di sicurezza del vostro provider, limitate le porte web dell’istanza agli indirizzi della rete interna e della VPN. Se l’applicazione è servita da un reverse proxy Nginx, bastano due direttive nel blocco interessato, da adattare al vostro intervallo di indirizzi:

allow 10.8.0.0/24;
deny all;

Avvisate gli utenti: chi lavora da remoto passerà dalla VPN, e i clienti di un portale Jira Service Management pubblico perderanno l’accesso per la durata dell’intervento.

2. Verificare

Provate l’indirizzo pubblico da una connessione esterna, per esempio da un telefono con la rete mobile. Dovete ottenere un rifiuto o un timeout, non la pagina di login.

L’isolamento fa guadagnare tempo. Non sostituisce la patch, perché una postazione interna compromessa raggiunge comunque il server.

Soluzione 2: fare il backup, poi installare la versione corretta

È l’unica vera riparazione. Atlassian non pubblica più patch binarie da applicare sopra un’installazione: la correzione passa da una versione di manutenzione completa.

1. Congelare lo stato della macchina

Fate uno snapshot della macchina virtuale e un backup del database. Questa doppia copia serve come punto di ripristino e come elemento da conservare se dovesse rendersi necessaria un’indagine.

2. Scegliere la versione giusta

Restate nel vostro ramo e prendete la versione di manutenzione corretta. Per la CVE-2026-21589, l’avviso ufficiale indica le versioni seguenti. Controllatele sulla pagina di Atlassian prima di scaricare, perché il produttore a volte aggiorna i propri avvisi.

Se il vostro ramo non figura nell’elenco, non è più mantenuto: bisogna salire a un ramo che lo sia, il che rappresenta un lavoro più lungo. In tal caso applicate nel frattempo la soluzione 3.

3. Provare, poi aggiornare

Se disponete di un ambiente di staging, aggiornatelo per primo e verificate le app di terze parti, che sono la causa abituale degli aggiornamenti falliti. Altrimenti lo snapshot fa da rete di sicurezza. In un cluster, intervenite su tutti i nodi. Per Bitbucket, Atlassian precisa che sono interessati anche i mirror.

4. Verificare

Rileggete il numero di versione nell’amministrazione, aprite un ticket o una pagina di prova, controllate che le app siano attive. Riaprite l’accesso esterno solo dopo la soluzione 4.

Soluzione 3: applicare una mitigazione temporanea se l’aggiornamento deve aspettare

Atlassian propone delle regole di blocco e le definisce esso stesso limitate: non sostituiscono la correzione. Servono a reggere qualche giorno, il tempo di ottenere una finestra di manutenzione.

Il principio è rifiutare le richieste il cui indirizzo contiene due punti consecutivi attaccati a un separatore di percorso, in tutte le loro forme codificate. L’espressione esatta è lunga e si ricopia male. Prendetela dall’avviso ufficiale con un copia e incolla, senza ribatterla.

Tre punti in cui applicarla, a seconda del prodotto:

• Sul WAF o sul reverse proxy, per tutti i prodotti. È l’unica opzione per Fisheye e Crucible.
• In Tomcat, per Jira, Jira Service Management, Confluence, Bamboo e Crowd: attivazione del componente RewriteValve nel file server.xml, poi aggiunta di un file rewrite.config nella cartella WEB-INF, su ogni nodo, seguita da un riavvio.
• In Bitbucket: una regola inserita in cima al file urlrewrite.xml, nella cartella app/WEB-INF della directory di installazione, poi riavvio.

Fate una copia dei file prima di modificarli: un errore di sintassi in server.xml impedisce all’applicazione di avviarsi.

Soluzione 4: cercare tracce di compromissione

Atlassian scrive di non poter confermare se le vostre istanze siano state colpite. La verifica spetta a voi.

1. I log di accesso

L’indicatore fornito dal produttore è semplice da enunciare: nei log di accesso HTTP, cercate le richieste che contengono due punti consecutivi accostati a una barra, a una barra rovesciata o a un doppio simbolo dei due punti. Gli aggressori codificano spesso questi caratteri, da cui l’indicazione di decodificare gli indirizzi fino a due volte prima di cercare, o di applicare direttamente l’espressione di blocco alle righe grezze.

Guardate anche i log del reverse proxy e del WAF, spesso conservati più a lungo di quelli dell’applicazione.

Leggete poi il codice di risposta. Una richiesta sospetta seguita da un codice 200 e da un volume di dati non nullo merita una preoccupazione seria. Un codice 404 segnala piuttosto un tentativo fallito. L’avviso non entra nel dettaglio di questa distinzione: è una lettura di buon senso, non una garanzia.

2. Che cosa permette in seguito un file rubato

La lettura di un file non modifica nulla sul server. Il pericolo viene da ciò che l’aggressore fa con un segreto recuperato. Controllate quindi le possibili conseguenze:

• gli account amministratore creati o promossi senza una ragione nota;
• le app installate che nessuno ha richiesto;
• i token API e i collegamenti tra applicazioni comparsi al di fuori delle vostre operazioni;
• le attività pianificate del sistema e i servizi sconosciuti;
• le connessioni in uscita dal server verso indirizzi insoliti;
• le connessioni al database da una macchina diversa dal server applicativo.

In Jira, il file atlassian-jira-security.log, che si trova nella sottocartella log della directory dei dati, registra gli accessi e i rifiuti di accesso. Il log di audit di ciascun prodotto ricostruisce le modifiche di amministrazione.

Soluzione 5: reagire se trovate delle tracce

Mantenete il server isolato e conservate tutto: lo snapshot fatto in precedenza, una copia dei log fuori dalla macchina, la cronologia delle vostre azioni.

Rinnovate poi i segreti, partendo dal presupposto che tutto ciò che si trovava in un file possa essere stato letto. Password dell’account del database, account di collegamento alla directory LDAP o Active Directory, credenziali del server di posta, token API personali, collegamenti tra applicazioni, chiavi SSH e token di accesso di Bitbucket, certificati privati se la loro chiave era conservata nell’albero delle directory. L’avviso di Atlassian non dà indicazioni su questo punto; è però la conseguenza logica di una falla di lettura dei file.

Se un terzo ha apportato modifiche, prima correggete, poi ripristinate. Un backup precedente all’intrusione rimesso online su una versione vulnerabile viene compromesso di nuovo in giornata.

Resta l’aspetto legale. Jira e Confluence contengono quasi sempre dati personali: nomi, indirizzi email, ticket di clienti, a volte fascicoli delle risorse umane. Se la violazione presenta un rischio per le persone, il titolare del trattamento deve notificarla al Garante per la protezione dei dati personali entro 72 ore dal momento in cui ne è venuto a conoscenza, come prevede il GDPR. Il regolamento consente di fornire le informazioni in fasi successive: una notifica iniziale entro il termine, poi un’integrazione a indagine conclusa. Gli interessati vanno avvisati direttamente quando il rischio è elevato. Fuori dall’Italia, rivolgetevi all’autorità per la protezione dei dati del vostro paese.

Tabella riepilogativa

Se nulla funziona

L’aggiornamento fallisce: ripristinate lo snapshot, lasciate il server isolato, applicate la mitigazione, poi aprite un ticket al supporto Atlassian. Allegate il prodotto, la versione di partenza, la versione di destinazione, il database utilizzato, il log di avvio e l’elenco delle app. Un ticket completo viene gestito molto più in fretta.

Sospettate un’intrusione senza avere i mezzi per analizzarla: rivolgetevi a un fornitore specializzato nella risposta agli incidenti. Se c’è il sospetto di un reato informatico, potete sporgere denuncia alla Polizia Postale. Se avete una polizza cyber, denunciate l’incidente prima di qualsiasi intervento pesante, alcuni contratti lo richiedono.

Evitare che si ripeta

La misura più conveniente è anche la più semplice: smettere di esporre direttamente questi strumenti. Un Jira interno non ha bisogno di rispondere al mondo intero. Mettetelo dietro una VPN o un gateway di accesso Zero Trust, che verifica identità e dispositivo prima di lasciar passare la minima richiesta. Se un portale clienti deve restare pubblico, isolatelo dietro un WAF e collocate il server in una zona di rete separata dal resto.

Seguite gli avvisi alla fonte. Atlassian pubblica i propri avvisi critici per i prodotti Data Center il martedì, e un bollettino mensile il terzo martedì di ogni mese. Aggiungete gli avvisi dello CSIRT Italia e riservate subito dopo una finestra di manutenzione. Restare su una versione con supporto a lungo termine semplifica le cose: il produttore vi riporta le correzioni critiche.

Infine, guardate l’orizzonte. Le edizioni Server non vengono più corrette, e Atlassian ha annunciato la fine programmata dell’offerta Data Center per Jira, Confluence e Crowd, con il mantenimento delle correzioni critiche fino alla scadenza. Bitbucket e Bamboo non seguono questo calendario. Ogni avviso di questo tipo è un’occasione per quantificare una migrazione.

Domande frequenti

Jira Cloud e Confluence Cloud sono interessati da questa falla?

Atlassian ha corretto la propria piattaforma Cloud e non vi ha trovato tracce di sfruttamento. Ai clienti Cloud non è richiesta alcuna azione.

Il mio server è raggiungibile solo dall’interno, devo aggiornare comunque?

Sì. La versione resta vulnerabile, diminuisce soltanto il numero dei possibili aggressori. Basta una postazione infetta o un fornitore collegato alla VPN. L’urgenza è minore, l’obbligo no.

La pagina di login non basta a proteggermi?

No. La falla si sfrutta senza autenticazione. Nella sua indicazione di isolamento Atlassian include in modo esplicito le istanze pubbliche dotate di autenticazione.

Bisogna davvero cambiare tutte le password se non trovo alcuna traccia?

Se i log coprono tutto il periodo di esposizione e sono puliti, non è indispensabile. Se sono incompleti o troppo brevi, rinnovate almeno la password del database, l’account della directory e i token API.

La mia edizione Server non ha una correzione, che cosa fare?

Toglierla da Internet in via definitiva, lasciarla raggiungibile solo tramite VPN e pianificare la migrazione. Nessuna regola di filtraggio compensa a lungo l’assenza di aggiornamenti.

Una vulnerabilità Atlassian Data Center si gestisce meglio con una procedura scritta in anticipo che con buoni riflessi improvvisati. Se avete incontrato un blocco durante l’aggiornamento o trovato un metodo di controllo dei log che vi ha fatto risparmiare tempo, raccontatelo nei commenti: sarà utile ad altri amministratori.