Neste artigo do Blog Dolutech, vamos analisar em profundidade o lançamento do WordPress 7.1.1, publicado oficialmente em 17 de setembro de 2026. A atualização combina correções de manutenção com a resolução de 11 falhas de segurança que afetam diferentes componentes do núcleo da plataforma, incluindo processamento de conteúdo, API HTML, API REST, XML-RPC, temas, plugins, comentários e mecanismos de autorização.
Além das correções de segurança, o WordPress 7.1.1 inclui 17 ajustes no núcleo e 19 correções relacionadas ao Editor de Blocos, segundo o comunicado oficial publicado pela equipe do projeto. Por se tratar de uma versão de segurança, a orientação é que administradores atualizem seus sites imediatamente.
Outro ponto que chama atenção nesta versão é a participação direta de organizações que utilizam inteligência artificial na pesquisa de vulnerabilidades. A Anthropic foi creditada pela descoberta de duas falhas, enquanto a pwn.ai participou da identificação de outra vulnerabilidade corrigida na atualização.
Para a Dolutech, esse movimento confirma uma tendência que vem se tornando cada vez mais evidente nos últimos meses: a inteligência artificial está ampliando significativamente a capacidade de encontrar vulnerabilidades em softwares maduros, reduzindo o tempo e o custo necessários para analisar grandes bases de código.
WordPress 7.1.1: uma atualização de manutenção e segurança
O WordPress 7.1.1 é classificado oficialmente como uma atualização de ciclo curto, voltada principalmente para manutenção e segurança. A versão sucede o WordPress 7.1 e prepara o ecossistema para o próximo lançamento principal, o WordPress 7.2, atualmente planejado para dezembro de 2026.
O comunicado oficial apresenta os seguintes números:
| Categoria | Quantidade de correções |
|---|---|
| Falhas de segurança | 11 |
| Correções no núcleo | 17 |
| Correções no Editor de Blocos | 19 |
| Data de lançamento | 17 de setembro de 2026 |
| Próxima versão principal | WordPress 7.2 |
A equipe do WordPress recomenda atualização imediata de todas as instalações. Sites que possuem atualizações automáticas em segundo plano habilitadas devem iniciar o processo automaticamente, mas isso não elimina a necessidade de verificação manual.
Administradores não devem presumir que a atualização foi concluída com sucesso apenas porque a função automática está ativada. Problemas de permissão, limitações da hospedagem, falhas de conexão, falta de espaço em disco e personalizações do núcleo podem interromper o processo.
A versão instalada pode ser verificada diretamente no painel administrativo, na seção de atualizações, ou por meio do WP-CLI:
wp core versionPara atualizar o núcleo pela linha de comando:
wp core updateApós a atualização, também é recomendável verificar a integridade dos arquivos oficiais:
wp core verify-checksumsAs 11 falhas de segurança corrigidas no WordPress 7.1.1
O boletim oficial do WordPress apresenta 11 vulnerabilidades corrigidas. Até o momento da publicação deste artigo, o comunicado não atribuiu identificadores CVE individuais, pontuações CVSS ou classificações formais de severidade para cada problema.
Também não há, no anúncio oficial, confirmação de que essas vulnerabilidades estejam sendo exploradas ativamente. A ausência de exploração pública conhecida, entretanto, não deve ser interpretada como ausência de risco. A publicação de uma atualização permite que pesquisadores e agentes maliciosos comparem o código antigo com o código corrigido, processo conhecido como patch diffing, para localizar exatamente o que foi alterado.
A seguir, detalhamos cada uma das correções.
XSS armazenado no wpautop()
Uma das falhas de maior destaque está relacionada à função wpautop(), utilizada pelo WordPress para transformar automaticamente quebras de linha em parágrafos e elementos HTML.
Segundo o comunicado oficial, a vulnerabilidade poderia permitir que um visitante não autenticado injetasse um script no site. A exploração estaria condicionada à aprovação do comentário, o que adiciona uma barreira operacional, mas não elimina o risco.
Esse tipo de problema é classificado como Stored Cross-Site Scripting, também conhecido como XSS armazenado. Diferentemente do XSS refletido, o código malicioso pode permanecer gravado no banco de dados e ser executado quando um administrador, editor ou visitante acessa a página afetada.
Dependendo do contexto, um XSS armazenado pode resultar em roubo de sessão, redirecionamento para páginas falsas, modificação de conteúdo, execução de ações administrativas e comprometimento de contas privilegiadas.
A falha foi reportada por Rafie Muhammad, da Awesome Motive.
Falha na API HTML por sequências de fechamento abrupto
A segunda vulnerabilidade envolve a API HTML do WordPress, mais especificamente o método set_modifiable_text().
O problema permitia escapar do contexto de um comentário HTML por meio de sequências de fechamento abrupto especialmente construídas. Em termos práticos, uma interpretação incorreta da estrutura HTML poderia permitir que conteúdo originalmente tratado como comentário passasse a ser processado como parte ativa do documento.
Falhas de parsing são especialmente relevantes porque pequenas diferenças na forma como o servidor, o sanitizador e o navegador interpretam o mesmo conteúdo podem criar oportunidades para injeção de elementos não autorizados.
A vulnerabilidade foi identificada por Jeremy Felt, integrante da equipe de segurança do WordPress.
XSS armazenado em temas com cabeçalhos personalizados
O WordPress 7.1.1 também corrige uma vulnerabilidade de XSS armazenado presente em determinados temas que oferecem suporte a cabeçalhos personalizados.
Temas WordPress podem permitir que administradores selecionem imagens, textos e configurações para personalizar o cabeçalho do site. Quando os dados utilizados nesse processo não passam por validação e sanitização adequadas, existe o risco de conteúdo malicioso ser armazenado e posteriormente executado no navegador.
Embora a exploração possa depender das permissões disponíveis ao usuário, o impacto deve ser avaliado considerando ambientes com múltiplos administradores, editores, colaboradores externos ou contas comprometidas.
A falha também foi reportada por Jeremy Felt, da equipe de segurança do WordPress.
Instalação e visualização de tema por URL manipulada
Outra correção impede que URLs especialmente preparadas provoquem a instalação e a visualização automática de um tema inativo disponível no diretório oficial do WordPress.org.
A funcionalidade de instalação e pré visualização de temas envolve ações administrativas sensíveis. Um fluxo que possa ser acionado indevidamente por meio de um endereço manipulado cria risco de engenharia social e de execução de ações não intencionais por um administrador autenticado.
Mesmo quando o tema vem do repositório oficial, a instalação automática ou não autorizada altera o estado da aplicação e amplia a superfície de ataque. Também pode gerar incompatibilidades, modificações visuais inesperadas e exposição a vulnerabilidades existentes no componente instalado.
A falha foi reportada por Paulos Yibelo em conjunto com a pwn.ai, empresa especializada em pesquisa de segurança com inteligência artificial.
Ativação indevida de plugins exclusivos de rede
O WordPress Multisite possui regras específicas para plugins que devem ser utilizados exclusivamente em nível de rede. Esses componentes não deveriam seguir o mesmo fluxo de ativação dos plugins comuns de um site individual.
A atualização corrige uma situação na qual um administrador de site poderia ativar em toda a rede um plugin instalado e marcado como exclusivo para rede.
Em uma instalação Multisite, existe uma diferença importante entre o administrador de um site e o superadministrador da rede. Uma falha que permita ultrapassar essa separação pode afetar outros sites hospedados na mesma estrutura.
O problema foi reportado por Jesse McNeil.
Path traversal autenticado no controlador de templates da API REST
Uma das duas vulnerabilidades identificadas pela Anthropic é uma falha de path traversal autenticado no controlador de templates da API REST do WordPress.
Path traversal é uma categoria de vulnerabilidade em que uma aplicação processa caminhos de arquivos sem validar corretamente os diretórios que podem ser acessados. Dependendo da implementação, um atacante pode tentar sair do diretório esperado e alcançar arquivos ou locais internos do servidor.
O boletim do WordPress descreve a falha como autenticada, o que significa que uma conta válida seria necessária para iniciar a exploração. O comunicado, entretanto, não apresenta o nível mínimo de privilégio exigido, o alcance exato dos arquivos acessíveis ou uma classificação CVSS.
Por esse motivo, administradores devem evitar conclusões baseadas apenas na exigência de autenticação. Em sites com cadastro público, áreas de membros, lojas virtuais e plataformas educacionais, conseguir uma conta de baixo privilégio pode ser relativamente simples.
Bypass de permissão no XML-RPC
O WordPress 7.1.1 também corrige uma falha no XML-RPC que poderia ser usada para publicar conteúdos do tipo customize_changeset sem respeitar corretamente a verificação da capacidade edit_css.
O XML-RPC é um recurso tradicional do WordPress utilizado para comunicação remota, publicação de conteúdo e integração com aplicativos externos. Embora ainda seja necessário para determinadas ferramentas, ele também é frequentemente explorado em ataques de força bruta, abuso de autenticação e amplificação de requisições.
A falha corrigida permitia contornar uma verificação de permissão associada à edição de CSS e às mudanças realizadas pelo personalizador do WordPress.
O problema foi reportado por Ben Bidner, integrante da equipe de segurança do projeto.
Se o XML-RPC não for utilizado no ambiente, a Dolutech recomenda avaliar sua desativação ou restrição no servidor web, no WAF ou em uma ferramenta de segurança compatível. Antes de bloquear o recurso, é importante verificar integrações legítimas que possam depender do arquivo xmlrpc.php.
Sobrescrita arbitrária de publicações por colaboradores
A segunda vulnerabilidade reportada pela Anthropic permitia a sobrescrita arbitrária de publicações por usuários com perfil de colaborador ou superior.
O perfil Contributor, chamado de Colaborador na tradução do WordPress, possui permissões limitadas. Normalmente, esse usuário pode escrever e editar as próprias publicações, mas não pode publicar diretamente nem modificar livremente conteúdos de outros autores.
Uma falha capaz de ultrapassar essas limitações representa um problema de controle de acesso e autorização. Em sites com equipes editoriais, portais de notícias, blogs corporativos e ambientes com múltiplos autores, a vulnerabilidade poderia ser utilizada para alterar conteúdos fora do escopo autorizado.
O risco também precisa ser considerado em situações nas quais uma conta de colaborador tenha sido comprometida por reutilização de senha, phishing ou ausência de autenticação multifator.
Exposição do título de uma publicação privada
Outra correção resolve a ausência de uma verificação read_post na função attachment_submitbox_metadata().
A falha poderia expor o título de uma publicação privada relacionada a um anexo. Embora o conteúdo integral não fosse necessariamente disponibilizado, títulos podem conter informações confidenciais, nomes de projetos, clientes, produtos ainda não anunciados, documentos internos ou referências a processos empresariais.
Em segurança da informação, a exposição de metadados também deve ser tratada como um incidente relevante. Informações aparentemente pequenas podem ser combinadas com outros dados para apoiar ataques de engenharia social, espionagem corporativa ou reconhecimento de alvos.
A vulnerabilidade foi reportada pela HDWSec.
Divulgação de slugs de rascunhos e publicações pendentes
O WordPress 7.1.1 corrige ainda uma falha de autorização que poderia permitir a divulgação de slugs de publicações em rascunho ou aguardando revisão para usuários com perfil de colaborador ou superior.
O slug é a parte do endereço utilizada para identificar uma publicação. Apesar de não representar o conteúdo completo, ele pode revelar informações sobre materiais ainda não publicados, campanhas futuras, nomes de produtos, eventos, documentos internos ou estratégias de comunicação.
A exposição também pode ajudar um atacante a preparar campanhas de phishing altamente contextualizadas ou monitorar páginas antes do lançamento oficial.
A falha foi reportada por Jakub Herman.
Reassociação indevida de comentários e notas
A última vulnerabilidade listada no boletim permitia que qualquer usuário autenticado alterasse a associação de comentários, incluindo notas, vinculando esses registros a outro conteúdo.
Essa alteração, conhecida como reparenting, pode afetar a integridade das informações armazenadas no WordPress. Um comentário criado para uma publicação poderia ser associado a outro conteúdo sem que o usuário tivesse autorização suficiente para realizar essa operação.
Dependendo dos plugins instalados e da forma como comentários e notas são utilizados, o problema poderia causar manipulação de conteúdo, exposição de informações em locais incorretos, confusão em fluxos editoriais e comprometimento da rastreabilidade dos registros.
A falha foi reportada por Justin Hart, da Viridis Security.
Resumo técnico das vulnerabilidades
| Vulnerabilidade | Acesso necessário | Impacto principal |
|---|---|---|
XSS armazenado em wpautop() | Visitante, sujeito à aprovação de comentário | Execução de script persistente |
Falha em set_modifiable_text() | Não detalhado no boletim | Manipulação do contexto HTML |
| XSS em cabeçalhos personalizados | Não detalhado no boletim | Execução de script armazenado |
| Instalação de tema por URL manipulada | Interação ou contexto administrativo | Alteração indevida de tema |
| Ativação de plugin exclusivo de rede | Administrador de site | Violação de separação no Multisite |
| Path traversal na API REST | Usuário autenticado | Acesso indevido por caminhos manipulados |
| Bypass no XML-RPC | Não detalhado no boletim | Publicação sem a permissão edit_css |
| Sobrescrita de publicação | Colaborador ou superior | Modificação não autorizada de conteúdo |
| Exposição de título privado | Não detalhado no boletim | Vazamento de metadados |
| Divulgação de slug | Colaborador ou superior | Exposição de conteúdo não publicado |
| Reassociação de comentários | Qualquer usuário autenticado | Manipulação da integridade dos registros |
A tabela utiliza apenas as informações disponibilizadas no comunicado oficial. Como não foram publicados CVEs, vetores CVSS ou requisitos completos de exploração para todas as vulnerabilidades, não é tecnicamente responsável atribuir classificações críticas ou afirmar impactos que ainda não foram confirmados.
A inteligência artificial está deixando as vulnerabilidades mais evidentes
A presença da Anthropic e da pwn.ai nos créditos do WordPress 7.1.1 não é um detalhe isolado. Ela representa uma mudança estrutural na forma como vulnerabilidades são pesquisadas.
Durante muitos anos, a análise de segurança de grandes projetos dependia principalmente de auditorias manuais, ferramentas estáticas, fuzzing especializado e conhecimento acumulado por pesquisadores experientes. Esses métodos continuam sendo essenciais, mas agora estão sendo ampliados por modelos capazes de interpretar código, identificar fluxos complexos, correlacionar funções e sugerir cenários de abuso.
Nos últimos meses, falhas de segurança passaram a aparecer com muito mais frequência no debate público. Isso não significa necessariamente que todos os softwares tenham se tornado repentinamente mais vulneráveis. Em muitos casos, os problemas já estavam presentes havia anos, mas ainda não tinham sido encontrados.
A mudança está na capacidade de descoberta.
Modelos de inteligência artificial conseguem analisar grandes volumes de código em paralelo, revisar componentes legados, localizar inconsistências de autorização e identificar combinações de comportamentos que seriam difíceis de perceber em uma revisão convencional.
A HackerOne informou, em abril de 2026, que as submissões de vulnerabilidades em sua plataforma cresceram 76% em comparação com o ano anterior, atingindo um recorde em março. Aproximadamente 25% das descobertas foram confirmadas como exploráveis, enquanto a participação de falhas críticas e de alta severidade subiu para 32%.
Esses números ajudam a explicar por que organizações estão recebendo mais relatórios. Uma parte desse crescimento pode conter duplicações, falsos positivos e relatórios de baixa qualidade, mas o volume absoluto de vulnerabilidades reais também está aumentando.
IA na defesa e no ataque
A inteligência artificial possui aplicação de uso duplo. Pesquisadores legítimos podem utilizá-la para encontrar falhas, preparar correções, revisar patches e proteger projetos de código aberto. Ao mesmo tempo, grupos maliciosos podem usar tecnologias semelhantes para procurar versões desatualizadas, comparar atualizações, automatizar reconhecimento e reduzir o intervalo entre divulgação e exploração.
Esse cenário altera diretamente a gestão de vulnerabilidades.
No modelo tradicional, muitas organizações trabalhavam com janelas mensais de atualização. Um sistema poderia aguardar semanas até a próxima manutenção programada. Com a automação da descoberta e da análise de patches, esse processo se torna cada vez mais arriscado.
O intervalo entre a publicação de uma correção e o desenvolvimento de tentativas de exploração pode ser medido em horas. Isso exige inventário atualizado, monitoramento contínuo, priorização por risco e capacidade de aplicar patches rapidamente.
Para o ecossistema WordPress, o desafio é ainda maior. A plataforma está presente em uma parcela expressiva da internet e possui milhares de temas e plugins. Um invasor não precisa encontrar manualmente cada instalação vulnerável. Ferramentas automatizadas podem consultar milhões de domínios, identificar versões expostas e concentrar esforços nos alvos que ainda não foram corrigidos.
Recomendações da Dolutech
Nós da Dolutech recomendamos que administradores de sites WordPress adotem as seguintes medidas:
- Atualize o núcleo para o WordPress 7.1.1 imediatamente.
- Confirme manualmente se a atualização automática foi concluída.
- Faça um backup completo dos arquivos e do banco de dados antes de mudanças em produção.
- Atualize todos os plugins e temas instalados.
- Remova componentes inativos que não sejam mais necessários.
- Verifique a integridade do núcleo com o WP-CLI ou uma solução de segurança confiável.
- Revise usuários com perfil de Colaborador, Autor, Editor e Administrador.
- Revogue contas antigas, desconhecidas ou sem necessidade operacional.
- Implemente autenticação multifator para contas administrativas.
- Analise logs em busca de alterações suspeitas em posts, comentários, temas e plugins.
- Avalie a necessidade do XML-RPC e restrinja o recurso quando ele não for utilizado.
- Implemente um Web Application Firewall para reduzir a exposição a requisições maliciosas.
- Mantenha backups externos, criptografados e testados.
- Utilize um ambiente de homologação para validar compatibilidade, mas não transforme o processo de testes em justificativa para atrasar indefinidamente uma atualização de segurança.
O que fazer em caso de suspeita de comprometimento
A atualização impede a exploração futura das falhas corrigidas, mas não remove alterações maliciosas realizadas antes da instalação do patch.
Caso existam sinais de comprometimento, a Dolutech recomenda:
- Colocar o site em modo de manutenção ou restringir temporariamente o acesso.
- Preservar logs do servidor web, PHP, banco de dados, WAF e painel de hospedagem.
- Verificar contas administrativas criadas ou modificadas recentemente.
- Comparar os arquivos do núcleo com os checksums oficiais.
- Auditar plugins, temas e arquivos presentes em diretórios de upload.
- Restaurar um backup limpo quando a integridade do ambiente não puder ser garantida.
- Alterar senhas do WordPress, banco de dados, hospedagem, FTP, SFTP, SSH e painel de domínio.
- Regenerar as chaves e salts de segurança presentes no arquivo
wp-config.php. - Revogar todas as sessões autenticadas.
- Avaliar a necessidade de comunicação às autoridades e aos titulares de dados.
LGPD, GDPR e responsabilidade sobre incidentes
Uma vulnerabilidade no WordPress pode ultrapassar o impacto técnico e criar consequências regulatórias.
No Brasil, organizações que utilizam o WordPress para formulários, lojas virtuais, áreas de clientes, inscrições e armazenamento de dados pessoais estão sujeitas à Lei Geral de Proteção de Dados. Se uma exploração resultar em risco ou dano relevante aos titulares, a empresa deve avaliar as obrigações de comunicação previstas pela ANPD.
Na União Europeia, o GDPR exige análise e eventual comunicação de violações de dados pessoais. Organizações enquadradas na NIS2 também precisam considerar os requisitos de gestão de riscos e notificação de incidentes significativos. Instituições financeiras e fornecedores relacionados ainda podem estar sujeitos ao DORA.
A existência de uma vulnerabilidade não significa automaticamente que ocorreu uma violação de dados. Entretanto, ignorar uma atualização de segurança amplamente divulgada pode ser interpretado como falha nas medidas razoáveis de proteção, especialmente quando o patch estava disponível e a organização não possuía um processo adequado de gestão de vulnerabilidades.
Considerações finais da Dolutech
O WordPress 7.1.1 corrige 11 vulnerabilidades que atingem diferentes partes do núcleo, incluindo processamento HTML, temas, plugins, API REST, XML-RPC, publicações privadas e comentários. Embora o boletim oficial não tenha divulgado pontuações CVSS, identificadores CVE ou evidências de exploração ativa, a recomendação do próprio projeto é clara: todos os sites devem ser atualizados imediatamente.
A participação da Anthropic e da pwn.ai na descoberta de três falhas também confirma uma transformação importante na cibersegurança. A inteligência artificial está tornando vulnerabilidades antigas e complexas muito mais visíveis. Isso não significa apenas que existem mais falhas, mas que agora possuímos ferramentas capazes de encontrá-las em escala e velocidade muito maiores.
O mesmo avanço que ajuda defensores também pode beneficiar atacantes. A diferença estará na capacidade das organizações de identificar seus ativos, acompanhar boletins, testar atualizações e aplicar correções antes que as vulnerabilidades sejam incorporadas a campanhas automatizadas.
Para a Dolutech, a principal conclusão é objetiva: o ciclo tradicional de atualizar sistemas apenas quando surge um problema visível não acompanha mais a realidade atual. Segurança precisa ser contínua, monitorada e integrada ao funcionamento normal da organização.
Se você administra um ou vários sites WordPress, confirme agora a versão instalada, aplique o WordPress 7.1.1, revise seus usuários e verifique se todos os plugins e temas estão atualizados. Em um cenário no qual a inteligência artificial acelera tanto a descoberta quanto a exploração de vulnerabilidades, cada hora de exposição pode fazer diferença.
Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.