WordPress 7.1.4 corrige 22 falhas de segurança: o que fazer no site da sua empresa

A 28 de outubro de 2026, o WordPress publicou a versão 7.1.4, uma atualização de segurança que corrige 22 vulnerabilidades no núcleo da plataforma. A mais grave está no próprio mecanismo de atualização e pode levar à execução remota de código no servidor. A recomendação do projeto é direta: "atualize os seus sites imediatamente".

É a quarta versão de segurança do WordPress desde 17 de setembro, depois da 7.1.1, da 7.1.2, de 22 de setembro, e da 7.1.3, de 6 de outubro. Se a sua empresa tem o site, a loja ou o blogue em WordPress, explicamos o que foi corrigido, quem corre mais risco e o que fazer esta semana.

O que foi corrigido

Segundo a página oficial da versão 7.1.4, as 22 falhas estão descritas em 17 entradas. Em resumo:

• Uma condição de corrida durante as atualizações do núcleo, que "pode levar à execução remota de código". Foi comunicada pelo investigador Umut Bayram. É a falha mais séria da lista.
• Várias falhas de XSS armazenado (código malicioso guardado na base de dados, que depois corre no navegador de quem abre a página), nos blocos, no Personalizador e na Interactivity API. A maioria exige uma conta com o papel de Colaborador ou superior.
• Uma fuga de informação que deixava visitantes sem sessão iniciada ver alterações ainda não publicadas do Personalizador.
• Um problema de permissões que deixava funções personalizadas, com permissão para moderar comentários, ler, editar e apagar notas em artigos que não podem editar.
• Uma atualização dos certificados raiz incluídos no WordPress, por causa da revogação da autoridade de certificação eMudhra, um caso que já explicámos em «Chaves da eMudhra comprometidas».

Duas das falhas foram comunicadas pela Anthropic, a empresa de inteligência artificial que desenvolve o Claude.

Quão grave é?

O WordPress não atribuiu uma classificação de gravidade às falhas e, segundo a análise da Atlas Security, nenhuma tem ainda um identificador CVE. A Atlas classifica a versão como de gravidade alta, por causa da falha no processo de atualização, que não exige conta no site.

Há, no entanto, um pormenor importante. Essa falha só pode ser explorada nos segundos em que uma atualização está a decorrer. A Patchstack, empresa especializada em segurança WordPress citada pela Atlas, chama-lhe "impraticável de explorar na prática" e dá prioridade "baixa" às suas entradas para esta versão. As restantes falhas exigem, quase todas, que o atacante já tenha uma conta com permissões de escrita.

Não é motivo para pânico, mas também não é motivo para adiar. Em setembro, a Patchstack viu as primeiras tentativas de explorar a falha corrigida na 7.1.2 no próprio dia da correção, como contámos no artigo sobre a falha crítica de setembro. Segundo a Atlas, as correções da 7.1.4 estão públicas no repositório do WordPress desde a manhã de 28 de outubro. Em setembro, segundo a Patchstack, quem atacou a falha da 7.1.2 "estava a trabalhar a partir das diferenças" do código corrigido.

Que versões estão afetadas

Todas as versões anteriores à correção de cada ramo. O WordPress publicou correções para os ramos antigos até à série 4.7. A página oficial indica quantas das 22 falhas afetam cada um:

Ramo	Versão corrigida	Falhas que o afetam
7.1	7.1.4	22
7.0	7.0.8	22
6.9	6.9.11	22
6.8	6.8.12	20
6.7	6.7.11	20
6.6	6.6.11	19
6.4 e 6.5	6.4.14 e 6.5.14	17
4.7 a 6.3	4.7.39 a 6.3.14	2 a 9

O WordPress 4.6 e versões anteriores já não recebem atualizações de segurança. O projeto lembra ainda que só a versão mais recente é suportada ativamente e que as correções para ramos antigos são "uma cortesia". A próxima versão principal, a 7.2, está prevista para 8 de dezembro.

A Atlas detetou um atraso: ao fim da tarde de 28 de outubro, o serviço de atualizações do WordPress.org ainda não oferecia as correções dos ramos 6.5 e anteriores. Quem estiver nesses ramos deve confirmar no painel se a atualização já apareceu ou passar diretamente para a 7.1.4.

Que sites correm mais risco

As falhas de XSS só são um problema real quando há contas com permissões de escrita nas mãos de pessoas em quem não confia totalmente. Exemplos:

• sites com vários autores ou colaboradores externos;
• agências e freelancers com acessos antigos que nunca foram retirados;
• plugins de associados, cursos ou classificados que dão papéis de escrita a quem se regista;
• redes multisite.

Se um administrador abrir um conteúdo com código malicioso, esse código corre com a sessão do administrador. E, na maioria dos sites, um administrador pode instalar plugins. Por isso, uma falha que parece pequena pode acabar no controlo total do site.

O que fazer esta semana

1. Confirme a versão. No painel, em Painel → Atualizações, ou no rodapé da área de administração. Tem de ver 7.1.4, ou a versão corrigida do seu ramo.
2. Confirme que as atualizações automáticas funcionaram. O WordPress instala sozinho as versões de segurança, mas não em todos os casos. A Atlas lembra que as definições WP_AUTO_UPDATE_CORE, AUTOMATIC_UPDATER_DISABLED ou DISALLOW_FILE_MODS no wp-config.php desligam esse comportamento. O mesmo acontece em instalações geridas com Git ou Composer.
3. Proteja primeiro a pasta de atualizações. Para a falha da atualização, a Patchstack aconselha bloquear o acesso web à pasta wp-content/upgrade/ no servidor e garantir que o seu conteúdo não pode ser listado. Segundo os testes da Atlas, a própria atualização para a 7.1.4 ainda passa pelo código antigo, por isso vale a pena fazer o bloqueio antes de atualizar.
4. Reveja quem tem conta. Apague utilizadores que já não precisam de acesso e confirme que o papel atribuído a quem se regista é «Subscritor».
5. Atualize também o plugin Gutenberg, se o usar. Segundo a Atlas, as correções dos blocos chegam também na versão 24.3.0 do plugin.
6. Não se esqueça do PHP. Esta atualização não substitui as correções do PHP de 21 de outubro. Se ainda não tratou disso, leia «PHP2Shell: a falha crítica do PHP e o que fazer no seu site».

Antes de qualquer atualização, confirme que tem uma cópia de segurança recente e que sabe repô-la. Explicamos como em «Cópias de segurança: como saber se o site volta».

E se o site já tiver sido atacado?

Redirecionamentos estranhos, páginas que não criou ou utilizadores de administração novos são sinais de alerta. Se os encontrar, atualizar já não chega. Siga os passos de «O site foi pirateado: o que fazer nas primeiras horas».

A manutenção é o que evita o susto

Quatro versões de segurança em seis semanas mostram que um site em WordPress precisa de acompanhamento regular, não só no dia em que é lançado. Defendemos isso há anos em «WordPress seguro: a manutenção que evita o susto».

Para um primeiro diagnóstico, a auditoria gratuita da MarcaWeb analisa o site por fora, em menos de um minuto e sem registo, e mostra a nota de segurança dos cabeçalhos e do certificado HTTPS. Se preferir que tratemos da atualização, do bloqueio da pasta e da revisão de contas por si, fale connosco.