Tencent BrowserSkill проверял лишь то, что идентификатор расширения выглядит настоящим, — любое расширение могло подсунуть агенту поддельные страницы

17 сентября 2026 года пользователь GitHub, публикующийся под именем carfeii, открыл issue #273 в open-source-проекте BrowserSkill компании Tencent с узким утверждением: локальный демон, соединяющий браузерное расширение с ИИ-агентом, не проверял, какое расширение подключается, а лишь то, что соединение вообще выглядело как расширение. Три дня спустя, 20 сентября, VulnCheck опубликовала находку как CVE-2026-94111, описала демон, который «принимает любой origin chrome-extension, состоящий из 32 символов в диапазоне a-p», классифицировала её как CWE-346 (ошибка проверки origin) и выразила благодарность George Chen. Бюллетень оценивает её в CVSS 4.0 6.9, средний уровень, при этом влияние на целостность оценено как высокое, а на конфиденциальность и доступность — как низкое. Ничто в записи не указывает на то, что уязвимость использовалась: архив не регистрирует случаев эксплуатации и присваивает записи уровень уверенности A, при этом real_harm имеет значение false. Это одна запись в AI incident archive, где каждая запись содержит собственные источники, серьёзность, уровень уверенности и флаг спорности.

Проверка формата, которая так и не проверила идентичность

Код в центре записи невелик. В crates/bsk-cli/src/daemon/ws.rs функция origin_allowed() принимает заголовок Origin рукопожатия WebSocket, отбрасывает строку chrome-extension:// и возвращает true, если оставшееся имеет ровно 32 символа и каждый символ находится между a и p. Это и есть вся проверка. Она выполняется один раз, внутри колбэка обновления HTTP, и при неудаче возвращается 403 с сообщением «Origin not in chrome-extension allow-list» — хотя, как было опубликовано, никакого списка, в котором можно было бы находиться, не существовало.

Шаблон не случаен. Идентификаторы расширений Chrome Manifest V3 состоят из 32 символов, взятых ровно из этих шестнадцати букв, поэтому проверка корректно распознаёт форму настоящего источника расширения. Дефект в том, что такую форму имеет каждое расширение. Проверка спрашивает, выглядит ли вызывающая сторона как браузерное расширение, и никогда — является ли она браузерным расширением этого проекта, а идентификатор, с которым следовало сравнивать, уже был публичным: README проекта ссылается на страницу Chrome Web Store, идентификатор которой — hhcmgoofomhgciiibhipgmgkgnoenaoi, и указанный рядом с ним ID в Edge Add-ons. Ни одна из этих строк нигде не встречается в гейте.

Демон прослушивает фиксированный локальный порт, 52800, объявленный как DEFAULT_WS_PORT в CLI и используемый без изменений в пути локального подключения. Порт задокументирован, постоянен и доступен для всего, что уже работает в профиле браузера пользователя. Именно из-за местоположения вектор в рекомендации начинается с AV:L — атакующему нужна точка опоры на машине, а PR:L фиксирует, что достаточно точки опоры с низкими привилегиями. Расширение, установленное в том же профиле, — как раз такая точка опоры.

Сколько стоит место и насколько оно устоялось

Фраза о воздействии в рекомендации сформулирована широко: злоумышленник, зарегистрировавший вредоносное расширение как браузерный клиент, может «перехватывать и манипулировать содержимым страницы, DOM и скриншотами, возвращаемыми AI-агенту». Именно это описание фигурирует в CVE, в записи рекомендации GitHub GHSA-x6f2-qp26-2xrh и в архиве, и оно объясняет высокую оценку целостности по CVSS. Это также резюме, написанное стороной, назначившей CVE, а не отчёт о продемонстрированной атаке.

Более внимательный разбор появился в ту же неделю, в самом треде issue. 20 сентября комментатор под ником bb6894 сообщил, что перепроверил код относительно main на коммите fa953dc6 (18 сентября) и проследил, к чему сторонний клиент действительно имеет доступ после рукопожатия. Большинство входящих методов инструментов, как сказано в комментарии, возвращают UnknownMethod узлу WebSocket; запросы аудита ограничены собственными записями клиента; а межсессионные действия, такие как window_closed, user_interrupt и update_interaction, защищены от сессий, принадлежащих другому браузеру. То, что проходит этот фильтр, оказывается более узким и, для агента, возможно, даже хуже перехвата: стороннее расширение может занять слот браузера под instance_id, выбранным атакующим, и если оно — единственный зарегистрированный браузер — при холодном запуске или перезапуске демона — оно получает запросы инструментов агента и отвечает на них поддельным содержимым страницы, DOM или скриншотами. Комментатор называет это «подделкой результатов в адрес агента» и «каналом в восприятие агента». Второй эффект — отказ в обслуживании: если настоящий браузер также онлайн и селектор не указан, запуск сессии может завершиться ошибкой MultipleBrowsersOnline.

Ни одна из версий не была публично продемонстрирована. Автор отчёта описал proof of concept как «доступный по запросу»; никто его не опубликовал, и эксплуатация не зафиксирована. Таким образом, разница между двумя версиями — это разница между двумя прочтениями одного и того же исходного файла, а не между теорией и работающим эксплойтом; и в материале приводятся обе, а не выбирается одна. Что можно утверждать без оговорок: после рукопожатия никогда не проводилась повторная проверка личности, поэтому то, что допустил шлюз, оставалось допущенным на всё время существования соединения.

Код уже знал

Самый неудобный документ в этой записи — не уведомление. Это комментарий непосредственно над функцией, поставляемый в тегированном релизе, на который указывает уведомление. В нём этот пробел помечен как TODO(M10/M12), назван список разрешённых, который предполагается построить, — DaemonConfig::allowed_extension_ids — набор, заполняемый из конфигурационного файла или в ходе процесса сопряжения, — а затем указана причина, по которой это было отложено: «приемлемый на данный момент пробел в эшелонированной защите, поскольку сопряжение происходит через всплывающее окно, но расширение, установленное в обход магазина, на той же машине в настоящее время проходит проверку».

Если читать буквально, сопровождающие знали, какой вызывающий код пропускает эта проверка, зафиксировали, что знали об этом, и выпустили релиз. Это не делает подверженность большей, чем сказано в рекомендации; это делает её менее неожиданной и переносит вопрос с «как это прошло ревью» на «что заставило бы отложенное исправление стать срочным». Смягчающее допущение проектирования реально и тоже задокументировано: локальное подключение включается только по желанию пользователя. Согласно README, пользователь устанавливает расширение, открывает его всплывающее окно и включает локальное подключение, а демон должен быть запущен, чтобы хоть что-то из этого было доступно. Профиль, в котором расширение установлено, но переключатель выключен, или в котором не запущен демон bsk, не является целью прослушивания.

Пять недель спустя ворота не изменились.

Диапазон затронутых версий в записи — «до 0.3.0 включительно», и именно этот диапазон назначил CNA. Но в репозитории история на этом не заканчивается. Релиз CLI 0.3.0 был помечен тегом 17 сентября в 02:22 UTC; issue был зарегистрирован в тот же день в 15:14 UTC, примерно через тринадцать часов. С тех пор вышло ещё три релиза CLI — 0.3.1 — 23 сентября, 0.3.2 — 30 сентября и 0.3.3 — 15 октября, — и функция origin_allowed() в каждом из этих тегов представляет собой ту же проверку, описанную выше, причём TODO по-прежнему находится над ней. Основная ветка также содержит её по состоянию на 27 октября.

Исправление существует, но только в виде предложения. 28 сентября участник под ником dangzitou открыл pull request #363 из личного форка под названием «fix(daemon): закрепить шлюз источника WS за собственными ID расширений BrowserSkill». Он заменяет проверку формы на сравнение с двумя ID из магазинов и добавляет BSK_ALLOWED_EXTENSION_IDS как явный путь допуска для сборок, устанавливаемых вручную, и для сборок для разработки, у которых распакованные ID выводятся из пути установки. В описании pull request утверждается, что он закрывает как путь подделки, так и отказ в обслуживании MultipleBrowsersOnline. По состоянию на 27 октября он всё ещё открыт и не объединён, а issue остаётся открытой, и к ней не приложено никаких заявлений поставщика.

Практическое следствие состоит в том, что не существует версии, на которую можно было бы обновиться и которая содержала бы исправление. Любой, кто советует «обновиться до версии выше 0.3.0», советует шаг, которого ещё не существует: более поздние выпуски — это более поздние выпуски, а не исправленные. Диапазон в записи следует читать как диапазон, который CNA оценил 20 сентября, а не как утверждение, что 0.3.1 и последующие версии чисты.

Что установлено, а что — нет

• Установлено: выпущенный исходный код в теге cli-v0.3.0 содержит проверку origin, которая допускает любой 32-символьный chrome-extension origin, состоящий из символов a–p. Автор отчёта, CNA и сам файл согласуются, а код является публичным.

• Установлено: проверка выполнялась один раз, при апгрейде WebSocket, без последующей проверки идентичности, на фиксированном локальном порту 52800.

• Установлено: собственный комментарий в исходном коде проекта признавал, что расширение, установленное в обход магазина, пройдёт, а список разрешённых был отложен.

• Установлено: CVSS 4.0 6.9 и CVSS 3.1 6.6 — обе оценки принадлежат VulnCheck и зафиксированы NVD как вторичные. Собственный статус записи в NVD — Deferred, что означает, что NVD опубликовал данные CNA, не добавив анализа, подготовленного NVD.

• Установлено:Оценка SSVC агентства CISA, датированная 21 сентября, указывает эксплуатацию как отсутствующую, автоматизируемость как «нет», а техническое воздействие как частичное. EPSS организации FIRST по состоянию на 26 октября оценивает вероятность эксплуатации в следующие тридцать дней в 0,00135, что соответствует 2,9-му процентилю.

• Не установлено: какое-либо использование в реальных условиях. Нет эксплуатации, нет опубликованного доказательства концепции, нет данных о количестве затронутых установок. Метрики репозитория проекта не являются подсчётом установок, и никто таких данных не публиковал.

• Не установлено: какая оценка воздействия применима. Формулировки CNA «перехват и манипуляция» и приведённые в ветке «подделка результатов плюс отказ в обслуживании» описывают разные верхние пределы, и ни одна из них не была продемонстрирована за пределами чтения кода.

• Не установлено: что уязвимость ограничивается версией 0.3.0. Строка версии — это оценка CNA; код не менялся в трёх выпусках после неё, и ни одно заявление поставщика не снимает с них подозрений.

• Противоречиво, не разрешено: один агрегатор, DevGuard, отображает сигнал «обнаружены попытки эксплуатации» для этой CVE, не указывая источник, IOC или поставщика телеметрии. Это противоречит зафиксированной оценке CISA об отсутствии эксплуатации и отсутствию каких-либо публичных отчётов; архив также не фиксирует эксплуатацию. Рассматривайте флаг агрегатора как необоснованный, а не как вторую точку данных.

Почему транспорт — интересная цель

Большинство рекомендаций по промпт-инъекциям проводят одну и ту же границу: считать полученный текст страницы недоверенным, а механизм, который его доставляет, — доверенным. Предполагается, что инструмент, читающий веб-страницу, действительно читает страницу; вопрос в том, что на ней написано. Эта запись переворачивает данную логику. То, что агент получает в качестве содержимого страницы, DOM и скриншотов, определяется тем, что решит отправить клиент на другом конце локального сокета, а единственная проверка на этом сокете задавала вопрос, на который мог правильно ответить любой кандидат. Если клиент чужой, проверке «что говорит страница» больше не с чем сверяться.

Именно поэтому уровень серьёзности оказывается именно таким, а не выше. Атака является локальной: она предполагает, что в профиле уже установлено расширение или присутствует другой локальный код, и требует, чтобы демон был запущен с включённым локальным подключением. Для целевых пользователей инструмента такие условия обычны, а для всех остальных — необычны. Средний уровень серьёзности, указанный в архиве, и зафиксированное там отсутствие ущерба соответствуют этой картине: реальное расширение зоны доверия ровно на той границе, которую по замыслу должна была контролировать архитектура, при отсутствии свидетельств того, что кто-либо через неё прошёл.

Следующий узкий практический совет — это не средство защиты, которое кто-либо опубликовал, а лишь граница, которую код оставляет на месте. Поскольку допуск решается один раз при рукопожатии на опубликованном порту, доступная поверхность определяется тем, какие расширения установлены в профиле, в котором работает демон, и включены ли этот демон и локальное подключение расширения в данный момент. Пока не появится список разрешённых идентификаторов расширений, весь контроль сводится к этим двум фактам.

CVE-2026-94111 состарится одним из двух способов. Либо пулл-реквест будет принят, и запись превратится в короткую заметку об известном пробеле, который долго не закрывали, либо та же проверка формы через год всё ещё будет присутствовать в дереве, и запись будут цитировать как ранний пример класса, к которому она относится: не страница, несущая враждебную инструкцию, а канал, который решает, какую страницу читает агент.