No dia 17 de julho, ao divulgar um alerta de segurança sobre duas vulnerabilidades graves no núcleo do WordPress, a recomendação era clara: atualizar imediatamente. A orientação não era mera formalidade. Falhas críticas e não autenticadas em cadeias de pré-autenticação no core do WordPress costumam ser rapidamente convertidas em exploits a partir da própria correção publicada, sendo disparadas contra sites vulneráveis em toda a internet em poucas horas.
Foi exatamente isso que aconteceu. Nos dias seguintes à divulgação, um sistema de proteção especializado bloqueou mais de 65 mil tentativas de exploração dessas duas falhas, originadas de mais de 1.500 endereços IP distintos. É importante destacar que as regras de mitigação usadas só são ativadas em sites que efetivamente possuem as versões vulneráveis instaladas — e são removidas automaticamente após a correção. Isso significa que cada uma das tentativas registradas tinha como alvo sites ainda não corrigidos. Além disso, como essa camada de proteção atua dentro da própria aplicação, os ataques registrados já haviam passado por qualquer firewall de rede ou de servidor posicionado na frente desses sites.
Entendendo a vulnerabilidade
A falha não é um problema isolado, mas uma cadeia composta por duas vulnerabilidades distintas:
- CVE-2026-60137: uma injeção de SQL facilitada no WP_Query, através dos parâmetros author_exclude ou author__not_in, afetando as versões 6.8 a 7.0.1.
- CVE-2026-63030: uma confusão de rota/manipulador no endpoint de lote da REST API (/batch/v1), presente nas versões 6.9 a 7.0.1.
Isoladamente, nenhuma das duas falhas permite uma invasão completa de imediato. A injeção SQL é apenas de leitura, restrita a um contexto de SELECT, sem capacidade de gravação no banco de dados. Já a confusão no endpoint de lote não concede, por si só, uma sessão administrativa. O problema surge quando as duas são combinadas: a falha no endpoint de lote permite que uma requisição não autenticada contorne o esquema de validação que normalmente bloquearia a injeção SQL, abrindo caminho para a criação de um novo usuário administrador e, por fim, para execução remota de código.
As duas vulnerabilidades foram corrigidas nas versões 7.0.2, 6.9.5 e 6.8.6. Um ponto que gerou confusão na comunidade merece esclarecimento: versões mais antigas, como 6.1 e 6.2, não são afetadas. A verificação direta no código-fonte confirmou que o trecho vulnerável relacionado ao author__not_in foi introduzido na versão 6.8, e a falha no endpoint de lote surgiu na 6.9. Sites com versões anteriores a 6.8 que tenham sido comprometidos certamente foram atacados por outra via.
A corrida contra o tempo começou em 17 de julho
A correção foi incorporada ao repositório principal do WordPress cerca de uma hora e meia antes do lançamento oficial da versão 7.0.2. Esse commit já funcionava, na prática, como uma divulgação pública: qualquer pessoa acompanhando o desenvolvimento do núcleo poderia comparar as alterações e entender exatamente o que havia sido corrigido.
Essa é a janela de tempo que realmente importa. As primeiras tentativas concretas de exploração foram detectadas aproximadamente 90 minutos após o lançamento da versão 7.0.2 — ou seja, apenas três horas depois da correção ter sido registrada no código. Esse foi todo o tempo de reação disponível para os administradores de sites: um commit, uma comparação de código, e logo em seguida ataques já circulando, antes mesmo que muitos donos de sites tivessem lido as notas de lançamento.
Noventa minutos é um tempo extremamente curto, mas já não surpreende mais quem acompanha esse tipo de ameaça. É o retrato de uma exploração industrializada: alguém analisa o patch, outra pessoa transforma isso em uma ferramenta de varredura automatizada, e essa ferramenta é apontada contra toda a internet.
A escalada do ataque
Nos dias seguintes, o que se viu não foi uma operação coordenada e centralizada, mas uma verdadeira corrida generalizada de diversos atores agindo simultaneamente:
- Mais de 1.500 endereços IP de origem distintos.
- A rede mais ativa foi responsável por apenas 6,45% do tráfego total, e as dez redes mais ativas juntas somaram cerca de 22%.
A grande maioria do tráfego partiu de provedores de VPS e nuvem, como Vultr (Choopa), M247, HostPapa, além de uma longa lista de outras faixas de hospedagem. Esse perfil é típico dos primeiros dias após uma divulgação de alto impacto: pesquisadores validando a prova de conceito pública, varreduras automatizadas em escala global buscando versões vulneráveis, operadores oportunistas e operadores de redes de bots incorporando o novo exploit às ferramentas que já utilizavam.
Um detalhe importante sobre esses dados: eles representam tentativas bloqueadas, não invasões concluídas. Portanto, o fato de a maior parte do tráfego consistir em sondagens iniciais de injeção SQL não significa que a campanha tenha se limitado a reconhecimento. Significa apenas que essas requisições foram interceptadas no estágio mais inicial da cadeia de exploração já divulgada publicamente. Em um site sem proteção, essas mesmas requisições avançariam até a criação de um administrador e, na sequência, até a execução de código.
O padrão de tráfego identificado
Quase tudo passou pelo endpoint de lote
97% de todo o tráfego bloqueado tinha como alvo o endpoint REST de lote (batch). Os atacantes alternavam entre as duas formas de acessá-lo:
- /?rest_route=/batch/v1
- /wp-json/batch/v1
A forma com ?rest_route= foi a mais utilizada. Além disso, foram identificadas diversas variações claramente pensadas para escapar de filtros ingênuos de correspondência de caminho, como /index.php?rest_route=/batch/v1, /wp/?rest_route=/batch/v1, /blog/?rest_route=/batch/v1 e /wp-json?rest_route=/batch/v1.
Essa é justamente a metade da cadeia relacionada à confusão de rota (CVE-2026-63030), atuando como o veículo de entrega do ataque. Na maioria dos casos, a lógica maliciosa não era visível na requisição externa, estando escondida dentro de arrays de requisições aninhadas que só se revelam quando o corpo do lote é analisado de forma recursiva.
Injeções SQL com múltiplas camadas de ofuscação
Cerca de três quartos das requisições bloqueadas continham tentativas de injeção no parâmetro author_exclude. Os payloads utilizavam recursos comuns de evasão, como alternância entre letras maiúsculas e minúsculas, comentários inseridos no meio do código, comentários condicionais do MySQL e codificação de URL, com padrões como AND (1=1), AnD (1=1), and(1=1), AND/**/(1=1), /*!AND*/, OR SLEEP(5) e UNION SELECT.
Essa variedade não é acidental: os payloads mudam constantemente, o que faz com que assinaturas de detecção baseadas em uma única forma de escrita se tornem rapidamente obsoletas. Ainda assim, o comportamento por trás dos ataques mantém o mesmo padrão: uma requisição em lote, uma chamada ao endpoint REST vulnerável e um valor não numérico no parâmetro author_exclude, onde apenas números inteiros deveriam ser aceitos.
Dois perfis de ataque: sondagem e cadeia completa
Ao classificar o tráfego por intenção, dois grupos ficaram evidentes. O primeiro, e disparadamente o maior, correspondia a testes de validação da injeção SQL — sondagens booleanas e baseadas em tempo, como AND (1=1), AND (1=2) e OR SLEEP(5) — usadas para confirmar se um alvo era vulnerável antes de investir esforço adicional nele. Trata-se do comportamento padrão de ferramentas de varredura: identificar primeiro os alvos mais fáceis.
O segundo grupo era pequeno, porém muito mais preocupante. Um número reduzido de requisições já trazia a cadeia completa e publicada de escalonamento de privilégios, indo direto para a criação de um usuário administrador, sem se limitar a testar a vulnerabilidade. Essas requisições continham, dentro do corpo da requisição em lote, uma estrutura equivalente a uma chamada POST para o caminho /wp/v2/users, com corpo contendo nome de usuário, e-mail, senha e a definição do papel de administrador.
Essas requisições completas, com a cadeia de exploração inteira, partiram de apenas três endereços IP: 129.121.77.134, 91.202.233.61 e 125.164.233.50.
Em outras palavras, enquanto a maior parte da internet ainda testava a fechadura, um pequeno grupo de operadores já estava efetivamente atravessando a porta.
O risco real para quem ainda não atualizou
O impacto, em termos práticos, é significativo. O exploit publicado, que circula publicamente sob o nome de “wp2shell”, utiliza a injeção SQL de leitura para forjar dados que o próprio WordPress passa a processar, criando publicações e uma alteração no customizador que resultam na criação de uma nova conta de administrador. A partir do momento em que o atacante tem acesso de administrador, o restante do processo é trivial: efetuar login, enviar um plugin que na verdade é um webshell e executar código remotamente. A verificação independente confirmou que a combinação dessas vulnerabilidades leva à tomada completa do site, incluindo execução remota de código.
Diante desse cenário, a orientação permanece a mesma desde o início: sites que ainda utilizam versões vulneráveis do WordPress devem ser atualizados imediatamente para as versões corrigidas — 7.0.2, 6.9.5 ou 6.8.6 —, já que o intervalo entre a divulgação de uma falha e sua exploração em massa tem se mostrado cada vez mais curto.
