CVE-2026-63077: RCE critica in TeamCity On-Premises
Una nuova vulnerabilità critica minaccia migliaia di ambienti di sviluppo software in tutto il mondo. Si chiama CVE-2026-63077 e colpisce JetBrains TeamCity On-Premises, una delle piattaforme CI/CD più utilizzate a livello enterprise. Se gestisci un’infrastruttura DevOps basata su TeamCity, questo articolo ti spiega cosa sta succedendo, perché è così pericoloso e cosa devi fare subito per proteggere la tua supply chain software.
Cos’è CVE-2026-63077 e perché è così critica
CVE-2026-63077 è una vulnerabilità di Remote Code Execution (RCE) non autenticata che affligge JetBrains TeamCity On-Premises. La causa tecnica risiede in una deserializzazione di dati non fidati (classificata come CWE-502) all’interno del protocollo di polling utilizzato dagli agent per comunicare con il server.
In parole semplici: un attaccante remoto, senza bisogno di credenziali, può inviare dati malevoli al server TeamCity e ottenere l’esecuzione di codice arbitrario con i privilegi del processo. Questo tipo di vulnerabilità è tra le più pericolose in assoluto, perché elimina qualsiasi barriera di autenticazione.
La gravità della situazione ha spinto CISA a inserire questa CVE nel proprio catalogo KEV (Known Exploited Vulnerabilities), confermando che esistono già segnalazioni di sfruttamento attivo in ambienti reali.
Come funziona l’attacco
- L’attaccante individua un’istanza TeamCity On-Premises esposta su internet.
- Invia un payload malevolo attraverso il canale di polling agent-server.
- Il server, deserializzando dati non fidati, esegue il codice contenuto nel payload.
- L’attaccante ottiene controllo remoto con i privilegi del processo TeamCity.
Da questo punto, le possibilità di danno sono enormi: furto di credenziali, manomissione delle build, accesso a repository di codice sorgente e movimento laterale nella rete interna.
Versioni interessate e patch disponibili
Secondo le advisory ufficiali, tutte le installazioni TeamCity On-Premises risultano potenzialmente vulnerabili. JetBrains ha reagito rapidamente rilasciando due build corrette:
- TeamCity 2025.11.7
- TeamCity 2026.1.3
Se non è possibile aggiornare immediatamente, JetBrains mette a disposizione un plugin di mitigazione temporanea, pensato per ridurre la superficie di attacco fino a quando non sarà possibile completare l’upgrade. È fondamentale verificare la compatibilità del plugin con la propria versione, seguendo le istruzioni riportate nell’advisory ufficiale di JetBrains.
Checklist di risposta immediata all’incidente
Se gestisci un’istanza TeamCity, il tempo è un fattore critico. Ecco le azioni da intraprendere, organizzate per priorità temporale.
Entro 15 minuti: contenere l’esposizione
- Identifica tutte le istanze TeamCity esposte pubblicamente tramite scansione DNS e inventario asset.
- Blocca l’accesso pubblico immediato usando firewall, WAF o security group.
- Sposta l’accesso amministrativo dietro VPN o bastion host.
- Applica regole di allowlist IP per limitare le connessioni consentite.
Entro 1 ora: mitigare e proteggere
- Applica il plugin di mitigazione ufficiale se l’aggiornamento non è immediatamente possibile.
- Limita la comunicazione server-agent solo a reti interne e agent riconosciuti.
- Avvia la raccolta e conservazione dei log critici (server, agent, syslog, rete) per eventuali analisi forensi.
Entro 24 ore: analisi approfondita e bonifica
- Esegui un inventario completo: versione installata, plugin attivi, agent connessi, credenziali memorizzate.
- Se l’istanza è stata esposta durante il periodo vulnerabile, trattala come compromessa: crea uno snapshot forense e isola la macchina dalla rete.
- Ruota immediatamente tutte le credenziali e i segreti memorizzati (token di deploy, chiavi VCS, service account).
- Analizza i log alla ricerca di attività anomale: nuovi utenti amministratori, modifiche ai job di build, comandi shell non autorizzati, connessioni in uscita sospette.
- Verifica l’integrità degli artefatti prodotti durante il periodo di esposizione, confrontando checksum e, se possibile, ricostruendo le build in ambiente isolato.
Perché una CI/CD compromessa è una minaccia per l’intera supply chain
Un server CI/CD come TeamCity non è un semplice strumento di automazione: è il cuore pulsante del ciclo di rilascio del software. Orchestra build, test e distribuzione, spesso con accesso diretto a repository di codice, chiavi di firma e credenziali di deploy.
Quando un attaccante ottiene il controllo di questo sistema, può:
- Inserire codice malevolo in pipeline apparentemente legittime.
- Manomettere artefatti che verranno distribuiti come “ufficiali” ai clienti finali.
- Rubare segreti e credenziali usate per accedere ad altri sistemi.
- Usare il server come punto di pivoting per muoversi lateralmente nella rete aziendale.
Questo scenario ricorda da vicino altri incidenti storici di supply chain attack, dove la compromissione di uno strumento di build ha avuto conseguenze a cascata su migliaia di organizzazioni downstream. Il costo di un incidente simile va ben oltre il danno tecnico: coinvolge la fiducia dei clienti, obblighi di disclosure e, spesso, la necessità di ricostruire completamente la catena degli artefatti distribuiti.
Contromisure aggiuntive se l’aggiornamento non è immediato
In alcuni contesti aziendali, l’aggiornamento immediato non è sempre praticabile per vincoli operativi. In questi casi, è possibile adottare misure compensative temporanee:
- Installare il plugin di sicurezza ufficiale fornito da JetBrains.
- Limitare l’accesso al server tramite VPN o allowlist IP rigorose.
- Configurare regole WAF per bloccare richieste sospette e ispezionare i payload in transito.
- Disabilitare temporaneamente funzionalità non essenziali, come le connessioni da agent esterni non verificati.
- Adottare policy di “build from source” verificato come ulteriore livello di garanzia sull’integrità del software prodotto.
Queste misure non sostituiscono la patch definitiva, ma riducono significativamente la finestra di rischio nel breve termine.
Conclusione
CVE-2026-63077 rappresenta un caso da manuale di come una singola vulnerabilità in un componente CI/CD possa mettere a rischio l’intera supply chain software di un’organizzazione. La combinazione di esecuzione di codice non autenticata, sfruttamento attivo confermato e presenza nel catalogo KEV di CISA rende questa minaccia una priorità assoluta per qualsiasi team che gestisca TeamCity On-Premises.
Le azioni da intraprendere sono chiare: aggiornare immediatamente alle versioni 2025.11.7 o 2026.1.3, applicare le mitigazioni ufficiali se l’upgrade non è possibile, ruotare tutte le credenziali potenzialmente esposte e verificare l’integrità degli artefatti prodotti durante il periodo di rischio. Trattare ogni istanza esposta come potenzialmente compromessa, fino a prova contraria, è l’approccio più prudente e responsabile in questo momento.
Monitorare costantemente le fonti ufficiali, come l’advisory di JetBrains e il database NVD, resta essenziale per rimanere aggiornati su eventuali evoluzioni della minaccia.