Введение

CVE-2026-20131 — критическая уязвимость в веб-интерфейсе Cisco Secure Firewall Management Center. Удалённому атакующему не нужны ни учётная запись, ни действия администратора: достаточно отправить специально подготовленный Java-объект. Уязвимый FMC десериализует его, и цепочка вызовов может закончиться выполнением произвольного Java-кода с правами root. К моменту публичного раскрытия уязвимость уже использовали в реальных атаках.

Данная статья представлена исключительно в образовательных целях. Red Team сообщество "GISCYBERTEAM" не несёт ответственности за любые последствия ее использования третьими лицами.

Когда говорят об атаке на firewall, обычно представляют обход правил фильтрации, уязвимость VPN или удалённое выполнение кода на самом шлюзе.

CVE-2026-20131 бьёт в другое место.

Cisco Secure Firewall Management Center (FMC) — это центр управления. Через него администраторы создают политики, меняют сетевые объекты, подключают устройства и распространяют конфигурацию на весь парк firewall.

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

Cisco раскрыла уязвимость 4 марта 2026 года и присвоила ей максимальную оценку CVSS 10.0. 18 марта компания добавила предупреждение о попытках эксплуатации. В тот же день Amazon Threat Intelligence сообщила, что группировка Interlock использовала уязвимость ещё с 26 января — за 36 дней до публичного раскрытия. 19 марта CVE попала в каталог активно эксплуатируемых уязвимостей CISA KEV.

Что такое CVE-2026-20131

CVE-2026-20131 — это небезопасная десериализация недоверенных данных (CWE-502) в веб-интерфейсе Cisco FMC.

Для успешной атаки не требуется аутентификация. По описанию Cisco, специально подготовленный сериализованный Java-объект может привести к выполнению произвольного Java-кода и повышению привилегий до root.

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

Где находится уязвимость

Упрощённо архитектуру можно представить так:

       Администратор
             │
             ▼
   Web-интерфейс FMC
             │
             ▼
   Java application layer
             │
             ▼
 Политики, объекты, устройства
             │
             ▼
      Управляемые firewall

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

Что такое Java-десериализация и где всё ломается

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

На первый взгляд это похоже на разбор JSON. Но есть принципиальная разница.

JSON обычно описывает данные: строки, числа, массивы. Java serialization описывает граф объектов конкретных классов. Пока JVM собирает этот граф, она может вызывать специальные методы вроде readObject() и другие callbacks.

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

Важно: сериализованный поток не содержит готовую Java-программу, которую JVM просто запускает. Он заставляет сервер собрать определённый граф объектов, а уже методы доступных на сервере классов могут привести к выполнению нужного атакующему действия.

Как развивается атака

Этап 1. Запрос попадает в веб-интерфейс без аутентификации

Атакующий отправляет специально сформированный Java byte stream на уязвимый обработчик FMC.

Этап 2. Сервер восстанавливает граф объектов

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

В этот момент сервер уже работает не просто с набором байтов. Он создаёт экземпляры классов, восстанавливает связи между ними и вызывает предусмотренные механизмом десериализации методы.

Первые четыре байта стандартного Java serialization stream выглядят так:

AC ED 00 05

Этап 3. Срабатывает gadget chain

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

Упрощённо:

 Недоверенный HTTP body
          │
          ▼
 Java-десериализация
          │
          ▼
 Восстановление object graph
          │
          ▼
     Gadget chain
          │
          ▼
 Выполнение Java-кода

Отсюда ещё одна важная деталь: payload зависит от окружения. Цепочка, работающая на одной версии приложения, может не сработать на другой из-за отличий в библиотеках и их версиях.

Этап 4. Код выполняется с правами root

По данным Cisco, успешная эксплуатация позволяет выполнить произвольный Java-код и повысить привилегии до root.

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

Как уязвимость использовали в реальных атаках

История CVE-2026-20131 стала особенно неприятной после публикации расследования Amazon Threat Intelligence.

Исследователи обнаружили активность группировки Interlock, начавшуюся 26 января 2026 года. В HTTP-запросах к уязвимому ПО находились попытки выполнения Java-кода и две ссылки: одна использовалась для получения данных, необходимых эксплойту, другая — для проверки успешного выполнения через исходящий HTTP PUT-запрос от жертвы.

Amazon имитировала такой callback, фактически притворившись уже взломанным сервером. В ответ операторы Interlock перешли к следующей стадии и отправили команды на загрузку и запуск вредоносного ELF-файла.

Дальше цепочка выглядела как полноценное ransomware-вторжение. В инфраструктуре атакующих исследователи нашли инструменты разведки, Java- и JavaScript-бэкдоры, легитимный ScreenConnect для резервного удалённого доступа и memory-resident web shell, который регистрировался в Java-приложении и выполнял код прямо в памяти.

Почему «FMC не смотрит в интернет» — не решение

Закрытый management interface действительно уменьшает поверхность атаки. Cisco прямо отмечает это в advisory.

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

Правильная модель выглядит так:

Fixed software
      +
Доступ только через management-сегмент
      +
Мониторинг и ретроспективная проверка

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

Что делать владельцу FMC

1. Проверить именно версию FMC

Не ASA и не FTD, а management server: release и build FMC нужно сопоставить с официальным Cisco Software Checker.

2. Установить fixed software

Cisco выпустила обновления и отдельно подчёркивает, что полноценного workaround нет. Если FMC ещё не обновлён, сетевые ограничения стоит рассматривать только как временное снижение риска.

Для Cisco Security Cloud Control исправление уже развёрнуто самой Cisco; пользователям SaaS отдельное действие не требуется.

3. Ограничить доступ к management interface

FMC должен быть доступен только из выделенного management-сегмента — через VPN или bastion и с явным списком разрешённых источников. Публичный доступ к панели управления превращает pre-auth RCE в проблему совсем другого масштаба.

Итог

CVE-2026-20131 — хороший пример того, почему центр управления защитой сам должен считаться критическим активом.

Уязвимый FMC принимал недоверенный Java byte stream и начинал восстанавливать переданный граф объектов. Подходящая gadget chain могла привести к выполнению произвольного Java-кода, а затем — к повышению привилегий до root.

Упрощённо:

Запрос без аутентификации
           ↓
Сериализованный Java-объект
           ↓
Небезопасная десериализация
           ↓
Gadget chain
           ↓
Java-код с правами root
           ↓
Компрометация management plane

Главный практический вывод прост: проверить версию FMC, установить fixed software и изучить журналы за прошлые периоды, если интерфейс был доступен из недоверенной сети.