// 2 ZERO-DAY · 5 CVE · 4 EXPLOIT · 2 ADVISORY NELLE ULTIME 24H
JetBrains ha confermato la violazione del servizio cloud Cadence tramite una vulnerabilità nota in TeamCity. Credenziali AWS IAM e dati personali sono stati esposti

JetBrains ha confermato il 23 agosto 2026 la violazione del servizio cloud Cadence, orchestrata tramite una vulnerabilità critica nel proprio prodotto TeamCity che il vendor non era riuscito a patchare internamente. L'attività malevola è proseguita per 16 giorni, dall'8 al 24 agosto, prima che il server api.cadence.jetbrains.com venisse messo offline. Il caso rappresenta una dimostrazione emblematica di come la frammentazione tra sicurezza del prodotto venduto e sicurezza del servizio cloud-hosted possa generare fallimenti sistemici anche nelle aziende che costruiscono gli strumenti di difesa.

Punti chiave
  • JetBrains ha ammesso esplicitamente che il server TeamCity interno usato per Cadence "avrebbe dovuto essere patchato" ma non lo è stato, nonostante patch disponibili e inserimento nel catalogo KEV CISA
  • La vulnerabilità CVE-2026-63077, con punteggio CVSS 9.8 secondo il record ufficiale NVD, consente esecuzione remota di codice non autenticata tramite il protocollo agent polling di TeamCity
  • Gli attaccanti hanno compromesso un backup completo del server Cadence del 2024 contenente credenziali AWS IAM multiple, inclusi utenti appartenenti a dipendenti JetBrains
  • Dati personali esfiltrati confermati: username, nomi reali, indirizzi email, timestamp dell'ultimo login e indirizzi IP dell'ultimo accesso

Il meccanismo: deserialization non autenticata nel polling agent

Il record CVE-2026-63077 nel database NVD identifica la falla come una vulnerabilità di deserialization di dati non trusted nel protocollo agent polling di TeamCity. Il vettore di attacco è classificato AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, che tradotto significa: accesso remoto, complessità bassa, nessun privilegio richiesto, nessuna interazione utente, con impatto massimo su confidenzialità, integrità e disponibilità. È una configurazione che nella pratica rende l'exploitificazione banale e automatizzabile.

Il protocollo agent polling è il canale attraverso cui i build agent di TeamCity si registano presso il server per ricevere job di compilazione. La deserialization non sicura permette a un attaccante di iniettare oggetti serializzati dannosi che vengono eseguiti con i privilegi del processo server, ottenendo immediatamente il controllo dell'istanza. Secondo l'advisory ufficiale di JetBrains, il server compromesso era quello che gestiva il servizio Cadence, la piattaforma cloud di orchestrazione workflow integrata con PyCharm.

La timeline: 16 giorni di persistenza tra KEV e scoperta

La sequenza temporale rivela un gap critico tra esposizione pubblica e risposta interna. Il CVE-2026-63077 è stato inserito nel catalogo KEV (Known Exploited Vulnerabilities) di CISA il 5 agosto 2026, con una deadline di due giorni per l'applicazione delle patch. Il server api.cadence.jetbrains.com è rimasto tuttavia vulnerabile. L'attività malevola è stata identificata dall'8 agosto, con la scoperta ufficiale da parte di JetBrains il 23 agosto e il takedown del server il giorno successivo.

Le versioni corrette di TeamCity, secondo le release notes ufficiali citate dall'advisory JetBrains, erano disponibili come 2025.11.7 e 2026.1.3. L'azienda non ha fornito la versione specifica in esecuzione sul server Cadence né ha spiegato le cause del mancato aggiornamento. Questo elemento resta tra i limiti del dossier: il perché di un'omissione così evidente non è stato chiarito nella disclosure controllata del vendor.

"The server should have been patched as part of our response to the vulnerability, but it was not. We sincerely apologize for this failure and the impact it may have on you." — JetBrains, advisory ufficiale

I dati esposti: dal backup 2024 allo storage corrente

La compromissione ha interessato in primo luogo un backup completo del server Cadence risalente al 2024. Secondo l'advisory ufficiale di JetBrains, questo archivio conteneva "credenziali, configurazioni, artefatti e log". Nello specifico, sono state compromesse "multiple utenze AWS IAM e credenziali/secret associate utilizzate con Cadence, inclusi utenti IAM appartenenti a dipendenti JetBrains". La formulazione del vendor lascia intendere che le credenziali esposte non fossero limitate a un singolo account o servizio.

I dati personali degli utenti Cadence confermati come esfiltrati includono: username, nomi reali, indirizzi email, timestamp dell'ultimo login e indirizzi IP dell'ultimo accesso. Queste informazioni, sebbene non classificabili come dati sensibili nel senso stretto del GDPR, costituiscono un profilo comportamentale dettagliato utile per attacchi di spear-phishing futuri.

Un elemento di incertezza permane sull'ambiente corrente. JetBrains ha dichiarato in un aggiornamento che "il threat actor ha ottenuto un accesso che avrebbe potuto permettergli di raggiungere storage contenenti dati associati agli utenti attuali di Cadence, inclusi indirizzi email, codice sorgente di progetto e credenziali". Tuttavia, il vendor specifica di non avere evidenza di esfiltrazione effettiva da questo storage. La stessa incertezza vale per eventuali bucket S3 in account clienti: "Non sappiamo attualmente se i threat actor abbiano accesso a bucket di storage negli account dei clienti", si legge nell'advisory.

Cosa fare adesso

JetBrains ha emesso raccomandazioni operative specifiche che gli utenti Cadence devono attuare immediatamente:

  • Rotazione massiva di credenziali: revocare o ruotare tutte le credenziali e i secret utilizzati per eseguire workflow Cadence, senza assumere che siano ancora validi
  • Trattare le esecuzioni come non trusted: considerare potenzialmente compromessi tutti gli input e output dei workflow Cadence, inclusi quelli storici
  • Invalidazione token: JetBrains ha già disabilitato tutti i token di accesso del plugin PyCharm per Cadence; gli utenti devono rigenerarli con nuove credenziali
  • Verifica account AWS: controllare l'attività IAM e i log di accesso S3 per eventuali anomalie, dato che le credenziali AWS esposte potrebbero avere permesso movimenti laterali o accesso a risorse esterne al perimetro JetBrains

Il paradosso della supply chain: chi patcha il patcher?

L'incidente solleva una questione strutturale che trascende il singolo vendor. JetBrains vende TeamCity come piattaforma di CI/CD sicura, con advisory, patch tempestive e integrazione nei flussi enterprise. Il fallimento interno dimostra che la garanzia di sicurezza del prodotto non si traduce automaticamente nella sicurezza del servizio cloud che lo impiega. La responsabilità di patching, quando viene distribuita tra team prodotto e team operazioni cloud, può generare zone grigie dove nessuno possiede la visibilità completa.

Per le aziende che affidano pipeline critiche a servizi cloud-hosted, il caso funge da ammonimento: la promessa di sicurezza "out of the box" non elimina la necessità di verificare indipendentemente lo stato di patching dell'infrastruttura sottostante. La fiducia nel vendor come unico guardiano della propria supply chain si rivela un modello con punti ciechi sistemici, specialmente quando il vendor è allo stesso tempo fornitore dell'arma e vittima dell'assalto.

Daniel Gallo, Solutions Engineering Lead di JetBrains, ha precisato che le nuove analisi "non hanno identificato utenti aggiuntivi interessati rispetto a quelli già contattati direttamente", ma che "per precauzione stiamo trattando i dati lì conservati come potenzialmente esposti". La cautela linguistica non cancella la gravità del caso: 16 giorni di accesso persistente a un server cloud con credenziali AWS in chiaro rappresentano una finestra temporale più che sufficiente per movimenti laterali non ancora rilevati.

Domande e risposte

Perché il server non è stato patchato se le fix erano disponibili?
JetBrains non ha fornito spiegazioni tecniche o organizzative sulla causa del mancato patching. L'advisory si limita all'ammissione dell'errore senza dettagliare se il problema derivasse da processi di change management, classificazione errata del sistema o altre cause operative.
I clienti di TeamCity Cloud sono a rischio?
Secondo l'advisory ufficiale di JetBrains, i clienti di TeamCity Cloud non erano esposti al rischio legato a questa specifica compromissione. Il servizio interessato era Cadence, con infrastruttura separata.
Cosa significa "trattare le esecuzioni come non trusted" nella pratica?
Significa che output di build, artifact generati, variabili d'ambiente e eventuali secret iniettati nei workflow Cadence potrebbero essere stati alterati o esfiltrati. La raccomandazione implica audit di integrità e, dove possibile, riscostruzione delle pipeline da sorgenti verificate.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. thehackernews.com
  2. adtmag.com
  3. beyondmachines.net
  4. securityonline.info
  5. blog.jetbrains.com
  6. nvd.nist.gov