Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Quando leggi “CVSS 9.9”, spesso sei già in modalità allerta, no? Perché quella è la scala massima di gravità in ambito vulnerabilità. E questo nuovo problema nel Semantic Kernel di Microsoft non scherza affatto.
La notizia gira nei canali tecnici e nei forum di sicurezza da qualche giorno: un bug che permette la scrittura arbitraria di file potrebbe creare una breccia seria nei sistemi che usano quell’SDK, soprattutto chi ci costruisce sopra agenti AI o applicazioni complesse.
Il cuore del problema, è che prima della versione 1.70.0 del pacchetto Microsoft.SemanticKernel.Core c’era un difetto dentro il componente SessionsPythonPlugin. In pratica, quando certe funzioni accettavano percorsi di file, non li verificavano bene. Questo significa che un attaccante con accesso alla rete e permessi bassi poteva convincere il sistema a scrivere file dove non doveva, con tutte le conseguenze che immagini per la sicurezza.
Non è un attacco che richiede interazione umana, e non serve essere amministratore per provarci. In breve: un cattivo potrebbe sfruttare questo bug da remoto, con impatto su confidenzialità, integrità e disponibilità dei dati.
Sovrascrivere file non è un termine astratto, vuol dire che si può corrompere, cancellare o alterare quello che c’è in un percorso critico del sistema, con possibilità di interrompere servizi o rompere funzionalità. Basta un input “sbagliato” passato alle funzioni tipo DownloadFileAsync o UploadFileAsync per far sì che il percorso venga aperto e il contenuto venga scritto altrove.
Se ci pensi, è quel tipo di falla che potrebbe trasformarsi in un problema enorme per chiunque usi l’SDK in produzione.
La prima e più efficace risposta è: aggiorna tutto. Microsoft ha risolto il problema rilasciando la versione 1.70.0 o superiore di Microsoft.SemanticKernel.Core, dove questa falla non esiste più.
Poi, se per qualche motivo non puoi aggiornare subito, puoi implementare un filtro di invocazione delle funzioni (Function Invocation Filter) che controlli gli argomenti in ingresso (soprattutto il percorso del file) e consenta solo quelli in una allowlist.
Come spesso accade nei team DevOps e SecOps, un bug che sembra “tecnico” può avere ricadute pratiche enormi. Qui parliamo di API di basso livello che vengono usate come blocco costitutivo per applicazioni intelligenti, microservizi, automazioni. Un errore lì, può riverberarsi a catena.
Gli sviluppatori devono avere questo nel backlog di sicurezza: controllare le dipendenze e forzare l’aggiornamento del pacchetto prima possibile. Serve un po’ di disciplina nei processi di build e di audit delle librerie terze parti, perché è lì che spesso si nascondono i problemi.
Un esempio, eh: immagina un sistema di automazione che scarica file da un agente AI e li salva… se il percorso non è verificato, potrebbe scrivere in cartelle di sistema o sovrascrivere configurazioni importanti. Non è fantascienza, succede.
Molte volte le vulnerabilità gravi non sono nelle funzioni appariscenti, ma in quelle che manipolano dati di base, come file o percorsi. Questa CVE ne è un esempio lampante: è semplice da spiegare, ma può avere conseguenze complesse.
La vulnerabilità è stata documentata e seguita da GitHub Advisory Database attraverso la segnalazione GHSA-2ww3-72rp-wpp4 e riferita come CVE-2026-25592, con dettagli completi sulla problematica nel repository ufficiale. Puoi leggere l’articolo completo di GitHub Advisory Database.
La lezione di oggi è che anche le librerie “invisibili” nel tuo stack possono nascondere problemi critici. Non aspettare che una CVE si trasformi in incidente: monitora, aggiorna e filtra sempre gli input più pericolosi (come i percorsi file), soprattutto nelle dipendenze open source.
