Go blocca otto chiavi CA: la fiducia nel cloud e negli agenti AI vacilla

🛡️ Executive Summary

• Go 1.27.3 e 1.26.10 bloccano otto chiavi di autorità di certificazione intermedie per motivi di sicurezza non ancora chiariti pubblicamente.
• ConnectWise revoca credenziali applicative dopo accessi non autorizzati, mentre OpenCode avverte che le chiavi API di un sottoinsieme degli utenti Console potrebbero essere state esposte.
• Langflow affronta tentativi di sfruttamento della CVE-2026-105740, vulnerabilità RCE con punteggio CVSS 9,9 che coinvolge le configurazioni dei server MCP.

Go ha rilasciato un aggiornamento urgente che impedisce di considerare attendibili otto chiavi crittografiche appartenenti a una stessa autorità di certificazione, senza chiarire pubblicamente le ragioni dell’intervento. La decisione del team di sviluppo coincide con nuovi sviluppi negli incidenti ConnectWise Cloud Backup e OpenCode Console, dove l’accesso a identità applicative e chiavi API ha imposto misure di contenimento, mentre gli attacchi contro Langflow confermano quanto le configurazioni degli agenti AI possano diventare un vettore di esecuzione remota. I quattro episodi non risultano collegati tra loro, ma mettono in evidenza una fragilità comune: le credenziali, i certificati e i privilegi concessi al software costituiscono una superficie d’attacco capace di compromettere servizi e infrastrutture anche quando l’applicazione principale non presenta una vulnerabilità direttamente sfruttabile.

Go 1.27.3 e 1.26.10 revocano la fiducia a otto chiavi di certificazione

Il team Go ha pubblicato le versioni 1.27.3 e 1.26.10 introducendo nel componente crypto/x509 un controllo che impedisce la validazione di catene di certificati contenenti otto specifiche chiavi pubbliche appartenenti ad autorità intermedie. Il problema è identificato come CVE-2026-111943 ed è stato gestito attraverso il percorso URGENT, riservato alle situazioni considerate particolarmente gravi per la sicurezza dell’ecosistema. Nella segnalazione ufficiale Go relativa alla mitigazione gli sviluppatori parlano di preoccupazioni specifiche riguardanti il funzionamento di una Certificate Authority, senza indicarne pubblicamente l’identità o precisare se siano avvenute emissioni fraudolente. Un’analisi dei fingerprint pubblicati ha associato le otto chiavi a certificati intermedi eMudhra/emSign, ma questa identificazione proviene dalla community e non costituisce una conferma ufficiale del team Go. Il controllo interessa la chiave pubblica e non soltanto il singolo certificato, impedendo quindi di aggirare il blocco attraverso una catena alternativa di firme. Le applicazioni Go devono essere ricompilate con una versione corretta per incorporare la nuova protezione, mentre quelle che utilizzano le chiavi escluse potrebbero non riuscire più a stabilire connessioni TLS valide. La decisione riguarda la stessa infrastruttura di fiducia già finita al centro dell’indagine sui registri ccTLD compromessi e sull’emissione di certificati HTTPS validi per Google, pur senza alcun collegamento dimostrato tra i due episodi. Il blocco non prova che tutte le chiavi fossero state rubate, ma indica che gli sviluppatori hanno ritenuto necessario escluderle preventivamente dai meccanismi di verifica.

Leggi anche: Microsoft revoca certificati, corregge bug in Windows 11 mentre WatchGuard risolve bug

ConnectWise cambia credenziali e mantiene sospeso Cloud Backup

Un differente problema di fiducia nelle identità applicative emerge dall’incidente ConnectWise Cloud Backup, il servizio precedentemente conosciuto come SkyKick. Dopo la scoperta degli accessi non autorizzati, l’azienda ha disabilitato sette identità applicative, revocato certificati utilizzati dalle connessioni interessate e avviato la rotazione delle credenziali condivise. L’aggiornamento del 19 ottobre introduce ulteriori interventi sulle protezioni amministrative e conferma la sospensione di Cloud Backup, SaaS Security e Cloud Management, necessaria per verificare il contenimento della minaccia. Nel Trust Center ufficiale di ConnectWise viene chiarito che gli archivi di backup rimangono cifrati e isolati, senza evidenze di accesso non autorizzato ai dati conservati. Questo risultato non esclude tuttavia la compromissione di singoli tenant Microsoft 365: revocare un’identità applicativa impedisce nuove autenticazioni attraverso quella connessione, ma non annulla automaticamente le modifiche già compiute nell’ambiente del cliente. Il precedente attacco alla supply chain ConnectWise e Microsoft 365 aveva già documentato autenticazioni anomale e possibili escalation dei privilegi; il nuovo sviluppo riguarda quindi la bonifica e la verifica dell’effettiva rimozione degli accessi. Per i Managed Service Provider diventa indispensabile esaminare i log delle identità applicative, gli eventuali privilegi amministrativi aggiunti, le credenziali associate ai service principal e le modifiche ai sistemi Exchange. La sospensione dei backup rappresenta inoltre un problema di continuità operativa, perché durante l’incidente rimangono indisponibili anche le attività di ripristino.

OpenCode Console espone le chiavi API: la distillazione AI diventa un rischio economico

Anche OpenCode affronta le conseguenze di una compromissione che ha interessato una componente specifica della piattaforma. L’incidente, comunicato il 17 ottobre, riguarda l’1,4% degli utenti di OpenCode Console che avevano collegato provider esterni come OpenAI, Anthropic e Google. Rispetto alla prima comunicazione sulla violazione di OpenCode Console, i nuovi dettagli chiariscono che l’accesso non autorizzato avrebbe interessato un sistema legacy e potrebbe aver esposto le chiavi API conservate nel servizio ospitato. La distinzione è fondamentale: non risultano coinvolte automaticamente le credenziali dei client OpenCode utilizzati esclusivamente in locale, mentre gli utenti Console interessati sono stati invitati a revocare direttamente presso i rispettivi provider le chiavi potenzialmente compromesse. OpenCode ha associato l’incidente a un attacco di distillazione AI su larga scala, senza fornire elementi sufficienti per chiarire il rapporto causale tra l’intrusione e le attività di estrazione sistematica delle risposte dei modelli. Alcuni utenti hanno denunciato consumi API non autorizzati e addebiti anche superiori a mille dollari, ma queste dichiarazioni non equivalgono a una ricostruzione forense completa dell’esfiltrazione. L’attacco presenta analogie operative con le campagne di distillazione attribuite da OpenAI a un cluster collegato a Moonshot, senza dimostrare che siano coinvolti gli stessi responsabili. Una chiave API sottratta può continuare a generare costi anche dopo essere stata eliminata da OpenCode Console, perché la sua revoca deve avvenire presso il provider che l’ha emessa.

Langflow, 1.423 tentativi di exploit contro una RCE critica nei server MCP

Il quarto sviluppo riguarda Langflow, piattaforma utilizzata per costruire workflow e applicazioni basate su agenti AI. La vulnerabilità CVE-2026-105740, classificata con punteggio CVSS 9,9, consente a un utente autenticato di ottenere esecuzione remota di comandi attraverso la configurazione dei server MCP con trasporto stdio. Nell’advisory di sicurezza pubblicato dal progetto Langflow viene spiegato che il campo command, controllabile dall’utente, viene passato alla shell senza adeguate validazioni, mentre la configurazione malevola può persistere nelle impostazioni del progetto e riattivarsi quando viene caricata la lista dei server. Il problema è stato corretto nella versione 1.9.0. I ricercatori di Previdian hanno registrato 1.423 tentativi di sfruttamento sui propri sensori tra il 19 settembre e il 15 ottobre, provenienti da 27 indirizzi IP. In alcuni casi gli aggressori hanno tentato di utilizzare credenziali comuni, estrarre variabili d’ambiente contenenti segreti e interrogare il sistema operativo. Il numero indica tentativi osservati sulle honeypot e non 1.423 installazioni realmente compromesse. L’attività documentata rappresenta un nuovo sviluppo rispetto ai precedenti exploit Langflow finalizzati al furto di credenziali e dati, mostrando come una semplice configurazione MCP possa diventare un meccanismo persistente di esecuzione di comandi.

Continua con:

Shai-Hulud espande la caccia: 469 percorsi per rubare segreti da AI, cloud e CI/CD

MCP malevoli e passkey espongono agenti AI e identità passwordless

Certificati, token e agenti AI: cosa devono verificare le aziende italiane

I quattro casi richiedono interventi differenti, ma condividono la necessità di controllare la fiducia concessa alle identità digitali. Gli sviluppatori Go devono aggiornare le toolchain supportate e ricompilare le applicazioni, verificando eventuali incompatibilità nelle connessioni TLS e nei servizi che utilizzano certificati intermedi esclusi. I partner ConnectWise devono esaminare i tenant Microsoft 365 prima di riattivare le integrazioni, conservando i log e verificando autorizzazioni applicative, account privilegiati e nuove credenziali eventualmente aggiunte. Gli utenti OpenCode Console notificati devono invece revocare le chiavi direttamente presso OpenAI, Anthropic e Google, controllando consumi e fatturazione, mentre gli amministratori Langflow devono utilizzare una versione corretta, disabilitare l’accesso automatico quando non necessario ed esaminare le configurazioni MCP persistenti. Per le imprese italiane che sviluppano applicazioni Go, affidano la gestione Microsoft 365 a fornitori esterni o integrano agenti AI nei processi aziendali, il rischio concreto è che un’autorizzazione legittima continui a essere sfruttabile anche dopo il contenimento iniziale di un incidente. Il problema non riguarda esclusivamente le password: certificati, token, identità applicative e permessi dei tool sono diventati componenti essenziali della sicurezza operativa. La priorità non è soltanto correggere una vulnerabilità, ma verificare quali soggetti e quali programmi possano ancora agire all’interno dell’infrastruttura dopo che la fiducia iniziale è stata compromessa.