O WordPress lançou nesta terça-feira (22) a versão 7.1.2, uma atualização de segurança que corrige uma vulnerabilidade crítica capaz de permitir a um invasor executar comandos em um site sem precisar de login ou senha. A falha afeta praticamente todas as versões do sistema desde 2016 e representa risco alto para quem administra páginas construídas na plataforma, a mais usada do mundo para criação de sites.
A brecha foi descoberta por Robert Ressl e recebeu o identificador CVE-2026-87902. De acordo com a classificação técnica CVSS 4.0, ela atingiu nota 9,2 em uma escala que vai até 10, patamar considerado crítico. O problema está catalogado como CWE-98, categoria que trata de falhas no controle de nomes de arquivo usados em comandos de inclusão de código.
O que essa falha de segurança no WordPress permite fazer?
O problema está na forma como o WordPress escolhe qual arquivo de modelo (template) usar para exibir uma página. A função responsável por essa tarefa monta o nome do arquivo a partir de um parâmetro enviado diretamente na requisição feita ao site, chamado “pagename”.
O sistema já tinha uma verificação de segurança para evitar que esse tipo de dado fosse manipulado de forma maliciosa. No entanto, essa checagem era aplicada em apenas um dos trechos de código responsáveis por montar o nome do arquivo. O outro trecho, que lida diretamente com o dado enviado pelo usuário, ficou sem a mesma proteção por quase dez anos de versões do sistema.
Na prática, isso abre espaço para um ataque conhecido como inclusão local de arquivo (LFI, na sigla em inglês), em que um invasor consegue fazer o site carregar arquivos que não deveriam ser acessíveis. Para que esse acesso se transforme em execução de código arbitrário, o servidor precisa reunir algumas condições específicas, como ter instalado o componente PEAR com o arquivo pearcmd.php e estar configurado com a opção register_argc_argv habilitada.
Quais sites estão mais vulneráveis?
Segundo o alerta técnico, essa configuração de PHP vem ativada por padrão nas imagens oficiais do Docker e também em ambientes cPanel que rodam versões do PHP anteriores à 8.5. Isso significa que a condição para o ataque evoluir de simples leitura de arquivo para controle total do site é mais comum do que se imagina.
Também é necessário que o tema ativo no site tenha uma pasta com nome iniciado por “page-“, como é o caso de temas antigos padrão do WordPress e de vários temas de terceiros populares. Sites que não atendem a esse critério ficam menos expostos à execução remota de código, mas continuam vulneráveis à inclusão indevida de arquivos.
Como o WordPress corrigiu o problema
A correção trouxe duas mudanças no código. A primeira aplica ao trecho vulnerável a mesma verificação de segurança que já existia na outra parte do sistema, fechando a brecha específica identificada por Ressl.
A segunda mudança vai além do problema pontual relatado. O WordPress 7.1.2 passou a exigir que qualquer arquivo de modelo resolvido pelo sistema, não importa por qual caminho do código ele chegue até ali, esteja obrigatoriamente dentro de diretórios permitidos do tema em uso. Essa camada extra de proteção sugere que a equipe de segurança do WordPress optou por tratar a resolução de templates como um ponto de risco mais amplo, e não apenas corrigir o caso isolado relatado.
Como atualizar o site agora
A atualização já está disponível para instalação imediata. Veja como proceder:
- Acesse o painel administrativo do WordPress e vá até a seção “Atualizações”
- Ou baixe a versão 7.1.2 diretamente pelo site oficial WordPress.org
- Sites com atualizações automáticas em segundo plano ativadas já devem ter recebido a correção
- A correção foi disponibilizada também para versões antigas do sistema, com pacotes específicos para cada uma das ramificações ainda mantidas com suporte a partir da versão 4.7
Vale lembrar que apenas a versão mais recente do WordPress recebe suporte ativo e contínuo da equipe de desenvolvimento.
O que fazer enquanto a atualização não é aplicada?
Para quem não pode atualizar o site imediatamente, duas verificações ajudam a entender o nível de exposição. A primeira é checar se o tema ativo possui alguma pasta de nível superior que comece com “page-“. A segunda é verificar se a configuração register_argc_argv está habilitada no PHP do servidor.
Nenhuma dessas checagens substitui a correção oficial, mas ajudam o administrador do site a dimensionar o risco real enquanto a atualização não é instalada. Diante da gravidade da falha e da quantidade de versões afetadas, a recomendação é tratar o caso como prioridade e não deixar a atualização para uma janela de manutenção futura.
Com informações de patchstack.com.
