WordPress: Travessia de caminho sem autenticação levando a RCE condicional

Artigo original ↗ Discussão no Hacker News ↗

Uma vulnerabilidade recém-divulgada no WordPress permite travessia de caminho sem autenticação que pode levar à execução remota de código sob certas configurações, especialmente quando combinada com estruturas comuns de temas e configurações inseguras de PHP, como nas imagens oficiais do Docker. Comentaristas debatem quão generalizado é realmente o risco, observando que muitos temas seguem as recomendações de diretório do próprio WordPress e que correções do core já foram retroportadas para versões antigas. O incidente reacende críticas mais amplas ao modelo de segurança do WordPress, ao ecossistema de plugins e à dependência de pontuações CVSS base, com alguns argumentando que organizações devem isolar ou substituir o WordPress por completo, enquanto outros ressaltam que configuração cuidadosa e hardening podem mantê-lo razoavelmente seguro.

Vulnerabilidade e impacto

  • Problema central: uso não sanitizado de get_page_template / locate_template, permitindo travessia de caminho para incluir arquivos PHP arbitrários já presentes no servidor.
  • Principal pré-condição: o tema tem um diretório de nível superior page-* (por exemplo, page-templates/), o que a documentação do WordPress recomenda explicitamente. Vários comentaristas argumentam que isso torna um grande número de temas vulneráveis, não apenas “alguns poucos”.
  • Em uma instalação nova, usuários aleatórios não podem enviar PHP, mas invasores podem abusar de qualquer “PHP que executa comandos” já existente no sistema.

Condições e cadeias de exploração

  • Cadeia de exemplo: combinar esta falha com um dos muitos bugs de upload de arquivos sem autenticação em plugins para chegar a uma RCE condicional; invasores podem preferir isso a simplesmente enviar webshells para evitar configurações reforçadas e logs.
  • A imagem oficial do PHP no Docker historicamente incluía pearcmd.php com register_argc_argv ativado e sem open_basedir, oferecendo um alvo poderoso uma vez que a travessia de caminho é obtida.
  • Alguns argumentam que isso é efetivamente explorável “por drive-by” em sites que usam temas populares junto com o Docker padrão ou configurações típicas de hospedagem compartilhada.

Status do patch e implantação

  • Corrigido no WordPress 7.1.2, com backports “como cortesia” para ramos até 4.7 (exceto uma versão de atualização automática quebrada).
  • Um comentarista inicialmente se pergunta se os temas ainda precisam de auditoria após o patch, mas conclui que a correção no core deve neutralizar o comportamento do tema.
  • O WordPress não tem um LTS verdadeiro; ramos mais antigos dependem de backports seletivos, deixando bugs desconhecidos sem correção.

Debate sobre pontuação CVSS

  • Um lado: notas CVSS são números de “tabuleiro ouija”, facilmente manipuláveis e frequentemente desalinhados com o risco do mundo real; usá-las para priorizar o que ler é perigoso.
  • Outro lado: o CVSS base é uma medida útil de primeira passagem do impacto técnico; organizações devem recalcular por ambiente usando calculadoras e controles compensatórios.
  • Contraste de exemplo: esta RCE do WordPress (9.x) vs vulnerabilidades de ferramentas do Hugo (também 9.3) — mesma severidade numérica, mas exposição prática muito diferente.

Avaliações da segurança do WordPress

  • Crítica forte: “RCE-as-a-Service”, “um pedaço de lixo”, código bagunçado, mal tipado, muitas APIs sem documentação, modelo padrão inseguro (o site pode escrever seu próprio código; uploads frequentemente executáveis; plugins ampliam massivamente a superfície de ataque).
  • Contra-argumentos: extremamente popular, inclusive em sites de alto valor; pode ser operado com segurança com conhecimento, hardening e uso disciplinado de plugins. Os problemas muitas vezes vêm de contratados baratos e não especialistas “montando em LEGO” plugins e temas.
  • Alguns argumentam que popularidade e extensibilidade inevitavelmente atraem invasores; outros dizem que a popularidade por si só não explica o histórico de explorações do WordPress.

Alternativas e migrações

  • Vários participantes relatam migração do WordPress para geradores estáticos (Hugo, Astro) ou PHP personalizado majoritariamente estático, descrevendo:
    • Enorme redução na complexidade operacional e na preocupação com segurança.
    • Liberdade de cruft de plugins, comportamento caixa-preta e upgrades frágeis.
  • No entanto, até ferramentas estáticas podem ter bugs de CVSS alto (exemplo do Hugo); a diferença é que os sites gerados são HTML estático, então a exposição em tempo de execução é muito menor.
  • Sistemas de comentários continuam sendo um ponto difícil para sites estáticos; as sugestões incluem serviços de terceiros e sistemas mínimos auto-hospedados.

Observações mais amplas de segurança

  • Travessia de caminho é vista como uma classe recorrente de bug impulsionada por abstrações ruins de sistema de arquivos; um comentarista promove suporte em bibliotecas para mitigar isso.
  • Logs de servidores públicos mostram varredura constante por explorações PHP, com caminhos do WordPress e arquivos .env vazados sendo comumente sondados.
  • Alguns especulam que a análise de código impulsionada por IA pode aumentar enormemente as vulnerabilidades descobertas em todos os ecossistemas, desafiando suposições sobre qual software é “mais explorável”.