TeamCity CVE-2026-63077: RCE non autenticata sulla macchina che rilascia il codice

Il 27 luglio 2026 JetBrains ha pubblicato l'advisory per CVE-2026-63077: un attaccante non autenticato con accesso HTTP(S) a un server TeamCity On-Premises può aggirare i controlli di autenticazione tramite il protocollo di polling degli agent ed eseguire comandi di sistema operativo con i privilegi del processo server. CVSS 9.8. Tutte le versioni On-Premises sono affette. Al momento della pubblicazione JetBrains non aveva evidenza di sfruttamento; a oggi non esiste un proof-of-concept pubblico e il CVE non è nel catalogo CISA KEV.

È esattamente per quest'ultima frase che questo articolo esce adesso e non fra una settimana. Le due precedenti falle critiche pre-auth sullo stesso prodotto sono passate da advisory a compromissione di massa più in fretta di quanto duri un normale ciclo di approvazione dei change. La finestra in cui vi trovate oggi è l'unica parte di questa cronologia che potete controllare.

Cosa fa CVE-2026-63077 a un server TeamCity

Il difetto è una deserializzazione di dati non attendibili (CWE-502) raggiungibile attraverso il protocollo di polling degli agent. Il trasporto predefinito di TeamCity è unidirezionale: è il build agent ad aprire una connessione HTTP(S) in uscita verso il server e a interrogarlo periodicamente per ricevere lavoro. È una scelta di design corretta dal punto di vista della sicurezza — evita di dover consentire al server di raggiungere le reti degli agent — ma implica anche che l'endpoint che accetta traffico agent debba essere raggiungibile da qualunque macchina esegua build, e che quell'endpoint parli un protocollo a oggetti serializzati.

L'analisi di Rapid7 conferma il profilo: vettore di rete, complessità bassa, nessun privilegio richiesto, nessuna interazione utente, esecuzione arbitraria di comandi con i privilegi del processo server. La vulnerabilità è stata segnalata privatamente a JetBrains il 10 luglio 2026 dal ricercatore Antoni Tremblay e corretta 17 giorni dopo nelle versioni 2025.11.7 e 2026.1.3. TeamCity Cloud è già stato aggiornato da JetBrains e non richiede azioni.

L'impatto dichiarato dal vendor è insolitamente esplicito. Daniel Gallo, Solutions Engineering Lead di JetBrains, ha spiegato a Help Net Security che uno sfruttamento riuscito può esporre dati, configurazioni e credenziali memorizzate in TeamCity, consentire la modifica dello stato del server e compromettere gli artefatti di build e le pipeline CI/CD a valle. Tradotto: tre incidenti distinti impacchettati in un solo CVE — una violazione di credenziali, una di integrità e una di supply chain.

Il precedente delle 48 ore: TeamCity ci è già passato due volte

È la terza volta in tre anni che una falla critica pre-auth su TeamCity diventa la notizia del momento.

Settembre 2023 — CVE-2023-42793. L'SVR russo, tracciato come APT29, l'ha sfruttata su larga scala. Il 13 dicembre 2023 FBI, CISA e NSA hanno pubblicato con partner internazionali l'advisory AA23-347A, riportando oltre 100 server TeamCity compromessi tra Stati Uniti, Europa, Asia e Australia. La motivazione indicata nell'advisory è la formulazione più chiara del threat model che qualcuno abbia scritto: l'accesso a un server TeamCity dà all'attaccante "accesso al codice sorgente di quello sviluppatore, ai suoi certificati di firma e alla capacità di sovvertire i processi di compilazione e deployment". FortiGuard Labs ha documentato la fase post-exploitation nelle reti vittima: esecuzione di DLL via scheduled task, dump di credenziali con ntdsutil, movimento laterale su WMIC/RDP/SMB, account amministrativi locali nascosti e C2 incanalato attraverso le API di OneDrive e Dropbox.

Marzo 2024 — CVE-2024-27198. Bypass di autenticazione, divulgato il 4 marzo. SecurityWeek ha riportato che GreyNoise ha osservato tentativi di sfruttamento da oltre una dozzina di IP distinti lo stesso giorno, e che LeakIX ha contato circa 2.700 istanze non aggiornate il 5 marzo, scese a circa 1.700 il giorno successivo — di cui circa 1.400 mostravano già la creazione di utenti fraudolenti. Gli attaccanti creavano da 3 a 300 account per server, con nomi utente alfanumerici di otto caratteri. I payload successivi erano tutt'altro che sofisticati: ransomware Jasmin, attività riconducibile a BianLian, XMRig, Spark RAT.

Circa l'80% della popolazione esposta compromessa entro 48 ore da un advisory pubblico. Non da uno stato-nazione: da chiunque abbia lanciato per primo il PoC.

Il build server è infrastruttura Tier-0 che nessuno governa come Tier-0

Chiedete a un team di sicurezza quali sono i loro asset Tier-0 e sentirete nominare i domain controller, l'identity provider, il vault PAM, forse l'hypervisor. Quasi mai il build server. Quel vuoto è il vero reperto di questa storia; CVE-2026-63077 è solo l'occasione.

	Domain controller	Server CI/CD
Custodisce credenziali per	La directory	Ogni ambiente su cui rilascia, più VCS, cloud, registry
Può modificare	L'identità	Il codice che gira in produzione
Finestra di change	Esiste un percorso di patch d'emergenza	"Lo gestisce il team di sviluppo"
In perimetro di pentest	Sempre	Raramente: è "tooling interno"
Monitorato da	SOC, primo livello	Chi riceve l'email di build fallita
Raggiungibile da internet	Mai	Spesso, per far funzionare agent remoti e webhook

Un server CI/CD è un sistema di identità che si autentica verso tutto, più un servizio di esecuzione codice di cui tutto ciò che sta a valle si fida, gestito con una cadenza di aggiornamento dettata dal calendario di rilascio di un team di sviluppo. Gli attaccanti tornano su TeamCity non perché JetBrains scriva codice peggiore di Microsoft, ma perché questa classe di asset è sistematicamente sottoclassificata.

Che cosa cerca davvero l'attaccante

La domanda istintiva dopo un advisory di RCE è "hanno preso root sulla macchina?". Su un build server è la domanda sbagliata, perché la macchina in sé vale poco e tutto ciò a cui punta vale moltissimo.

Difensore: Abbiamo aggiornato TeamCity mercoledì mattina, sei giorni dopo l'advisory. Tutto a posto.

Attaccante, se fosse entrato lunedì: Va benissimo. Il primo giorno ho letto dalle credenziali memorizzate sul server le vostre deploy key VCS, le access key AWS, i token di pubblicazione sui registry e il materiale di firma degli artefatti. Ho aggiunto un build step a una libreria che nessuno rilegge. La patch ha chiuso la mia via d'ingresso. Non ha revocato nulla di ciò che ho preso e non ha ricostruito nulla di ciò che ho toccato.

Applicare la patch a un server CI/CD dopo una RCE che espone credenziali ripristina la disponibilità, non la fiducia. La fiducia torna solo dopo rotazione e verifica degli artefatti — ed è il motivo per cui il runbook qui sotto dedica più spazio al punto 5 che al punto 2.

Remediation

1. Sono affetto?

Tutte le versioni On-Premises precedenti a 2025.11.7 / 2026.1.3 sono vulnerabili. TeamCity Cloud no.

# Versione via REST API (può richiedere autenticazione su installazioni irrigidite)
curl -sk -H "Accept: application/json" https://<teamcity-host>/app/rest/server

# Fonte autorevole: Administration → Diagnostics riporta il build number esatto
# Anche i log di avvio lo contengono:
grep -m1 -iE 'TeamCity server version|build [0-9]{5}' \
  "<TeamCity Server Home>/logs/teamcity-startup.log"

Poi rispondete alla domanda sull'esposizione, che pesa più della versione:

# La porta HTTP(S) del server è raggiungibile fuori dalle reti degli agent?
# Default 8111, oppure 443 dietro reverse proxy.
curl -sk -m 10 -o /dev/null -w "%{http_code}\n" https://<teamcity-host>/login.html

# Su quale interfaccia è in ascolto?
ss -tlnp | grep -E ':(8111|443)'

Se una rete non-agent riesce a completare una richiesta HTTP verso il server, trattatelo come P1.

2. Patch — versioni corrette esatte

Aggiornare a 2025.11.7 oppure 2026.1.3. Se non riuscite ad aggiornare stanotte, JetBrains distribuisce un security patch plugin che copre CVE-2026-63077 per TeamCity 2017.1 e successive; su 2024.03+ compare in Administration → Updates → Available security updates. Le versioni 2017.1–2018.1 richiedono un riavvio del server dopo l'installazione, dalla 2018.2 no. Il plugin corregge solo questo CVE: è un ponte, non un sostituto dell'aggiornamento.

3. Non potete applicare la patch subito? Controlli compensativi

• Limitate la porta HTTP(S) del server alle subnet degli agent e alla VPN amministrativa, su firewall o security group. È la prima raccomandazione di JetBrains stessa e azzera l'intera superficie non autenticata per gli attaccanti da internet.
• Terminate il TLS su un reverse proxy e richiedete certificati client (mTLS) sui path degli agent, così una richiesta non autenticata non raggiunge mai il codice di deserializzazione. Richiede di riconfigurare gli agent perché presentino il certificato: pianificate il rollout e usate l'ACL di rete come controllo immediato.
• Fate girare il servizio TeamCity con un account di sistema a privilegi minimi. L'esecuzione di comandi "con i privilegi del processo server" è grave quanto lo sono quei privilegi.
• Non esponete la pagina di login né le REST API su internet.

4. Cercate segni di compromissione

Se il server era raggiungibile da una rete non fidata prima della patch, partite dal presupposto che sia compromesso e dimostrate il contrario. I log stanno in <TeamCity Server Home>/logs.

• Account e token fraudolenti — Administration → Users, cercando account che non avete creato, in particolare con ruolo System Administrator. Poi i token per utente su /app/rest/users/id:<id>/tokens. La firma della campagna 2024 erano 3–300 nuovi utenti con nomi alfanumerici casuali di otto caratteri: stavolta aspettatevi un pattern diverso, quindi filtrate per data di creazione, non per nome.
• Build step piantati — cercate nel tree di configurazione dei progetti la classica forma scarica-ed-esegui:

  grep -rEl 'curl |wget |/dev/tcp|powershell -enc|base64 -d' \
    "<TeamCity Data Directory>/config/projects/"
  

  Controllate anche le VCS root per URL alterati e i trigger di build per schedulazioni che nessuno ha aggiunto.
• Plugin malevoli — i plugin girano dentro la JVM del server, quindi un solo .zip piantato è una RCE persistente. Elencate <TeamCity Data Directory>/plugins/ per mtime e riconciliate con Administration → Plugins List.
• Agent non riconosciuti — il protocollo agent è la superficie d'attacco: verificate ogni agent autorizzato contro l'inventario.
• Artefatti di deserializzazione — in teamcity-server.log cercate InvalidClassException, StreamCorruptedException, ClassNotFoundException e stack trace con ObjectInputStream addensati intorno al traffico agent. I tentativi di gadget falliti sono più rumorosi di quelli riusciti. Abilitate teamcity-rest.log (disattivato di default) prima di averne bisogno.
• Mappatura ATT&CK — T1190 (sfruttamento di applicazione esposta) → T1136.001 / T1098 (creazione e manipolazione di account) → T1505 (server software component, il plugin) → T1552.001 (credenziali nei file) → T1195.002 (compromissione della supply chain software) → T1567.002 (esfiltrazione verso cloud storage, come nel pattern OneDrive/Dropbox di APT29).

5. Bonifica e verifica

L'ordine conta: isolare, applicare la patch, poi ruotare. Ruotare i segreti mentre la RCE è ancora raggiungibile significa consegnare all'attaccante quelli nuovi.

1. Fate uno snapshot del disco per la forensics prima di toccare qualsiasi cosa.
2. Ruotate in ordine di raggio d'impatto: prima le chiavi e i certificati di firma degli artefatti (una chiave di firma rubata sopravvive a ogni altro segreto), poi le access key IAM cloud e le sessioni STS, i token di pubblicazione sui package registry, le credenziali dei container registry, le deploy key VCS e le coppie SSH, i token API di TeamCity, tutte le password utente con revoca delle sessioni, i token di autorizzazione degli agent e le credenziali del database TeamCity. Non saltate una classe perché "non era memorizzata su quella macchina": prima controllate l'albero dei parametri per segreti incorporati.
3. Verificate la provenienza degli artefatti: ricostruite dall'ultimo tag ritenuto integro su infrastruttura pulita e confrontate gli hash con ciò che avete rilasciato. Riverificate le firme di tutto ciò che è stato promosso nella finestra di esposizione (codesign --verify --deep --strict, signtool verify /pa, gpg --verify). Una discrepanza di hash che non sapete spiegare è un incidente, non un problema di build non deterministica: dimostratelo in un senso o nell'altro.
4. Revocate l'autorizzazione a tutti gli agent e riautorizzate solo le macchine che controllate.
5. Confermate che la correzione tenga: versione aggiornata riportata, porta del server in ascolto solo verso reti fidate, nessuna connessione in uscita stabilita e inspiegata dall'host.

Per i soggetti in perimetro NIS2 e DORA, documentate cronologia, registro delle rotazioni ed evidenze di verifica mentre le producete. Ricostruire tutto questo tre settimane dopo per un auditor è nettamente peggio che catturarlo in diretta.

Dove si colloca Zero Hunt

Il filo che lega 2023, 2024 e ora 2026 non è "TeamCity è insicuro". È che il tooling interno raggiungibile da internet viene classificato a basso rischio, escluso dal perimetro di test e aggiornato secondo un calendario di sviluppo — e gli avversari hanno capito benissimo di quale classe di asset stiamo parlando.

Lo swarm di 10 agenti AI di Zero Hunt — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, sotto un AI Controller — esiste per chiudere quel vuoto di perimetro invece di discuterne. Recon trova il build server che non è nell'inventario perché risponde sulla 8111 da una rete da cui non dovrebbe rispondere. L'agente Exploit scrive un exploit generativo per la vostra istanza con un LLM locale, invece di rigiocare una entry di ExploitDB: la validazione non dipende dal fatto che qualcuno pubblichi per primo un PoC, cosa che per CVE-2026-63077 non è ancora successa. Ogni tentativo gira in un container Docker effimero con hardening gVisor opzionale, quindi dimostrare la sfruttabilità su un build server di produzione non significa metterlo a rischio. E poiché le campagne sono schedulate e attivate dai cambiamenti, un endpoint CI appena esposto fa partire una campagna completa entro un'ora: l'unica cadenza che regge il confronto con una finestra di sfruttamento di massa di 48 ore. Le nuove skill offensive vengono validate in backtest nell'AI Gym — oltre 142 skill contro Vulhub, NYU CTF Bench, Cybench e 314 task black-box basati su CVE — prima di toccare un ambiente cliente, e il Knowledge RAG recupera come si è comportata una catena di deserializzazione della stessa classe nelle esecuzioni precedenti invece di riscoprirla ogni volta.

La metà post-exploitation è un problema di traffico, non di endpoint. Quando un build server inizia ad aprire sessioni TLS prolungate verso un ASN che non ha mai contattato, o un agent si dirama verso host per cui non compila nulla, il modello di AI Traffic Analysis di Zero Hunt — quattro teste di inferenza su miliardi di sequenze PCAP, 2,7+ Gbit/s sulla GPU dell'appliance — lo segnala mentre sta accadendo. Qui conta in modo specifico: le intrusioni TeamCity di APT29 usavano OneDrive e Dropbox come C2, destinazioni in allowlist ovunque e invisibili all'ispezione basata su firme, ma comportamentalmente sbagliate se partono da una macchina il cui mestiere è compilare codice.

Tutto gira on-prem, senza callback verso il cloud e senza API LLM esterne — che, per l'unico server che custodisce le vostre chiavi di firma, è l'unico modello di deployment di cui valga la pena discutere. Per vedere come si chiude in pratica quel vuoto di perimetro, scriveteci o leggete la panoramica della piattaforma.