O WordPress 7.1.3 foi lançado em 6 de outubro de 2026, trazendo sete correções de segurança e quatro correções de bugs. Trata-se de uma versão de manutenção que chega duas semanas depois da 7.1.2, lançamento que havia corrigido uma única vulnerabilidade (CVE-2026-87902) capaz de permitir que um visitante não autenticado provocasse uma inclusão local de arquivo e, dependendo da configuração do PHP, chegasse até a execução remota de código. A atualização do WordPress 7.1.3, no entanto, tem um perfil diferente: das falhas corrigidas, duas podem ser exploradas por um visitante sem autenticação — o vazamento no feed de comentários e um problema de XSS nos comentários, que exige também o clique de um moderador. Outras três dependem de uma conta de Colaborador ou Autor, uma depende de um administrador executando uma exportação, e a última é um reforço de segurança que depende de plugins específicos. A recomendação é atualizar o quanto antes, ainda que não se trate de uma emergência que exija ação imediata a qualquer custo.
O que mostra a atualização do WordPress 7.1.3
Entre os problemas corrigidos estão:
- XSS persistente na página administrativa de Comentários, via comentários pendentes — exige um comentário pendente e o clique de um moderador (Editor ou superior) em um link; reportado por Thomas Chauchefoin, da Trail of Bits
- Negação de serviço em WP_Http::make_absolute_url() — exige uma conta de Colaborador ou superior; reportado pela Anthropic
- Injeção SQL de segunda ordem na exportação WXR — exige um administrador executando uma exportação, além de um valor malicioso de _thumbnail_id já presente no banco de dados; reportado pela Anthropic
- Autores conseguindo fixar posts como destaque — exige uma conta de Autor ou superior; reportado pela Anthropic
- Exposição de comentários em posts privados e não publicados — sem exigir autenticação; reportado por Ananda Dhakal, da Patchstack
- Embeds do Imgur vulneráveis a XSS — exige uma conta de Colaborador ou superior e um alvo que visualize o conteúdo; reportado por Zhengyu Liu, Jingcheng Yang e Gavin Zhong
- Colisão no nome do hook {status}_{type} — ocorre quando um plugin passa um status ou tipo de post bruto para wp_insert_post(); reportado por Alex Concha, da equipe de segurança do WordPress
XSS nos comentários
O manipulador de clique da aba de Ajuda, no arquivo wp-admin/js/common.js, repassava o href de um link para a função $() do jQuery, que monta HTML a partir de qualquer string com aparência de HTML. Um link dentro de um comentário pendente pode carregar esse href. Como o manipulador só reage dentro de elementos com a classe contextual-help-tabs, o link também precisa estar dentro de um elemento com essa classe específica. Antes da versão 7.1.0, comentários de visitantes não podiam carregar classes — recurso que passou a existir justamente nessa versão para suportar menções via span class, sendo removido no momento de salvar o comentário. Segundo a análise, o ataque via comentário pendente afeta as versões 7.1.0 a 7.1.2, e os backports mais antigos reforçam o mesmo trecho de código. Já o WordPress 7.1.3 passa a usar .find(), método que apenas lê seletores, sem o mesmo risco.
Negação de serviço em make_absolute_url()
Um laço responsável por reduzir pares de segmento/../ nunca termina diante de um caminho relativo como a//../b, já que a expressão regular não encontra correspondência e o caminho permanece inalterado. Dentro do WordPress, um Colaborador pode acionar esse comportamento através da pré-visualização de link do editor de blocos, apontando para uma página sob seu controle. A versão 7.1.3 interrompe o laço sempre que uma passagem não produz nenhuma substituição.
Injeção SQL na exportação WXR
O processo de exportação coletava os IDs de imagem destacada diretamente do metadado _thumbnail_id e os concatenava em uma string de consulta sem garantir que o valor fosse, de fato, um número inteiro. Por isso, o WordPress 7.1.3 passou a aplicar absint() em três pontos do processo. Vale destacar que esse trecho vulnerável existe apenas desde a versão 6.5.0 e só é alcançado quando a exportação é feita por um único tipo de conteúdo — a opção padrão de exportação “Todo o conteúdo” não chega a acioná-lo.
Autores fixando posts como destaque
A API REST só recusava um pedido de destaque quando o usuário não possuía, ao mesmo tempo, as capacidades edit_others_posts e publish_posts. Como Autores já possuem a capacidade publish_posts, a verificação acabava sendo contornada. A correção simplesmente troca o operador && (e) pelo operador || (ou).
Exposição de comentários em posts privados
Nos feeds de comentários de posts individuais, o WP_Query carregava os comentários do post antes mesmo de verificar se o visitante tinha permissão para visualizá-lo. A checagem então limpava os dados do post, mas não os comentários já carregados — e, como feeds nunca retornam um erro 404, o conteúdo acabava sendo exibido de qualquer forma. A versão 7.1.3 corrige isso movendo a consulta de comentários para depois da verificação de visibilidade.
XSS via embeds do Imgur
O WordPress normalmente processa o HTML vindo de provedores de oEmbed não confiáveis através de um filtro que reduz o conteúdo a um iframe isolado (sandbox). Contudo, o Imgur estava na lista de provedores confiáveis, o que fazia esse filtro ser ignorado — assim, qualquer resposta vinda da API do Imgur era exibida diretamente na página. Como essa resposta inclui texto do próprio uploader da imagem ou álbum, qualquer conteúdo malicioso inserido ali chegava sem filtragem ao site. A correção remove o Imgur da lista de provedores confiáveis, de modo que URLs do Imgur deixam de ser incorporadas sem passar pelo filtro de segurança.
Embora o WordPress 7.1.3 corrija essa vulnerabilidade, ele não remove conteúdo de oEmbed já armazenado em cache (os metadados _oembed_* e os posts de oembed_cache), de forma que um embed malicioso já existente continua sendo renderizado. Por isso, é essencial limpar o cache do site logo após a atualização.
Colisão no nome do hook
O WordPress constrói parte dos nomes de suas ações a partir dos próprios dados do post. Quando um post muda de status, a função wp_transition_post_status() dispara a ação ${new_status}_{$post_type} — assim, publicar um post aciona publish_post. O problema é que ações completamente diferentes seguem esse mesmo padrão de nomenclatura: delete_post é disparada quando um post é excluído, e comment_post quando um comentário é adicionado. A versão 7.1.2 nunca verificava se o status e o tipo de post eram, de fato, registrados antes de montar esse nome. Dessa forma, um post salvo com o status “delete” e o tipo “post” acabava disparando a ação delete_post — a mesma de uma exclusão real — fazendo com que qualquer callback associado a ela rodasse como se um post tivesse sido efetivamente apagado. O WordPress 7.1.3 passa a disparar esses hooks apenas quando o status e o tipo de post estão devidamente registrados.
Linha do tempo e recomendação de atualização
Em 6 de outubro de 2026, o WordPress 7.1.3 foi lançado, com backports estendidos até as versões da série 6.6. Até o momento da publicação deste artigo, os ramos entre 4.7 e 6.5 ainda não haviam recebido as correções. Na mesma data, as vulnerabilidades divulgadas foram incluídas na base de dados da Patchstack.
A atualização para o WordPress 7.1.3 está disponível diretamente no Painel, na seção Atualizações, ou pelo site WordPress.org. Sites configurados com atualizações automáticas em segundo plano devem recebê-la sem necessidade de ação manual, já que essas correções foram replicadas para versões anteriores, pelo menos até a série 6.6.
Enquanto estiver no Painel para aplicar a atualização, vale aproveitar o momento para revisar quem possui contas de Colaborador ou com permissões superiores nos sites administrados. Afinal, boa parte das falhas corrigidas nesta versão está diretamente relacionada ao alcance que esses perfis de usuário têm dentro do sistema.
Com informações de patchstack.com.
