Una vulnerabilità critica di JetBrains TeamCity, corretta a fine luglio 2026, è ora sfruttata anche da gruppi ransomware. La notizia riguarda direttamente le aziende che usano TeamCity on-premises o che si affidano a fornitori software con pipeline di sviluppo interne: quando viene colpita la piattaforma che compila e distribuisce il software, il rischio non è solo il fermo operativo, ma anche la compromissione di credenziali, configurazioni e artefatti di build.
Per una PMI questo significa una cosa molto concreta: un sistema tecnico apparentemente “di sviluppo” può diventare un punto di ingresso con effetti sull’intera infrastruttura aziendale. Se TeamCity è esposto su Internet e non è stato aggiornato, la priorità è intervenire subito.
Cosa è successo
Il 24 settembre 2026 la CISA, l’agenzia statunitense per la cybersicurezza, ha aggiornato il proprio catalogo delle vulnerabilità sfruttate attivamente segnalando che la falla CVE-2026-63077 di JetBrains TeamCity viene utilizzata anche in attacchi ransomware.
La vulnerabilità era stata corretta da JetBrains il 25 luglio 2026 nelle versioni TeamCity On-Premises 2025.11.7 e 2026.1.3. Secondo il produttore, si tratta di un problema critico di bypass dell’autenticazione che, tramite il protocollo di polling degli agenti TeamCity, consente a un attaccante non autenticato con accesso HTTP(S) di eseguire comandi sul sistema operativo con i privilegi del processo server di TeamCity.
In pratica, un aggressore può entrare senza credenziali valide e prendere controllo del server applicativo. Da lì può accedere a dati, configurazioni, credenziali memorizzate, alterare lo stato del server e compromettere l’integrità degli artefatti di build e delle pipeline CI/CD a valle.
Perché TeamCity è un bersaglio così delicato
TeamCity è una piattaforma CI/CD usata per automatizzare compilazione, test e distribuzione del software. Non è un semplice strumento accessorio: spesso custodisce token, chiavi di accesso, variabili d’ambiente, connessioni a repository Git, credenziali cloud e processi di rilascio verso ambienti di test o produzione.
Quando una vulnerabilità colpisce questo tipo di sistema, il problema va oltre il singolo server. Chi attacca può:
- usare TeamCity come punto di ingresso nella rete aziendale;
- sottrarre segreti tecnici e credenziali operative;
- modificare build o pacchetti software;
- compromettere il processo di rilascio;
- estendere l’attacco ad altri sistemi connessi.
Per questo TeamCity è considerato un obiettivo ad alto valore sia per gruppi ransomware sia per attori più sofisticati. La CISA ricorda che, da ottobre 2023, ha già classificato quattro vulnerabilità di TeamCity come sfruttate attivamente in the wild, tutte usate anche in campagne ransomware.
Dalla correzione agli attacchi reali
La sequenza dei fatti è importante, perché mostra quanto si sia ridotta la finestra utile per reagire.
- 25 luglio 2026: JetBrains pubblica la correzione per CVE-2026-63077.
- 5 agosto 2026: CISA inserisce la falla nel catalogo KEV delle vulnerabilità sfruttate attivamente e ordina alle agenzie federali statunitensi di proteggere i propri sistemi entro tre giorni.
- 7 agosto 2026: JetBrains conferma che la vulnerabilità è stata sfruttata in attacchi reali, pubblica indicatori di compromissione e invita i clienti che non possono aggiornare subito a limitare l’accesso alle sole reti fidate.
- 24 settembre 2026: CISA aggiorna nuovamente il catalogo e indica che la vulnerabilità è ora sfruttata anche da gruppi ransomware.
Il messaggio per le aziende è chiaro: tra la pubblicazione della patch e l’uso in operazioni ransomware il tempo disponibile per mettere in sicurezza i sistemi è stato molto breve.
Quanti server sono ancora esposti
Secondo i dati riportati da Shadowserver, dopo la pubblicazione della patch erano stati individuati circa 700 server TeamCity esposti su Internet e vulnerabili. Ora i sistemi non aggiornati tracciati sarebbero poco più di 160.
Il dato può sembrare in calo, ma non deve rassicurare troppo. Un numero relativamente piccolo di server vulnerabili può comunque rappresentare un bacino molto interessante per chi cerca accessi ad alto impatto. Inoltre, un server CI/CD compromesso può offrire molto più valore di un normale endpoint, perché spesso collega sviluppo, infrastruttura e distribuzione applicativa.
Il rischio non riguarda solo chi sviluppa software “in casa”
È facile pensare che il problema interessi soltanto software house o reparti DevOps strutturati. In realtà il perimetro è più ampio.
Molte aziende usano applicativi personalizzati, integrazioni sviluppate da fornitori esterni o ambienti interni gestiti da consulenti. Anche se TeamCity non è amministrato direttamente dall’ufficio IT aziendale, può comunque essere parte della catena che aggiorna software, portali, gestionali o servizi esposti a clienti e dipendenti.
Questo significa che una PMI dovrebbe porsi almeno tre domande:
- usiamo TeamCity direttamente, anche solo per un progetto specifico?
- un nostro partner o software vendor lo utilizza per rilasciare componenti che ci riguardano?
- esistono server di sviluppo o test pubblicati su Internet senza piena visibilità da parte della direzione IT?
Se a una sola di queste domande la risposta è “forse”, vale la pena fare una verifica immediata.
Cosa significa per la tua azienda
Se nella tua organizzazione è presente TeamCity on-premises, oppure se hai dubbi sulla sua esposizione, le azioni prioritarie sono pratiche e abbastanza chiare.
1. Verifica subito la versione installata Controlla se il server TeamCity è aggiornato alle versioni corrette indicate da JetBrains, cioè 2025.11.7 o 2026.1.3, oppure a una release successiva. Se il sistema è ancora vulnerabile, pianifica l’aggiornamento con massima urgenza.
2. Riduci l’esposizione su Internet Se non puoi aggiornare nell’immediato, limita l’accesso al server alle sole reti fidate, come raccomandato anche da JetBrains. Esporre pubblicamente una piattaforma CI/CD aumenta il rischio in modo significativo.
3. Cerca segnali di compromissione JetBrains ha condiviso indicatori di compromissione: vanno verificati nei log e negli apparati di sicurezza. In presenza di accessi anomali, esecuzioni sospette o modifiche non autorizzate, tratta il caso come un possibile incidente in corso.
4. Ruota credenziali e token potenzialmente esposti Se il server è stato vulnerabile ed era raggiungibile dall’esterno, considera a rischio le credenziali memorizzate nella piattaforma: account tecnici, token API, chiavi di integrazione, accessi a repository e servizi cloud.
5. Controlla l’integrità delle pipeline e degli artefatti Non basta “mettere la patch”. Occorre verificare che build, script, agenti, job automatizzati e pacchetti rilasciati non siano stati alterati. In un contesto CI/CD, la compromissione del processo può avere effetti invisibili ma persistenti.
6. Rafforza il processo di patch management Questo caso conferma quanto sia critico aggiornare rapidamente i sistemi esposti. Dove possibile, conviene affiancare al patching un servizio strutturato di monitoraggio e gestione degli endpoint e dei server, così da ridurre i tempi tra allerta e intervento. In quest’ottica può essere utile rivedere le procedure di gestione desktop e sistemi IT e i livelli di presidio contrattuale.
7. Prepara il piano di continuità operativa Se un attacco ransomware colpisce un server centrale, il vero danno è il fermo. Backup verificati, copie isolate e tempi di ripristino realistici fanno la differenza. Per ambienti critici è opportuno valutare soluzioni di backup remoto e procedure di recovery testate.
8. Valuta l’impatto sui dati e sugli obblighi normativi Se la compromissione può aver coinvolto credenziali personali, dati aziendali o informazioni di terzi, bisogna verificare anche i profili di conformità e gestione dell’incidente. In questi casi è utile coordinare la risposta tecnica con gli adempimenti privacy previsti dal GDPR.
Una tendenza che si ripete
La notizia su TeamCity si inserisce in una dinamica ormai consolidata: le vulnerabilità critiche nei sistemi di infrastruttura vengono sfruttate molto rapidamente, e quando il sistema compromesso gestisce autenticazione, automazione o distribuzione software, l’impatto può essere sproporzionato rispetto al numero di server esposti.
La stessa CISA, negli ultimi mesi, ha diffuso avvisi analoghi su altri prodotti presi di mira da gruppi ransomware. Il punto non è il singolo marchio o il singolo bug: è il modello di attacco. Gli aggressori cercano piattaforme centrali, ben connesse e spesso trascurate perché considerate “strumenti interni”.
Per le imprese italiane questo si traduce in una priorità gestionale, non solo tecnica: sapere quali sistemi sono esposti, chi li amministra, con quali tempi vengono aggiornati e quali credenziali custodiscono.
Domande frequenti
TeamCity riguarda solo le software house?
No. Anche aziende manifatturiere, studi professionali o PMI di servizi possono usare applicazioni sviluppate internamente o da fornitori che si appoggiano a TeamCity per build e rilasci.
Se abbiamo già applicato la patch siamo al sicuro?
La patch è essenziale, ma da sola non basta se il server è rimasto esposto mentre la vulnerabilità era sfruttabile. Vanno controllati log, credenziali, configurazioni e integrità delle pipeline.
Cosa fare se non so se TeamCity è presente in azienda?
Occorre una verifica rapida dell’inventario IT e dei servizi esposti, coinvolgendo anche eventuali fornitori software o partner che gestiscono ambienti di sviluppo e rilascio.