TeamCity espone le pipeline, VMware e Rails chiudono falle critiche

🛡️ Executive Summary

• TeamCity corregge una RCE senza autenticazione capace di compromettere credenziali, build e artefatti dell’intera pipeline CI/CD.
• Rails chiude una lettura arbitraria di file, mentre VMware corregge bypass di autenticazione, code execution e fuga dalle macchine virtuali.
• Google attribuisce agli strumenti AI 1.072 bug corretti in Chrome 149 e 150 e prepara aggiornamenti di sicurezza più frequenti.

Quattro aggiornamenti mostrano la crescente pressione sulle infrastrutture di sviluppo, virtualizzazione e navigazione web. JetBrains ha corretto una vulnerabilità critica di TeamCity che permette l’esecuzione remota di comandi senza autenticazione, mettendo a rischio credenziali, build e artefatti software. Ruby on Rails ha chiuso una falla in Active Storage capace di esporre file e segreti del server attraverso upload manipolati, mentre Broadcom ha pubblicato patch urgenti per cinque vulnerabilità VMware, comprese un’autenticazione aggirabile e una fuga dalla macchina virtuale verso l’host. Parallelamente, Google sostiene che l’intelligenza artificiale abbia contribuito a correggere 1.072 problemi di sicurezza nelle ultime due versioni principali di Chrome.

TeamCity permette comandi remoti senza autenticazione

La vulnerabilità CVE-2026-63077 interessa tutte le versioni di TeamCity On-Premises e può essere sfruttata da un aggressore non autenticato che riesca a raggiungere il server attraverso HTTP o HTTPS. Il problema si trova nel protocollo utilizzato dagli agenti per interrogare TeamCity e consente di superare i controlli di autenticazione, arrivando all’esecuzione di comandi arbitrari con i privilegi del processo server. L’impatto non riguarda soltanto il sistema operativo sul quale è installata la piattaforma: TeamCity conserva configurazioni, credenziali, token di accesso ai repository, chiavi per i registri dei container e segreti utilizzati dalle pipeline. Un controllo del server può quindi consentire di modificare il codice durante la compilazione, contaminare gli artefatti distribuiti ai clienti o sottrarre credenziali utilizzabili contro altri ambienti. La vulnerabilità assume una gravità particolare perché i server CI/CD occupano una posizione centrale nella supply chain software e possiedono spesso accesso contemporaneo a codice sorgente, ambienti cloud e sistemi di produzione. Gli attacchi precedenti contro TeamCity sfruttato da gruppi ransomware hanno già dimostrato come una singola falla nella piattaforma possa trasformarsi in un accesso persistente all’intera infrastruttura di sviluppo. JetBrains ha corretto il problema nelle versioni 2025.11.7 e 2026.1.3, che includono complessivamente più di venti interventi di sicurezza. Per le installazioni dalla release 2017.1 in poi che non possono essere aggiornate immediatamente è disponibile un plugin di sicurezza, ma il produttore raccomanda comunque il passaggio a una versione completa e supportata. TeamCity Cloud è già stato protetto e non richiede azioni da parte dei clienti. Nell’avviso ufficiale dedicato a CVE-2026-63077, JetBrains afferma di non conoscere casi di sfruttamento attivo al momento della pubblicazione e invita a limitare l’accesso ai server alle sole reti fidate, utilizzare host dedicati e ridurre i privilegi del processo TeamCity.

Rails espone file e credenziali attraverso gli upload

CVE-2026-66066, classificata critica con punteggio CVSS 9.5, interessa il componente Active Storage di Ruby on Rails quando l’applicazione utilizza libvips per elaborare immagini caricate da utenti non fidati. Active Storage passava gli allegati a operazioni di libvips considerate non sicure per contenuti ostili, permettendo a un file appositamente costruito di richiamare loader o funzioni estranee alla normale gestione delle immagini. L’attacco fornisce una primitiva di lettura arbitraria dei file accessibili al processo Rails e può esporre variabili d’ambiente, secret_key_base, master key, password dei database, credenziali per storage AWS, Google Cloud o Azure e token di servizi esterni. La falla non produce automaticamente l’esecuzione remota di codice in ogni installazione, ma i segreti recuperati possono consentire di firmare cookie, decifrare credenziali, accedere ai database o muoversi lateralmente verso altri sistemi. Le applicazioni vulnerabili devono utilizzare Vips, accettare upload non fidati e includere operazioni sfruttabili nella propria build di libvips; MiniMagick non è interessato da questo specifico percorso. Le versioni corrette sono Rails 7.2.3.2, 8.0.5.1 e 8.1.3.1, mentre le release 7.1 e precedenti non più supportate devono essere migrate almeno alla serie 7.2. La patch richiede inoltre libvips 8.13 o successivo e, quando utilizzato, ruby-vips dalla versione 2.2.1. Gli amministratori non devono limitarsi all’aggiornamento: ogni segreto leggibile dal processo deve essere considerato potenzialmente esposto e sostituito, compresi master key, credenziali Active Storage, password del database e token delle API. L’advisory ufficiale pubblicato dal Rails Security Team chiarisce che le versioni precedenti di libvips non possono bloccare le operazioni non fidate e che, in assenza di un aggiornamento immediato, la dipendenza deve essere rimossa oppure configurata con VIPS_BLOCK_UNTRUSTED. Non risultano tentativi di sfruttamento confermati, ma è già comparso un proof of concept indipendente che sostiene di concatenare la lettura dei file alla code execution.

VMware chiude bypass, code execution e fuga dalle macchine virtuali

L’advisory VMSA-2026-0006 comprende cinque vulnerabilità in VMware vCenter, ESX, Workstation e Fusion, tre delle quali classificate critiche. CVE-2026-59309, con punteggio CVSS 9.8, permette a un aggressore non autenticato con accesso di rete a vCenter di aggirare il meccanismo di autenticazione del VMware Directory Service. CVE-2026-59310, anch’essa valutata 9.8, è una directory traversal nel server Syslog di vCenter che può portare all’esecuzione arbitraria di codice senza credenziali. Il terzo problema critico, CVE-2026-47876, è una scrittura fuori dai limiti nell’adattatore virtuale VMXNET3: un aggressore con privilegi amministrativi dentro una macchina virtuale può eseguire codice sull’host ESX e realizzare una vera VM escape. Le altre due falle comprendono CVE-2026-41703, che consente letture fuori dai limiti, fuga di informazioni o denial of service, e CVE-2026-41709, che permette a un amministratore ESX ostile di compiere alcune operazioni senza lasciare registrazioni adeguate. Le correzioni riguardano anche i prodotti che incorporano vCenter o ESX, tra cui VMware Cloud Foundation, vSphere Foundation e le piattaforme Telco Cloud. Non esistono workaround e Broadcom considera l’intervento una modifica di emergenza: vCenter deve essere aggiornato alle versioni 9.1.0.0300, 9.0.2.0100 o 8.0 Update 3k, mentre ESX deve passare a 9.1.0.0200, 9.0.2.0100 o 8.0 Update 3k. Workstation e Fusion 25H2 devono essere aggiornati alla serie 26H1 per chiudere CVE-2026-41703. L’approfondimento ufficiale VMware su VMSA-2026-0006 raccomanda di presumere vulnerabili tutte le versioni precedenti a quelle indicate e chiarisce che sostituire VMXNET3 con schede virtuali differenti non rappresenta una mitigazione adeguata. L’aggiornamento di vCenter interrompe temporaneamente le interfacce di gestione ma non le macchine virtuali, mentre la patch di ESX richiede il riavvio dell’host e può essere distribuita progressivamente tramite vMotion o Live Patch negli ambienti compatibili.

Google usa agenti AI per trovare e correggere i bug di Chrome

Google afferma che Chrome 149 e Chrome 150 abbiano corretto complessivamente 1.072 problemi di sicurezza, superando il totale risolto nelle ventitré versioni principali precedenti. L’aumento non indica necessariamente che il browser sia diventato improvvisamente meno sicuro, ma riflette la capacità degli strumenti basati sull’intelligenza artificiale di individuare più difetti, riprodurre automaticamente i report e assistere gli sviluppatori nella preparazione delle patch. I modelli vengono utilizzati lungo l’intero ciclo di gestione della vulnerabilità: scoperta, eliminazione dei duplicati, riproduzione dei proof of concept, assegnazione della gravità, selezione del team responsabile, generazione di possibili correzioni e costruzione dei test di regressione. Il percorso è iniziato con l’uso degli LLM nei sistemi di fuzzing, è proseguito con Naptime e Big Sleep e si è esteso nel 2026 a un agent harness basato su Gemini capace di analizzare porzioni più ampie del codice Chromium.

Tra i risultati viene indicata una sandbox escape rimasta nel codice per oltre tredici anni, potenzialmente utilizzabile da un renderer già compromesso per leggere file locali. Google precisa che gli agenti non sostituiscono fuzzing e revisione umana, ma filtrano segnalazioni, preparano più patch candidate e riducono il tempo speso dagli sviluppatori nelle attività ripetitive. Nei soli mesi iniziali del 2026, l’aumento delle segnalazioni AI ha portato Chrome a ricevere entro marzo più bug di sicurezza di quanti ne fossero arrivati durante l’intero 2025. Il documento Chromium dedicato alla gestione dei bug di sicurezza generati dall’AI chiede ai team di trattare inizialmente queste segnalazioni come vulnerabilità reali, anche quando il proof of concept non è ancora disponibile, e suggerisce di aggiungere file SECURITY.md per descrivere confini di fiducia e ridurre i falsi positivi. Chrome sta inoltre passando a un ciclo principale di due settimane, con aggiornamenti di sicurezza settimanali e test su due release correttive ogni settimana, mentre la futura funzione di dynamic patching dovrebbe applicare alcune correzioni senza richiedere il riavvio del browser.