MaxKB прикрепил инструмент Shell к каждому ассистенту с поддержкой инструментов и никак не ограничил доступ к нему

MaxKB — открытая платформа корпоративных ассистентов, опубликованная в рамках организации GitHub 1Panel-dev, — строила своих чат-агентов на фреймворке, который молча добавляет инструмент оболочки всякий раз, когда передаётся бэкенд с поддержкой оболочки, — и MaxKB так и не удалила этот инструмент и не попросила кого-либо одобрить его использование. Уязвимость — это CVE-2026-77521, опубликованная как рекомендация GitHub GHSA-f36j-f34j-h3rx от 2 сентября 2026 года и оценённая в 10,0 из 10 по CVSS 3.1 для случая публичного или встроенного ассистента. Lasso Security, которая обнаружила и сообщила о ней, продемонстрировала, что сообщение в чате — или текст, который ассистент просто получает через поиск или загруженный документ, — может заставить модель выполнять команды: при развёртывании на физическом сервере напрямую на хосте и в официальном контейнере через обёртку, которую, по словам исследователей, можно обойти с помощью точки с запятой. Ни один из цитируемых источников не фиксирует эксплуатацию этой уязвимости в реальных условиях. Собственная оценка серьёзности, оценка уверенности и список источников из записи находятся в архиве инцидентов ИИ, вместе с соседними записями о MaxKB и агентных инструментах из той же партии раскрытий.

MaxKB — это развёртываемый на собственных серверах продукт для создания ассистентов с дополненной выборкой: оператор создаёт ассистента, подключает к нему возможности — инструменты, серверы Model Context Protocol, навыки, вложенные приложения, — связывает с базой знаний, построенной по загруженным документам или просканированным веб-сайтам, а затем предоставляет ассистента либо через консоль с аутентификацией, либо как публичный встраиваемый чат-виджет. Эта универсальность и есть поверхность атаки. Условие срабатывания из рекомендации — не необычная конфигурация, а обычная: любой ассистент, к которому подключена хотя бы одна возможность, направляет свой чат через затронутый путь агента, тогда как чат без подключённых возможностей — нет. В материале Lasso проект описывается как один из наиболее широко распространённых в своей категории, и отмечается, что MaxKB обычно развёртывается как мультитенантный сервис, — а это помещает команду, выполняющуюся от имени пользователя приложения, под модель многотенантности, а не внутрь части этой модели, принадлежащей одному тенанту.

Инструмент оболочки появился вместе с фреймворком, а не с продуктом.

MaxKB создает этих агентов с помощью библиотеки deepagents от LangChain, закрепленной на версии 0.6.11 в файле pyproject.toml проекта как для уязвимого тега, так и для текущего. В apps/application/flow/tools.py, в строке 467 тега v2.10.3-lts, проект вызывает create_deep_agent с backend, установленным в SandboxShellBackend, подкласс MaxKB, который выполняет команды на хосте. Согласно рекомендации, deepagents автоматически внедряет набор инструментов всякий раз, когда shell-backend передается таким образом: execute, ls, read_file, write_file, edit_file, glob и grep. Они не являются частью аргумента tools=list, который содержит только собственные инструменты оператора, инструменты MCP и инструменты навыков. Их нельзя удалить из интерфейса или через конфигурацию.

MaxKB также не передаёт excluded_tools — аргумент библиотеки, который удалял бы их. В рекомендации осторожно объясняется, почему это важно даже в качестве средства устранения: excluded_tools «удаляет инструмент из того, что сообщается модели, но не из исполнителя». Различие между инструментом, о котором модель не знает, и инструментом, который не может выполняться, — это весь этот баг в миниатюре.

Шлюз, который перечисляет три инструмента и опускает четвёртый

Контроль с участием человека в том же вызове — это одна строка, и она перечисляет три операции: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. Запись файла, чтение файла и редактирование файла названы. Выполнение команд вообще не является ключом в словаре. В трактовке рекомендации это означает, что для execute одобрение не запрашивается — три операции с файловой системой названы и явно заданы так, чтобы не прерывать выполнение, а инструмент оболочки не назван вовсе.

В совокупности цепочка выглядит так: недоверенный текст достигает модели, модель вызывает execute, и команда выполняется. В рекомендации указаны два способа поступления недоверенного текста. Прямой — чат: публичный или встроенный виджет либо беседа другого арендатора. Косвенный — контент, который поглощает ассистент: документ RAG, загруженный файл или веб-страница, которую платформа сканирует в базу знаний. Публикация Lasso делает второй маршрут наглядным, отмечая, что «круг людей, которые могут поместить текст перед моделью, шире круга людей, которые могут общаться с ней в чате».

При установке на «голое железо» команда — это просто команда.

Всё, что MaxKB делает для изоляции, происходит в apps/application/flow/backend/sandbox_shell.py, и в v2.10.3-lts это начинается со значения по умолчанию. В строке 9 записано _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))), а SANDBOX не появляется в Config.defaults в apps/maxkb/conf.py. При отсутствии явной настройки MAXKB_SANDBOX значение равно нулю, ветка-обёртка в строке 65 пропускается, и execute напрямую достигает subprocess.run с shell=True на хосте от имени пользователя, запускающего службу, — root, согласно формулировке в рекомендации, если служба запущена от root.

Это та конфигурация, которую исследователи использовали для своего доказательства концепции на хосте. Они запустили настоящий код MaxKB из исходников с неустановленной переменной MAXKB_SANDBOX, создали ассистента с одним подключённым инструментом и в одном сообщении чата попросили его выполнить команды получения системной информации. Инструмент execute сработал и записал файл, содержимым которого был вывод uname, id и sw_vers самого хоста — вывод, который, как отмечается в уведомлении, был подтверждённо недоступен внутри любого контейнера. Lasso также фиксирует предел того, что его остановило: модель отказалась от файла с откровенно говорящим названием, указывающим на доказательство, тогда как безобидные рабочие формулировки — нет. Выравнивание модели, по их словам, — это «частичное препятствие, а не механизм контроля».

На официальном образе песочница запускалась и всё равно допускала утечку

Официальный контейнер задаёт MAXKB_SANDBOX=1 в базовом образе, в файле installer/Dockerfile-base, строка 48, поэтому там обёртка активна — и обёртка является второй уязвимостью. Она формировала одну строку: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so, затем gosu sandbox, а затем команду, переданную моделью, и отдавала её оболочке, работающей от root. Поскольку команда интерполировалась как текст, под gosu выполнялся только её первый токен. Любая точка с запятой, конвейер, перенаправление или подстановка команды в выводе модели вычислялись внешней root-оболочкой ещё до того, как sandbox успевал их увидеть.

В разборе Lasso показана рабочая схема: полезная нагрузка вида env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id, в которой ls ограничен песочницей, whoami — нет, а всё после него выполняется без ограничений. В ходе тестирования исследователи записали принадлежащий root файл с помощью перенаправления, пока внутренняя команда в песочнице была заблокирована. Усугубляет ситуацию то, что ни installer/Dockerfile, ни installer/Dockerfile-base не содержат директивы USER, поэтому образ приложения работает с UID 0 — в рекомендательном отчёте подтверждается получение root во время выполнения. Таким образом, контейнер всё равно выполнял команды, а песочница лишь определяла, какие из них косметически приписываются пользователю с низкими привилегиями.

Полный сценарий атаки, описанный Lasso, вообще не требует доступа к цели. Злоумышленник размещает команды на веб-странице, ждёт, пока агент жертвы проиндексирует её в базу знаний, после чего жертва задаёт обычный вопрос. Ответ возвращается корректным и легитимным; внедрённый curl уже выполнился на сервере злоумышленника. В рекомендациях отмечается, что исследователи тестировали только собственные развёртывания, а не какие-либо сторонние или размещённые в облаке экземпляры MaxKB.

Что источники устанавливают, а что просто не измерено

Механизм, два режима развертывания, указание авторства и исправленный выпуск совпадают во всех четырех документах: в уведомлении GitHub, записи NVD, опубликованной 21 сентября 2026 года, собственном техническом разборе Lasso от 10 сентября 2026 года и отчете GBHackers от 22 сентября 2026 года — единственном материале независимого издания, найденном по этой CVE. Ни один источник не оспаривает ни одну часть вывода, и архив фиксирует запись как неоспариваемую с высшей степенью достоверности.

Чего в источниках нет, так это какой-либо количественной оценки подверженности. Там нет ни подсчёта развертываний MaxKB, ни подсчёта ассистентов, доступных из интернета или встроенных, ни результата сканирования, ни телеметрии и ни одного названного пострадавшего. Ничто в материалах не показывает, что эта уязвимость применялась против кого-либо, и собственная оценка эксплуатации CISA согласуется с этим: блок SSVC, приложенный к записи NVD 22 сентября 2026 года, оценивает эксплуатацию как «poc», автоматизируемость как «yes», а техническое воздействие как «total». Модель EPSS организации FIRST по состоянию на 27 октября 2026 года оценила вероятность эксплуатации в следующие 30 дней в 1,05 процента, что соответствует 64-му процентилю, а CVE не фигурирует в каталоге CISA Known Exploited Vulnerabilities по состоянию на 27 октября 2026 года. Собственная оценка архива отражает те же данные: серьёзность — высокая, реальный ущерб — false.

Оценка 10,0 заслуживает того, чтобы указать её область действия, поскольку именно это число вероятнее всего процитируют вне контекста. Это оценка для случая публичного или встроенного ассистента, где вектор CVSS имеет вид AV:N/AC:L/PR:N/UI:N/S:C — доступность по сети, отсутствие привилегий, отсутствие взаимодействия с пользователем и изменение области действия, поскольку команда внутри ассистента проникает в операционную систему хоста. Оценка принадлежит CNA, а CNA здесь — программа консультаций GitHub, на которую также указывает идентификатор источника в записи CVE. NVD приводит тот же вектор в качестве вторичной метрики и по состоянию на 28 октября 2026 года указывает для этой записи статус «Deferred», что означает, что NVD опубликовала анализ назначившего органа, а не свой собственный.

Патч был выпущен за месяц до публикации уведомления.

Хронология идёт в обратном порядке от публикации, и это самая неинтуитивная часть этой истории. Lasso сообщил об уязвимости приватно через канал GitHub для сообщений об уязвимостях 8 июля 2026 года. MaxKB ответил на следующий день, сузив отчёт до официального образа и запросив proof of concept в контейнере; исследователи предоставили его и обход песочницы 10 июля. Коммит с исправлением 594f50f2 был внесён 9 июля — через день после отчёта — и переписал sandbox_shell.py так, что строка команды модели сначала парсится, а префикс gosu применяется к каждой простой команде, а не только к первой, при этом каждый список аргументов заново заключается в кавычки, чтобы подстановка не могла вырваться в родительскую оболочку. В отчёте Lasso это изменение описывается как применение префикса gosu «к каждой простой команде, а не только к первой».

Релиз, содержащий его, v2.10.5-lts, был опубликован 6 августа 2026 года. Уведомление GitHub появилось 2 сентября, NVD опубликовала CVE 21 сентября, блок SSVC от CISA был добавлен, и GBHackers сообщил об этом 22 сентября, а собственная публикация Lasso появилась 10 сентября — в середине этой последовательности, а не в начале. Оператор, отслеживающий теги релизов, а не ленты уведомлений, получил патч примерно за четыре недели до предупреждения.

Границе версий стоит уделить больше внимания, чем это делает рекомендация, поскольку два основных источника расходятся, и вопрос решает репозиторий. В поле формы рекомендации затронутые версии указаны как «<= 2.10.3-lts», с примечанием, что это было проверено на 2.10.3-lts и что уязвимый путь «вероятно» затрагивает все версии, в которых агенты собираются таким образом. В собственной публикации Lasso затронутый диапазон указан как «<= 2.10.4-lts». Теги подтверждают более широкий диапазон: v2.10.4-lts, выпущенная 16 июля 2026 года, содержит тот же 75-строчный sandbox_shell.py, что и v2.10.3-lts, а переписанный файл из 311 строк впервые появляется в v2.10.5-lts. Оператор на 2.10.4-lts, прочитавший только диапазон из рекомендации, заключил бы, что его версия вне его. Это было не так.

Что исправление не сделало

Что исправляет 2.10.5-lts — это обёртка: она больше не собирает одну shell-строку под root. Но она ничего не делает с самим инструментом. Непосредственное чтение репозитория на теге v2.10.8-lts, опубликованном 22 октября 2026 года, показывает, что агент по-прежнему создаётся с backend=SandboxShellBackend, а interrupt_on по-прежнему содержит ровно три ключа — write_file, read_file и edit_file — без execute. Первые два предложения по исправлению из рекомендательного бюллетеня — по умолчанию использовать бэкенд без выполнения и добавить "execute": True в карту одобрений — в этом выпуске отсутствуют.

Рекомендация о fail-closed появилась позже, в v2.10.7-lts, и она важна для того режима развёртывания, который находился в худшем положении. Опубликованная 15 октября 2026 года, она меняет строку в sandbox_shell.py с CONFIG.get("SANDBOX", 0) на CONFIG.get("SANDBOX", 1). В установке из исходного кода или на bare-metal, где переменная никогда не задавалась, обёртка теперь по умолчанию включена, а не отключена, что и представляет собой рекомендацию «fail closed on non-container deploys» в узком смысле. В рекомендательном документе под тем же заголовком требовалось большее — чтобы поток, способный выполнять команды, отказывался запускаться, когда среда выполнения песочницы недоступна, — а отдельно требовалось, чтобы обёртка никогда не формировала строку команды для root-оболочки. Что касается контейнеров, это факт, а не рекомендация: ни installer/Dockerfile, ни installer/Dockerfile-base не содержат директивы USER в теге v2.10.8-lts, поэтому образ приложения по-прежнему запускается от root.

Если собрать всё вместе, зафиксированное состояние по состоянию на 28 октября 2026 года таково. Вторая половина уязвимости — песочница, из которой выбралась точка с запятой, — закрыта, и закрыт режим fail-open по умолчанию при развёртывании на хостах. Первая половина — инструмент execute, который поставляется с объектом бэкенда и не является ключом в карте одобрений, — по-прежнему лежит в основе того, как MaxKB создаёт ассистента с поддержкой инструментов. Собственная рекомендация исследователей по устранению была узкой: обновиться до версии 2.10.5-lts или более поздней и запускать Docker-версию с включённой песочницей. GBHackers передал ту же инструкцию и более широкий список для администраторов: отключать бэкенды агентов, способные выполнять команды оболочки, если только выполнение кода не требуется явно; требовать одобрения человеком перед любым действием execute; запускать контейнеры не от имени root; а также рассматривать страницы, собранные краулером, документы RAG и загруженные файлы как недоверенные входные данные.

Другая запись MaxKB из той же сентябрьской партии

Вторая запись MaxKB из этой партии в архиве — это другая ошибка с более серьёзным финалом. CVE-2026-77516, также опубликованная в NVD 21 сентября 2026 года, представляет собой обход разрешений, а не внедрение команд: с версии 2.0.0 по 2.9.2 участник рабочей области с самой низкой ролью, которому через WorkspaceUserResourcePermission было явно отказано в доступе к инструменту, всё ещё мог привязать идентификатор этого инструмента через tool_ids, skill_tool_ids или mcp_tool_ids и выполнить его через путь диспетчеризации агента или рабочего процесса. Путь диспетчеризации не применяет повторно разрешение для отдельного инструмента, которое обеспечивают специализированные маршруты инструментов, а при выполнении инструмента расшифровываются init_params на стороне сервера, поэтому вызывающая сторона получает учётные данные, передаваемые инструментом, в доступе к которому ей было отказано. Его оценка — 5.4, а описание NVD завершается предложением, которое CVE-2026-77521 не обязана содержать: «По состоянию на момент этого обзора исправленная версия недоступна».

Контраст — вот что полезно для любого, кто проводит триаж этой пары. Уязвимость с оценкой 10.0 получила исправление, закоммиченное в течение дня и выпущенное за месяц до того, как она была опубликована. У уязвимости с оценкой 5.4 на момент публикации её CVE не было опубликованной исправленной версии.

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