Omnigent, un meta-harness open source che esegue agent di coding dietro un unico livello di policy e sandbox, ha ricevuto quattro segnalazioni di sicurezza in un solo colpo il 2 settembre. Tra queste figurano un problema critico di remote code execution autenticata sugli host runner e due ulteriori falle ad alta gravità. Quella che merita di essere letta per intero è anche la meno grave delle quattro.
Il bug dell’astensione che significa consenti
CVE-2026-62676 descrive un parser condiviso per comandi shell che supporta due controlli separati: la allowlist di repository e branch e il contenimento della working directory. Quando arriva un comando soggetto a gating in una forma che il parser non modella, questo non produce alcuna operazione, l’evaluator non restituisce nulla e il nulla viene interpretato come astensione, che si risolve in consenti. L’avviso elenca i bypass: incapsulare il comando in bash -lc, precederlo con binari wrapper come timeout o nice, oppure nasconderlo all’interno della command substitution. La classificazione è CWE-184, incomplete denylist, e riguarda il componente il cui unico compito è dire no.
Che cosa sbaglia la cornice più comune
Due cose. Primo, la graduatoria della gravità ribalta la storia operativa: il 7.1 è più rilevante del 9.0 per chiunque usi questo harness come livello di contenimento, perché vanifica la promessa centrale del prodotto — eseguire output di modello non attendibile, ma confinato — invece di richiedere un accesso autenticato già esistente. Secondo, e più importante per chi legge i feed CVE: questi non sono bug nuovi. I commit di correzione sono arrivati il 26 e 27 giugno, con la release corretta subito dopo. Le advisories sono datate 2 settembre. È un intervallo di 68 giorni tra la correzione del codice e l’avviso agli utenti.
Perché il ritardo è la lezione ricorrente
Chiunque monitori il rischio degli strumenti AI attraverso le date di pubblicazione delle CVE sta leggendo un segnale in ritardo di settimane o mesi rispetto alla reale finestra di esposizione. In questo ecosistema, le note di rilascio sono il feed di sicurezza. I team che bloccano le versioni degli agent-harness dovrebbero guardare ai release del repository, non aspettare che escano le advisories.
La regola di progettazione che ne deriva
La remediation raccomandata dall’avviso è una checklist per chiunque stia costruendo un livello di approvazione dei comandi: l’astensione deve risolversi in diniego, i binari wrapper devono essere resi canonici e l’evaluator deve ricorsivamente entrare in sh -c e nelle command substitution prima di giudicare. I layer di approvazione fatti in casa e realizzati quest’anno stanno già distribuendo lo stesso tipo di bug.