Критическая уязвимость в Hoppscotch позволяет перехватить управление экземплярами без аутентификации

Hoppscotch

В платформе для тестирования API Hoppscotch выявлена уязвимость CVE-2026-50160, затрагивающая самостоятельно развёртываемую (self-hosted) версию бэкенда. Проблема описана в GitHub-консультации GHSA-j542-4rch-8hwf и получила максимальную оценку CVSS 10.0 из-за простоты эксплуатации и потенциального уровня компрометации. Уязвимость присутствует во всех сборках вплоть до версии 2026.4.1, исправление включено в релиз 2026.5.0.

Уязвимость  CVE-2026-50160

Суть проблемы заключается в ошибке массового присваивания (mass assignment) в эндпоинте POST /v1/onboarding/config, который доступен без аутентификации на этапе начальной настройки, пока в системе не создано ни одного пользователя (usersCount === 0). Предполагалось, что этот эндпоинт используется только для конфигурирования параметров подключения - например, SMTP или OAuth. Однако из-за некорректной валидации входящих данных злоумышленник может передать произвольные ключи конфигурации, не предусмотренные в ожидаемой структуре запроса.

Корень проблемы - неправильное применение NestJS ValidationPipe без включения опции allowlist. В результате дополнительные свойства, переданные в теле запроса, не отсекаются и попадают непосредственно в логику приложения. Далее эти свойства обрабатываются с помощью Object.entries(dto), которая перебирает все переданные ключи без каких-либо ограничений. Критично то, что чувствительные ключи конфигурации, такие как JWT_SECRET и SESSION_SECRET, являются допустимыми внутренними значениями перечисления, поэтому переданные атакующим значения принимаются и сохраняются.

Ситуация усугубляется тем, что логика validateEnvValues не отклоняет явно неавторизованные ключи. Неизвестные записи проходят через условие default: break, фактически пропуская валидацию. В сочетании с отсутствием аутентификации на эндпоинте эти слабости образуют цепочку атак, позволяющую полностью скомпрометировать экземпляр Hoppscotch.

В сценарии успешной эксплуатации злоумышленник может перезаписать JWT_SECRET на контролируемое им значение, что даёт возможность подделать действительные токены аутентификации для любого пользователя, включая администраторов. Поскольку проверка токенов опирается на этот секрет, все защиты JwtAuthGuard становятся неэффективными. Атакующий может выдавать себя за пользователей, получать доступ к чувствительным данным, извлекать ключи API и сохранять постоянный доступ даже после сброса учётных данных. Кроме того, перезапись SESSION_SECRET позволяет угнать сессии и аннулировать легальные пользовательские сессии.

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

Эксплуатация не требует сложных действий - достаточно одного сформированного HTTP-запроса. В опубликованном доказательстве концепции показано, что сначала проверяется статус начальной настройки через GET /v1/onboarding/status, затем отправляется POST-запрос с внедрением произвольных значений конфигурации, и после этого злоумышленник может проверить результат, запросив базу данных. Успешная атака приводит к тому, что бэкенд сохраняет подконтрольные атакующему секреты, что позволяет подделывать токены и получать постоянный несанкционированный доступ.

Исследователи безопасности относят данную проблему к классу CWE-915 (неконтролируемое изменение динамически определяемых атрибутов объектов) - распространённому, но опасному типу уязвимостей в современных фреймворках API. В консультации подчёркивается, что включение опции whitelist: true в ValidationPipe полностью предотвратило бы атаку, поскольку лишние поля отбрасывались бы на этапе парсинга. Дополнительными рекомендуемыми мерами защиты указаны строгая проверка разрешённых ключей конфигурации, явное отклонение чувствительных параметров, а также использование аутентификации или одноразовых токенов для эндпоинтов начальной настройки.

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

Ссылки

Комментарии: 0