O WordPress lançou, em 28 de outubro de 2026, a versão 7.1.4, dedicada exclusivamente à correção de falhas de segurança. Ao todo, foram contabilizadas 22 vulnerabilidades distribuídas em 17 avisos técnicos — número bem superior ao da atualização anterior, a 7.1.3, lançada três semanas antes, que havia corrigido apenas sete problemas. A atualização de segurança reforça a importância de manter o core, os temas e os plugins sempre em dia, já que a maioria das brechas corrigidas dependia de algum nível de acesso prévio ao site, geralmente uma conta de Colaborador.
A exceção mais grave é uma condição de corrida (race condition) no processo de atualização do próprio WordPress, capaz de resultar em execução remota de código sem exigir qualquer conta de usuário. Segundo a Plustag IA, essa falha específica é a que mais preocupa, justamente por não depender de autenticação. Os backports foram disponibilizados no mesmo dia para todas as versões ainda suportadas, chegando até a branch 4.7.39.
Falha crítica na atualização do WordPress 7.1.4 permite execução remota de código
Quando o WordPress instala ou atualiza qualquer componente, ele extrai o pacote para a pasta wp-content/upgrade/, que o servidor web trata como qualquer outro diretório acessível. Até a versão 7.1.4, o nome dessa pasta de extração era derivado diretamente do nome do pacote, tornando-o previsível para qualquer arquivo enviado pelo painel administrativo. Pior ainda: a rotina de limpeza que roda antes da extração apagava tudo o que havia nesse diretório, inclusive o arquivo index.php responsável por impedir a listagem pública da pasta.
Dessa forma, durante os poucos segundos em que uma atualização está em andamento, uma instalação completa do WordPress fica exposta em um caminho previsível e navegável. Entre os arquivos extraídos está o wp-admin/setup-config.php, que pode ser executado isoladamente, sem depender da configuração do site. Ou seja, um invasor que conseguisse acessar esse caminho no momento certo poderia rodar o instalador apontando para um banco de dados sob seu controle, dentro do diretório raiz de outra pessoa.
A correção trazida pela versão 7.1.4 passou a acrescentar 16 caracteres aleatórios ao nome da pasta, recriar o arquivo index.php e interromper sua exclusão. Além disso, uma segunda mudança no arquivo update-core.php, não mencionada oficialmente no comunicado de lançamento, passou a impedir que o wp-config.php seja copiado para fora do diretório de trabalho.
Apesar da gravidade, a janela de exploração é extremamente curta: é preciso acessar o caminho exato no instante em que uma atualização está em execução, o que motivou a classificação AC:H — ou seja, um ataque considerado de difícil execução prática. Ainda assim, trata-se de uma falha que não exige autenticação nem interação do usuário, com origem que remonta à versão 2.8 do WordPress, e que volta a se abrir a cada nova atualização, inclusive nas automáticas.
Um firewall em nível de PHP não é capaz de bloquear esse tipo de ataque, já que a cópia extraída carrega sua própria instância do WordPress a partir de arquivos isolados, e o pacote oficial não inclui diretório mu-plugins — por isso, o firewall do site simplesmente não entra em ação para essa requisição específica. A recomendação é bloquear o acesso no próprio servidor web, negando o acesso a wp-content/upgrade/ e verificando se o diretório não permite listagem. Fora dos momentos de atualização, essa pasta deve conter apenas um arquivo index.php vazio.
Interactivity API concentra sete das vulnerabilidades corrigidas
Sete dos 17 avisos de segurança dizem respeito a falhas na Interactivity API, todas com uma causa comum: o mecanismo KSES, responsável por definir quais trechos de HTML um usuário sem a permissão unfiltered_html pode salvar, permite qualquer atributo data-* com qualquer valor. Como todas as diretivas da Interactivity API são atributos data-*, como data-wp-interactive, data-wp-context e data-wp-bind–href, um Colaborador poderia inserir diretivas maliciosas em um post, fazê-las passar intactas pela filtragem e, assim, fazer com que o runtime do cliente as executasse quando um visitante carregasse a página.
A partir desse ponto, diversos vetores de ataque se tornaram possíveis: vínculos que definem URLs do tipo javascript:, bindings em manipuladores on* que o lado PHP já havia recusado, chaves reservadas como __proto__ alcançando a mesclagem de contexto, bindings em elementos object que escapavam das verificações de dados e tipo feitas pelo KSES, e um parser de CSS que reprocessava sua própria entrada a cada iteração — essa última falha caracteriza uma negação de serviço que trava a aba do navegador do visitante, não o servidor.
A versão 7.1.4 corrige esses problemas em três frentes: o KSES passou a remover bindings que alterariam um valor já validado, o processador PHP de diretivas restringiu os bindings em elementos object, e o runtime passou a recusar destinos inseguros. Vale notar que o runtime cliente da Interactivity API foi lançado na versão 6.4, uma versão antes da classe PHP correspondente, disponibilizada na 6.5 — por isso o WordPress lista as versões 6.4 e 6.5 como afetadas pelo mesmo número de problemas.
Outras correções: Script Module, Customizer e blocos
Outra falha corrigida envolve o chamado “sombreamento” de dados do Script Module. A Interactivity API lê seu estado a partir de um elemento script localizado via getElementById(), método que retorna o primeiro elemento com aquele ID, independentemente da tag usada. Como o WordPress imprime o bloco de dados real em wp_footer, após o conteúdo do post, um conteúdo armazenado com o mesmo ID conseguia chegar primeiro e fornecer um estado falso ao runtime. A versão 7.1.4 passou a verificar se o elemento encontrado é, de fato, um elemento script.
No Customizer, o recurso de atualização seletiva (selective refresh) construía definições parciais a partir de atributos data-customize-partial-* presentes no documento de pré-visualização, permitindo que conteúdo de post declarasse um seletor direcionado à função $() do jQuery — que trata strings iniciadas por “<” como HTML a ser construído, e não como seletor a ser buscado, o mesmo comportamento por trás de uma das correções da versão 7.1.3. Agora, o sistema utiliza .find(), que apenas interpreta seletores reais. Separadamente, uma falha permitia que uma requisição de pré-visualização do Customizer sem UUID de changeset assumisse automaticamente o changeset não publicado mais recente, sem qualquer verificação de permissão — expondo a um visitante anônimo tanto o UUID quanto a pré-visualização renderizada. A versão 7.1.4 passou a exigir a capacidade customize para esse tipo de solicitação.
Entre os blocos nativos, três correções trataram de conteúdo que havia sido filtrado corretamente, mas reinterpretado depois. O bloco Categories passava o rótulo do menu suspenso pela função wp_kses_post() e, em seguida, inseria o resultado em uma string de formato usada pelo sprintf(), permitindo que diretivas de formatação no rótulo fossem expandidas após a filtragem. Já os blocos Image e Playlist construíam marcação usando preg_replace() com texto correspondente influenciado pelo atacante como string de substituição, permitindo que o PHP expandisse referências como $0 dentro dela — sem limite de substituição, isso possibilitava mesclar uma tag dentro do atributo de outra. Ambos os blocos agora utilizam a HTML API. Além disso, os blocos Comments Pagination e Post Navigation Link imprimiam seu atributo de rótulo sem o devido escape, falha também corrigida nesta atualização.
Diante do volume de correções trazidas pelo WordPress 7.1.4, a recomendação da Plustag IA para administradores de sites é aplicar a atualização o quanto antes, revisar permissões concedidas a contas de Colaborador e Editor, e, especialmente para quem opera ambientes de alto tráfego, bloquear o acesso externo ao diretório wp-content/upgrade/ diretamente no servidor web como camada adicional de proteção.
Com informações de patchstack.com.
