Вход с ЛЮБЫМ паролем: как пропущенный «await» сломал аутентификацию Rocket.Chat (CVE-2026-28514)

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

Единственное пропущенное ключевое слово await в кодовой базе Rocket.Chat означало, что кто угодно мог войти в любую учётную запись, используя буквально любой пароль. Не слабый пароль. Не угаданный пароль. Любой пароль. Строка «banana» работала ровно так же, как правильный пароль.

Это CVE-2026-28514 — критическая уязвимость обхода аутентификации, обнаруженная GitHub Security Lab с помощью их open-source AI-фреймворка для исследований в области безопасности. Она имеет оценку CVSSv4 9,3 из 10 и затрагивала все версии Rocket.Chat до 8.0.0 в нескольких ветках релизов.

Если просто: если злоумышленник знал имя пользователя — а имена пользователей часто можно угадать или они видны публично — он получал полный контроль над учётной записью.

Как объект Promise заменил реальную безопасность

Первопричина объясняется почти до смешного просто, что делает ситуацию ещё более тревожной.

Сервис учётных записей Rocket.Chat внутри микросервиса DDP streamer вызывает асинхронную функцию для проверки паролей. Асинхронные функции в JavaScript возвращают объекты Promise. Чтобы получить фактический результат — ответ true или false на вопрос «правильный ли это пароль?» — код должен выполнить await для этого Promise.

Ключевое слово await отсутствовало.

Без него код оценивал сам объект Promise вместо того, чтобы дождаться булевого результата. Объект Promise в JavaScript всегда является «истинным» (truthy) — а значит, проверка аутентификации всегда проходила успешно, независимо от того, какой пароль был отправлен.

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

Согласно описанию в NVD, эта уязвимость «может привести к захвату учётной записи любого пользователя, чьё имя пользователя известно или может быть угадано». Это преуменьшение серьёзности. В большинстве развёртываний Rocket.Chat имена пользователей видны в каналах, в профилях и через каталог пользователей платформы.

Что злоумышленник мог сделать на самом деле

GitHub Security Lab подтвердила, что эксплуатация была простой. Они подключились к WebSocket-эндпоинту сервиса DDP streamer, аутентифицировались с произвольным паролем и получили полный доступ. После входа злоумышленник мог:

• Читать сообщения в любом канале, к которому имел доступ скомпрометированный пользователь
• Вступать в каналы и мониторить их, включая приватные
• Выдавать себя за пользователей — отправлять сообщения от их имени, изменять настройки, повышать привилегии
• Получать доступ к учётным записям администраторов, если имя пользователя администратора было известно

Команда GitHub продемонстрировала получение сообщений в реальном времени в канале «General» после аутентификации с поддельным паролем. Атака не требовала специальных инструментов — только WebSocket-соединение и знание действительного имени пользователя.

Как ИИ нашёл то, что пропустили люди

Что делает эту историю особенно актуальной для бизнеса — это способ, которым была обнаружена уязвимость. GitHub Security Lab создала open-source AI-фреймворк, предназначенный для помощи исследователям безопасности в поиске уязвимостей в масштабе. Они направили его на Rocket.Chat, и фреймворк обнаружил обход аутентификации.

Как описано в блог-посте GitHub, AI-агент вернул заметку, гласящую:

VULNERABILITY: обход аутентификации по паролю в account-service позволяет войти как любой пользователь, у которого установлен пароль.

Сами исследователи признались, что поначалу «было трудно в это поверить». Но ручная проверка немедленно подтвердила находку.

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

Это именно тот класс багов, в обнаружении которого AI-ассистированное исследование безопасности особенно эффективно: тонкие логические ошибки, которые прячутся на виду в больших кодовых базах.

Это была не единственная находка

CVE-2026-28514 стала главной уязвимостью, но фреймворк GitHub Security Lab выявил и другие проблемы. В блог-посте отмечается, что это были «ошибки логики авторизации», которые «оставались необнаруженными годами».

Отдельно исследователи также выявили значительные слабости в реализации сквозного шифрования (E2EE) Rocket.Chat. Подробный анализ, опубликованный академическими исследователями, обнаружил:

• Слабая генерация пароля E2EE: алгоритм генерации пароля мобильного приложения применяет toLowerCase() к тому, что должно быть буквенно-цифровым выводом, существенно сокращая пространство ключей
• Офлайн-атаки перебором: механизм резервного копирования закрытого ключа допускает офлайн-атаки, потому что начальное пространство пароля E2EE слишком мало
• Пластичность шифротекста: шифрование AES-CBC без MAC позволяет злоумышленникам подделывать валидные блоки зашифрованных сообщений с произвольным текстом после перехвата одного шифротекста
• Отсутствие ротации ключей при сбросе пароля: скомпрометированные групповые ключи остаются действительными даже после сброса пользователем пароля E2EE

Кроме того, CVE-2026-23477 выявила уязвимость раскрытия информации, при которой эндпоинт /api/v1/oauth-apps.get раскрывал учётные данные OAuth-приложений неавторизованным пользователям; исправлена в версии 6.12.0.

Реальные цифры: оценка EPSS (Exploit Prediction Scoring System) для CVE-2026-28514 составляет 0,00110, а уязвимость имеет VMScore 1000 на Vulmon — что означает максимальную серьёзность в их модели оценки.

Какие версии затронуты и что делать

Уязвимость затрагивает все версии Rocket.Chat до следующих исправленных релизов:

Вот что мы рекомендуем:

1. Обновитесь немедленно. Это не уязвимость из категории «запланируем на следующий спринт». Любой пароль подходит. Если сервис DDP streamer доступен по сети, инстанс скомпрометирован до установки патча.
2. Проверьте журналы доступа. Ищите необычные паттерны входа — доступ к нескольким учётным записям с одного IP, входы из неожиданных локаций или доступ к каналам, нетипичным для пользователя.
3. Проверьте экспозицию DDP streamer. Определите, доступен ли WebSocket-эндпоинт DDP streamer из интернета или ограничен внутренними сетями. Даже после установки патча минимизация поверхности атаки — разумная практика.
4. Выполните ротацию учётных данных. Если используется непропатченная версия, допустите возможность компрометации. Сбросьте пароли, выполните ротацию API-ключей и проверьте учётные данные OAuth-приложений.
5. Оцените зависимость от E2EE. Если организация полагается на сквозное шифрование Rocket.Chat для конфиденциальных коммуникаций, академические выводы о слабостях E2EE требуют отдельной оценки рисков.

Что это значит для вашего проекта

Ключевой вывод для бизнеса: этот инцидент иллюстрирует три вещи, которые важны за пределами самого Rocket.Chat.

Во-первых, тривиальные баги вызывают катастрофические сбои. Единственное пропущенное ключевое слово — пять символов — полностью устранило аутентификацию корпоративной коммуникационной платформы. Безопасность — это не про экзотические векторы атак. Чаще всего это про банальные недосмотры в критических участках кода. Каждый вызов асинхронной функции, который обрабатывает аутентификацию, авторизацию или валидацию данных, — потенциальный CVE, если await пропущен.

Во-вторых, AI-инструменты для безопасности уже здесь. Фреймворк GitHub Security Lab нашёл класс уязвимостей, который традиционные инструменты и ручные ревью пропускали годами. Организациям, использующим открытую инфраструктуру, стоит рассмотреть интеграцию AI-анализа кода в свои рабочие процессы безопасности — не как замену исследователей-людей, а как мультипликатор силы, который ловит то, что люди пропускают.

В-третьих, self-hosted не значит self-secured. Rocket.Chat популярен именно потому, что организации могут запускать его на своей инфраструктуре для соответствия нормативным требованиям и суверенитета данных. Но самостоятельное размещение полностью перекладывает бремя установки патчей на организацию. Если команда безопасности не отслеживает CVE для каждого self-hosted компонента, «безопасная» самостоятельно размещённая платформа может оказаться менее защищённой, чем управляемая SaaS-альтернатива, которая патчится автоматически.

Часто задаваемые вопросы

Как пропущенное ключевое слово await приводит к обходу аутентификации?

В JavaScript асинхронные функции возвращают объекты Promise. Когда ключевое слово await опущено, код оценивает сам объект Promise, а не разрешённое булево значение. Поскольку любой объект в JavaScript является «истинным» (truthy), проверка пароля всегда проходит успешно — независимо от того, какой пароль отправлен. Функция валидации пароля существует и выполняется, но её результат никогда фактически не проверяется.

Могут ли злоумышленники перебирать действительные имена пользователей для атак на учётные записи?

В большинстве развёртываний Rocket.Chat имена пользователей видны через списки участников каналов, каталоги пользователей и страницы профилей. Платформа является инструментом коммуникации — имена пользователей по замыслу должны быть обнаруживаемыми. Это означает, что единственное препятствие для эксплуатации (знание действительного имени пользователя) в типичных конфигурациях фактически не является препятствием вовсе.

Какие конкретно версии затронуты и какие патчи доступны?

Все версии Rocket.Chat до 7.8.6, 7.9.8, 7.10.7, 7.11.4, 7.12.4, 7.13.3 и 8.0.0 уязвимы. Исправление было применено ко всем поддерживаемым веткам релизов одновременно. Организациям следует обновиться до последней доступной версии в рамках своей ветки релиза или перейти на 8.0.0+.

Требует ли сервис DDP streamer аутентификации для подключения?

Сервис DDP streamer принимает WebSocket-соединения, и обход аутентификации происходит в процессе входа в рамках этого сервиса. Неаутентифицированный пользователь может подключиться к WebSocket-эндпоинту и затем эксплуатировать уязвимость для аутентификации под любым пользователем, у которого установлен пароль. Для доступа к уязвимому пути кода не требуется предварительная аутентификация.

Как организации могут определить, были ли они скомпрометированы?

Проверьте журналы аутентификации на предмет аномалий: входы с необычных IP-адресов, доступ к учётным записям, которые обычно неактивны, или паттерны, показывающие последовательный доступ к нескольким учётным записям с одного источника. Поскольку эксплойт оставляет нормально выглядящие события входа (аутентификация «проходит успешно»), обнаружение требует поведенческого анализа, а не поиска неудачных попыток входа.