ManageEngine закрыла обход проверки подлинности в Log360 и EventLog Analyzer

ManageEngine выпустила исправление для Log360 и EventLog Analyzer. Ошибка CVE-2026-13594 в контроле доступа позволяет по сети получить доступ к продукту без учётных данных. Оценка критическая, CVSS 9.1, а затронуты сборки ниже 13062.

Что известно об уязвимости

ManageEngine, подразделение Zoho, выпускает два связанных продукта для работы с журналами. Log360 - это SIEM-платформа: она собирает события из сети, коррелирует их и поднимает оповещения. EventLog Analyzer решает ту же задачу в более узком виде, разбирая журналы Windows, Linux, сетевого оборудования и приложений.

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

CVE-2026-13594 относится к классу CWE-284, неправильный контроль доступа. Простыми словами, приложение неверно решает, кому разрешено действие. Здесь сбой произошёл на этапе проверки подлинности: запрос доходил до функций продукта, хотя оснований пускать его не было.

Условия атаки

Вектор CVSS описывает атаку по сети. Сложность низкая, привилегии не требуются, участие пользователя тоже не нужно. Значит, для эксплуатации достаточно сетевого доступа к веб-интерфейсу продукта. Ни учётной записи, ни действий администратора со стороны жертвы не требуется.

Практический вывод простой. Если интерфейс Log360 или EventLog Analyzer виден из сегментов сети, где работают не только администраторы, условие для атаки уже выполнено. Такие системы часто ставят за балансировщиком и открывают шире, чем нужно, чтобы обеспечить доступ инженерам и подрядчикам.

Отдельно стоит подчеркнуть, что это не локальная ошибка. Атакующему не нужен доступ к серверу или возможность запускать свои программы. Достаточно HTTP-запросов к уязвимому компоненту.

Что даёт эксплуатация

Оценка 9.1 по CVSS 3.1 - критическая. Вектор указывает высокое влияние на конфиденциальность и целостность, влияние на доступность отсутствует. Проще говоря, атакующий получает доступ к данным и может их менять, а сервис продолжает работать как обычно.

Что именно лежит внутри SIEM. Во-первых, сами журналы: имена хостов, адреса, доменные учётные записи, события входов, сведения о сетевой топологии. Во-вторых, конфигурация источников, правил корреляции и оповещений. В-третьих, встроенные учётные записи интеграций, через которые продукт забирает данные с других систем.

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

Есть и четвёртый, менее очевидный момент. SIEM - это система, которой доверяют. Если в неё внесены изменения, разбор инцидента усложняется: часть следов просто не попадёт в журналы или попадёт в искажённом виде. Поэтому компрометация такого узла требует отдельной проверки доверия к его данным.

Затронутые версии

В записи CVE затронутыми указаны Log360 и EventLog Analyzer сборок ниже 13062. Вендор пишет, что исправление доступно в сборке 13062 и более поздних. Формулировки расходятся, поэтому ориентироваться стоит на более осторожное чтение: целевая версия - 13062 или выше.

Речь идёт об установке service pack. Продукты чаще разворачивают в локальной инфраструктуре, значит обновление целиком в руках администратора и само не приедет. Для гибридных схем стоит отдельно уточнить, какие компоненты обслуживает вендор, а какие обновляются вручную.

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

Что исправляет патч

Вендор усилил проверки аутентификации в затронутых компонентах. То есть исправление меняет саму логику проверки, а не добавляет внешний фильтр поверх уязвимого обработчика. Для администратора это означает, что обходных путей через старые точки входа остаться не должно.

Ошибку нашёл исследователь tran nghia в рамках программы Zoho BugBounty. Вендор подтвердил проблему и закрыл её обновлением, а не временной рекомендацией.

Если обновиться нельзя

Сначала сузить периметр. Интерфейс управления стоит открыть только доверенным сетям, а лучше убрать за VPN или обратный прокси с собственной аутентификацией. Это не устраняет ошибку, но убирает условие, при котором её можно использовать по сети.

Затем включить дополнительную аутентификацию для всех, кто работает с продуктом, и пересмотреть список учётных записей. Отдельно проверьте старые сервисные записи, которые заводили для интеграций и забыли.

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

Если есть подозрение, что доступ был, смените пароли учётных записей продукта и секреты интеграций. Затем сверьте данные SIEM с независимыми источниками: журналами контроллера домена, межсетевого экрана, EDR. Так можно найти пропуски, которые могли появиться.