Уязвимость FortiMail с оценкой CVSS 9,8 уже используют в атаках: ошибка позволяет неавторизованному атакующему записывать произвольные файлы на систему через HTTP или HTTPS-запросы. Для компаний, где FortiMail стоит на периметре почтовой инфраструктуры, это не «поставим в план на квартал», а задача на ближайшие часы.
Американское агентство CISA внесло CVE-2026-104286 в каталог Known Exploited Vulnerabilities после сообщений об активной эксплуатации, сообщает The Hacker News. Для федеральных гражданских ведомств США установлен дедлайн: применить патч или временные меры до 4 октября 2026 года. Этот срок полезен и частному сектору: если регулятор режет окно реакции до нескольких дней, значит, эксплуатация уже выглядит достаточно практичной.
По описанию Fortinet, проблема связана сразу с двумя классами ошибок: path traversal и некорректной нейтрализацией NULL-байта или NULL-символа. В нормальном переводе с языка CWE это означает, что специально собранный запрос может обойти ограничения пути и записать файл туда, куда приложение писать не должно. Самая неприятная часть — для атаки не требуется учетная запись. Если интерфейс доступен извне и попадает под уязвимую версию, злоумышленнику не нужно сначала добывать пароль администратора.
Под удар попали несколько веток 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. Fortinet рекомендует для 8.0 перейти на будущую 8.0.2 или выше, для 7.6 — на будущую 7.6.7 или выше, для 7.4 — на будущую 7.4.9 или выше. Для ветки 7.2 компания указывает переход на 7.4 или более новую ветку. Формулировка с «будущими» версиями неприятная, но честная: для части установок полноценный фикс еще не готов, поэтому временные меры становятся не опцией, а рабочим минимумом.
В качестве обходного пути Fortinet советует отключить поддержку IBE через CLI и убрать интерфейс управления FortiMail из интернета. Если полностью закрыть доступ нельзя, его нужно ограничить доверенными частными сетями. Для админов это звучит скучно, зато ровно такие скучные настройки обычно отделяют инцидент от спокойного понедельника. Отдельно стоит проверить, не торчит ли management-интерфейс через забытый NAT, старый VPN-профиль или «временное» правило фаервола, которое пережило уже трех руководителей инфраструктуры.
Fortinet также опубликовала индикаторы компрометации. Среди подозрительных IP-адресов указаны 79.141.169[.]187 и 45.129.0[.]192. В файловых артефактах фигурируют добавленные /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice и /data/etc/ld.so.preload, а также измененные /bin/smit, /data/etc/httpd.conf и /data/migadmin.tar.gz. Наличие таких файлов или изменений не доказывает полный масштаб атаки само по себе, но это достаточный повод поднимать журналы, проверять целостность системы и готовить план восстановления, а не только «поменять пароль на всякий случай».
Для русскоязычных компаний риск особенно практический: FortiMail часто ставят как корпоративный шлюз для почты, антиспама и защиты от фишинга, то есть ближе к границе сети, чем хотелось бы при ошибке с записью файлов без авторизации. Если такой узел скомпрометирован, атакующий может получить удобную точку закрепления, вмешаться в работу сервисов или подготовить дальнейшее движение по инфраструктуре. Почтовая безопасность здесь превращается в классическую проблему периметра: защищающий сервис сам становится входной дверью.
Случай с уязвимостью FortiMail ложится в более широкий тренд последних недель: в активной эксплуатации также упоминались ошибки в продуктах Check Point, Arista VeloCloud Orchestrator, F5 BIG-IP Access Policy Manager, Cisco Catalyst SD-WAN Manager и Citrix NetScaler ADC/Gateway. Общий знаменатель виден без микроскопа: атакующие охотятся за управляемыми снаружи корпоративными системами, где один удачный баг дает доступ не к одной машине разработчика, а к важному узлу инфраструктуры.
Командам безопасности стоит начать с инвентаризации версий FortiMail, проверки доступности management-интерфейса из интернета и поиска опубликованных индикаторов. Разработчикам и DevOps-командам, которые обычно «не трогают почту», тоже лучше не проходить мимо: почтовый шлюз часто связан с LDAP, SSO, журналированием, SIEM и внутренними процессами доставки уведомлений. Компрометация такого узла может быстро стать проблемой не только SOC, но и всех сервисов, где почта используется для сброса паролей, алертов и бизнес-процессов.
Главный вывод из этой истории простой и неприятный: устройства безопасности больше нельзя считать нейтральной инфраструктурной мебелью. Уязвимость FortiMail показывает, что патч-менеджмент для почтовых шлюзов, VPN, балансировщиков и SD-WAN-контроллеров должен жить в том же срочном контуре, что и критичные серверы приложений. Следующий вопрос для бизнеса уже не «есть ли у нас FortiMail», а «сколько времени пройдет между появлением KEV-записи и реальным изменением конфигурации в проде».