Критическая уязвимость Fortinet FortiMail перешла в категорию, где промедление создает дополнительную проблему. Согласно данным Агентства кибербезопасности Сингапура, CVE-2026-104286 уже активно эксплуатируется. Она позволяет неаутентифицированному атакующему записывать произвольные файлы в базовую систему FortiMail с помощью специально сформированных HTTP- или HTTPS-запросов. По шкале CVSS v3.1 проблема получила оценку 9,8 из 10.

Редакционная иллюстрация корпоративного шлюза электронной почты в процессе реагирования на активно эксплуатируемую уязвимость: критическое оповещение, индикаторы установки исправления и сетевые следы для расследования.

Это важно потому, что FortiMail — не обычный сервер приложений. Он находится на границе доверия электронной почты, обрабатывает чувствительный почтовый трафик, а его интерфейсы управления или сервисы нередко доступны из интернета. Успешная запись файла может быть лишь одним этапом более крупного проникновения, поэтому установка исправления сама по себе не доказывает, что устройство не подвергалось воздействию.

Практические действия должны идти по двум направлениям: немедленно сократить экспозицию и одновременно выяснить, есть ли на устройстве признаки эксплуатации. Первое направление относится к продукту и конфигурации. Второе — к реагированию на инцидент, даже если первоначальные свидетельства окажутся неполными.

Что затрагивает CVE-2026-104286

Уязвимость описывается как некорректное ограничение имени пути разрешенным каталогом; обычно это называют обходом пути, или path traversal. Проще говоря, запрос может заставить систему обратиться к файлу за пределами расположения, которое приложение должно было разрешать. В данном случае заявленное последствие — запись произвольных файлов в базовую систему FortiMail.

Особенно важны следующие обстоятельства:

  • Согласно опубликованному правительственному предупреждению, атакующему не нужна аутентификация.
  • Атака может передаваться через HTTP- или HTTPS-запросы.
  • Речь идет о создании или изменении файлов в базовой системе устройства, а не просто о безвредной ошибке веб-интерфейса.
  • Сообщается об активной эксплуатации.

Диапазоны, указанные Агентством кибербезопасности Сингапура, включают FortiMail 7.2.0–7.4.8, 7.6.0–7.6.6 и 8.0.0–8.0.1. Это отправная точка для первичной проверки, а не замена актуальному бюллетеню Fortinet. По мере расследования Fortinet может добавить другие ветки, исправленные сборки или отдельные инструкции для конкретных веток.

Администраторам нужно проверить точную работающую сборку, а не только основной номер выпуска в закупочной документации. Кластер, виртуальный шлюз, резервный узел или образ аварийного восстановления могут использовать другую версию, чем основная система. В инвентаризацию следует включить устройства под управлением центральной консоли, унаследованные среды и системы, которые считаются внутренними, но способны получать трафик через обратный прокси, балансировщик, VPN или другое средство защиты.

Почему для почтового шлюза требуется реагирование на инцидент

Почтовый шлюз интересен атакующему не только сам по себе. У него могут быть сетевые маршруты к почтовым серверам, службам каталогов, административным сетям, хранилищам карантина, инфраструктуре журналирования, сервисам обновлений и системам идентификации. Кроме того, он видит большой объем переписки и может хранить метаданные сообщений или их содержимое.

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

Нужно ответить на несколько разных вопросов:

  1. Был ли экземпляр FortiMail доступен атакующему в уязвимый период?
  2. Доходили ли до него запросы, соответствующие признакам эксплуатации?
  3. Создавались или изменялись ли неожиданные файлы?
  4. Устанавливал ли шлюз необычные исходящие соединения или выполнял подозрительные попытки аутентификации?
  5. Доверяла ли другая система данным, полученным от устройства, принимала их или запускала что-либо, созданное шлюзом?

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

Первые операционные решения

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

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

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

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

Приоритеты установки исправления и снижения риска

Авторитетным источником исправленных версий и временных обходных мер является бюллетень Fortinet PSIRT. Используйте его вместе с актуальной документацией по выпуску FortiMail. Не выбирайте версию только потому, что она выглядит самой новой на портале загрузки: проверьте, что это исправленная сборка именно для вашей ветки и типа развертывания.

Последовательность действий должна быть продуманной:

  • Подтвердите, какие узлы FortiMail и образы затронуты.
  • Получите исправленный выпуск или временную меру, предписанную поставщиком.
  • Ограничьте ненужный доступ устройства из интернета на время подготовки изменений.
  • Создайте резервную копию конфигурации согласно политике восстановления организации и защитите ее как чувствительные данные.
  • Установите обновление или обходную меру на нужный узел.
  • Проверьте почтовый поток, применение политик, работу карантина, аутентификацию, журналирование и доступ к управлению.
  • Повторите процедуру для резервных, кластерных компонентов и компонентов аварийного восстановления.
  • Запишите итоговую сборку и доказательства, использованные для подтверждения исправления.

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

Что проверять до и после обновления

Точные индикаторы и расположение журналов должны быть взяты из рекомендаций Fortinet и документации устройства. Не стоит самостоятельно придумывать правило обнаружения на основе общего сигнатурного признака обхода пути. Атакующие могут менять кодирование, пути запросов, заголовки, время и инфраструктуру доставки, а узкий шаблон способен создать ложную уверенность.

Минимальный набор для сбора и анализа включает:

  • веб-журналы, административные, системные и событийные журналы за период экспозиции;
  • записи обратного прокси, межсетевого экрана, балансировщика и системы предотвращения вторжений перед устройством;
  • данные DNS, прокси и исходящего трафика о неожиданных направлениях;
  • записи аутентификации административных и сервисных учетных записей, а также интеграций, подключенных к FortiMail;
  • доступные на устройстве сведения о целостности файлов и состоянии системы;
  • изменения конфигурации, новые учетные записи, измененные сертификаты, политики и неожиданную активность по расписанию;
  • записи синхронизации кластера и центральной консоли управления.

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

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

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

Учетные данные и соседние системы

Ротация учетных данных должна опираться на результаты расследования, однако команда должна быть готова быстро действовать, если устройство хранило, обрабатывало или могло использовать аутентификационные материалы. В первую очередь проверьте привилегированные учетные записи FortiMail, локальные пароли администраторов, API-токены, учетные данные служб каталогов, секреты SMTP-реле, учетные данные мониторинга и резервного копирования, а также сертификаты и ключи, которые могли применяться в других системах.

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

Проверьте соседние системы на аномалии аутентификации и трафика за тот же период. Устройство могло быть исходной целью, промежуточной площадкой или лишь одним элементом более широкой кампании. Изучите события провайдера идентификации, журналы каталогов, аутентификацию на почтовых серверах, административный VPN-доступ и изменения транспортных правил. Особенно внимательно сопоставляйте активность, начавшуюся вскоре после подозрительного события на FortiMail.

Что сообщить внутри организации

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

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

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

Практическое дерево решений

Следующая последовательность помогает не тратить время на спор о ярлыках.

Если экземпляр не затронут: зафиксируйте сведения о версии, подтвердите проверку всех связанных узлов и закройте запись об уязвимости, указав источник и дату проверки.

Если он затронут, но никогда не был доступен из недоверенной сети: установите исправленный выпуск, проверьте внутренние пути доступа и журналы, а также сохраните объяснение ограниченного масштаба экспозиции. Формулировка не доступен из интернета не означает не доступен вообще; проверьте сегментацию и административные маршруты.

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

Если найдены подозрительные запросы или изменения системы: рассматривайте устройство как потенциальный инцидент. Сохраните доказательства, ограничьте доступ, подключите группу реагирования и проверьте учетные данные и связанные системы до закрытия дела.

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

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

Чего делать не следует

Не открывайте интерфейс управления в интернет только ради удобства экстренного администрирования. Не отправляйте тестовые эксплойт-полезные нагрузки в рабочий FortiMail, если организация явно не разрешила такие действия, не оценила их влияние и не подготовила контролируемый план. Опубликованная проблема достаточно серьезна, чтобы защитная проверка не превращалась в предотвратимый простой.

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

Не удаляйте подозрительные файлы или журналы до их сбора в соответствии с внутренней процедурой работы с доказательствами. Удаление способно сделать устройство визуально чистым и одновременно уничтожить сведения о произошедшем. Если для немедленного сдерживания нужен пересбор образа, сначала задокументируйте состояние и сохраните доступную конфигурацию и телеметрию.

Не воспринимайте оценку CVSS как прогноз конкретного ущерба организации. Оценка 9,8 описывает техническую серьезность по стандартной модели. Бизнес-последствия зависят от доступности, конфигурации, сетевого размещения, доступа к данным, качества мониторинга и дальнейших действий атакующего.

Более широкий урок для почтовой инфраструктуры

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

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

Второй урок состоит в том, что исправление и расследование — разные меры контроля. Обновление программного обеспечения снижает вероятность продолжающейся эксплуатации, но не отвечает на вопрос, использовал ли атакующий уязвимость вчера. Зрелая реакция закрывает оба вопроса: может ли это произойти сейчас и произошло ли это до исправления.

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

Итог

CVE-2026-104286 заслуживает приоритета, поскольку сочетает неаутентифицированный доступ, запись произвольных файлов, критическую оценку серьезности и сообщения об активной эксплуатации. Операторам FortiMail нужно определить затронутые сборки, ограничить ненужную экспозицию, применить актуальное исправление или временную меру Fortinet и проверить каждый связанный узел.

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

Источники и дополнительные материалы: