Il 5 agosto la CISA, l'agenzia federale statunitense per la cybersicurezza, ha inserito la CVE-2026-63077 nel catalogo delle vulnerabilità sfruttate attivamente (Known Exploited Vulnerabilities), fissando per le agenzie federali una scadenza di remediation all'8 agosto: tre giorni, il termine più stretto previsto dalla direttiva BOD 26-04. È la conferma di quanto scrivevamo il 29 luglio: la falla critica di JetBrains TeamCity non sarebbe rimasta a lungo un problema teorico.

Cosa è cambiato in una settimana

Il 27 luglio JetBrains aveva pubblicato l'advisory per una vulnerabilità di deserializzazione di dati non attendibili con punteggio CVSS 9.8, che consente a un attaccante non autenticato di aggirare i controlli di accesso ed eseguire comandi arbitrari sul sistema operativo con i privilegi del processo TeamCity. Il vettore è il protocollo di polling degli agent, raggiungibile via HTTP o HTTPS: lo stesso canale che ogni installazione usa per far comunicare i build agent con il server centrale. Sono interessate tutte le versioni On-Premises; le correzioni sono nelle release 2025.11.7 e 2026.1.3, con in aggiunta un plugin di patch di sicurezza installabile dalla versione 2017.1 in poi. TeamCity Cloud, gestito direttamente da JetBrains, è già stato messo in sicurezza.

All'epoca dell'advisory JetBrains dichiarava di non essere a conoscenza di sfruttamenti attivi. Circa una settimana dopo la divulgazione pubblica, CISA ha rovesciato quel quadro inserendo la CVE nel KEV. Un dettaglio va sottolineato con onestà: non esistono al momento informazioni pubbliche sugli attacchi, né indicatori di compromissione, né attribuzioni, né dati sul volume delle scansioni. L'inserimento nel KEV richiede a CISA prove di sfruttamento reale, ma l'agenzia non ne pubblica i dettagli. Chi difende si trova quindi nella condizione peggiore: sfruttamento confermato, nessun IOC su cui costruire una caccia mirata.

Sette giorni, non sette settimane

Il copione è quello che TeamCity conosce bene. Nel 2023 la CVE-2023-42793 fu sfruttata su larga scala da gruppi legati all'intelligence nordcoreana e poi da APT29; nel marzo 2024 la CVE-2024-27198 vide comparire exploit pubblici a poche ore dall'advisory, subito adottati da affiliati ransomware. La differenza rispetto ad allora è la compressione dei tempi: la finestra fra pubblicazione della patch e inizio dello sfruttamento di massa si misura ormai in giorni. La patch stessa è la mappa: chi la analizza ricava la logica del bug e costruisce l'exploit, spesso prima che il team IT abbia finito di pianificare la finestra di manutenzione.

Cosa significa per le aziende italiane

TeamCity On-Premises è molto diffuso nelle software house italiane e nei reparti di sviluppo interni delle aziende medio-grandi, spesso in installazioni che nessuno tocca da mesi perché "funzionano". Il problema non è però il server in sé: è tutto ciò che il server tocca. Un'istanza di continuous integration custodisce le credenziali per i repository di codice, i token per i registry di artefatti e per gli ambienti cloud, le chiavi di firma, i secret iniettati nelle pipeline. E soprattutto produce il software che finisce in produzione — o, per chi sviluppa su commessa, nei sistemi dei clienti.

Qui sta il rischio concreto per il mercato italiano, fatto in larga parte di fornitori software di piccole e medie dimensioni che lavorano per la pubblica amministrazione, per la sanità, per il manifatturiero e per il settore bancario. Una compromissione della build non si ferma al perimetro di chi la subisce: si propaga a valle verso ogni cliente che riceve l'artefatto, con la firma e i crismi dell'ufficialità. È la dinamica di SolarWinds, e non richiede un attaccante di livello statale per essere replicata su scala più piccola.

C'è poi un problema pratico che rende questa vulnerabilità più insidiosa di altre: il protocollo degli agent non si filtra facilmente. Molte installazioni sono esposte su internet proprio perché devono ricevere connessioni da agent remoti, runner su cloud e sviluppatori in mobilità. Bloccare la porta sul firewall significa fermare le build. Chi si è raccontato che "tanto è dietro VPN" farebbe bene a verificarlo con una scansione esterna, non con un diagramma di rete.

Il contesto normativo

Per i soggetti essenziali e importanti ai sensi della NIS2 (recepita in Italia con il D.lgs. 138/2024), una compromissione del sistema di build rientra a pieno titolo fra gli incidenti potenzialmente significativi: preallarme al CSIRT Italia entro 24 ore, notifica entro 72 ore, relazione finale entro un mese. Ma il punto più delicato viene prima dell'incidente: il decreto richiede esplicitamente misure di gestione delle vulnerabilità e di sicurezza della catena di approvvigionamento. Un TeamCity lasciato non patchato per settimane, con una CVE già presente nel catalogo KEV e sfruttamento confermato, è una posizione difficile da sostenere davanti a un'ispezione o a un'assicurazione cyber.

Sul fronte privacy, va verificato se sul server transitano dati personali: capita più spesso di quanto si ammetta, fra dump di produzione usati per i test, log applicativi e ambienti di staging popolati con dati reali. In quel caso scatta la valutazione ai sensi del GDPR, con le 72 ore per la notifica al Garante se emerge un rischio per i diritti degli interessati.

Cosa fare subito

  • Aggiornare oggi a TeamCity 2025.11.7 o 2026.1.3. Se il ciclo di aggiornamento richiede tempi lunghi, installare il plugin di patch di sicurezza (attivabile a caldo dalla versione 2018.2; sulle versioni 2017.1-2018.1 richiede il riavvio del server).
  • Se non è possibile intervenire immediatamente, rimuovere il server dall'esposizione diretta a internet, limitando l'accesso a IP noti tramite firewall o reverse proxy con allow-list.
  • Assumere la compromissione se il server è stato raggiungibile da internet e non patchato dal 27 luglio: ruotare tutti i secret, i token di deploy, le chiavi SSH e le credenziali dei registry configurate in TeamCity, non solo le password degli utenti.
  • Verificare l'integrità degli artefatti prodotti dopo il 27 luglio, confrontando hash e, dove disponibili, ricostruendo le build su un'infrastruttura pulita.
  • Controllare account e token creati di recente: nuovi utenti amministrativi, token API generati fuori orario, modifiche ai build step non riconducibili a una richiesta di sviluppo.
  • Analizzare i log del server e la telemetria EDR alla ricerca di processi figli anomali del processo Java di TeamCity (cmd.exe, powershell.exe, bash, curl, wget) e di connessioni in uscita verso destinazioni non note.
  • Non interpretare l'assenza di indicatori pubblici come assenza di attacchi: in questa fase la caccia va impostata sui comportamenti, non sulle firme.

La scadenza dell'8 agosto vale formalmente per le agenzie federali statunitensi, ma il calendario degli attaccanti non distingue fra giurisdizioni. Per chi ha un TeamCity esposto, è ragionevole trattare quella data come la propria.