Segurança · WordPress

Atualização de segurança do WordPress 7.1.2: falha crítica afeta todas as versões desde o 4.7

O WordPress 7.1.2 corrige uma falha crítica sem autenticação presente em todas as versões desde o 4.7. Atualize agora — veja o que mudou.

Redação Amicatek22 Set 202611 min de leitura

A atualização de segurança do WordPress publicada em 17 de setembro de 2026 eliminou 11 vulnerabilidades de uma só vez. Pelo menos três foram descobertas por empresas que empregam inteligência artificial na busca por falhas. Isso não é apenas uma informação de bastidor: trata-se da transformação mais significativa enfrentada pelo ecossistema WordPress neste ano, com impacto direto no prazo que você pode esperar para instalar uma correção.

Na Amicatek, acompanhamos todos os ciclos de lançamento porque a manutenção faz parte dos serviços que oferecemos. O WordPress 7.1.1 se diferencia das versões anteriores tanto pela velocidade quanto pela origem das descobertas. Entender esse cenário é importante.

Atualização — 22 de setembro de 2026. Poucas horas depois da publicação original deste artigo, o WordPress lançou o 7.1.2, uma correção de emergência para uma falha crítica: execução remota de código sem autenticação, presente em todas as versões desde a 4.7. Se o seu site não está no 7.1.2, atualize agora. Os detalhes vêm na próxima seção; o restante do texto segue como publicado.

O 7.1.2 chegou cinco dias depois — e mudou a urgência

Em 22 de setembro, cinco dias após o 7.1.1, o projeto publicou o WordPress 7.1.2 para corrigir uma única falha, classificada como crítica: CVE-2026-87902, com CVSS 9.2.

O problema está em get_page_template(), no arquivo wp-includes/template.php. A função montava nomes de arquivos de template a partir da variável de consulta pagename sem validar o resultado. Isso permitia incluir qualquer arquivo PHP legível fora dos diretórios do tema ativo — uma inclusão local de arquivo (LFI), sem necessidade de autenticação.

Uma LFI, sozinha, não garante execução de código: é preciso que exista no servidor um arquivo .php legível que faça algo útil ao ser incluído. O caminho prático mais citado é o pearcmd.php, do PEAR, que se torna explorável quando o PHP está com register_argc_argv ligado — configuração padrão nas imagens Docker oficiais do PHP e em ambientes cPanel rodando PHP anterior ao 8.5. Nessas condições, a LFI vira execução remota de código.

A janela de exposição é o dado mais desconfortável: a falha afeta da versão 4.7.0 à 7.1.1 — quase uma década de releases. Foi reportada por Robert Ressl, por divulgação responsável, e corrigida com duas medidas: aplicar validate_file() ao ramo pagename_decoded, que estava desprotegido, e acrescentar uma verificação de contenção que obriga todo template resolvido a permanecer dentro dos diretórios de tema permitidos.

Vale registrar um ponto que corre na direção contrária à tese deste artigo: essa falha não foi encontrada por inteligência artificial. Um pesquisador humano a identificou, em um trecho de código que estava no núcleo desde 2016. É um lembrete de que a revisão manual continua produzindo os achados mais graves, e de que uma década de exposição não é exclusividade de nenhum método de descoberta.

Quais problemas foram resolvidos no WordPress 7.1.1

O WordPress 7.1.1 foi disponibilizado como uma atualização de manutenção e segurança. A versão reúne 17 ajustes no núcleo da plataforma, 19 correções no editor de blocos e 11 vulnerabilidades corrigidas, com a participação de mais de 90 colaboradores. As correções de segurança também foram levadas até a versão 4.7, embora somente a edição atual conte com suporte ativo.

Entre os problemas corrigidos, dois exigem atenção especial de quem administra sites de clientes.

Uma vulnerabilidade que funciona sem autenticação

A falha mais grave é um XSS armazenado na rotina wpautop() — CVE-2026-93485, com pontuação CVSS 7.1 — identificado por Rafie Muhammad. O ataque não depende de uma conta de usuário. Basta que um comentário aparentemente comum, contendo a carga maliciosa adequada, atravesse o processo de sanitização e seja executado quando a página for aberta por qualquer visitante.

A principal barreira é o sistema de moderação, que apresenta limitações quando permanece com a configuração padrão. O primeiro comentário de uma pessoa é enviado para análise; depois que uma publicação é aprovada, os comentários seguintes desse mesmo autor podem ser liberados automaticamente. Assim, um invasor pode começar com uma mensagem inofensiva, aguardar a aprovação e retornar posteriormente com o código malicioso.

Click2Shell: uma combinação de falhas que chega à execução remota

A segunda vulnerabilidade chama atenção pela forma como foi construída. Paulos Yibelo, da pwn.ai, encontrou uma falha de CSRF relacionada à instalação e à visualização prévia de temas. A Patchstack chamou a cadeia de exploração de Click2Shell.

O processo começa com um endereço especialmente preparado, capaz de instalar silenciosamente um tema disponível no WordPress.org. Em seguida, o tema é ativado pelo Customizer. A partir desse ponto, um manipulador AJAX sem proteção adequada pode permitir a execução de código no servidor.

A origem do problema está em uma diferença de tratamento entre as camadas da aplicação. O backend higieniza o slug do tema de determinada maneira, enquanto o JavaScript do frontend insere o mesmo conteúdo diretamente em uma string usada como seletor do jQuery, sem o devido tratamento. Isso permite a injeção de seletores.

A versão 7.1.1 corrigiu o problema limitando a busca a elementos .theme válidos e utilizando $.escapeSelector(). Dessa forma, o valor passa a ser interpretado como texto literal, e não como parte da estrutura do seletor.

Para que a exploração ocorra, um administrador autenticado precisa abrir o endereço preparado. Isso pode acontecer por meio de phishing direcionado ou pela utilização de um XSS que já esteja presente no site. Portanto, quando combinada com a primeira vulnerabilidade, essa ameaça deixa de ser apenas uma possibilidade teórica.

As outras nove correções tratam de problemas como path traversal no controlador REST de templates, substituição arbitrária de posts por usuários com a função de colaborador, exposição de títulos pertencentes a posts privados, alteração da hierarquia de comentários por qualquer usuário autenticado, contorno de permissões via XML-RPC e ativação de plugins em uma rede por administradores de sites no modo multisite. Em grande parte dos casos, algum nível de autenticação é necessário, inclusive com funções de baixa permissão, como a de colaborador.

A origem dos relatos também mudou — e isso tem consequências

É nesse ponto que a questão deixa de ser exclusivamente técnica e passa a afetar diretamente a operação.

A Anthropic identificou duas das 11 vulnerabilidades corrigidas no 7.1.1 — o path traversal na API REST e a substituição de posts por colaboradores. A terceira foi descoberta pela pwn.ai. De acordo com o The Repository, empresas de inteligência artificial aparecem nos créditos de todas as versões de segurança do WordPress lançadas desde julho de 2026. Antes disso, os lançamentos mencionaram a Sol Ultra, da OpenAI, e a Aikido Security.

Os números ajudam a explicar essa mudança. O mesmo levantamento informa que a quantidade de relatórios de segurança enviados ao WordPress pelo HackerOne passou de uma média histórica entre 20 e 30 por mês para 773 somente em agosto de 2026. Não se trata de um aumento momentâneo de interesse. O crescimento resulta diretamente da capacidade de modelos de IA analisarem grandes volumes de código e sugerirem cadeias de exploração plausíveis.

O projeto já começou a responder a esse novo cenário. Em 28 de agosto, a equipe de segurança apresentou a Core Security Initiative, estruturada em três linhas de atuação: automatizar mais etapas do processo de lançamento e ampliar os testes de ponta a ponta; realizar um esforço concentrado para eliminar o acúmulo de relatórios ainda abertos; e utilizar ferramentas de análise apoiadas por IA para encontrar vulnerabilidades antes que sejam exploradas. O programa de recompensa por bugs também teve seu escopo ajustado para acompanhar o aumento da demanda.

O que muda na sua rotina de atualização de segurança do WordPress

Para quem administra um único site WordPress ou uma estrutura com centenas de instalações, a atualização de segurança deixou de ser uma atividade reservada ao encerramento do mês. Quatro efeitos merecem destaque:

O período entre a divulgação da correção e o surgimento de ataques está menor. As mesmas ferramentas que localizam uma vulnerabilidade também conseguem examinar o changelog e as diferenças introduzidas pelo commit. Depois que a correção se torna pública, o caminho para identificar o problema também fica mais evidente. Por isso, o intervalo de duas semanas entre o lançamento e a instalação do patch, ainda adotado por muitas agências, passou a representar uma aposta arriscada.

As atualizações automáticas do núcleo se tornaram indispensáveis. Versões menores, como a passagem de 7.1 para 7.1.1, já são aplicadas automaticamente por padrão há bastante tempo. Ainda assim, muitas instalações desativaram esse recurso após experiências ruins com plugins incompatíveis. O equilíbrio mudou: atualmente, permanecer vulnerável por falta de atualização tende a oferecer mais risco do que instalar uma versão corretiva.

Contas com permissões reduzidas também representam uma porta de entrada. Diversas falhas do 7.1.1 dependem apenas da existência de um usuário autenticado, como colaborador ou autor, e em alguns casos de qualquer tipo de conta. Um site que mantém 40 acessos antigos de estagiários e freelancers possui 40 possíveis pontos de entrada. Revisar usuários é uma medida básica de segurança, não um procedimento meramente administrativo.

Agilidade exige um ambiente de validação. Atualizar rapidamente sem staging significa trocar o risco de permanecer vulnerável pelo risco de provocar uma indisponibilidade. A estratégia mais segura combina ambiente de homologação, backup automático anterior à atualização e um procedimento de reversão já testado, em vez de uma solução improvisada durante uma emergência.

Lista de verificação para concluir em 30 minutos

Se você quer transformar esta leitura em uma ação imediata:

Consulte a versão instalada em Painel → Atualizações. Caso o site ainda não esteja no 7.1.2, atualize agora — este item deixou de ser “hoje” e passou a ser “agora” com a falha crítica corrigida em 22 de setembro.
Ative as atualizações automáticas das versões menores do núcleo. No arquivo wp-config.php, utilize:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Examine as contas em Usuários → Todos os usuários. Exclua acessos sem uso e reduza as permissões de quem não precisa editar conteúdo.
Torne a moderação de comentários mais rigorosa. Em Configurações → Discussão, configure a aprovação manual para todas as publicações, e não apenas para o primeiro comentário de cada pessoa.
Se o site não depender do XML-RPC — o que ocorre na maioria dos casos — desative o recurso no servidor ou por meio de um plugin de segurança.
Confirme a data do último backup que foi restaurado com êxito. Uma cópia nunca submetida a um teste de restauração é apenas uma suposição, não uma garantia.
Repita a avaliação para plugins e temas, pois o núcleo representa somente uma parcela da superfície de ataque.

A inteligência artificial também pode atuar na proteção

É compreensível interpretar esse episódio apenas como uma notícia negativa, mas essa não é a história completa.

As três vulnerabilidades identificadas com auxílio de IA no WordPress 7.1.1 foram encaminhadas por meio de divulgação responsável e corrigidas antes de qualquer exploração conhecida. Além disso, a Core Security Initiative incorporou ferramentas de análise assistidas por inteligência artificial ao processo de segurança do projeto.

Até o momento, o resultado é um WordPress com menos falhas ocultas do que havia um ano atrás. O que mudou foi a rapidez com que esses problemas são descobertos e a disciplina necessária para manter sites atualizados e disponíveis.

É justamente essa mudança que orienta nosso trabalho. O WordPress continua sendo a plataforma mais adequada para a maioria dos projetos, mas administrá-lo em 2026 exige uma rotina bastante diferente daquela praticada em 2022.

Seu site já está no WordPress 7.1.2? Se você não consegue confirmar isso com convicção, essa própria incerteza já indica a resposta. A Amicatek faz o diagnóstico do seu site WordPress, avaliando versão instalada, exposição de usuários, situação dos backups e estratégia de atualização. Também assumimos a manutenção contínua para empresas que preferem evitar uma descoberta difícil no futuro.