КИБЕРБЕЗОПАСНОСТЬ

BeyondTrust закрывает критические уязвимости в RS и PRA

Почти 2000 внешне доступных инстансов BeyondTrust требуют проверки после исправления двух критических багов обхода аутентификации в RS и PRA.

✍️ Редакция iTech News | 08.07.2026 | ⏱ 5 мин | Источник: BleepingComputer
🔑

BeyondTrust выпустила исправления для двух критических уязвимостей в Remote Support и Privileged Remote Access, которые при определенной конфигурации позволяют обойти аутентификацию. Для компаний, у которых эти системы висят в интернете и используются для админского доступа, история неприятная: речь идет не о локальном сбое, а о входе в контур через инструменты, которые обычно стоят максимально близко к привилегированным учеткам.

Проблема затрагивает уязвимости BeyondTrust с идентификаторами CVE-2026-40138 и CVE-2026-40139, сообщает BleepingComputer. Первая касается платформ RS и PRA версий 25.3.2 и ниже. По описанию вендора, ошибка находится в подсистеме аутентификации: атакующий без привилегий может обойти контроль доступа и получить доступ к целевому appliance, включая учетные записи с повышенными правами. Вторая, CVE-2026-40139, связана с некорректной обработкой запросов аутентификации в RS и позволяет неаутентифицированному удаленному атакующему получить несанкционированный доступ к уязвимым инстансам.

Есть важная оговорка, но не успокаивающая. BeyondTrust отдельно подчеркнула, что эксплуатация обеих дыр требует включенной специфической конфигурации аутентификации, однако деталей не раскрыла. Для ИБ-команд это означает привычную дилемму: вендор уже признал критичность, но критерии риска по конкретной инсталляции придется выяснять самостоятельно, без публичного чек-листа по условиям эксплуатации. В таких случаях нормальная тактика одна: считать внешний периметр потенциально уязвимым, пока не доказано обратное.

Одновременно компания закрыла еще две серьезные проблемы: CVE-2026-40140 и CVE-2026-40141. Они не относятся к категории critical, но тоже неприятны: речь идет о возможности вызвать отказ в обслуживании или получить доступ к ограниченным ресурсам на незащищенных RS- и PRA-инстансах. Сам BeyondTrust формулирует последствия достаточно прямо: самые опасные уязвимости могут дать удаленному неаутентифицированному атакующему обход контроля доступа и несанкционированный доступ к appliance; дополнительные баги могут привести к сбоям сервиса, непреднамеренному доступу к данным и, при отдельных конфигурациях, к повышению привилегий уже аутентифицированного пользователя.

Для облачных клиентов патч, по данным компании, был установлен еще 21 апреля 2026 года. Self-hosted заказчикам рекомендовано либо поставить апрельский security rollup для затронутой версии, если автоматические обновления не включены, либо перейти на RS 25.3.3 и выше или PRA 25.3.3 и выше. Это, пожалуй, главный практический вывод из всей истории: если обновление на таких системах у вас до сих пор проходит через ручной change request, согласование окна и надежду, что никто не забыл про отключенные автоапдейты, то именно такие кейсы потом и превращаются в инциденты с длинным разбором на уровне совета директоров.

Дополнительный нерв добавляет статистика Shadowserver. Группа отслеживает почти 2000 RS- и PRA-инстансов BeyondTrust, доступных из интернета. Это не значит, что все они уязвимы: часть может быть уже исправлена, часть может оказаться honeypot. Но сама цифра показывает масштаб поверхности атаки. Remote support и privileged access по определению не любят публичность, а когда в этой зоне всплывают баги на обход аутентификации, счет обычно идет не на «сколько серверов надо перезагрузить», а на «сколько сегментов сети и доверенных связей может потянуть за собой одна компрометация».

Контекст у BeyondTrust тоже не самый комфортный. В последние годы продукты компании уже не раз оказывались в новостях из-за эксплуатации уязвимостей в реальных атаках. Самый свежий пример — критическая pre-auth RCE-уязвимость CVE-2026-1731 в Remote Support и Privileged Remote Access. Ее использовали для установления WebSocket-каналов и разворачивания вымогательского ПО на уязвимых системах. Для администраторов и ИБ-архитекторов это важный маркер: речь не о гипотетическом интересе атакующих к классу таких решений, а о вполне прикладной эксплуатации.

Еще более показателен кейс двухлетней давности с Министерством финансов США. Тогда ведомство раскрыло взлом, связанный с китайской группой Silk Typhoon. По имеющимся данным, злоумышленники использовали два zero-day в BeyondTrust — CVE-2024-12356 и CVE-2024-12686, — а затем через украденный API-ключ скомпрометировали 17 SaaS-инстансов Remote Support, включая инстанс Treasury. Среди целей назывались также CFIUS, проверяющий иностранные инвестиции на предмет угроз национальной безопасности, и OFAC, отвечающий за санкционные программы США. После таких эпизодов любой новый advisory по уязвимости в продуктах удаленного доступа читается уже не как рутинный бюллетень, а как потенциальный предвестник следующей волны атак.

Для русскоязычной IT-аудитории здесь нет экзотики. Во многих компаниях RS/PRA-класс решений живет на стыке ИТ-операций, поддержки подрядчиков, администрирования инфраструктуры и удаленного доступа к критичным системам. Поэтому уязвимости BeyondTrust бьют сразу по нескольким ролям. Разработчикам и DevOps такие новости напоминают, что доверенная админская плоскость не менее чувствительна, чем production-контур. Продуктовым и ИТ-руководителям — что «вспомогательный» доступ поставщика или службы поддержки часто оказывается самым коротким маршрутом к важным данным. HR и рекрутерам в ИТ это тоже косвенно знакомо: чем сильнее распределенные команды и аутсорс, тем выше зависимость бизнеса от внешнего удаленного доступа, а значит, и цена ошибки в его настройке.

Практический минимум сейчас очевиден: проверить версии RS и PRA, подтвердить, включены ли автоматические обновления, выяснить, используется ли та самая специфическая конфигурация аутентификации, о которой предупреждает вендор, и пересмотреть внешний доступ к таким инстансам вообще. Главный вопрос здесь шире конкретного патча: сколько еще компаний по-прежнему рассматривают системы удаленного администрирования как удобный сервисный слой, а не как одну из самых чувствительных точек входа в инфраструктуру. Судя по тому, как часто именно этот класс продуктов оказывается в цепочках реальных компрометаций, переоценка приоритетов давно просится не в дорожную карту, а в ближайшее окно обслуживания.

Поделиться: Telegram X LinkedIn