Omnigent, un meta-harness de código abierto que ejecuta agentes de código detrás de una única capa de políticas y sandbox, recibió cuatro avisos de seguridad de una sola vez el 2 de septiembre. Entre ellos hay un problema crítico de ejecución remota de código autenticada en hosts de ejecución y otros dos fallos de alta gravedad. El que merece leerse completo es el peor valorado de los cuatro.
El error de abstenerse significa permitir
CVE-2026-62676 describe un parser compartido de comandos de shell que da soporte a dos controles distintos: la allowlist del repositorio y de la rama, y el confinamiento del directorio de trabajo. Cuando llega un comando controlado en una forma que el parser no modela, no produce ninguna operación, el evaluador no devuelve nada, y nada se interpreta como abstención, lo que se resuelve como permitir. El aviso enumera los desvíos: envolver el comando en bash -lc, anteponer binarios envoltorio como timeout o nice, o esconderlo dentro de una sustitución de comandos. La clasificación es CWE-184, lista de denegación incompleta, y se sitúa en el componente cuya única misión es decir que no.
Qué falla en el encuadre habitual
Dos cosas. Primero, la jerarquía de gravedad invierte la historia operativa: el 7.1 es más relevante que el 9.0 para cualquiera que ejecute este harness como capa de contención, porque vulnera la promesa central del producto — ejecutar la salida no confiable del modelo, pero confinada — en lugar de requerir un acceso autenticado ya existente. Segundo, y más importante para quienes leen feeds de CVE: no son fallos nuevos. Los commits de corrección llegaron el 26 y 27 de junio, y la versión corregida se publicó inmediatamente después. Los avisos están fechados el 2 de septiembre. Hay una brecha de 68 días entre la corrección del código y la notificación a los usuarios.
Por qué la brecha es la lección recurrente
Cualquiera que siga el riesgo de las herramientas de IA a través de las fechas de publicación de CVE está leyendo una señal que va semanas o meses por detrás de la ventana real de exposición. En este ecosistema, las notas de versión son el feed de seguridad. Los equipos que fijan versiones de harness para agentes deberían vigilar los lanzamientos del repositorio, no esperar a que aparezcan los avisos.
La regla de diseño que se desprende
La corrección que recomienda el aviso se lee como una lista de comprobación para cualquiera que construya una capa de aprobación de herramientas: abstenerse debe resolverse como denegar, los binarios envoltorio deben canonicalizarse y el evaluador debe recursar en sh -c y en las sustituciones de comandos antes de juzgar. Las capas de aprobación artesanales que se están construyendo este año están publicando ahora mismo el mismo tipo de fallo.