Omnigent, um meta-harness open-source que executa agentes de codificação sob uma única camada de política e sandbox, recebeu quatro avisos de segurança em uma única leva em 2 de setembro. Eles incluem uma issue crítica de execução remota de código autenticada em hosts de runner e duas outras falhas de alta gravidade. A que vale a leitura na íntegra é a de menor classificação entre as quatro.
O bug em que abster-se significa permitir
CVE-2026-62676 descreve um parser compartilhado de comandos de shell que sustenta dois controles separados: a lista de permissões de repositório e branch, e o confinamento do diretório de trabalho. Quando um comando protegido chega em um formato que o parser não modela, ele não produz operação alguma, o avaliador não retorna nada, e nada é tratado como abstenção, o que se resolve em permitir. O aviso lista os desvios: embrulhar o comando em bash -lc, prefixá-lo com binários de wrapper como timeout ou nice, ou escondê-lo dentro de substituição de comando. A classificação é CWE-184, lista de negação incompleta, e ela está no componente cuja função inteira é dizer não.
O que a formulação comum erra
Duas coisas. Primeiro, a hierarquia de severidade inverte a história operacional: a 7,1 é mais consequente do que a 9,0 para qualquer pessoa que use esse harness como camada de contenção, porque ela rompe a promessa central do produto — executar a saída não confiável do modelo, mas confinada — em vez de exigir acesso autenticado já existente. Segundo, e mais importante para leitores que varrem feeds de CVE: esses não são bugs novos. Os commits de correção chegaram em 26 e 27 de junho, com o lançamento corrigido vindo imediatamente na sequência. Os avisos são datados de 2 de setembro. Isso representa um intervalo de 68 dias entre o código ser corrigido e os usuários serem informados.
Por que o intervalo é a lição recorrente
Quem acompanha o risco em ferramentas de IA por meio das datas de publicação de CVE está lendo um sinal que fica semanas ou meses atrás da janela real de exposição. Nesse ecossistema, as notas de versão são o feed de segurança. Equipes que fixam versões de agent-harness deveriam monitorar os lançamentos do repositório, e não esperar que os avisos apareçam.
A regra de projeto que isso produz
A remediação recomendada no aviso soa como uma lista de verificação para quem constrói uma camada de aprovação de ferramentas: abster-se deve se resolver em negar, binários de wrapper precisam ser canonizados, e o avaliador deve recursar em sh -c e substituições de comando antes de julgar. Camadas de aprovação caseiras construídas neste ano estão entregando agora a mesma forma de bug.