Защитная проверка lmdeploy по GHSA-9xq9-36w5-q796: версия, обратимый fixture, PASS/FAIL/Unknown, stop-rule и обезличенный пакет доказательств.
Что проверить для lmdeploy
Эта валидация нужна не для поиска эксплуатации, а для доказательства состояния конкретной сборки. Владелец inference-сервиса не видит, разрешает ли загрузчик выполнение кода из удалённой модели без отдельного согласия. Короткий ответ: подтвердите фактический набор и границу «pip/lmdeploy <= 0.12.3 → 0.13.0», затем выполните только обратимую проверку: на отключённом от production стенде использовать локальный mock-репозиторий без исполняемого кода и исследовать, что загрузка требует явного opt-in. Не используйте production, чужие данные или вредоносные payload. GitHub Advisory Database указывает severity high и обновление 2026-08-31; это приоритет для инвентаризации, а не доказательство атаки или массового спроса. Запишите digest сборки, resolved dependency и статус затронутой функции. Если набор транзитивный, имя образа или процесса не заменяет lock-файл, SBOM либо provenance артефакта.
Как определить применимость версии
Зафиксированная advisory-ограничение: pip/lmdeploy <= 0.12.3 → 0.13.0. Сопоставляйте её с реально загруженной библиотекой, а не только с manifest исходников. Разделите исход на `not_present`, `outside_range`, `affected_candidate`, `patched_or_backported` и `unknown`. Для fork оставьте upstream commit и описание backport. Для категории `supply` отдельно отметьте, достигается ли соответствующий путь из доверенной зоны. Если branch или package не удаётся однозначно сопоставить, остановитесь на Unknown и не подменяйте факт общим советом «обновить всё».
Обратимый тест без опасного воспроизведения
Рекомендуемый fixture: на отключённом от production стенде использовать локальный mock-репозиторий без исполняемого кода и исследовать, что загрузка требует явного opt-in. До запуска подготовьте пустой временный контекст, ограничьте время и ресурсы, отключите внешнюю сеть и отметьте expected result. Сначала выполните benign positive control, который доказывает работоспособность функции. Затем один отрицательный случай, проверяющий только заявленную границу. Не переносите в fixture токены, персональные данные, реальные пути, production-конфигурацию или опубликованные proof-of-concept. После теста удалите временные сущности и подтвердите отсутствие изменения исходного состояния.
Критерии PASS, FAIL и Unknown
Практический артефакт: карта документ модели–флаг доверия–ожидаемый отказ–фактический наблюдение. PASS означает, что разрешённый control работает, а пограничный случай отклонён до нежелательного состояния. FAIL фиксируется только при работающем control и наблюдаемом нарушении заявленной границы. Unknown обязателен, если release не доказана, test harness не достиг нужного пути, наблюдение нельзя прочитать обратно или ограничитель сам оборвал проверку. Для `supply` дополнительно отметьте время, память, нормализованный путь, субъект доступа либо контекст вывода — только те ключи, которые относятся к механизму.
План обновления и stop-rule
Если сборка попадает в затронутый диапазон, используйте поддерживаемую исправленную ветку из primary source и повторите тот же fixture до и после изменения. Не меняйте одновременно dependency, proxy, права и формат данных: иначе наблюдение потеряет причинность. Stop-rule: немедленно завершите тест при росте ресурсов вне лимита, неожиданном сетевом обращении, записи за пределами временного каталога, попытке затронуть чужой объект или появлении реальных секретов. WAF, отсутствие жалоб и статус active не равны исправлению GHSA-9xq9-36w5-q796.
Что приложить к запросу поддержки
Сохраните GHSA-9xq9-36w5-q796, package name, resolved version, artifact digest, ветку и commit, feature state, hash синтетического fixture, наблюдения control и negative case, а также итог PASS/FAIL/Unknown. Приложите ссылки на GitHub Advisory Database и primary upstream source, но не вставляйте большие фрагменты чужого текста. Отдельная боль: владелец inference-сервиса не видит, разрешает ли загрузчик выполнение кода из удалённой модели без отдельного согласия. Результат — карта документ модели–флаг доверия–ожидаемый отказ–фактический наблюдение. Механизм GHSA-9xq9-36w5-q796 (lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out) не совпадает с соседними intent и требует собственного набора наблюдений. Такой набор позволяет maintainer повторить решение без доступа к production. Если advisory, локальная сборка и regression test расходятся, перечислите расхождение как Unknown вместо предположения о безопасности.
Контрольная карточка GHSA-9xq9-36w5-q796 для supply
Карточка именно этого решения связывает вопрос «владелец inference-сервиса не видит, разрешает ли загрузчик выполнение кода из удалённой модели без отдельного согласия» с проверкой «на отключённом от production стенде использовать локальный mock-репозиторий без исполняемого кода и исследовать, что загрузка требует явного opt-in». В первой строке укажите lmdeploy, затем границу pip/lmdeploy <= 0.12.3 → 0.13.0. Во второй строке оставьте исходный сигнал: lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out. Третья строка — ожидаемый практический наблюдение «карта документ модели–флаг доверия–ожидаемый отказ–фактический наблюдение». Для этого механизма не подходят доказательства соседних страниц: название продукта, общий статус службы, один HTTP 200, отсутствие жалоб или скриншот интерфейса не отвечают на заявленный вопрос. Отдельно отметьте, какой benign control подтверждает достижимость пути, какое наблюдение считается отказом до побочного эффекта и при каком условии решение становится Unknown. Пакет не должен содержать токены, реальные имена, адреса узлов, содержимое документов, дампы памяти или полный production-log. Финальная подпись включает дату 2026-08-31, GHSA-9xq9-36w5-q796, digest сборки и ссылку на upstream. Так другой специалист проверит категорию supply по тем же полям, не повторяя опасный сценарий и не получая доступ к данным пользователя.
Минимальный record для повторной проверки lmdeploy-trust-remote-code-optin-check
Владелец inference-сервиса не видит, разрешает ли загрузчик выполнение кода из удалённой модели без отдельного согласия. Рабочее действие для этой карточки: на отключённом от production стенде использовать локальный mock-репозиторий без исполняемого кода и проверить, что загрузка требует явного opt-in. Ожидаемый артефакт: карта источник модели–флаг доверия–ожидаемый отказ–фактический результат. Upstream формулировка механизма: lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out. Компонентная граница: pip/lmdeploy <= 0.12.3 → 0.13.0. Для model-supply boundary важны provenance репозитория, revision pin, настройка исполнения внешнего кода и явное согласие оператора. Стенд не загружает случайные публичные модели: используется локальный mock с известным manifest. PASS требует отказа по умолчанию и отдельного opt-in, который виден в конфигурации и журнале решения. Цепочка наблюдения «lmdeploy → trust → remote → code → optin → check» задаёт названия колонок и порядок read-back. Машиночитаемые ключи record: lmdeploy-trust-remote-code-optin-check-baseline, lmdeploy-trust-remote-code-optin-check-inventory, lmdeploy-trust-remote-code-optin-check-control, lmdeploy-trust-remote-code-optin-check-boundary, lmdeploy-trust-remote-code-optin-check-fixture, lmdeploy-trust-remote-code-optin-check-deadline, lmdeploy-trust-remote-code-optin-check-readback, lmdeploy-trust-remote-code-optin-check-sideeffects, lmdeploy-trust-remote-code-optin-check-verdict, lmdeploy-trust-remote-code-optin-check-provenance, lmdeploy-trust-remote-code-optin-check-rollback, lmdeploy-trust-remote-code-optin-check-timestamp, lmdeploy-trust-remote-code-optin-check-owner, lmdeploy-trust-remote-code-optin-check-digest, lmdeploy-trust-remote-code-optin-check-unknownreason. После обновления повторяется тот же fixture, поэтому изменение lmdeploy можно отделить от изменения окружения. Для GHSA-9xq9-36w5-q796 verdict остаётся Unknown при пропущенном control, несовпадающей ветке либо недоступном read-back.
Материал подготовлен редакцией VOne с помощью ИИ; версии, источники, безопасный fixture, stop-rule, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.
Источники и проверка
- GitHub Advisory Database GHSA-9xq9-36w5-q796 проверено 2026-08-31
- Primary upstream source for lmdeploy проверено 2026-08-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.