В Банке данных угроз безопасности информации появилась запись BDU:2026-18942 об уязвимости аутентификации в OpenRemote Core. Удалённый нарушитель может выдать свой MQTT-клиент за уже подключённое устройство, если знает его открытый сертификат: платформа проверяет сертификат, но не требует подтверждения владения закрытым ключом. Оценка CVSS 3.1 - 10.0, критический уровень. Уязвимы версии OpenRemote Core до 1.34.0, исправление вышло в 1.34.0. Идентификатора CVE у уязвимости нет.
Что позволяет уязвимость
OpenRemote Core - открытая IoT-платформа. На ней подключают устройства, собирают телеметрию, управляют атрибутами и настраивают правила автоматизации. Платформа работает с MQTT, а для первичной настройки устройств использует автоматическое предоставление доступа по X.509-сертификатам: устройство присылает сертификат, платформа проверяет его и связывает подключение со служебной учётной записью этого устройства.
Проблема в том, что проверяется сам сертификат, а не связь сертификата с текущим подключением. Обработчик в OpenRemote Core принимает от анонимного MQTT-клиента сообщение с сертификатом, проверяет, что сертификат подписан настроенным удостоверяющим центром, действителен и что его общее имя совпадает с идентификатором устройства в топике. После этого платформа аутентифицирует текущее подключение как служебную учётную запись этого устройства. Проверки владения закрытым ключом нет: в сообщении передаётся только открытый сертификат.
Открытый сертификат не является секретом. Он может лежать в прошивке устройства, в конфигурации, в пакете настройки, в журналах или в материалах поддержки. Поэтому злоумышленнику достаточно знать открытый сертификат уже подключённого устройства и отправить его в запросе на предоставление доступа. Закрытый ключ, имя пользователя и пароль MQTT при этом не нужны.
Дальше атакующий получает ровно те права, которые есть у служебной учётной записи целевого устройства. В зависимости от настроек это может быть чтение ассетов, атрибутов и телеметрии, запись атрибутов и изменение состояния устройства, управление исполнительными механизмами, подписка на события устройства и нарушение его работы в пределах доступных ассетов. Если служебная учётная запись настроена широко, набор доступных ассетов будет больше. Выполнение кода в демонстрации не показано, и прав выше прав целевой учётной записи атака сама по себе не даёт.
Служебные учётные записи устройств часто имеют доступ к нескольким ассетам, поэтому через одну такую запись можно дотянуться до соседних устройств и их данных. Для платформ умных зданий и промышленной автоматизации это означает риск не только для одного датчика или исполнительного механизма.
В записи BDU указаны оценки CVSS 2.0 - 9.7, CVSS 3.1 - 10.0 и CVSS 4.0 - 9.2, а также классы CWE-287 (неправильная аутентификация) и CWE-306 (отсутствие аутентификации для критичной функции). Уязвимость выявлена 23 сентября 2026 года, сведения об устранении опубликованы 4 ноября 2026 года, запись в Банке данных угроз опубликована 12 ноября 2026 года. В BDU указаны связанные документы GHSA-7jp3-2229-xgqj и COK-2026-11-07; CVE-идентификатор не присвоен.
Условия эксплуатации
Атака идёт по сети и требует доступа к MQTT-прослушивателю и возможности публиковать сообщения. Нужно знать идентификатор целевого устройства и его открытый сертификат в формате PEM, а само устройство должно быть уже подключено к платформе хотя бы один раз.
Учётная запись OpenRemote, имя пользователя и пароль MQTT, закрытый ключ устройства и участие пользователя не требуются. Если оператор отдельно требует mTLS для любого MQTT-подключения, это добавляет ещё одно условие, но не закрывает проблему: обработчик не сравнивает сертификат из сообщения с сертификатом клиента на транспортном уровне, поэтому сертификат в полезной нагрузке нельзя считать заменой транспортной аутентификации.
Затронутые версии и исправление
Уязвимы версии OpenRemote Core до 1.34.0. В версии 1.34.0 автоматическое предоставление доступа по X.509 изменено: устройства должны подтверждать владение закрытым ключом и подписывать одноразовый запрос при каждом подключении. Обмен устроен в два шага: клиент запрашивает одноразовое задание, подписывает его закрытым ключом и отправляет ответ. Без действительной подписи подключение не аутентифицируется. Запросы, содержащие только сертификат, отклоняются без запасного варианта, поэтому клиентам предоставления доступа нужно реализовать новый обмен.
Если обновление пока невозможно, стоит ограничить круг клиентов, которые могут подключаться к MQTT-прослушивателю, и поставить на входе mTLS, если инфраструктура это позволяет. Анонимную публикацию в топики предоставления доступа лучше закрыть или ограничить известными адресами, а сам MQTT-брокер держать во внутреннем сегменте. Эти меры снижают риск, но не заменяют обновление.
Что проверить
В журналах MQTT стоит искать анонимные подключения, которые публикуют запросы на предоставление доступа для уже подключённых устройств, и подключения, аутентифицированные как служебные учётные записи, но пришедшие с необычных адресов или с нехарактерными идентификаторами клиента. После обновления полезно убедиться, что в запросах есть шаг с подписанным одноразовым запросом, а не только сертификат.
В самой платформе проверьте недавние изменения ассетов, атрибутов и команд исполнительным механизмам: атака даёт именно такие возможности. Если есть подозрение на компрометацию, стоит пересмотреть список подключённых устройств и их служебных учётных записей, а также то, где хранятся открытые сертификаты устройств и не попали ли они в общедоступные материалы.
Порядок действий: инвентаризация установок OpenRemote Core, обновление до 1.34.0, ограничение доступа к MQTT-прослушивателю и включение mTLS, затем проверка журналов подключений и изменений ассетов. Для устройств, чьи сертификаты могли утечь, стоит предусмотреть перевыпуск.
Ссылки
- https://bdu.fstec.ru/vul/2026-18942
- https://github.com/openremote/openremote/security/advisories/GHSA-7jp3-2229-xgqj
- https://github.com/openremote/openremote/releases/tag/1.34.0
