WatchGuard Firebox iked Out of Bounds Write Vulnerability
Prioritize patching. It under exploitation confirmed by CISA and has a public proof of concept.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Summary
Falha de out-of-bounds write (CWE-787) no processo iked do Fireware OS, que processa negociações IKEv2 de VPN. Um atacante remoto não autenticado pode travar o processo ou executar código arbitrário no appliance WatchGuard Firebox, afetando tanto VPN de usuário móvel via IKEv2 quanto VPN de escritório filial IKEv2 configurada com peer de gateway dinâmico. Já está no catálogo KEV da CISA com exploração confirmada em campo e atividade pós-exploração documentada pelo próprio fornecedor, o que eleva a urgência muito além do que o CVSS já indica.
Technical detail
A vulnerabilidade está no parsing de payloads IKE_AUTH pelo processo iked, responsável por negociar túneis IPsec via IKEv2. O fornecedor e a CISA classificam como CWE-787 (out-of-bounds write): o processo escreve dados de entrada além dos limites de um buffer durante o processamento de um payload da mensagem IKE_AUTH, especificamente relacionado ao payload CERT (cadeia de certificados) enviado pelo peer remoto durante a negociação.
O atacante controla o conteúdo do payload IKE_AUTH — incluindo o tamanho e o número de certificados na cadeia CERT — porque a interação ocorre antes de qualquer autenticação bem-sucedida ser estabelecida com o Firebox. Os indicadores publicados pela WatchGuard mostram que uma cadeia de certificados com mais de 8 certificados, ou um payload CERT anormalmente grande (acima de 2000 bytes), geram condições anômalas no log do iked, sugerindo que o dimensionamento ou validação do tamanho desse campo é a origem da escrita fora dos limites.
A falha exige que o Firebox tenha VPN de usuário móvel com IKEv2 ativa, ou VPN de escritório filial via IKEv2 configurada com peer de gateway dinâmico — ambas expõem o processo iked à negociação com peers não confiáveis pela rede. O advisory nota um detalhe crítico: mesmo que essas configurações tenham sido removidas, o Firebox pode continuar vulnerável se ainda houver uma VPN de escritório filial configurada com peer de gateway estático, porque o mesmo processo iked atende esse cenário.
A exploração bem-sucedida causa travamento (hang) do processo iked, interrompendo negociações e re-keys de túneis VPN — túneis já estabelecidos podem continuar passando tráfego mesmo com o iked pendurado. Falhas de exploração (bem ou mal sucedidas) também podem gerar crash do processo com relatório de falha no dispositivo, embora esse sintoma isolado tenha causas alternativas e seja um indicador fraco.
How it’s exploited
O vetor é de rede, sem necessidade de autenticação prévia (AV:N/PR:N/UI:N no vetor CVSS4.0) e sem exigência de configuração fora do padrão de uso de VPN IKEv2 — basta o Firebox expor a negociação IKEv2 na interface WAN, seja para VPN de usuário móvel, seja para VPN de escritório filial com gateway dinâmico (ou estático, pelo motivo explicado acima). O atacante inicia uma negociação IKE_AUTH manipulada contra o serviço exposto, sem precisar de credenciais de VPN, certificado válido ou qualquer segredo compartilhado.
A WatchGuard confirma exploração ativa em campo e documentou duas variantes de atividade pós-exploração observadas: em uma, o atacante extrai e criptografa o arquivo de configuração ativo do Firebox e o exfiltra para o mesmo IP de origem do ataque; na outra, cria um arquivo gzip contendo tanto a configuração ativa quanto o banco de dados local de usuários administrativos, e exfiltra esse pacote. Isso indica que o objetivo primário observado até agora é coleta de credenciais e configuração — não necessariamente ransomware ou destruição (KEV marca 'Known To Be Used in Ransomware Campaigns: Unknown').
A CISA definiu prazo de remediação de 26/12/2025 (adicionado ao KEV em 19/12/2025), reforçando que já há exploração confirmada e não apenas risco teórico. Existe PoC pública associada à CVE, o que reduz a barreira técnica para novos atores replicarem os ataques observados.
Versions
How to protect
A correção definitiva é atualizar o Fireware OS: 2025.1.x para 2025.1.4; ramo 12.x para 12.11.6; modelos T15 e T35 no ramo 12.5.x para 12.5.15; a versão certificada FIPS 12.3.1 para 12.3.1_Update4 (build B728352). O ramo 11.x está em fim de vida (End of Life) e não recebe correção — dispositivos nessa versão precisam ser migrados para um ramo suportado, não há patch a aplicar.
Se a atualização imediata não for viável, o único paliativo real descrito pelo fornecedor se aplica a um cenário restrito: se o Firebox estiver configurado apenas com túneis de VPN de escritório filial para peers de gateway estático (sem VPN de usuário móvel IKEv2 e sem peer de gateway dinâmico), é possível seguir as recomendações da WatchGuard para 'Secure Access to Branch Office VPNs that Use IPSec and IKEv2' como mitigação temporária. Fora desse cenário específico, o próprio advisory marca 'Workaround Available: False' — ou seja, para a maioria dos ambientes com VPN de usuário móvel ativa, não existe mitigação de configuração; a única saída é atualizar ou desativar o serviço IKEv2 exposto.
Em qualquer caso onde há suspeita ou confirmação de exploração — presença dos IoCs listados, hang do processo iked, ou logs de payload CERT anômalo — a WatchGuard exige, além de aplicar o patch, rotacionar todos os segredos armazenados localmente no Firebox (chaves compartilhadas, credenciais de administração local), seguindo o artigo de boas práticas do fornecedor. Rotação de segredos não é opcional nesse cenário: a atividade pós-exploração documentada envolve exfiltração direta do arquivo de configuração e do banco de usuários locais, então mesmo depois de corrigido o software, credenciais antigas continuam comprometidas se não forem trocadas.
How to detect
A WatchGuard publicou indicadores de ataque específicos: seis endereços IP associados a atividade de ameaça conhecida (45.95.19.50, 51.15.17.89, 172.93.107.67, 199.247.7.82, 38.252.8.14, 94.249.197.106) — conexões de saída do Firebox para esses IPs são forte indício de comprometimento, e conexões de entrada a partir deles podem indicar reconhecimento ou tentativa de exploração. Em nível de log, com logging de erro padrão do iked, a mensagem 'Received peer certificate chain is longer than 8. Reject this certificate chain' é indicador médio; com logging no nível 'info', uma mensagem de requisição IKE_AUTH com payload CERT maior que 2000 bytes é indicador forte de tentativa de exploração.
Em nível de comportamento do dispositivo, o hang do processo iked (interrompendo negociações e re-keys de túneis, embora túneis já ativos possam continuar passando tráfego) é forte indicador de exploração bem-sucedida; um crash do iked com geração de fault report é indicador fraco, pois tem outras causas possíveis. Não há assinatura de rede única e confiável fora desses payloads anômalos — a detecção depende de correlacionar logs do iked com os IPs publicados e monitorar exfiltração de arquivos de configuração ou do banco de usuários locais.