CVE-2025-20352

Falha de stack overflow (CWE-121) no subsistema SNMP do Cisco IOS e IOS XE, explorável remotamente por atacante autenticado via pacote SNMP malformado. Com credenciais de leitura (comunidade RO SNMPv1/v2c ou usuário SNMPv3 válido) o resultado é reload do dispositivo (DoS); se o atacante já tiver também credenciais de privilégio 15/admin no IOS XE, o mesmo bug permite execução de código como root, dando controle total do equipamento. Está no catálogo KEV da CISA com exploração confirmada e PoC pública, o que eleva a urgência mesmo exigindo autenticação prévia.

A vulnerabilidade está no processamento de pacotes SNMP pelo subsistema SNMP do IOS/IOS XE. Um pacote SNMP construído de forma específica, ao ser recebido, causa overflow de buffer baseado em pilha (CWE-121) durante o parsing/tratamento de um OID afetado. O advisório da Cisco é explícito: a falha afeta todas as versões de SNMP (v1, v2c e v3) — o problema está na lógica de tratamento do OID, não em uma versão específica do protocolo.

O atacante controla o conteúdo do pacote SNMP enviado ao agente do dispositivo, incluindo o OID alvo que dispara o caminho de código vulnerável. Como o SNMP é um serviço autenticado (mesmo SNMPv2c com community string funciona como uma forma fraca de autenticação), a Cisco classifica o requisito mínimo de exploração como 'atacante autenticado com privilégios baixos'.

Há dois desfechos distintos documentados pelo fornecedor, dependendo do nível de acesso do atacante: com apenas a community string RO (SNMPv1/v2c) ou credenciais SNMPv3 válidas, o overflow provoca corrupção de pilha suficiente para forçar o reload do processo/dispositivo — DoS. Se o atacante também possui credenciais administrativas (privilégio 15) no IOS XE, o mesmo overflow pode ser manipulado para desviar o fluxo de execução e rodar código arbitrário como root, comprometendo totalmente o sistema — isso é o RCE, exclusivo do IOS XE segundo o advisório (IOS puro sofre apenas o DoS).

O CVSS 3.1 (7.7, AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H) reflete o cenário de DoS com privilégio baixo; o cenário de RCE com privilégio alto não está capturado nesse score único, o que é importante notar ao priorizar — o risco real em ambientes onde contas admin e SNMP RO coexistem é maior do que o número sugere isoladamente.

O vetor é um pacote SNMP malformado enviado ao dispositivo sobre IPv4 ou IPv6, atingindo a porta/serviço SNMP exposto. Pré-requisito inescapável: o atacante precisa de credenciais válidas de leitura SNMP — a community string RO em SNMPv1/v2c (frequentemente 'public' ou strings default/fracas em ambientes mal configurados) ou um usuário SNMPv3 legítimo. Sem isso não há superfície de ataque, já que o SNMP não aceita pacotes anônimos para essas operações.

O cenário de DoS é o mais acessível: qualquer atacante com a community RO ou usuário SNMPv3 consegue, em tese, provocar o reload do dispositivo — impacto direto em disponibilidade de rede, sem necessidade de acesso privilegiado adicional. Já o cenário de execução de código como root exige, além das credenciais SNMP, uma segunda credencial: acesso administrativo ou privilégio 15 no próprio dispositivo IOS XE. Isso restringe bastante o alcance prático da RCE — é essencialmente uma escalação root/persistência mais profunda para quem já tem acesso administrativo, não uma porta de entrada externa para quem não tem nada.

A presença no catálogo KEV da CISA (adicionado em 2025-09-29, prazo de correção 2025-10-20) confirma exploração ativa observada, e há PoC pública circulando — o que reduz a barreira técnica para replicar ao menos o cenário de DoS contra dispositivos com SNMP habilitado e credenciais fracas ou reaproveitadas de outros vazamentos. A CISA classifica como 'desconhecido' o uso em campanhas de ransomware.

A Cisco não lista workaround que elimine a vulnerabilidade — apenas uma mitigação parcial. A correção definitiva é atualizar para versão corrigida de IOS ou IOS XE; o advisório oficial lista as releases fixas na seção 'Fixed Software', mas o conteúdo específico de números de versão não foi capturado nesta pesquisa — consulte diretamente o advisório da Cisco (cisco-sa-snmp-x4LPhte) para a tabela de versões fixas aplicável ao seu trem de release antes de agir.

Como mitigação temporária, a Cisco recomenda restringir o acesso SNMP apenas a usuários confiáveis e, principalmente, excluir os OIDs afetados usando uma SNMP view (comando snmp-server view) que remova do escopo acessível MIBs como snmpUsmMIB, snmpVacmMIB, snmpCommunityMIB e o mapeamento específico do CISCO-AUTH-FRAMEWORK-MIB (cafSessionMethodsInfoEntry), aplicando essa view à community string (RO) ou ao grupo SNMPv3. O custo real dessa mitigação: pode quebrar funcionalidades de gerência via SNMP que dependem desses OIDs, como descoberta de dispositivo e inventário de hardware — não é um ajuste sem efeito colateral. Nem todo software suporta o OID citado; se o OID não existe na versão instalada, o dispositivo não é afetado por aquele vetor específico.

O que não funciona: apenas trocar a community string ou desabilitar SNMPv1 em favor de SNMPv3 não mitiga nada — o advisório é explícito que a falha afeta todas as versões de SNMP (v1, v2c e v3), então a mitigação real é a exclusão de OID ou a atualização de software, não a troca de versão do protocolo. Monitorar hosts SNMP configurados com 'show snmp host' é recomendado pela Cisco como controle complementar de visibilidade, não como correção.

Verificar se SNMP está habilitado e exposto: 'show running-config | include snmp-server community' (SNMPv1/v2c) e 'show running-config | include snmp-server group' + 'show snmp user' (SNMPv3) — presença de saída indica serviço ativo e, portanto, superfície vulnerável. 'show snmp host' permite monitorar hosts configurados para receber SNMP, útil como linha de base de quem deveria estar falando SNMP com o dispositivo.

Não há assinatura de payload divulgada publicamente pela Cisco ou pela CISA nas fontes consultadas — o overflow ocorre dentro do parsing de um pacote SNMP válido do ponto de vista de autenticação, então tráfego SNMP anômalo (pacotes malformados, tamanhos fora do padrão, tentativas repetidas contra o OID afetado) direcionado à porta SNMP é o sinal mais próximo disponível, mas exige captura e inspeção de pacote SNMP para diferenciar de tráfego de gerência legítimo. Reloads inesperados de dispositivos com SNMP habilitado, sem outra causa identificada, são indício retroativo de possível exploração do cenário DoS.