JetBrains ha pubblicato il 27 luglio un advisory per la CVE-2026-63077, una vulnerabilità critica con punteggio CVSS 9.8 che colpisce tutte le versioni di TeamCity On-Premises, il diffusissimo server di continuous integration e delivery usato dai team di sviluppo software. Un attaccante senza credenziali, con semplice accesso HTTP o HTTPS al server, può aggirare i controlli di autenticazione ed eseguire comandi arbitrari sul sistema operativo con i privilegi del processo TeamCity. Al momento non risultano sfruttamenti attivi, ma la storia recente di questo prodotto suggerisce di non aspettare a scoprirlo.

Cosa è successo

La falla risiede nel protocollo di polling degli agent, il canale con cui i build agent comunicano con il server centrale per ricevere i lavori da eseguire. Abusando di questo protocollo, un attaccante non autenticato può scavalcare l'autenticazione ed arrivare all'esecuzione di comandi. A seconda dei privilegi con cui gira il processo server, un attacco riuscito può esporre dati, configurazioni e credenziali salvate in TeamCity, modificare lo stato del server e compromettere l'integrità degli artefatti di build e delle pipeline a valle.

La vulnerabilità è stata segnalata privatamente a JetBrains il 10 luglio dal ricercatore Antoni Tremblay, nell'ambito del programma di divulgazione coordinata. La correzione è arrivata nelle versioni 2025.11.7 e 2026.1.3; per chi non può aggiornare, JetBrains ha rilasciato un plugin di patch di sicurezza installabile su tutte le versioni dalla 2017.1 in poi. Sulle versioni dalla 2017.1 alla 2018.1 il plugin richiede un riavvio del server, dalla 2018.2 può essere attivato a caldo. Gli utenti di TeamCity Cloud non devono fare nulla: l'infrastruttura gestita da JetBrains è già stata corretta e le verifiche non hanno trovato tracce di tentativi di sfruttamento.

Il precedente che pesa: TeamCity nel mirino di APT e ransomware

Se JetBrains dedica un advisory con toni così netti a una falla non ancora sfruttata, un motivo c'è. Nel 2023 la CVE-2023-42793, anch'essa una RCE senza autenticazione, venne sfruttata su larga scala prima dai gruppi legati all'intelligence nordcoreana e poi da APT29, il gruppo dell'intelligence estera russa già responsabile dell'attacco a SolarWinds, con campagne che CISA e NSA documentarono per mesi. Nel marzo 2024 la storia si ripeté con la CVE-2024-27198: gli exploit pubblici comparvero a poche ore dalla pubblicazione dell'advisory e furono rapidamente adottati da affiliati ransomware per installare backdoor sui server esposti.

Il copione è collaudato: advisory pubblico, reverse engineering della patch, exploit funzionante nel giro di ore o giorni, scansioni di massa su tutta la superficie esposta a internet. Per chi difende, la finestra utile tra la pubblicazione della correzione e l'inizio degli attacchi è ormai questione di giorni. E questa volta il protocollo vulnerabile è lo stesso che ogni installazione usa per parlare con i propri agent, quindi difficile da filtrare senza interventi mirati.

Perché il CI/CD è un obiettivo di supply chain

Un server CI/CD non è un applicativo qualsiasi: è il punto in cui si concentrano le chiavi del regno dello sviluppo software. Contiene le credenziali per accedere ai repository di codice, i token per i registry e per gli ambienti cloud, i secret iniettati nelle pipeline. Soprattutto, produce gli artefatti che finiscono in produzione e, per le software house, nei sistemi dei clienti. Chi compromette la build compromette tutto ciò che la build produce: è la lezione di SolarWinds, che proprio da un sistema di build compromesso distribuì una backdoor a migliaia di organizzazioni. Un attaccante che ottiene l'esecuzione di codice su TeamCity può alterare silenziosamente un artefatto firmato e farlo arrivare a valle con tutti i crismi dell'ufficialità.

Cosa significa per le aziende italiane

In Italia TeamCity è diffuso nelle software house, nelle divisioni IT di banche e assicurazioni e in molte PMI tecnologiche, spesso in installazioni on-premises esposte su internet per servire team distribuiti e collaboratori esterni. Sono esattamente le installazioni che questa falla mette a rischio: l'advisory ricorda che anche la sola schermata di login o le API REST raggiungibili dall'esterno offrono agli attaccanti un punto d'appoggio.

C'è poi una dimensione normativa che il consulente non può ignorare. Per i soggetti NIS2, la sicurezza dello sviluppo software e della catena di fornitura rientra tra le misure dell'articolo 21: un fornitore di software che si fa compromettere la pipeline diventa il vettore d'attacco verso i propri clienti, con responsabilità contrattuali e reputazionali pesanti. Le aziende che sviluppano per soggetti essenziali o importanti devono aspettarsi che i clienti chiedano garanzie proprio su questo. E in prospettiva il Cyber Resilience Act europeo renderà la gestione delle vulnerabilità nel ciclo di vita del software un obbligo di legge per chi immette prodotti digitali sul mercato UE. Un incidente sulla pipeline che tocca dati personali o servizi critici può inoltre far scattare notifiche multiple: al Garante Privacy entro 72 ore per il GDPR, a CSIRT Italia per gli incidenti significativi NIS2.

Cosa fare subito

  • Aggiornare alla versione 2025.11.7 o 2026.1.3, oppure installare il plugin di patch per le versioni dalla 2017.1 in poi (riavvio necessario fino alla 2018.1).
  • Verificare gli aggiornamenti automatici: dalla versione 2024.03 TeamCity scarica da solo i plugin di sicurezza e li propone in Administration, sezione Updates, sotto Available security updates.
  • Togliere il server da internet: accesso solo via VPN o dietro un livello di autenticazione aggiuntivo. Nessun server CI/CD dovrebbe esporre login e API al mondo intero.
  • Ridurre i privilegi del processo server al minimo indispensabile e tenere il server su un host dedicato, separato dai build agent, come raccomanda la stessa JetBrains.
  • Se il server è stato esposto senza patch: ruotare i secret e le credenziali salvate in TeamCity (token dei repository, chiavi cloud, credenziali dei registry) e verificare l'integrità delle configurazioni di build recenti.
  • Monitorare i log per accessi anomali al protocollo agent e per registrazioni di agent inattesi.