Сразу три критические уязвимости FortiSandbox с оценкой CVSS 9.1 оказались не просто теорией для бюллетеней, а рабочим инструментом атакующих. Для российских ИБ-команд, администраторов и IT-руководителей здесь плохая новость простая: если у вас не обновлены песочницы Fortinet, окно для компрометации уже открыто.
О проблеме 16 июня сообщил The Register со ссылкой на threat intelligence-компанию Defused. Речь идет о трех дырах в FortiSandbox, которые в сумме дают довольно неприятный набор: обход аутентификации, повышение привилегий и выполнение произвольного кода или команд через специально сформированные HTTP-запросы. Две из них Fortinet закрыла еще в апреле, третью — только на прошлой неделе. На момент публикации патчей вендор утверждал, что сведений об активной эксплуатации нет. Теперь такие сведения есть.
Первая уязвимость, CVE-2026-39813, описывается как path traversal в JRPC API FortiSandbox. Она позволяет обойти аутентификацию через специально подготовленные HTTP-запросы. Под удар попадают версии FortiSandbox 4.4.0–4.4.8 и 5.0.0–5.0.5. Исправление — переход на 4.4.9 и выше либо 5.0.6 и выше, в зависимости от ветки. Эту проблему обнаружил аналитик Fortinet Лоик Пантано.
Вторая, CVE-2026-39808, еще прямолинейнее: это внедрение команд ОС в FortiSandbox, которое позволяет неаутентифицированному атакующему запускать несанкционированный код или команды через HTTP-запросы. Уязвимы версии 4.4.0–4.4.8, закрывается она обновлением до 4.4.9 или новее. За находку Fortinet благодарит исследователя KPMG Spain Самуэля де Лукаса Марото. Третья, CVE-2026-25089, снова относится к командной инъекции, но уже затрагивает не только FortiSandbox, но и FortiSandbox Cloud и FortiSandbox PaaS WEB UI. Здесь список уязвимых версий шире: FortiSandbox 4.4.0–4.4.8 и 5.0.0–5.0.5, FortiSandbox Cloud 5.0.4–5.0.5, FortiSandbox PaaS 5.0.4–5.0.5.
С технической точки зрения картина особенно неприятна не из-за самих CVE, а из-за их профиля. В корпоративной среде песочница — это не декоративная коробка с отчетами для аудита, а система, которая получает потенциально вредоносные объекты, анализирует вложения, файлы и поведение кода. Если атакующий получает доступ к такому узлу без аутентификации и может исполнять команды, он оказывается не где-то на периферии, а внутри чувствительного сегмента инфраструктуры безопасности. Это уже не история про «сломали еще один веб-интерфейс», а история про компрометацию инструмента, которому доверяют проверку угроз.
По данным Defused, эксплуатация началась в выходные перед публикацией. В посте на LinkedIn компания написала, что наблюдает атаки на несколько уязвимостей Fortinet FortiSandbox в течение последних 24 часов. При этом исследователи отдельно отметили важную деталь: рабочий публичный эксплойт для CVE-2026-25089, по их данным, еще не был раскрыт. Иначе говоря, злоумышленники, вероятно, действуют либо на основе приватной разработки, либо на основе быстро собранного собственного инструмента. Defused добавила, что эксплойт для этой дыры, похоже, был «наколеночно» сгенерирован и может работать нестабильно. Но для защитников это слабое утешение: нестабильный эксплойт, который уже летит в прод, все равно остается эксплойтом.
Отдельный сюжет — тайминг. Fortinet закрыла CVE-2026-39813 и CVE-2026-39808 еще в апреле, а CVE-2026-25089 — только на прошлой неделе. На момент выхода исправлений сообщений о реальных атаках, по словам вендора, не было. Такая последовательность снова напоминает банальную, но почему-то регулярно игнорируемую вещь: между выходом патча и массовым обновлением инфраструктуры обычно лежит неприятный промежуток, который атакующие используют лучше, чем многие внутренние регламенты change management. Особенно когда речь идет о периметровых и защитных продуктах, которые администраторы часто обновляют осторожно, с длинным циклом согласований и тестирования.
Контекст для Fortinet тоже не самый комфортный. The Register в том же материале напоминает, что в начале июня вице-президент по исследованию Check Point Лотем Финкельштейн предупреждал об эксплуатации критической уязвимости обхода аутентификации в Fortinet Remote Access VPN и Mobile Access. По его оценке, та же группа, связанная с ransomware-активностью, вероятно, использовала и другие VPN-уязвимости в продуктах Fortinet. Ранее также сообщалось об атаках на баг в FortiClient EMS и о кампании против более чем 600 FortiGate firewall. Иными словами, для злоумышленников экосистема Fortinet сейчас выглядит не как случайная цель, а как вполне системный вектор работы.
Для бизнеса и IT-эксплуатации выводы здесь очень приземленные. Если в инфраструктуре есть FortiSandbox, FortiSandbox Cloud или FortiSandbox PaaS из уязвимых веток, вопрос уже не в том, надо ли обновляться, а в том, успели ли вы это сделать до начала атак. Второй вопрос — есть ли у команды нормальная видимость по этим системам: логи HTTP-запросов к WEB UI и API, следы запуска нештатных команд, признаки обхода аутентификации, изменения учетных записей и любые подозрительные административные действия. Третий — не живет ли песочница в излишне доверенной зоне, откуда ее компрометация даст боковое перемещение в другие сегменты. Многие организации по-прежнему относятся к security-апплаенсам как к чему-то априори безопасному, а потом удивляются, что именно через них в сеть и входят.
Для разработчиков и продуктовых команд эта история тоже полезна, пусть и чужой кровью. Она снова показывает, насколько опасен старый набор из path traversal, незащищенных HTTP-эндпойнтов и OS command injection в системах, которые управляют безопасностью. Когда подобные ошибки появляются в защитных продуктах, стоимость дефекта автоматически растет: атакующий ломает не просто сервис, а доверенную часть обороны. Уязвимости FortiSandbox в этом смысле выглядят не как экзотика, а как очень дорогая версия классических багов, которые индустрия обещает перестать делать уже много лет.
Сейчас главный вопрос не в том, будут ли атаки расширяться, а в том, насколько быстро компании умеют обновлять собственные средства защиты, когда те сами становятся точкой входа. У Fortinet это уже не единичный информационный повод, а серия. Для рынка это неприятный сигнал: security-продукты все чаще приходится защищать с той же срочностью, что и публичные приложения на периметре, только цена задержки здесь обычно выше.