Omnigent, open-source meta-harness, который запускает coding agents за единым уровнем политик и песочницы, получил четыре уведомления о безопасности одним пакетом 2 сентября. Среди них — критическая уязвимость удалённого выполнения кода с аутентификацией на хостах runner'ов и ещё две уязвимости высокого уровня серьёзности. Подробно стоит прочитать самую низкооценённую из четырёх.
Баг «воздержание означает разрешение»
CVE-2026-62676 описывает общий парсер shell-команд, который лежит в основе двух отдельных механизмов: allowlist для репозиториев и веток, а также ограничения рабочей директории. Когда контролируемая команда приходит в форме, которую парсер не моделирует, он выдаёт отсутствие операции, оценщик возвращает ничего, и ничего трактуется как воздержание, которое означает разрешение. В уведомлении перечислены способы обхода: оборачивание команды в bash -lc, добавление префикса из wrapper binaries, таких как timeout или nice, либо сокрытие внутри command substitution. Классификация — CWE-184, incomplete denylist, и речь идёт о компоненте, чья единственная задача — говорить «нет».
Что неверно в распространённой трактовке
Две вещи. Во-первых, ранжирование серьёзности переворачивает операционную картину: 7.1 важнее, чем 9.0 для любого, кто использует этот harness как слой сдерживания, потому что он подрывает ключевое обещание продукта — запускать недоверенный вывод модели в изоляции — вместо того чтобы требовать уже имеющегося аутентифицированного доступа. Во-вторых, и это важнее для читателей, просматривающих потоки CVE: это не новые ошибки. Коммиты с исправлениями были внесены 26 и 27 июня, а патч-релиз вышел сразу после этого. Даты уведомлений — 2 сентября. Между исправлением кода и уведомлением пользователей прошло 68 дней.
Почему этот разрыв — повторяющийся урок
Любой, кто отслеживает риски AI-инструментов по датам публикации CVE, читает сигнал, который отстаёт от реального окна воздействия на недели и месяцы. В этой экосистеме security feed — это release notes. Команды, закрепляющие версии agent-harness, должны следить за релизами в репозитории, а не ждать появления уведомлений.
Какое правило проектирования из этого следует
Рекомендации по устранению, приведённые в уведомлении, выглядят как чек-лист для всех, кто строит слой одобрения команд: воздержание должно означать отказ, wrapper binaries нужно приводить к каноническому виду, а оценщик должен рекурсивно проходить внутрь sh -c и command substitutions, прежде чем выносить решение. Самодельные слои одобрения, которые выпускаются в этом году, прямо сейчас поставляются с тем же типом ошибки.