FortiMail: CVE-2026-104286 активно эксплуатируется, исправленные сборки еще ожидаются
Fortinet сообщила о критической уязвимости CVE-2026-104286 в FortiMail, которая позволяет неаутентифицированному атакующему записывать произвольные файлы в систему через специально сформированные HTTP- или HTTPS-запросы. Производитель подтвердил эксплуатацию в реальных атаках, а CISA внесла уязвимость в каталог KEV 1 октября 2026 года.
Что произошло
CVE-2026-104286 связана с недостаточной проверкой пути к файлу в FortiMail. В записи NVD, сформированной на основе данных Fortinet как координатора CVE, уязвимость описана как возможность для удаленного неаутентифицированного атакующего записывать произвольные файлы в базовую операционную систему через специально сформированные HTTP- или HTTPS-запросы. Оценка CVSS 3.1 от Fortinet — 9.8 из 10.
Fortinet указывает, что уязвимость уже эксплуатируется. CISA добавила CVE-2026-104286 в Known Exploited Vulnerabilities Catalog 1 октября 2026 года. Для федеральных гражданских ведомств США был установлен срок устранения или применения допустимых мер снижения риска до 4 октября 2026 года; для остальных организаций этот срок не является обязательным, но отражает приоритет угрозы.
По состоянию на 3 октября в бюллетене FG-IR-26-175 исправленные версии 8.0.2, 7.6.7 и 7.4.9 еще обозначались как upcoming. Для ветки 7.2 производитель указывает переход на ветку 7.4 или выше. Это означает, что перед обновлением нужно проверить именно актуальную редакцию бюллетеня Fortinet и убедиться, что целевая сборка действительно опубликована и содержит исправление.
Кого касается
Организаций, использующих FortiMail, особенно если интерфейс управления или связанные веб-компоненты доступны из Интернета. Наибольший приоритет — у пограничных почтовых шлюзов, которые были доступны из недоверенных сетей до применения мер снижения риска.
В актуальных сообщениях, ссылающихся на FG-IR-26-175, перечислены ветки FortiMail 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8 и 7.2.0–7.2.9. При этом в структурированных полях NVD и текстовом описании есть расхождения по отдельным границам версий. Поэтому эксплуатационное решение следует принимать по живому бюллетеню Fortinet, а не по агрегированной таблице NVD.
Почему это важно
FortiMail обычно расположен на границе инфраструктуры и обрабатывает внешний почтовый трафик. Произвольная запись файлов на таком узле может использоваться как этап закрепления и последующего выполнения кода. Наличие уязвимости в KEV и подтвержденная эксплуатация означают, что это уже не сценарий “обновить при ближайшем окне”, а задача активного реагирования.
Даже после появления исправленной сборки обновление само по себе не доказывает, что система не была скомпрометирована раньше. Если уязвимый интерфейс был доступен атакующему, нужно отделять две задачи: закрытие уязвимости и проверку факта возможного проникновения.
Что важно проверить
- Инвентаризировать все экземпляры FortiMail и зафиксировать точную ветку и номер сборки.
- Проверить, доступен ли интерфейс управления FortiMail из Интернета или других недоверенных сегментов.
- Сверить установленную сборку с актуальной таблицей affected/solution в FG-IR-26-175 непосредственно перед изменениями.
- Проверить опубликованные Fortinet признаки компрометации: измененные или добавленные файлы, журнальные события и иные IoC из бюллетеня.
- Сохранить диагностические данные и журналы до радикальных действий, если есть признаки эксплуатации.
Что делать
До установки подтвержденной исправленной сборки применить меры производителя: отключить поддержку Identity Based Encryption, если она не требуется, либо убрать доступ к интерфейсу управления из Интернета и разрешить его только из доверенной частной сети. Конкретную команду и применимость меры нужно перепроверить в текущей версии FG-IR-26-175.
После появления исправления — перейти на рекомендованную производителем сборку. Для ветки 7.2 нельзя считать безопасным переход на произвольный выпуск 7.4: необходимо убедиться, что выбранная версия уже не входит в уязвимый диапазон.
Если FortiMail был доступен из Интернета в уязвимом состоянии, провести отдельную проверку компрометации. При подтверждении признаков атаки рассматривать обновление как часть восстановления, а не как завершение расследования.