Gitea entra nel KEV e gli agenti AI aprono nuove vie all’esecuzione di codice

🛡️ Executive Summary

• CISA inserisce CVE-2026-60004 di Gitea nel KEV dopo evidenze di sfruttamento attivo: la falla permette code execution tramite Git hook.
• AWS corregge CVE-2026-78379 in Strands Agents Tools, dove batch e python_repl potevano aggirare il consenso umano ed eseguire Python sull’host.
• marimo risolve CVE-2026-75149, che permetteva a un notebook malevolo di lanciare un comando MCP locale prima dell’esecuzione delle celle.

Tre vulnerabilità mostrano quanto il confine tra sviluppo software, automazione AI e remote code execution stia diventando sempre più sottile. CISA ha aggiunto CVE-2026-60004 di Gitea al catalogo delle vulnerabilità attivamente sfruttate, confermando che una falla nella gestione dei diff patch viene già utilizzata contro sistemi reali. Quasi in parallelo, AWS ha corretto CVE-2026-78379 in Strands Agents Tools, dove un attaccante poteva aggirare la richiesta di consenso prima dell’esecuzione di Python. Sul fronte notebook, marimo ha invece chiuso CVE-2026-75149, capace di trasformare la semplice apertura di un file in edit mode nell’avvio di un comando MCP locale prima ancora che una cella venga eseguita.

Gitea entra nel KEV con una RCE costruita sui Git hook

CISA ha inserito CVE-2026-60004 nel proprio Known Exploited Vulnerabilities Catalog il 25 agosto, segnalando quindi evidenze concrete di sfruttamento in-the-wild. La vulnerabilità interessa Gitea dalla versione 1.17 fino alla 1.27.0 ed è stata corretta nella 1.27.1. L’advisory ufficiale del progetto Gitea descrive una catena nella quale l’endpoint diffpatch può essere abusato per installare un Git hook eseguibile all’interno del repository temporaneo utilizzato dal servizio. Un attaccante con normali permessi di scrittura può così eseguire comandi shell arbitrari come utente del servizio Gitea. Il problema è particolarmente serio nelle istanze con registrazione aperta, perché un visitatore può creare un account e ottenere autonomamente un repository scrivibile. L’inserimento nel KEV porta il caso sullo stesso piano operativo di Ray, GeoServer e altre vulnerabilità già passate dalla disclosure allo sfruttamento reale.

Il diffpatch trasforma un file controllato dall’utente in codice eseguibile

La falla nasce da un dettaglio dell’interazione tra Gitea e Git. Durante l’applicazione di una patch, il backend lavora su un clone bare temporaneo. In specifiche condizioni, una collisione add/add può costringere Git a materializzare un file all’interno della directory che coincide con $GIT_DIR. Se il percorso controllato dall’attaccante viene chiamato hooks/post-index-change e marcato come eseguibile, Git lo interpreta come un hook legittimo e lo avvia quando aggiorna l’indice. Il risultato è una trasformazione diretta da contenuto repository a codice di sistema. L’exploit pubblicato non necessita neppure di una connessione outbound: l’output del comando può essere scritto negli oggetti Git e recuperato successivamente attraverso HTTP autenticato. È un esempio efficace di come componenti nativi dello strumento di sviluppo possano diventare primitive RCE senza introdurre binari esterni.

AWS corregge un bypass del consenso negli agenti Strands

Il secondo fronte riguarda Strands Agents Tools, il pacchetto open source AWS destinato alla costruzione di agenti AI. Nel security bulletin AWS 2026-089 l’azienda documenta CVE-2026-78379, una vulnerabilità di consent bypass nelle versioni precedenti alla 0.8.5. Lo strumento python_repl può eseguire codice Python direttamente sull’host dell’agente, ma prima di farlo dovrebbe chiedere l’approvazione dell’operatore. Il problema nasce dalla combinazione con il tool batch: un prompt appositamente costruito può inoltrare il parametro non_interactive_mode come keyword argument e fare in modo che python_repl entri in modalità non interattiva. In pratica, il sistema continua ad avere un gate umano, ma l’attaccante riesce a disattivarlo attraverso lo stesso flusso controllato dal modello.

Il rischio non è il prompt injection in sé, ma ciò che l’agente può fare dopo

Il punto critico della vulnerabilità Strands non è semplicemente che un LLM possa essere manipolato. Il problema è che l’agente dispone di un tool con capacità di eseguire Python sull’host. Se un contenuto remoto controllato da un attaccante riesce a influenzare l’agente e contemporaneamente a bypassare la richiesta di consenso, il confine tra prompt injection e code execution collassa. AWS ha corretto il comportamento nella versione 0.8.5, facendo sì che non_interactive_mode venga letto esclusivamente dalla variabile di ambiente STRANDS_NON_INTERACTIVE e non possa più essere imposto da un caller. Fino all’aggiornamento, l’azienda raccomanda di rimuovere batch oppure python_repl dall’elenco dei tool e di non esporre python_repl ad agenti che elaborano contenuti non affidabili. L’episodio si inserisce nello stesso filone delle vulnerabilità AWS, SharePoint e SAP che mostrano come le superfici cloud e agentiche stiano convergendo.

marimo eseguiva un comando MCP prima ancora delle celle

La terza vulnerabilità riguarda marimo, notebook Python reattivo sempre più utilizzato anche in workflow AI. CVE-2026-75149, con CVSS 8.7 secondo il record CNA citato dai ricercatori, interessa le versioni precedenti alla 0.23.15. Un notebook malevolo può includere nella propria configurazione un comando MCP controllato dall’attaccante. Quando la vittima apre il notebook in edit mode, quel comando può essere lanciato come subprocesso locale prima che una singola cella venga eseguita. È questo dettaglio a rendere il bug particolarmente pericoloso: l’utente può pensare di stare semplicemente ispezionando il file senza aver ancora autorizzato alcuna esecuzione esplicita. In realtà il boundary di fiducia viene superato già nella fase di caricamento della configurazione.

La patch considera finalmente il metadata come input ostile

marimo ha corretto il problema nella release 0.23.15, rafforzando la sanitizzazione delle configurazioni PEP 723 fornite dal notebook. La patch elimina dalle sezioni controllabili dall’utente le categorie ai, mcp, completion, secrets e server, trattandole quindi come materiale non affidabile. È una modifica concettualmente importante: un notebook non è più soltanto codice da eseguire volontariamente, ma anche un contenitore di metadata che possono modificare l’ambiente prima dell’esecuzione visibile. Il problema richiama la precedente CVE-2025-49596 nell’Anthropic MCP Inspector, dove una superficie MCP esposta dal browser poteva portare a remote code execution. La logica comune è sempre la stessa: il protocollo o il framework non è pericoloso di per sé, ma diventa critico quando collega input non fidato a strumenti con privilegi locali.

marimo aveva già corretto una seconda falla capace di rubare API key

La stessa versione 0.23.15 aveva già corretto CVE-2026-67618, distinta dalla falla MCP ma basata sullo stesso confine di configurazione. In quel caso un notebook malevolo poteva inserire un base_url controllato dall’attaccante nella configurazione AI. Quando l’operatore effettuava successivamente una richiesta al modello, marimo poteva utilizzare quel server remoto insieme alla OPENAI_API_KEY dell’ambiente locale, trasmettendo così la chiave all’attaccante senza che fosse necessario eseguire una cella. Le due vulnerabilità dimostrano che PEP 723 e i metadata del notebook devono essere considerati equivalenti a input di rete ostile, non a semplice configurazione passiva.

Gli strumenti per sviluppatori stanno diventando direttamente superfici di attacco

Gitea, Strands e marimo appartengono a categorie diverse ma condividono lo stesso problema architetturale. Un repository, un prompt e un notebook vengono tradizionalmente considerati input di sviluppo, non superfici operative equivalenti a un endpoint esposto. Ma quando quegli input possono installare Git hook, invocare Python o registrare server MCP, acquisiscono la capacità di attraversare il confine tra dati e codice. CISA conferma che nel caso Gitea questo confine è già stato sfruttato nel mondo reale. AWS ha corretto Strands prima che il problema venisse trasformato in un caso KEV, mentre marimo ha rafforzato il proprio modello di fiducia dopo due vulnerabilità distinte nella stessa area di configurazione. La regola che emerge è sempre più netta: un agente AI o uno strumento di sviluppo deve considerare ostile tutto ciò che arriva da repository, notebook, prompt e configurazioni finché non viene esplicitamente validato. Il problema non è più soltanto impedire a un modello di generare una risposta sbagliata. È impedire che quella risposta, o il file che la contiene, diventi direttamente un comando sul sistema.