Новости
Критическая RCE-уязвимость SharePoint: CISA требует срочно обновиться
CISA внесла RCE-уязвимость SharePoint (CVE-2026-45659, CVSS 8.8) в список активно эксплуатируемых и обязала агентства США закрыть её к 4 июля.
Fortinet раскрыла уязвимость в почтовом шлюзе FortiMail, которую уже эксплуатируют в реальных атаках: неавторизованный злоумышленник может записать произвольный файл прямо в файловую систему устройства. CISA внесла брешь в каталог активно эксплуатируемых, а готового патча на момент публикации ещё нет — только временные меры.

Коротко: 1 октября 2026 года Fortinet сообщила об активной эксплуатации уязвимости CVE-2026-104286 (CVSS 9.8) в почтовом шлюзе FortiMail. Это path traversal в связке с некорректной обработкой null-байта: неавторизованный атакующий через специально сформированный HTTP(S)-запрос может записать произвольный файл в файловую систему устройства. В тот же день CISA внесла брешь в каталог известных эксплуатируемых уязвимостей (KEV) с дедлайном для федеральных агентств США — 4 октября. Готовых версий с патчем пока нет, доступны только временные меры защиты.
1 октября 2026 года Fortinet опубликовала бюллетень FG-IR-26-175 с описанием уязвимости CVE-2026-104286 в продукте FortiMail — корпоративном шлюзе для защиты и фильтрации электронной почты. В тот же день Агентство по кибербезопасности и защите инфраструктуры США (CISA) добавило уязвимость в каталог известных эксплуатируемых уязвимостей (Known Exploited Vulnerabilities, KEV), что подтверждает: брешь уже используют в реальных атаках, а не только в теории. Федеральным гражданским агентствам предписали закрыть проблему или прекратить использование уязвимых устройств к 4 октября 2026 года.
Уязвимости присвоена оценка CVSS 9.8 из 10 — критический уровень. Под угрозой версии FortiMail с ветки 7.2.0–7.2.9, 7.4.0–7.4.8, 7.6.0–7.6.6 и 8.0.0–8.0.1.
По классификации это сочетание двух проблем: path traversal (некорректное ограничение пути к каталогу, CWE-22) и некорректная обработка нулевого байта в имени файла. Проще говоря, сервис принимает от клиента путь к файлу, не проверяет его как следует, и атакующий может подставить в запрос последовательности вроде «выйти из рабочей директории» или обрезать проверку null-байтом, чтобы заставить FortiMail записать файл туда, куда он не должен.
Ключевая опасность — для атаки не требуется аутентификация: достаточно отправить специально сформированный HTTP- или HTTPS-запрос на уязвимое устройство. Если файл запишется в исполняемую или загружаемую веб-сервером директорию, это открывает путь к выполнению кода на устройстве и дальнейшему продвижению по сети компании.
Суть бреши — именно в том, куда и как записывается файл: классическая задача безопасной работы с файловой системой, которую разработчики любого сервиса обязаны закрывать валидацией пути. Когда это не сделано на уровне корпоративного почтового шлюза, цена ошибки — компрометация всего сервера, через который проходит переписка компании с вложениями.
На момент публикации исправленных сборок FortiMail нет. Fortinet анонсировала, что фиксы появятся в версиях 8.0.2, 7.6.7 и 7.4.9, но ни один независимый источник пока не подтвердил их доступность для загрузки. Ветка 7.2.x точечного патча не получит вовсе — Fortinet рекомендует обновиться на 7.4 или новее.
До выхода патча Fortinet предлагает два временных workaround: отключить функцию identity-based encryption командой config system encryption ibe / set status disable / end, либо вовсе ограничить доступ к административному веб-интерфейсу FortiMail из интернета, оставив его только во внутренней доверенной сети.
FortiMail — это не хранилище документов вроде облака или корпоративного файлового сервера, а шлюз, через который проходит вся почта компании вместе с вложениями. Компрометация такого узла означает риск не только для переписки, но и для всех файлов, которые пересылаются по e-mail: договоров, счетов, архивов, PDF. Это тот же класс риска, что и в истории с RCE-уязвимостью SharePoint: чем центральнее система для обмена файлами, тем дороже обходится промедление с патчем.
Для админов и команд, которые отвечают за периметр компании, актуальны базовые принципы безопасной работы с файлами и вложениями — проверка расширений, ограничение прав записи, изоляция сервисов приёма почты от остальной инфраструктуры. Общий обзор таких практик — в разделе безопасность файлов, а карта того, какие расширения вложений считаются рискованными, — в карте опасных расширений.
config system encryption ibe / set status disable / end.Главный вывод простой: пока патча нет, единственная рабочая защита — сократить площадь атаки, закрыв админку от внешнего доступа. Это универсальное правило для любого сервиса, который принимает и обрабатывает файлы от посторонних отправителей.