La fabbrica del software che esegue i comandi di chi passa: CVE-2026-63077 su TeamCity

Che cos'è la macchina di cui stiamo parlando

TeamCity è un server di integrazione e distribuzione continua. In pratica: è il computer aziendale che, ogni volta che uno sviluppatore consegna del codice, lo prende, lo compila, esegue i test, impacchetta il risultato e — molto spesso — lo pubblica dove il software va a girare davvero.

Per fare questo mestiere ha bisogno di due cose che lo rendono un bersaglio particolare. La prima sono le credenziali: chiavi dei repository, token dei registri di container, password dei server di produzione, certificati di firma. Un server di build che non può accedere a niente non serve a niente. La seconda è la fiducia a valle: il pacchetto che esce da lì viene installato senza sospetti, perché è il pacchetto ufficiale dell'azienda.

Chi prende il controllo di un server di build non ha bucato un sito. Ha bucato la catena di montaggio.

Che cosa è successo

Il 10 luglio 2026, secondo l'advisory di JetBrains, il ricercatore Antoni Tremblay segnala privatamente una vulnerabilità in TeamCity On-Premises, seguendo la politica di divulgazione coordinata dell'azienda. La falla riceve l'identificativo CVE-2026-63077.

La descrizione tecnica pubblicata da JetBrains è asciutta e vale la pena leggerla per intero: «An unauthenticated attacker could exploit the vulnerability via the TeamCity agent polling protocol to bypass authentication checks and execute arbitrary operating system commands with the privileges of the TeamCity server process».

Tre elementi in una riga sola. Non serve autenticarsi. Il canale usato è il protocollo con cui gli agenti di build interrogano il server — un canale interno di servizio, non l'interfaccia con cui parlano le persone. E il risultato non è la lettura di un file: sono comandi di sistema operativo, con i privilegi con cui gira il processo del server.

La descrizione su NVD è ancora più breve: «In JetBrains TeamCity before 2026.1.3, 2025.11.7 unauthenticated remote code execution was possible via the agent polling protocol». Il punteggio assegnato dal CNA di JetBrains e registrato da NVD è CVSS 3.1 pari a 9.8, vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: dalla rete, complessità bassa, nessun privilegio, nessuna interazione dell'utente, impatto alto su riservatezza, integrità e disponibilità. Il record NVD risulta in stato Analyzed.

1. 10 luglio 2026
   La segnalazione

   Antoni Tremblay riporta la falla a JetBrains in divulgazione coordinata.

2. 27 luglio 2026
   La pubblicazione

   Il record CVE-2026-63077 compare su NVD con CVSS 9.8.

3. 5 agosto 2026
   In CISA KEV

   La CVE entra nel catalogo delle vulnerabilità sfruttate davvero.

4. 8 agosto 2026
   La scadenza

   Termine di rimedio fissato da CISA per le agenzie federali statunitensi.

Il punto che merita di essere detto per intero

Nell'advisory, JetBrains scrive: «At the time of publishing this advisory, we are not aware of any active exploitation of this vulnerability». È una frase corretta e onesta — descrive quello che il produttore sapeva nel momento in cui pubblicava.

Pochi giorni dopo, la CISA inserisce la stessa CVE nel catalogo Known Exploited Vulnerabilities. Quel catalogo non elenca vulnerabilità pericolose in teoria: elenca vulnerabilità per cui esistono prove di sfruttamento reale. La voce riporta dateAdded: 2026-08-05, dueDate: 2026-08-08, cwes: ["CWE-502"], knownRansomwareCampaignUse: "Unknown".

Le due affermazioni non si contraddicono: sono due fotografie scattate in momenti diversi. Ma insieme dicono qualcosa di pratico, e non è la prima volta che questo sito lo osserva su un caso diverso: «non risulta sfruttata» è un'informazione con una data di scadenza molto breve, e non è un criterio con cui rinviare un aggiornamento. Su una falla non autenticata con punteggio 9.8, la finestra fra la pubblicazione dell'advisory e i primi tentativi reali si misura in giorni.

Una discrepanza da segnalare, perché è visibile a chiunque confronti le fonti: CISA classifica la vulnerabilità sotto CWE-502, «Deserialization of Untrusted Data», e intitola la voce JetBrains TeamCity Deserialization of Untrusted Data Vulnerability. JetBrains, nel proprio advisory, parla di bypass dei controlli di autenticazione ed esecuzione di comandi, senza usare la parola deserializzazione. Le due letture sono compatibili — una deserializzazione non sicura è un modo classico di ottenere esattamente quell'effetto — ma il meccanismo interno non è stato descritto pubblicamente in dettaglio, e non lo ricostruiamo per congettura.

Perché il danno non si ferma al server colpito

JetBrains descrive le conseguenze in modo esplicito: «a successful attack could expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines».

Le ultime cinque parole sono la parte che conta. L'integrità degli artefatti di build. Se qualcuno esegue comandi sul server che compila il vostro software, può fare due cose molto diverse fra loro: rubare le credenziali che trova — brutto ma circoscritto, si ruotano — oppure modificare ciò che il server produce. Nel secondo caso il pacchetto firmato che esce dalla pipeline è genuino dal punto di vista di chi lo riceve: viene dalla sorgente giusta, con la firma giusta, dal server giusto. Solo che dentro c'è qualcosa in più.

È lo stesso meccanismo che abbiamo visto in altri casi di compromissione della catena di fornitura del software: chi verifica la provenienza vede una spunta verde, perché la provenienza è effettivamente quella. La provenienza certifica dove un pacchetto è stato costruito, non cosa è stato messo dentro durante la costruzione.

1. 01
   Accesso non autenticato

   il protocollo di polling degli agenti è raggiungibile via HTTP(S)
2. 02
   Esecuzione di comandi

   con i privilegi del processo del server TeamCity
3. 03
   Credenziali e artefatti

   token, chiavi e firme in memoria; e ciò che la pipeline consegna a valle

Cosa fare, in ordine

Aggiornare a 2025.11.7 o 2026.1.3. Sono le versioni che contengono la correzione. JetBrains raccomanda l'aggiornamento come prima opzione, anche perché porta con sé altre correzioni di sicurezza.

Se non potete aggiornare, installate il plugin di patch. JetBrains lo ha pubblicato per TeamCity 2017.1 e successive. Dalla versione 2024.03 in poi il server scarica da solo i plugin di patch disponibili e avvisa gli amministratori, se le notifiche sono configurate: si trovano in Administration | Updates, sotto Available security updates. Per le versioni dalla 2017.1 alla 2018.1 serve un riavvio del server; dalla 2018.2 il plugin si attiva senza riavvio. Attenzione al limite dichiarato: «The security patch plugin will address only the vulnerability described above».

Se usate TeamCity Cloud, non dovete fare niente. JetBrains scrive che le misure sono già state applicate e che non c'è evidenza di ambienti Cloud sfruttati attraverso questa vulnerabilità.

Togliete il server dall'esposizione diretta a internet. È la raccomandazione che JetBrains dà come pratica di lungo periodo, ed è quella che vale oltre questa singola CVE: «consider requiring VPN connections or implementing an additional security layer», perché «even exposing the TeamCity login screen or REST API can provide attackers with potential entry points to exploit newly disclosed vulnerabilities». Un server di build non ha quasi mai bisogno di essere raggiungibile dal mondo intero.

Riducete i privilegi del processo. Il danno di questa falla è delimitato dai permessi con cui gira il server: «run the TeamCity server with the minimum operating system privileges required for normal operation». JetBrains raccomanda inoltre di tenere il server su host dedicati, separati dagli agenti di build.

Se eravate esposti, l'aggiornamento non chiude l'indagine. Con l'esecuzione di comandi di sistema, le credenziali conservate sul server vanno considerate potenzialmente lette: token dei repository, chiavi di distribuzione, certificati di firma. Vanno ruotati. E vale la pena confrontare gli artefatti prodotti nella finestra sospetta con quelli attesi — è la parte più noiosa e l'unica che risponde alla domanda che conta davvero, cioè se è uscito dalla catena di montaggio qualcosa che non doveva uscirne.

Cosa non sappiamo

Non è pubblico quando sia iniziato lo sfruttamento reale, né quante organizzazioni siano state raggiunte. CISA non pubblica i dettagli delle prove che portano una CVE in KEV, non indica un attore e registra l'uso in campagne ransomware come «Unknown». Non risultano, alla data di questo dossier, report di risposta agli incidenti pubblicati da vendor di threat intelligence su questa specifica campagna. La pagina Security issues fixed di JetBrains, citata fra le note della voce CISA, al momento della verifica non riportava un'entrata dedicata a questa CVE: il riferimento primario del produttore resta l'articolo sul blog di TeamCity.