CVE-2018-0125

Falha crítica de validação de entrada na interface web dos roteadores Cisco RV132W e RV134W permite que um atacante remoto e não autenticado execute código arbitrário como root, ou force o reload do dispositivo (DoS). Afeta todas as versões de firmware antes da 1.0.1.11 e está no catálogo KEV da CISA desde 2022, com evidência de exploração ativa em campo relatada pelo próprio time de PSIRT da Cisco.

A Cisco classifica a falha como CWE-20 (Improper Input Validation): a interface de gerenciamento web do dispositivo não valida corretamente dados controlados pelo usuário dentro de uma requisição HTTP. O advisory oficial não detalha qual endpoint, parâmetro ou rotina de parsing está envolvida — não há CWE mais específico (como buffer overflow ou command injection) divulgado publicamente pela Cisco, nem análise de terceiros disponível nas fontes consultadas.

O impacto declarado é execução de código arbitrário com privilégios de root no sistema operacional embarcado do roteador, ou seja, comprometimento total do dispositivo — não uma falha de escalonamento de privilégio parcial. O fato de o processo web rodar como root explica por que a exploração resulta em controle completo em vez de acesso restrito.

A vulnerabilidade atinge todas as releases de firmware anteriores à correção, sem versão inicial conhecida a partir da qual o bug foi introduzido — a Cisco trata como presente desde sempre nesses dois modelos, o que sugere um defeito estrutural na implementação da interface de administração, não uma regressão introduzida em release recente.

O vetor é uma requisição HTTP manipulada enviada à interface de gerenciamento web do roteador, sem necessidade de autenticação, interação do usuário ou condições de rede especiais além de acesso à interface exposta (AV:N, PR:N, UI:N, AC:L no vetor CVSS). Isso torna qualquer instância com a interface web acessível — inclusive pela WAN, se exposta — um alvo direto.

A Cisco não divulgou prova de conceito nem estrutura exata do payload, mas confirma no advisory (revisão de dezembro de 2022) que o PSIRT identificou tentativas adicionais de exploração em março de 2022, quatro anos após a publicação original — o que motivou a inclusão no catálogo KEV da CISA com prazo de correção definido (25/03/2022 a 15/04/2022). Isso indica que a falha permaneceu atrativa para atacantes por anos após a correção estar disponível, provavelmente por conta de dispositivos nunca atualizados e fim de vida dos produtos.

Não há relato de necessidade de credenciais, VLAN específica ou configuração não padrão para a exploração — o próprio fornecedor não lista pré-condições além de o dispositivo estar acessível via HTTP. Isso contrasta com muitas CVEs de roteadores SOHO que exigem acesso à rede local; aqui, se a interface de administração estiver exposta à internet, o risco é direto e crítico.

A Cisco não oferece workaround: o advisory afirma explicitamente 'There are no workarounds that address this vulnerability'. A única remediação oficial é atualizar o firmware para a versão 1.0.1.11 nos modelos RV132W e RV134W.

Como controle compensatório real quando a atualização não é imediata, restrinja o acesso à interface de gerenciamento web apenas à rede de gerência interna — nunca expor a administração desses roteadores diretamente à internet — e desative o acesso remoto de gerenciamento (HTTP/HTTPS WAN) se estiver habilitado. Isso reduz a superfície de ataque mas não elimina o risco caso um atacante já tenha pé dentro da rede local.

Vale notar que os modelos RV132W e RV134W estão em fim de vida no ciclo de produtos Cisco; para ambientes que não podem mais receber patches por esse motivo, a segmentação de rede e a substituição do equipamento são as únicas mitigações duráveis — não há flag de configuração, ACL específica ou assinatura de WAF documentada pelo fornecedor que neutralize a falha na origem.

Não há assinatura de exploração publicada pela Cisco ou nas fontes consultadas. O advisory apenas confirma que houve 'tentativas adicionais de exploração' identificadas pelo PSIRT em março de 2022, sem divulgar indicadores de comprometimento, padrões de requisição HTTP suspeitas ou strings de payload. Na ausência de IOCs oficiais, o sinal prático disponível é monitorar logs de acesso HTTP/HTTPS à interface de gerenciamento desses dispositivos por requisições anômalas, especialmente originadas da WAN, e verificar reloads inesperados do equipamento como possível indício de tentativa de DoS.