O WordPress 7.0.2, lançado em 17 de julho de 2026, corrige duas vulnerabilidades críticas do núcleo que, combinadas, permitem execução remota de código sem login em instalações desatualizadas das séries 6.8, 6.9 e 7.0. A correção deve ser aplicada imediatamente através do painel administrativo ou por linha de comando.
O WordPress 7.0.2 corrige duas falhas de segurança que, combinadas, permitem a um invasor executar código remotamente em um site sem precisar de login. A atualização foi liberada em 17 de julho de 2026 e classificada como crítica, então quem administra um blog em WordPress precisa atualizar o quanto antes.
Recebi o alerta dessa atualização no mesmo dia em que ela foi publicada, porque acompanho de perto os canais de segurança do WordPress desde que comecei a cuidar dos meus próprios blogs, lá em 2018. E olha, poucas vezes vi o time do WordPress.org tratar um lançamento com esse nível de urgência.
Normalmente uma atualização de versão menor passa despercebida. Você recebe o aviso no painel, agenda para depois e segue a vida. Com o WordPress 7.0.2 não foi assim. O próprio WordPress.org ativou atualização automática forçada para os sites afetados, algo que só acontece quando o risco é sério de verdade.
Neste artigo eu explico o que mudou na prática, quais versões estão vulneráveis, como aplicar a correção sem dor de cabeça e o que fazer se você não puder atualizar imediatamente.
O que mudou na versão 7.0.2 do WordPress
A atualização corrige duas vulnerabilidades no núcleo do WordPress. A primeira é uma falha de injeção SQL facilitada, catalogada como CVE-2026-60137. A segunda é um problema de confusão de rota em um endpoint de lote da REST API, catalogado como CVE-2026-63030.
Isoladamente, cada uma dessas falhas já seria motivo para atualizar. O problema fica sério mesmo quando elas são combinadas. Um invasor consegue usar a confusão de rota da REST API para alcançar o parâmetro vulnerável à injeção SQL, e a partir daí executar código no servidor. Pesquisadores batizaram essa cadeia de ataque de wp2shell.
O detalhe que mais chama atenção é que o ataque não exige login, não depende de plugins instalados e funciona em uma instalação padrão do WordPress. Basta uma requisição HTTP anônima bem construída.
A falha de injeção SQL foi reportada de forma responsável por um grupo identificado como TF1T, dtro e haongo. Já a cadeia completa, que leva à execução remota de código, foi descoberta por Adam Kues, da Assetnote, e comunicada através do programa da HackerOne mantido pelo WordPress.
Quais versões do WordPress estão vulneráveis
A injeção SQL isolada afeta as versões 6.8.0 até 6.8.5, 6.9.0 até 6.9.4 e 7.0.0 até 7.0.1. Já a parte que transforma o problema em execução remota de código, a confusão de rota na REST API, afeta apenas as versões 6.9.0 até 6.9.4 e 7.0.0 até 7.0.1. A versão 6.8 não é atingida por essa segunda metade da cadeia.
Isso significa que sites na série 6.8 correm um risco menor, restrito à injeção SQL. Já quem está nas séries 6.9 e 7.0 sem atualizar fica exposto ao ataque completo, incluindo a execução de código no servidor.
O WordPress corrigiu o problema em três frentes ao mesmo tempo: a versão 7.0.2, a versão 6.9.5 e a versão 6.8.6. Se o seu site está em qualquer uma dessas séries, existe uma correção disponível especificamente para ela, sem precisar migrar para a versão mais recente.
Se inscreva em nosso canal do YouTube agora
Vídeos sobre blogs, SEO e monetização direto no seu feed — sem precisar entrar em nenhum grupo.
- Conteúdo em vídeo, mais fácil de acompanhar no seu tempo livre.
- Estratégias e testes que eu não publico no blog.
- Vídeos novos direto na sua central de inscrições.
100% gratuito • Sem spam • Só conteúdo, sem enrolação
Assim como aconteceu em outras atualizações estruturais do WordPress, vale entender o contexto da própria série 7.0, que trouxe mudanças relevantes de dashboard e ferramentas de IA. Eu detalhei essas mudanças no artigo sobre WordPress 7.0: Tudo sobre as Novas Atualizações, que ajuda a entender por que essa versão específica ganhou tanta atenção do time de segurança.
Por que a atualização foi forçada em tantos sites
Normalmente, atualizações do WordPress ficam disponíveis no painel e o administrador decide quando aplicar. Para o 7.0.2, o time de segurança tomou uma decisão diferente e ativou o sistema de atualização automática forçada para instalações afetadas, mesmo em sites que normalmente têm essa função desligada.
Um erro que cometi no início da minha jornada com WordPress foi desligar as atualizações automáticas de segurança por medo de quebrar algo no tema ou em um plugin. Hoje eu penso completamente diferente. Deixar essas atualizações ligadas é justamente o que evita que um site fique exposto por dias enquanto o administrador nem percebeu o aviso.
Nesse caso específico, a decisão de forçar a atualização fez sentido. Pouco tempo depois do lançamento do patch, código de exploração já estava circulando publicamente, e relatos de exploração ativa começaram a aparecer. Quando isso acontece, cada hora sem atualizar aumenta o risco real, não hipotético.
Como atualizar seu WordPress agora para o WordPress 7.0.2
O caminho mais simples é entrar no painel administrativo, abrir o menu Atualizações e clicar em Atualizar Agora, caso o sistema ainda não tenha aplicado a correção sozinho. Depois de concluir, confira se a versão exibida no rodapé do painel corresponde a 7.0.2, 6.9.5 ou 6.8.6, dependendo da série que você usa.
Quem administra o site via linha de comando pode rodar o processo de atualização pelo WP-CLI e confirmar a versão instalada em seguida com o comando de verificação de versão do núcleo. É o método que eu prefiro nos meus próprios projetos, porque permite atualizar vários sites em sequência sem depender da interface gráfica.
Minha dica aqui é sempre fazer um backup completo antes de qualquer atualização de núcleo, mesmo quando ela é urgente. Em mais de 500 artigos publicados sobre WordPress e monetização, um dos temas que mais recebo dúvida é justamente sobre o que fazer quando uma atualização quebra algum plugin. Ter um backup recente resolve praticamente qualquer cenário de problema.
Se você administra blogs de terceiros, como muitos afiliados e produtores de conteúdo fazem, essa é também a hora de revisar rapidamente cada site sob sua responsabilidade. Um detalhe que costuma passar despercebido é que sites esquecidos, com pouco tráfego, acabam sendo os últimos a receber atenção, e são justamente esses os alvos preferidos de varreduras automatizadas.
O que fazer se não for possível atualizar de imediato
Em alguns casos, hospedagens compartilhadas mais antigas ou ambientes de homologação impedem uma atualização instantânea. Se esse for o seu caso, existe uma medida temporária: bloquear o acesso à rota de lote da REST API, o endpoint conhecido como batch, diretamente no firewall de aplicação web ou nas regras do servidor.
Essa medida não substitui a atualização. Ela apenas reduz a janela de exposição enquanto você organiza o processo de teste em um ambiente de homologação antes de aplicar em produção. Já testei esse tipo de bloqueio temporário em situações parecidas no passado, e funciona como uma barreira extra, nunca como solução definitiva.
Segundo uma análise recente sobre segurança do núcleo do WordPress, a grande maioria das vulnerabilidades reportadas no ecossistema vem de plugins de terceiros, e apenas uma fração mínima se origina do próprio núcleo, o que reforça o quanto esse tipo de falha crítica direto no core é pouco comum na prática. Isso não diminui a gravidade do 7.0.2, mas ajuda a entender por que o time de segurança tratou o caso com tanta urgência.
O impacto real para quem vive de blog e conteúdo
Para quem sobrevive de anúncios, afiliados e cursos, como é o meu caso desde que comecei a monetizar blogs com Google AdSense, um site comprometido não é apenas um problema técnico. É queda de posição no Google, perda de confiança do leitor e, em casos mais graves, suspensão de conta em programas de monetização por conteúdo malicioso injetado por invasores.
Quando comecei a aplicar rotinas de segurança mais rígidas no meu próprio blog, percebi uma coisa que pouca gente comenta: manter o WordPress atualizado tem impacto direto até na velocidade de carregamento e na estabilidade do site, porque versões desatualizadas acumulam código legado que nem sempre está otimizado. Segurança e desempenho caminham juntos mais do que parece.
Boa parte do que ensino sobre estrutura de blog, monetização e presença digital sustentável está organizada na formação Império dos Blogs, onde trato justamente de como blindar um projeto para que ele sobreviva a esse tipo de imprevisto sem comprometer o faturamento nem a reputação construída ao longo dos anos.
Outro ponto que costuma surpreender iniciantes é que sites com poucas visitas também são alvo. Ataques automatizados não escolhem só sites grandes, eles varrem a internet inteira em busca de instalações desatualizadas, independentemente do volume de tráfego. Pode parecer óbvio, mas muita gente ainda acredita que “meu blog é pequeno, ninguém vai me atacar”, e essa é exatamente a mentalidade que deixa portas abertas.
Manter a documentação do site organizada também ajuda nesses momentos de resposta rápida a incidentes. Eu recomendo revisar periodicamente páginas essenciais, como a política de privacidade e os termos de uso, para garantir que estejam alinhadas com as práticas reais de segurança do site. Se você ainda não tem essas páginas estruturadas, o prompt de IA para criar política de privacidade, termos de uso e páginas essenciais do blog facilita bastante esse processo.
Sinais de que seu site pode ter sido comprometido antes da atualização
Se o seu WordPress ficou rodando uma versão vulnerável por vários dias depois do lançamento do 7.0.2, vale conferir alguns sinais de comprometimento antes de simplesmente aplicar o patch e seguir em frente. Usuários administradores desconhecidos criados sem sua autorização são o alerta mais claro.
Outros sinais incluem arquivos modificados recentemente na pasta de temas ou plugins sem que você tenha feito alterações, redirecionamentos estranhos para visitantes vindos do Google e queda repentina de desempenho sem motivo aparente. Qualquer um desses pontos justifica uma varredura completa de malware antes de considerar o site limpo.
O que eu faço no meu blog nessas situações é comparar os arquivos do núcleo com uma cópia limpa da mesma versão do WordPress, procurando diferenças que não deveriam existir. É um processo simples, mas que revela boa parte das tentativas de invasão que passam despercebidas em uma checagem superficial.
Conclusão
O WordPress 7.0.2 corrige uma cadeia de vulnerabilidades que, juntas, permitiam a execução remota de código sem autenticação em instalações desatualizadas das séries 6.8, 6.9 e 7.0. A gravidade do problema levou o próprio WordPress.org a forçar a atualização automática em sites afetados, algo raro dentro do ecossistema.
Se você ainda não conferiu a versão do seu site, essa é a prioridade do dia. O processo leva poucos minutos pelo painel administrativo ou por linha de comando, e o backup prévio garante que qualquer imprevisto seja revertido com facilidade.
Manter o núcleo, os plugins e o tema sempre atualizados continua sendo a base de qualquer estratégia sólida de blog, seja ele voltado para AdSense, afiliados ou cursos próprios. Falhas como essa aparecem de tempos em tempos, e a diferença entre um site protegido e um site comprometido costuma estar simplesmente em quem atualizou a tempo.
Olá, me chamo Kildary Oliver e sou especialista em criação de blogs em WordPress e monetização com Google AdSense desde 2018. Já ajudei mais de 300 blogs de alunos a serem aprovados no AdSense e hoje reúno mais de 27 mil inscritos no meu canal do YouTube e mais de 10 mil alunos nos meus cursos. Acompanho de perto as mudanças do Google e do SEO, com formação recente em GEO e Agentes de IA aplicados a conteúdo.
