Cisco Secure Firewall Management Center Software Remote Code Execution Vulnerability

Falha de desserialização insegura (CWE-502) na interface web de administração do Cisco Secure Firewall Management Center (FMC) e do Cisco Security Cloud Control (SCC) Firewall Management, que permite a um atacante remoto e não autenticado executar código Java arbitrário como root. O CVSS 10.0 não é exagero: não exige autenticação, nem interação do usuário, e compromete totalmente o appliance que centraliza a gestão de políticas de firewall de toda a organização. Já confirmada em exploração ativa por ransomware (Interlock) antes mesmo da divulgação pública, e consta no catálogo KEV da CISA com prazo de correção de apenas 3 dias.

A causa raiz é desserialização de um byte stream Java fornecido pelo usuário sem validação, na interface de gerenciamento web do FMC. Aplicações Java que desserializam objetos arbitrários sem restringir classes permitidas ficam expostas a 'gadget chains' — sequências de código legítimo já presente no classpath que, quando encadeadas durante a desserialização, executam lógica arbitrária escolhida pelo atacante. O atacante não precisa injetar código novo: ele controla o objeto serializado enviado no corpo da requisição HTTP, e a própria JVM do FMC faz o trabalho de reconstruí-lo e executá-lo.

O vetor é uma requisição HTTP para um path específico da interface de gerenciamento do FMC, com um objeto Java serializado malicioso no corpo. A cadeia observada pela Amazon (via honeypots MadPot) embute duas URLs no payload: uma entrega dados de configuração que sustentam o exploit, outra serve para confirmar exploração bem-sucedida — o FMC comprometido faz um HTTP PUT de um arquivo gerado para o servidor do atacante, funcionando como callback de confirmação. Confirmado o comprometimento, o atacante emite comandos para buscar e executar um binário ELF malicioso a partir de servidor remoto, dando início à segunda fase do ataque (RATs customizados, scripts de reconhecimento, movimento lateral e, por fim, ransomware Interlock).

Não há pré-condição de configuração especial: a nota do fornecedor confirma que a falha afeta o produto 'independentemente da configuração do dispositivo'. A única variável relevante é a exposição da interface de gerenciamento — se ela não tem acesso à internet pública, a superfície de ataque cai, mas qualquer atacante com alcance de rede até a interface (inclusive de dentro da rede interna) continua com um caminho não autenticado para RCE como root.

Há exploração ativa confirmada e documentada: a Amazon identificou o grupo de ransomware Interlock explorando isso como zero-day a partir de 26 de janeiro de 2026, 36 dias antes da divulgação pública em 4 de março de 2026 — ou seja, quem só passou a monitorar após o advisory já estava atrasado mais de um mês. A CISA confirmou uso em campanhas de ransomware e deu prazo de remediação de apenas 3 dias no KEV (adicionado 19/03, vencimento 22/03/2026), reflexo direto da severidade e da exploração em curso.

O fornecedor não oferece workaround: a única remediação é atualizar para a versão corrigida. O advisory não lista números de versão fixa diretamente no texto — a orientação oficial é usar o Cisco Software Checker para identificar o 'first fixed release' específico do seu trem de software de FMC, já que a Cisco publica isso via ferramenta e não em tabela estática no advisory. Para Cisco Security Cloud Control (SCC) Firewall Management, que é SaaS, a correção já foi aplicada pela Cisco automaticamente — nenhuma ação do cliente é necessária nesse componente.

O único controle compensatório real citado pelo próprio fornecedor é reduzir a exposição da interface de gerenciamento do FMC à internet pública, o que diminui a superfície de ataque mas não elimina o risco — qualquer atacante com alcance de rede interna ainda explora a falha sem autenticação. Isso não é mitigação, é redução de exposição; trate como paliativo temporário até o patch, nunca como solução.

Não existe flag, configuração de hardening ou regra de WAF documentada pelo fornecedor que neutralize a falha de desserialização em si — o mecanismo está na camada de aplicação Java, não em algo filtrável de forma confiável na borda. Dado o histórico de exploração como zero-day e uso em ransomware, tratar como patch-now, sem postergar por planejamento de manutenção.

Nos logs da interface web do FMC, procurar requisições HTTP para o path de gerenciamento contendo corpo com objeto Java serializado e, no caso da campanha Interlock, duas URLs embutidas no payload — uma de entrega de configuração e outra usada como callback via HTTP PUT para confirmar exploração. Tráfego de saída do próprio FMC iniciando requisições HTTP/PUT para hosts externos é anômalo por si só, já que o appliance normalmente não deveria originar esse tipo de conexão. A Cisco publicou as regras Snort 66082 e 66083 para essa vulnerabilidade especificamente.

Após exploração bem-sucedida, sinais de segunda fase incluem download e execução de binário ELF a partir de servidor remoto, presença de RATs customizados, e — em ambientes Windows adjacentes comprometidos pela mesma campanha — um script de reconhecimento em PowerShell que grava artefatos em compartilhamento de rede nomeado \\JK-DC2\Temp, organizados por hostname. Ausência desses indicadores não garante que não houve exploração: a campanha documentada operou como zero-day por mais de um mês antes da divulgação, então ambientes sem esses logs específicos ainda devem ser tratados como potencialmente expostos até confirmação do patch.