Cisco подтвердила реальную эксплуатацию уязвимости в шлюзе безопасной электронной почты Cisco Secure Email Gateway. Подразделение по реагированию на инциденты информационной безопасности Cisco PSIRT узнало об атаках в сентябре 2026 года. Брешь в разборе почтовых сообщений позволяет неаутентифицированному удалённому злоумышленнику выполнять произвольные команды с правами суперпользователя (root) на операционной системе устройства. Базовая оценка по шкале CVSS (система оценки серьёзности уязвимостей) - 9.8. Уязвимость получила идентификатор CVE-2026-76461 и относится к классу внедрения SQL-кода.
Уязвимость CVE-2026-76461
Причина в недостаточной проверке данных внутри логики разбора почты. Злоумышленник отправляет особым образом составленное письмо, которое проходит через устройство. Проверок не хватает, поэтому SQL-выражения из письма доходят до базы данных и выполняются. Само по себе внедрение SQL-кода означает подмену или дополнение запроса, который приложение отправляет в базу. Здесь последствия тяжелее обычного чтения чужих записей. Успешная атака даёт команды с правами суперпользователя, то есть полный контроль над операционной системой шлюза.
Значимость определяется положением устройства в сети. Шлюз безопасной электронной почты стоит на границе инфраструктуры и принимает почту из интернета. Значит, злоумышленнику не нужны ни учётная запись, ни доступ во внутреннюю сеть, ни предварительная разведка. Достаточно одного письма. Под удар попадают и физические, и виртуальные устройства, при этом конфигурация роли не играет: уязвимы все сборки Cisco AsyncOS в затронутых версиях. Другие продукты Cisco, а именно Secure Email and Web Manager и Secure Web Appliance, названы не подверженными этой уязвимости. Интересна и история находки: проблему выявили при разборе обращения в службу технической поддержки Cisco TAC, а не в ходе планового аудита. Это значит, что эксплуатация шла до публикации бюллетеня.
Признаки компромисса искать непросто, и Cisco предупреждает об этом прямо. В почтовых журналах следует искать записи, содержащие подозрительные SQL-выражения, в том числе конструкции, которые запускают внешние программы. Если устройство входит в кластер, проверять нужно журналы каждого узла. Дальше начинается сложность: получив права суперпользователя, злоумышленник способен удалить или скрыть следы вторжения. Поэтому Cisco советует сверять сетевые журналы и журналы межсетевого экрана за пределами самого устройства. Тревожные сигналы - неожиданные отправки данных с шлюза на внешние адреса, загрузки с подозрительных адресов, странная активность в сегменте, где стоит устройство. Логи стоит хранить на внешнем сервере и достаточно долго, иначе расследование упрётся в пустоту.
Исправления доступны. Для ветки 15.5 и более ранних выпусков подготовлена сборка 15.5.5-0141, для ветки 16.0 - 16.0.4-3021, для ветки 16.5 - 16.5.0-780. Cisco рекомендует переходить именно на последнюю из них. Обновление ставится по сети через веб-интерфейс управления, раздел системного администрирования, либо из командной строки. После установки устройство перезагружается. Обходных путей, которые закрывали бы уязвимость без обновления, нет, и это стоит учитывать службам, где обновление шлюза требует согласований и окна простоя. Облачные устройства сервиса Cisco Secure Email Cloud уже переведены на исправленную сборку силами самой Cisco.
Если есть подозрение, что устройство уже скомпрометировали, порядок действий зависит от его типа. Для физического шлюза Cisco советует обращаться в центр технической поддержки и заранее включить удалённый доступ, чтобы ускорить разбор. Для виртуального сначала нужно зафиксировать данные для расследования по внутренним правилам обработки инцидентов. Разворачивать новый экземпляр до этого нельзя: вместе с конфигурацией исчезнут журналы. Затем разворачивают новую виртуальную машину с исправленной версией, заново собирают настройки, меняют пароли и криптографические материалы, установленные на устройстве. После этого несколько недель стоит наблюдать за поведением системы. Владельцам облачных устройств, которых Cisco уведомила напрямую, тоже рекомендуют сменить учётные данные и криптоматериалы, а также ограничить доступ к шлюзу.
Общие меры защиты выглядят обычно, но здесь они важны. Устройство не должно быть доступно из интернета; если доступ нужен, его ограничивают доверенными узлами, портами и протоколами. Почтовые и управляющие функции лучше развести по разным сетевым интерфейсам, чтобы случайный пользователь не дотянулся до внутренней сети управления. Шлюз ставят за фильтрующим устройством, например межсетевым экраном, и фильтруют управляющий трафик в обе стороны. HTTP для портала администратора нужно отключить, как и любые ненужные сетевые службы. Аутентификацию администраторов строят на SAML или LDAP (протокол доступа к каталогам), а пароль по умолчанию меняют. Для веб-доступа используют SSL/TLS и сертификат удостоверяющего центра.
Эта уязвимость показывает, насколько чувствительны пограничные устройства обработки почты. Они принимают данные от кого угодно, и любая ошибка в разборе входящего потока оборачивается прямым риском. Оценка 9.8 и подтверждённая эксплуатация переводят проблему в разряд срочных. Проверка журналов за пределами шлюза становится обязательной, потому что на самом устройстве следы могут быть уже стёрты.
Ссылки
