Защитная проверка github.com/mattermost/mattermost-server, github.com/mattermost/mattermost/server/v8 по GHSA-8qq9-cqj8-82w4: версия, обратимый fixture, PASS/FAIL/Unknown, stop-rule и обезличенный пакет доказательств.
Что проверить для github.com/mattermost/mattermost-server, github.com/mattermost/mattermost/server/v8
Безопасный аудит отделяет применимость advisory от наличия инцидента. Оператор shared channels не знает, очищается ли fileinfo.name до синхронизации файла от внешнего peer. Короткий ответ: подтвердите фактический пакет и границу «go/github.com/mattermost/mattermost-server = 11.6.0 → 11.6.1; go/github.com/mattermost/mattermost-server >= 11.5.0, <= 11.5.4 → 11.5.5; go/github.com/mattermost/mattermost-server >= 10.11.0, <= 10.11.15 → 10.11.17; go/github.com/mattermost/mattermost/server/v8 >= 8.0.0-20250731163400-5b955468ea1e, < 8.0.0-20260423180926-c021eeaff8f0 → 8.0.0-20260423180926-c021eeaff8f0», затем запустите только обратимую проверку: на тестовой федерации передать безвредные имена с разделителями и проверить нормализованное имя и место хранения. Не используйте production, чужие данные или вредоносные payload. GitHub Advisory Database указывает severity high и обновление 2026-08-24; это приоритет для инвентаризации, а не доказательство атаки или массового спроса. Запишите digest сборки, resolved dependency и состояние затронутой функции. Если пакет транзитивный, имя образа или процесса не заменяет lock-файл, SBOM либо provenance артефакта.
Как определить применимость версии
Зафиксированная advisory-boundary: go/github.com/mattermost/mattermost-server = 11.6.0 → 11.6.1; go/github.com/mattermost/mattermost-server >= 11.5.0, <= 11.5.4 → 11.5.5; go/github.com/mattermost/mattermost-server >= 10.11.0, <= 10.11.15 → 10.11.17; go/github.com/mattermost/mattermost/server/v8 >= 8.0.0-20250731163400-5b955468ea1e, < 8.0.0-20260423180926-c021eeaff8f0 → 8.0.0-20260423180926-c021eeaff8f0. Сопоставляйте её с реально загруженной библиотекой, а не только с manifest исходников. Разделите исход на `not_present`, `outside_range`, `affected_candidate`, `patched_or_backported` и `unknown`. Для fork зафиксируйте upstream commit и описание backport. Для категории `path` отдельно отметьте, достигается ли соответствующий путь из доверенной зоны. Если branch или package не удаётся однозначно сопоставить, остановитесь на Unknown и не подменяйте факт общим советом «обновить всё».
Обратимый тест без опасного воспроизведения
Рекомендуемый fixture: на тестовой федерации передать безвредные имена с разделителями и проверить нормализованное имя и место хранения. До запуска подготовьте пустой временный контекст, ограничьте время и ресурсы, отключите внешнюю сеть и зарегистрируйте expected result. Сначала запустите benign positive control, который доказывает работоспособность функции. Затем один отрицательный случай, проверяющий только заявленную границу. Не переносите в fixture токены, персональные данные, реальные пути, production-конфигурацию или опубликованные proof-of-concept. После теста удалите временные сущности и подтвердите отсутствие изменения исходного состояния.
Критерии PASS, FAIL и Unknown
Практический артефакт: матрица peer–input name–stored name–path–audit event. PASS означает, что разрешённый control работает, а пограничный случай отклонён до нежелательного состояния. FAIL фиксируется только при работающем control и наблюдаемом нарушении заявленной границы. Unknown обязателен, если версия не доказана, test harness не достиг нужного пути, итог нельзя прочитать обратно или ограничитель сам оборвал проверку. Для `path` дополнительно зарегистрируйте время, память, нормализованный путь, субъект доступа либо контекст вывода — только те наблюдения, которые относятся к механизму.
План обновления и stop-rule
Если сборка попадает в затронутый диапазон, используйте поддерживаемую исправленную ветку из primary source и повторите тот же fixture до и после изменения. Не меняйте одновременно dependency, proxy, права и формат данных: иначе итог потеряет причинность. Stop-rule: немедленно завершите тест при росте ресурсов вне лимита, неожиданном сетевом обращении, записи за пределами временного каталога, попытке затронуть чужой объект или появлении реальных секретов. WAF, отсутствие жалоб и статус active не равны исправлению GHSA-8qq9-cqj8-82w4.
Что приложить к запросу поддержки
Сохраните GHSA-8qq9-cqj8-82w4, package name, resolved version, artifact digest, ветку и commit, feature state, hash синтетического fixture, выводы control и negative case, а также итог PASS/FAIL/Unknown. Приложите ссылки на GitHub Advisory Database и primary upstream source, но не вставляйте большие фрагменты чужого текста. Отдельная боль: оператор shared channels не знает, очищается ли FileInfo.Name до синхронизации файла от внешнего peer. Результат — матрица peer–input name–stored name–path–audit event. Механизм GHSA-8qq9-cqj8-82w4 (Mattermost doesn't sanitize FileInfo.Name received from federated peers during shared channel file sync) не совпадает с соседними intent и требует собственного набора наблюдений. Такой пакет позволяет maintainer повторить решение без доступа к production. Если advisory, локальная сборка и regression test расходятся, перечислите расхождение как Unknown вместо предположения о безопасности.
Контрольная карточка GHSA-8qq9-cqj8-82w4 для path
Карточка именно этого решения связывает вопрос «оператор shared channels не знает, очищается ли FileInfo.Name до синхронизации файла от внешнего peer» с проверкой «на тестовой федерации передать безвредные имена с разделителями и проверить нормализованное имя и место хранения». В первой строке укажите github.com/mattermost/mattermost-server, github.com/mattermost/mattermost/server/v8, затем границу go/github.com/mattermost/mattermost-server = 11.6.0 → 11.6.1; go/github.com/mattermost/mattermost-server >= 11.5.0, <= 11.5.4 → 11.5.5; go/github.com/mattermost/mattermost-server >= 10.11.0, <= 10.11.15 → 10.11.17; go/github.com/mattermost/mattermost/server/v8 >= 8.0.0-20250731163400-5b955468ea1e, < 8.0.0-20260423180926-c021eeaff8f0 → 8.0.0-20260423180926-c021eeaff8f0. Во второй строке зафиксируйте исходный сигнал: Mattermost doesn't sanitize FileInfo.Name received from federated peers during shared channel file sync. Третья строка — ожидаемый практический итог «матрица peer–input name–stored name–path–audit event». Для этого механизма не подходят доказательства соседних страниц: название продукта, общий статус службы, один HTTP 200, отсутствие жалоб или скриншот интерфейса не отвечают на заявленный вопрос. Отдельно зарегистрируйте, какой benign control подтверждает достижимость пути, какое наблюдение считается отказом до побочного эффекта и при каком условии решение становится Unknown. Пакет не должен содержать токены, реальные имена, адреса узлов, содержимое документов, дампы памяти или полный production-log. Финальная подпись включает дату 2026-08-31, GHSA-8qq9-cqj8-82w4, digest сборки и ссылку на upstream. Так другой специалист проверит категорию path по тем же полям, не повторяя опасный сценарий и не получая доступ к данным пользователя.
Минимальный record для повторной проверки mattermost-federated-filename-sanitization-check
Оператор shared channels не знает, очищается ли fileinfo.name до синхронизации файла от внешнего peer. Рабочее действие для этой карточки: на тестовой федерации передать безвредные имена с разделителями и проверить нормализованное имя и место хранения. Ожидаемый артефакт: матрица peer–input name–stored name–path–audit event. Upstream формулировка механизма: Mattermost doesn't sanitize FileInfo.Name received from federated peers during shared channel file sync. Компонентная граница: go/github.com/mattermost/mattermost-server = 11.6.0 → 11.6.1; go/github.com/mattermost/mattermost-server >= 11.5.0, <= 11.5.4 → 11.5.5; go/github.com/mattermost/mattermost-server >= 10.11.0, <= 10.11.15 → 10.11.17; go/github.com/mattermost/mattermost/server/v8 >= 8.0.0-20250731163400-5b955468ea1e, < 8.0.0-20260423180926-c021eeaff8f0 → 8.0.0-20260423180926-c021eeaff8f0. Для filesystem containment сохраните requested name, результат нормализации, canonical target, canonical root и булево `is_relative_to_root`. Не читайте системные файлы и не создавайте ссылки на реальные каталоги. Positive control пишет нейтральный marker внутрь временного root; отрицательный случай должен быть отклонён до открытия файла. Цепочка наблюдения «mattermost → federated → filename → sanitization → check» задаёт названия колонок и порядок read-back. Машиночитаемые ключи record: mattermost-federated-filename-sanitization-check-baseline, mattermost-federated-filename-sanitization-check-inventory, mattermost-federated-filename-sanitization-check-control, mattermost-federated-filename-sanitization-check-boundary, mattermost-federated-filename-sanitization-check-fixture, mattermost-federated-filename-sanitization-check-deadline, mattermost-federated-filename-sanitization-check-readback, mattermost-federated-filename-sanitization-check-sideeffects, mattermost-federated-filename-sanitization-check-verdict, mattermost-federated-filename-sanitization-check-provenance, mattermost-federated-filename-sanitization-check-rollback, mattermost-federated-filename-sanitization-check-timestamp, mattermost-federated-filename-sanitization-check-owner, mattermost-federated-filename-sanitization-check-digest, mattermost-federated-filename-sanitization-check-unknownreason. После обновления повторяется тот же fixture, поэтому изменение github.com/mattermost/mattermost-server, github.com/mattermost/mattermost/server/v8 можно отделить от изменения окружения. Для GHSA-8qq9-cqj8-82w4 verdict остаётся Unknown при пропущенном control, несовпадающей ветке либо недоступном read-back.
Материал подготовлен редакцией VOne с помощью ИИ; версии, источники, безопасный fixture, stop-rule, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.
Источники и проверка
- GitHub Advisory Database GHSA-8qq9-cqj8-82w4 проверено 2026-08-31
- Primary upstream source for github.com/mattermost/mattermost-server, github.com/mattermost/mattermost/server/v8 проверено 2026-08-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.