CVE-2020-17496

Falha de execução remota de código pré-autenticação em vBulletin 5.5.4 até 5.6.2, causada por um patch incompleto para a CVE-2019-16759. Um único request HTTP ao endpoint ajax/render/widget_tabbedcontainer_tab_panel permite injetar código PHP através do parâmetro subWidgets, contornando a validação que a vBulletin havia adicionado na versão anterior. Está no catálogo KEV da CISA com exploração confirmada, tem PoC pública, módulo Metasploit e template Nuclei — é praticamente trivial de explorar e continua sendo usada em varreduras automatizadas contra fóruns vBulletin expostos.

Em setembro de 2019, um pesquisador anônimo publicou a CVE-2019-16759: era possível enviar, via ajax/render/[template], um nome de template arbitrário (widget_php) cujo parâmetro de configuração 'code' era executado como PHP puro pelo motor de templates do vBulletin. O fornecedor corrigiu isso em duas etapas — primeiro removendo a variável 'widgetConfig' das variáveis registradas (função cleanRegistered), depois, na 5.5.5, adicionando uma checagem explícita: se o template solicitado no routeInfo fosse 'widget_php', a resposta é esvaziada antes de qualquer renderização.

O problema é que essa checagem só olha o template requisitado no nível superior da rota (routeInfo[2]). O widget widget_tabbedcontainer_tab_panel aceita um array 'subWidgets', e cada subWidget carrega seu próprio 'template' e 'config' — esses são processados internamente pelo motor de renderização de widgets, fora do caminho que a checagem de 5.5.5 cobre. Um atacante pode setar subWidgets[0][template]=widget_php e subWidgets[0][config][code]=, e esse código é executado exatamente pelo mesmo mecanismo de renderização vulnerável da CVE-2019-16759 original, só que por uma rota lateral que o patch não previu.

A classificação de tipo de falha varia entre fontes: a CISA associa CWE-74 (injeção genérica em componente downstream) ao registro no KEV; o link de referência cataloga CWE-78 (OS Command Injection). Na prática, o mecanismo primário é injeção de código PHP no motor de templates (o atacante controla o corpo de uma função PHP executada pelo servidor); o PoC público usa esse código PHP injetado para chamar shell_exec() e daí obter execução de comandos do sistema operacional — ou seja, é uma cadeia code injection → command injection, não uma falha de sanitização de shell diretamente.

O ponto central é que o fornecedor tentou blindar apenas o vetor conhecido (a rota de renderização direta) sem revisar todos os caminhos internos que levam ao mesmo motor de template, deixando o widget de abas como porta lateral para o mesmo primitivo de execução.

O vetor é um único POST HTTP para /ajax/render/widget_tabbedcontainer_tab_panel, sem necessidade de autenticação, sessão ou qualquer configuração não padrão — a instalação default do vBulletin nas versões afetadas já expõe o endpoint. O corpo da requisição contém subWidgets[0][template]=widget_php e subWidgets[0][config][code] com o PHP a ser executado; o PoC público divulgado por Zenofex (bash e Python) demonstra isso encapsulando shell_exec() dentro do código PHP injetado, entregando execução de comando do sistema operacional em uma única chamada.

A complexidade de exploração é baixa: não há necessidade de interação do usuário, bypass de autenticação, nem conhecimento prévio de credenciais ou estado interno do fórum — condizente com o vetor CVSS AV:N/AC:L/PR:N/UI:N. O atacante obtém execução de código arbitrário no contexto do processo PHP do servidor web, o que na prática significa controle total da aplicação (leitura/escrita de arquivos, acesso ao banco de dados via credenciais da config, e execução de comandos do sistema operacional com o privilégio do usuário que roda o servidor web).

A presença no catálogo KEV da CISA (adicionada em novembro de 2021, com prazo de correção maio de 2022) confirma exploração ativa observada em campo, não apenas risco teórico. A combinação de PoC público trivial, módulo Metasploit pronto e template Nuclei torna esta CVE um alvo recorrente de scanners automatizados e botnets que buscam instalações vBulletin desatualizadas expostas à internet.

A correção é aplicar o patch de segurança anunciado pelo próprio fornecedor no fórum oficial (referenciado como patch para as versões 5.6.0, 5.6.1 e 5.6.2). As fontes consultadas não especificam o número exato de patch level liberado para a branch 5.5.x (5.5.4/5.5.5/5.5.6); qualquer instalação nessas versões deve aplicar a atualização mais recente disponível diretamente no anúncio oficial do fornecedor, não uma versão presumida.

Se a atualização não puder ser aplicada imediatamente, o único controle compensatório com respaldo nas fontes é bloquear ou filtrar requisições POST para o endpoint /ajax/render/widget_tabbedcontainer_tab_panel que contenham 'widget_php' no corpo (via regra de WAF ou proxy reverso) — isso tem custo real: pode quebrar a funcionalidade legítima do widget de abas (tabbed container) se ela for usada no fórum. Não há flag de configuração documentada do vBulletin para desativar esse widget de forma granular nas fontes lidas.

O que não funciona como mitigação: reaplicar apenas o patch da CVE-2019-16759 (cleanRegistered / bloqueio de template no nível de rota) não resolve nada — é exatamente esse patch que se mostrou incompleto e deu origem a esta CVE. Confiar em versão vBulletin >= 5.5.5 sem aplicar o patch específico de agosto de 2020 deixa o ambiente vulnerável.

O indicador mais direto é log de requisições POST para /ajax/render/widget_tabbedcontainer_tab_panel contendo os parâmetros subWidgets[0][template]=widget_php e subWidgets[0][config][code] no corpo — esse padrão não tem uso legítimo conhecido e corresponde exatamente ao PoC público. Ferramentas de varredura automatizada (Nuclei, Metasploit) usam essa mesma assinatura, então repetição de tentativas contra o mesmo endpoint a partir de IPs variados é sinal de scanning em massa, não de uso legítimo do fórum.

Não há sinal confiável no lado da aplicação (vBulletin não gera log de erro específico para essa exploração) além do acesso ao endpoint em si; ambientes sem logging de corpo de requisição HTTP (apenas access log de URL) não conseguirão diferenciar uma chamada legítima do widget de uma tentativa de exploração, já que a URL sozinha é idêntica em ambos os casos.