MaxKB: маршрут диспетчеризации агента позволяет пользователю, которому отказано в доступе к инструменту, всё равно вызвать его и прочитать его учётные данные.

MaxKB — открытый корпоративный AI-ассистент, поддерживаемый 1Panel-dev, — предоставляет список разрешений для каждого пользователя и каждого инструмента, позволяя администратору выдать участнику рабочего пространства один инструмент и запретить другой. Согласно бюллетеню безопасности, опубликованному 2 сентября 2026 года, этот запрет действовал на собственных маршрутах инструмента, но не на пути, который агент или рабочий процесс использует для вызова того же инструмента. Участник рабочего пространства с самой низкой ролью мог указать идентификатор запрещённого инструмента при построении рабочего процесса, запустить этот рабочий процесс и получить не только выходные данные инструмента, но и учётные данные, которые MaxKB расшифровывает на стороне сервера, чтобы запустить его. Затронуты версии с 2.0.0 по 2.9.2, при этом в бюллетене не указана исправленная версия. Эта запись — обход авторизации при диспетчеризации инструментов в MaxKB — является одной из записей в OrcaRouter AI Incident Archive, где содержится полный набор записей и соседние записи, относящиеся к этому инциденту.

То, что заставляет внимательно читать это дело, — не оценка. А то, что в продукте уже была нужная проверка, её применили к очевидной двери, но оставили без присмотра вторую дверь к той же функциональности. Рекомендация GHSA-383v-fx78-pphm была написана исследователем, который её обнаружил, и опубликована через систему рекомендаций GitHub 2 сентября 2026 года в 07:43 UTC с указанием авторства Matteo Panzeri (@matte1782). Запись CVE-2026-77516 появилась 21 сентября 2026 года.

Что устанавливает консультативное заключение

Модель MaxKB для каждого инструмента — это WorkspaceUserResourcePermission, описанная в рекомендации как список разрешений с запретом по умолчанию, определяемый во время запроса. Специализированные маршруты инструментов обеспечивают его соблюдение. В рекомендации перечислены механизмы принудительного применения в apps/tools/views/tool.py, где Operate.put, Operate.get, Debug.post, Export.get и Delete каждый содержит проверку разрешения представления на соответствие разрешению вызывающей стороны на инструмент рабочей области. Debug.post — маршрут, наиболее близкий к простому запуску инструмента, и он защищён проверкой.

Путь диспетчеризации агента и рабочего процесса не применяет эту проверку повторно. В рекомендации указаны три отдельных места, где она отсутствует. В apps/application/serializers/application.py сериализатор приложения привязывает tool_ids, skill_tool_ids и mcp_tool_ids напрямую из входных данных запроса без авторизации для каждого инструмента — и в рекомендации отмечается, что асимметрия видна в том же файле, поскольку knowledge_id_list проверяется на соответствие доступным пользователю базам знаний несколькими строками ниже, а инструменты — нет. В apps/common/utils/shared_resource_auth.py filter_authorized_ids пропускает каждый инструмент в собственном рабочем пространстве вызывающего без каких-либо условий; межрабочее ограничение доступа, на которое он полагается, — это хук, доступный только в корпоративной версии и отсутствующий в community-редакции, и он никогда не обращается к WorkspaceUserResourcePermission. А в конечной точке apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py выполняет сохранённый код инструмента с его init_params, расшифрованными с помощью rsa_long_decrypt от имени приложения, без проверки предоставления прав для каждого инструмента.

В рекомендации результат называется выполнением по схеме confused deputy: диспетчеризация рабочего процесса запускает инструмент и его сохранённые секреты, доступ к которым тому же вызывающему запрещён на собственных маршрутах инструмента. Раскрытие учётных данных — это часть, выходящая за рамки обычного несанкционированного использования инструмента. У инструмента init_params шифруются при хранении с помощью RSA и расшифровываются на стороне сервера только в момент выполнения, поэтому вызывающий, который инициирует это выполнение, получает значения, которыми никогда не располагал и которые не мог бы предоставить.

Демонстрация — в собственных цифрах исследователя

В рекомендации сообщается о динамическом подтверждении на v2.9.2, выполненном из официального all-in-one-образа 1panel/maxkb:v2.9.2. В ходе настройки использовались одно рабочее пространство, администратор и второй участник с ролью USER. Администратор создал инструмент A и инструмент B, поместил новый случайный секрет вinit_params, и написал тело инструмента B так, чтобы оно возвращало этот секрет при выполнении. Затем участнику было выдано разрешение на уровне отдельного инструмента только для инструмента A, и, как указано в рекомендации, состояние отсутствия разрешений для инструмента B было повторно проверено в базе данных после запуска.

Запрещённая половина теста вернула то, что обещает продукт. От имени участника отладочный маршрут для Tool B ответил 403, маршрут обновления ответил 403, маршрут экспорта ответил 403, а разрешённый Tool A вернул 200 в качестве проверки работоспособности. Затем половина с обходом привязала Tool B к приложению рабочего процесса через узел библиотеки инструментов — привязка была принята с HTTP 200 и без проверки отдельного инструмента — и запуск рабочего процесса вернул HTTP 200 с телом, содержащим имя инструмента, секрет-маркер и список ключей ["api_key"].

В рекомендации говорится, что секрет обнаружился на трёх уровнях: в ответе API рабочего процесса, в записи выполнения инструмента со статусом SUCCESS и в строке базы данных, где у инструмента B init_params находится как 344-байтовый RSA-шифротекст — именно так исследователь доказывает, что значение было расшифровано на стороне сервера от имени приложения, а не предоставлено вызывающей стороной. Тот же участник, которому было отказано на маршруте запуска инструмента, получил расшифрованный секрет инструмента, привязав его к рабочему процессу.

Одна оценка опубликована, о более высокой — спорят

Оценка, присвоенная CVE-2026-77516, — CVSS 3.1 5.4, средний уровень, с вектором AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. В записи NVD указано, что эта оценка получена из ленты рекомендаций GitHub, а не из собственного анализа NVD, а запись имеет статус Deferred, означающий, что NVD её не обогащала. Собственная классификация архива соответствует этой опубликованной оценке: средний уровень серьёзности, зафиксированного реального ущерба нет.

Собственный раздел о воздействии в уведомлении приводит доводы в пользу более высокой оценки. В нём указан уровень серьёзности 7,1 (High) по вектору, который повышает воздействие на конфиденциальность до высокого, и говорится, что эта цифра возрастает до 8,1, когда запускаемый инструмент выполняет привилегированные записи от имени приложения. Это разногласие о том, как учитывать экспозицию учётных данных, а не о том, существует ли обход — один и тот же документ и демонстрирует уязвимость, и утверждает, что её недооценивают. Ничто в открытых источниках не позволяет определить, какая цифра верна, а средняя оценка в архиве соответствует опубликованной оценке CVE, а не аргументации уведомления.

В материалах дела зафиксированы ещё две оценки. Точки принятия решений SSVC от CISA, добавленные в запись NVD 28 сентября 2026 года, фиксируют эксплуатацию как «poc», автоматизируемость как «no», а техническое воздействие — как «partial»; значение «poc» отражает наличие proof of concept, которое действительно есть — в самом бюллетене; это не является выводом об эксплуатации в реальных условиях. Модель EPSS от FIRST оценила вероятность эксплуатации в течение следующих 30 дней в 0,242%, что соответствует 15,2-му процентилю, в оценке от 27 октября 2026 года.

Исправление, выпущенное до публикации рекомендации, и ни одного в затронутом диапазоне.

В таблице версий в уведомлении указано, что затронуты версии с 2.0.0 по 2.9.2, исправленных версий нет, а в тексте говорится, что на момент проверки исправленная версия недоступна, и добавляется, что исправление в помеченном релизе позволило бы привязать к нему CVE. Репозиторий поставщика рассказывает несколько иную историю, и эта разница важна для всех, кто решает, что запускать.

В репозитории MaxKB функции, закрывающие путь диспетчеризации, — validate_bound_tool_permissions и get_authorized_tool_ids в apps/application/serializers/application.py — отсутствуют в теге v2.9.2 и в v2.10.2-lts, v2.10.3-lts и v2.10.4-lts, но присутствуют начиная с v2.10.5-lts. Этот релиз был опубликован 6 августа 2026 года, за четыре недели до публикации уведомления о безопасности. Тот же тег добавляет проверку инструментов для каждого пользователя в base_tool_lib_node.py, опираясь на WorkspaceUserResourcePermission, и добавляет фильтр с учётом пользователя в shared_resource_auth.py — иными словами, он в общих чертах реализует три шага по устранению уязвимости, которые позднее рекомендует уведомление о безопасности.

Никто не заявлял об этой связи публично. В примечаниях к выпуску v2.10.5-lts не упоминается исправление разрешений инструментов; там перечислены четыре не связанных с этим пункта безопасности и пакет доработок функций и исправлений ошибок. В уведомлении не указана версия 2.10.5, а диапазон затронутых версий просто заканчивается на 2.9.2 — последнем выпуске ветки 2.9. История выпусков не показывает ни одного патча 2.9.x после уведомления, поэтому для развертывания на 2.9.2 нет исправленной сборки в пределах его собственной ветки. Текущий выпуск — v2.10.8-lts, опубликованный 22 октября 2026 г.; в его примечаниях описаны исправления X-Pack в авторизации общих инструментов, а не что-либо в пути диспетчеризации community-версии.

Что не установлено

Из демонстрации стоит выделить три вещи. Во-первых, нет публичного отчёта о том, что обход использовался против кого-либо. В материалах речь идёт об обнаруженной уязвимости, а не о расследованном вторжении; у неё нет ни пострадавшего, ни приписанного исполнителя, ни ущерба, а proof of concept из бюллетеня был запущен исследователем в контролируемой среде. Во-вторых, ни одна новостная организация, регулятор или другая исследовательская команда, судя по всему, не анализировала эту уязвимость: имеющиеся публикации ограничены базами данных уязвимостей и агрегаторами — среди них VulDB, база данных Rapid7, Armis, SOCRadar и openCVE — которые перечисляют CVE и приводят описание из бюллетеня, и ни один из них не даёт независимой оценки кода. Таким образом, описанный здесь механизм опирается на один бюллетень и на собственный исходный код поставщика. В-третьих, нет данных о том, сколько развёртываний MaxKB находится в затронутом диапазоне, и ни поставщик, ни исследователь таких данных не опубликовали.

Совокупность подверженных риску систем узка, но её не так просто подсчитать: это самостоятельно размещённые установки MaxKB редакции Community Edition версий с 2.0.0 по 2.9.2, в которых больше одного участника рабочего пространства и где администратор с помощью разрешений на уровне отдельных инструментов запретил доступ к инструменту, содержащему учётные данные. Уязвимость не является удалённым выполнением кода и требует действующей учётной записи с низкими привилегиями, поэтому оценку определяет воздействие на конфиденциальность, а не путь атаки. То, что получает злоумышленник, ограничено тем, что содержат запрещённые инструменты, — ключами API, токенами и тем, к чему они дают доступ, — и именно поэтому авторы рекомендации утверждают, что воздействие больше, чем подразумевает низкая оценка конфиденциальности.

Что может оператор

Рекомендации по устранению адресованы мейнтейнерам, а не операторам, и их три шага соответствуют коду, появившемуся в v2.10.5-lts: применить разрешение для отдельного инструмента перед выполнением инструмента в реализациях tool-library и узла tool, проверять каждый привязанный tool_ids, skill_tool_ids и mcp_tool_ids во время привязки так же, как уже проверяется knowledge_id_list, и заставить filter_authorized_ids обращаться к разрешению для отдельного инструмента, а не только к членству в рабочем пространстве.

Для команды, использующей затронутую сборку, практические шаги, вытекающие из описания в самом уведомлении, таковы.

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

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

• Проверьте, какие рабочие процессы и агенты привязывают инструменты, содержащие учётные данные, поскольку именно эта привязка, согласно рекомендации, принимается без проверки каждого инструмента.

• При обновлении учтите, что проверка на уровне пользователя появляется в репозитории начиная с v2.10.5-lts, и что ни один выпуск не обозначен в рекомендации как исправление — оператор, полагающийся на обновление, полагается на исходный код с тегом, а не на заявление поставщика о патче.

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

Урок из этой истории носит структурный, а не числовой характер. Разрешение на уровне отдельного ресурса так же надёжно, как его наименее защищённая точка входа, а платформа агентов быстро накапливает точки входа: отладочный маршрут, маршрут экспорта, узел рабочего процесса, триггер чата. В MaxKB были список разрешений и проверка; чего не хватало в линейке 2.0–2.9, так это привычки задавать один и тот же вопрос у каждой двери.