CVE-2019-16759

Falha de execução remota de código pré-autenticação em vBulletin 5.x, explorada via o parâmetro widgetConfig[code] da rota ajax/render/widget_php, que permite injetar e executar PHP arbitrário sem qualquer autenticação. O CVSS 9.8 é justificado: não há pré-condição de configuração, conta ou rede interna — qualquer instalação padrão exposta à internet é vulnerável, o que gerou exploração em massa por botnets dias após a divulgação pública do exploit.

A causa raiz (CWE-94, Code Injection) está no widget PHP nativo do vBulletin 5, em includes/vb5/frontend/controller/bbcode.php. A função evalCode() do framework de widgets recebe um bloco de código PHP como parte da configuração de um widget e o executa diretamente com eval($code), sem qualquer sanitização, whitelist de funções ou verificação de origem da requisição.

O vetor de entrada é o parâmetro widgetConfig[code], enviado via POST para a rota routestring=ajax/render/widget_php. Esse endpoint faz parte do sistema de renderização assíncrona de widgets do vBulletin e, por design, não exige sessão autenticada — o próprio mecanismo de widgets foi pensado para ser acessível publicamente em páginas de fórum. O atacante controla integralmente o conteúdo passado a eval(), incluindo chamadas a funções como shell_exec(), o que dá execução de comando no sistema operacional, não apenas no interpretador PHP, com os privilégios do usuário sob o qual o vBulletin roda no servidor web.

O exploit publicado originalmente tinha 18 linhas e não exigia engenharia reversa: bastava montar o POST com routestring e widgetConfig[code]. Segundo Chaouki Bekrar (Zerodium), a falha circulava em mercados privados de exploits há anos antes da divulgação pública em setembro de 2019 — o que levou alguns pesquisadores a classificá-la informalmente como um 'bugdoor'.

Exploração real observada: requisição HTTP POST única, sem autenticação, sem necessidade de acesso prévio ou configuração não padrão — funciona em instalações padrão de vBulletin 5.x expostas na rede. A complexidade é trivial (AC:L no CVSS reflete isso corretamente) e não exige interação do usuário.

Após a divulgação em 23/09/2019 na lista Full Disclosure, pesquisadores (Bad Packets/Troy Mursch, Tenable) documentaram ataques em massa por botnets dentro de horas, muitos usando dorks do Shodan para localizar instalações vulneráveis em escala. Um padrão de ataque recorrente usava a injeção para rodar sed via shell_exec() e modificar o próprio bbcode.php, inserindo um backdoor condicionado a um parâmetro de senha (epass) — ou seja, o atacante explorava a RCE não só para comando imediato, mas para plantar uma porta dos fundos persistente, reutilizável mesmo que a vulnerabilidade original venha a ser corrigida depois.

O resultado final é execução de comando arbitrário no host com os privilégios do processo web/PHP do vBulletin — o suficiente, dependendo da configuração do servidor, para controle completo do host, exfiltração ou destruição de banco de dados (há relatos de bancos MySQL inteiros apagados) e uso do servidor como nó de botnet para ataques subsequentes.

A correção correta é aplicar o patch de segurança que a vBulletin Solutions publicou em 25/09/2019 (poucas horas após a divulgação pública), disponível como patch para a linha 5.x. As fontes consultadas não especificam um número de versão pós-patch distinto de 5.5.4 — o fornecedor distribuiu o patch como arquivo de correção aplicável sobre 5.5.4 (e retroativamente sobre versões anteriores da linha 5.x), não como um novo release numerado; confirme com o painel de administração/changelog do produto qual patch level está instalado antes de considerar o ambiente corrigido.

Atenção crítica: o patch original teve uma correção incompleta. Em agosto de 2020, o mesmo pesquisador (Zenofex) publicou um bypass que reintroduz a mesma classe de RCE pré-autenticada usando um widget diferente (widget_tabbedcontainer_tab_panel, via subWidgets[...][template]=widget_php), afetando versões de 5.5.4 até 5.6.2. Isso significa que apenas ter aplicado o patch de 2019 não garante proteção total contra essa família de falha — é preciso estar na versão mais recente da linha 5.x que trate ambos os vetores, e não apenas confirmar que o patch de setembro de 2019 foi instalado.

Se a atualização imediata não for possível: como medida paliativa, desabilitar ou remover o acesso à rota ajax/render/widget_php (e variantes de widget PHP) via configuração do servidor web/proxy reduz a exposição, mas quebra funcionalidade legítima de widgets PHP customizados, se usados. Bloqueio via WAF de requisições contendo widgetConfig[code] ou subWidgets[*][config][code] ajuda contra exploração automatizada genérica, mas não é garantia contra variações do payload. Não existe mitigação de configuração 'oficial' documentada nas fontes além do patch — instalações que não conseguem atualizar devem considerar tirar o fórum do ar até corrigir, como recomendado por pesquisadores na época do incidente.

Em logs de servidor web, procure requisições POST para rotas contendo routestring=ajax/render/widget_php (ou diretamente para /ajax/render/widget_php) com parâmetro widgetConfig[code] no corpo — especialmente conteúdo contendo eval, shell_exec, system, base64_decode ou comandos de shell codificados. Para a variante de bypass de 2020, o indicador é requisição para /ajax/render/widget_tabbedcontainer_tab_panel com subWidgets[0][template]=widget_php e subWidgets[0][config][code].

Como indicador de comprometimento pós-exploração, verifique integridade do arquivo includes/vb5/frontend/controller/bbcode.php: campanhas documentadas inseriram uma condicional if (isset($_REQUEST['epass']) && ...) em torno da chamada eval($code) original, criando um backdoor persistente com senha fixa. Qualquer modificação não originada de atualização oficial nesse arquivo é sinal forte de exploração bem-sucedida, mesmo que a vulnerabilidade de origem já tenha sido corrigida depois.