O CMS que sustenta metade da web recebeu dois releases críticos de core com cinco dias de distância em setembro. A falha: um path traversal não autenticado na resolução de page templates, catalogado como GHSA-7hp8-65ch-5whp, corrigido nos releases 6.9.9 e 7.1.2.
Sem login, sem conta, sem interação: um atacante remoto fornece sequências de traversal com codificação dupla e alcança arquivos fora do caminho pretendido, com exposição e inclusão de PHP local que podem escalar a execução condicional de código.
O mês que o core virou alvo
A falha de setembro não veio sozinha: em julho, o core recebeu o CVE-2026-63030, o "wp2shell", um RCE crítico não autenticado. Dois releases críticos de core em poucos meses contam a história de 2026: o WordPress voltou ao topo da fila de pesquisa ofensiva, e quem opera o CMS precisa tratá-lo como sistema que recebe patch contínuo, não como instalação que se esquece.
A crise de segurança do WordPress já estava documentada aqui: a cadeia de plugins e temas com código obscuro é o problema estrutural. A de setembro adiciona o capítulo core: quando o próprio núcleo exige dois patches de emergência em semanas, o inventário de versões deixa de ser boa prática e vira sobrevivência.
Por que "meu site é pequeno" não é defesa
A falha é explorável sem autenticação: o atacante não precisa de conta, precisa de endereço. Scanners automatizados varrem a web inteira atrás de versões vulneráveis, sem olhar o tamanho da empresa.
Na prática, os sites pequenos são os mais expostos: são os que ficam meses sem atualização, com plugins órfãos e sem ninguém olhando os logs. O alvo do scanner não é a fama, é a versão.
O procedimento que separa atualização de aposta
O howTo deste artigo traz o passo a passo, e o resumo é o de sempre em operação séria:
- Inventário do parque inteiro: todas as instalações com versão de core, plugins e temas, e dono de cada uma.
- Staging antes do production: compatibilidade de plugins é o risco real; valide o fluxo crítico na réplica.
- Caca de rastros: logs de acesso procurando traversal e acesso anômalo a templates; encontrou com o site vulnerável, trate como incidente.
- Redução de superfície: menos plugins ativos, e hospedagem com WAF, scanner e atualização assistida que encurta a janela no parque inteiro.
O item 4 é o que escala: gerenciar cinco sites à mão é viável, gerenciar cinquenta não. A operação que patcheia, testa e monitora é a diferença entre aplicar patch e apostar patch.
Conclusão
Dois releases críticos de core em um mês não são azar do WordPress: são o preço de sustentar metade da web num ano em que a pesquisa ofensiva está bem financiada e automatizada.
A resposta não é abandonar o CMS, é operá-lo: core atualizado em staging antes do production, parque inventariado, plugins mínimos e a camada de hospedagem encurtando a janela. A falha de setembro já tem patch; a pergunta é quantos sites do seu parque ainda não o receberam.