📰 Informação fresquinha chegando para você!
Não deixe essa passar: clique e saiba tudo!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Uma solicitação HTTP anônima pode executar código em um site WordPress. O bug está no núcleo, então uma instalação simples com zero plug-ins pode ser explorada.
Todos os sites 6.9 e 7.0 estavam ao alcance até sexta-feira, quando o WordPress lançou 6.9.5 e 7.0.2 e habilitou o que chama de atualizações forçadas por meio de seu sistema de atualização automática.
Adam Kues, da Assetnote, braço de gerenciamento de superfície de ataque da Searchlight Cyber, encontrou a falha e a relatou por meio do programa HackerOne do WordPress. O artigo, publicado sob o nome wp2shell, diz que o ataque “não tem pré-condições e pode ser explorado por um usuário anônimo”.
A empresa está aguardando os detalhes técnicos por enquanto e, em vez disso, colocou um verificador em wp2shell.com, para que os proprietários possam testar sua própria instância.
O WordPress lançou 6.9.5 e 7.0.2 em 17 de julho de 2026, fechando um RCE de pré-autenticação no núcleo que uma solicitação anônima pode acionar em uma instalação padrão sem plug-ins. Dois intervalos são afetados:
6.9.0 a 6.9.4, corrigido em 6.9.5
7.0.0 a 7.0.1, corrigido em 7.0.2
O WordPress não informou se o push forçado atinge sites que desativaram as atualizações automáticas. Verifique o que você está realmente executando, em vez de presumir que caiu.
7.1 beta2 traz a mesma correção. Os sites que ainda estão na versão 6.8 também têm uma atualização aguardando, mas a versão 6.8.6 é para o segundo bug de injeção de SQL na mesma rodada, relatado por uma equipe diferente.
A postagem do Searchlight estima que mais de 500 milhões de sites rodam WordPress. Esse número é a base instalada total, não a população vulnerável: o código defeituoso só existe a partir do 6.9 e o 6.9 foi enviado em 2 de dezembro de 2025. Portanto, cada site afetado está executando uma versão com menos de oito meses, e nenhum aviso diz quantos sites isso cobre.
O WordPress é mais aberto sobre a classe de bugs do que o pesquisador. Sua postagem de lançamento descreve a descoberta de Kues como “uma confusão de rota em lote da API REST e um problema de injeção de SQL que leva à execução remota de código”. O lançamento cobre uma falha crítica e outra de alta gravidade, e o WordPress não diz qual é qual.
A página da versão lista os três arquivos 7.0.2 tocados, cobrindo ambas as correções: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php e /wp-includes/rest-api.php. O endpoint do lote não é novo. O WordPress o envia desde 5.6 em novembro de 2020 e documentou o formato da solicitação publicamente desde então. Nada publicado até agora explica o que mudou no 6.9 para abri-lo.
Nenhum dos comunicados traz um ID CVE ou uma pontuação CVSS, e nenhum registro CVE apareceu até 18 de julho. Os scanners e inventários com chave CVE não sinalizarão este, e a CISA precisa de um CVE antes de poder adicionar qualquer coisa ao catálogo KEV. Rastreie-o pelo número da versão.
Se você não puder atualizar hoje
Cada mitigação que o Searchlight oferece se resume a manter os chamadores anônimos fora do endpoint do lote. Três opções, todas elas paliativas até você atualizar, e todas elas capazes de quebrar integrações legítimas:
Em um WAF, bloqueie /wp-json/batch/v1 e rest_route=/batch/v1. A empresa deixa explícito que ambos precisam ser eliminados, porque uma regra que cobre apenas o caminho /wp-json deixa a rota da string de consulta aberta.
Desative a API WP REST, que elimina o acesso REST não autenticado no atacado.
Um pequeno plugin drop-in que publica e rejeita solicitações anônimas /batch/v1 em rest_pre_dispatch.
Nenhuma tentativa de exploração foi relatada até 18 de julho. Sem CVE para marcar e sem assinatura pública correspondente, ninguém está realmente procurando ainda.
A exploração em massa do WordPress é uma indústria agora. Antes de seu servidor vazar em junho, apenas uma falha no plug-in de cache levou a equipe do WP-SHELLSTORM a mais de 17.000 sites, segundo suas próprias contas. Esse bug já era público, já corrigido e só funcionava em uma configuração não padrão.
Quando o Drupal corrigiu uma injeção SQL anônima em seu próprio núcleo em maio, o Searchlight transformou essa correção pública em uma desmontagem no mesmo dia com duas provas de conceito funcionais. Esse foi o bug e o patch de outra pessoa, e nada obriga a empresa a fazer o mesmo com a sua. Mas foi preciso um dia, e as pessoas que acertaram esse relógio são as que agora apostam que o silêncio dá tempo aos defensores.
O núcleo do WordPress é de código aberto, e 7.0.1 e 7.0.2 estão no arquivo de lançamento público, então a comparação está disponível para quem quiser. Esse é o limite para todo projeto de código aberto: você não pode enviar a correção sem enviar o mapa para o bug, e a única alavanca que resta é a rapidez com que o patch chega aos sites antes que alguém o leia.
O WordPress puxou essa alavanca na sexta-feira. O tráfego em lote/v1 será exibido quando os invasores chegarem, e as próprias estatísticas da versão do WordPress mostrarão se o patch chegou primeiro. Apenas um desses números chega a ser notícia.
Todos os sites 6.9 e 7.0 estavam ao alcance até sexta-feira, quando o WordPress lançou 6.9.5 e 7.0.2 e habilitou o que chama de atualizações forçadas por meio de seu sistema de atualização automática.
Adam Kues, da Assetnote, braço de gerenciamento de superfície de ataque da Searchlight Cyber, encontrou a falha e a relatou por meio do programa HackerOne do WordPress. O artigo, publicado sob o nome wp2shell, diz que o ataque “não tem pré-condições e pode ser explorado por um usuário anônimo”.
A empresa está aguardando os detalhes técnicos por enquanto e, em vez disso, colocou um verificador em wp2shell.com, para que os proprietários possam testar sua própria instância.
O WordPress lançou 6.9.5 e 7.0.2 em 17 de julho de 2026, fechando um RCE de pré-autenticação no núcleo que uma solicitação anônima pode acionar em uma instalação padrão sem plug-ins. Dois intervalos são afetados:
6.9.0 a 6.9.4, corrigido em 6.9.5
7.0.0 a 7.0.1, corrigido em 7.0.2
O WordPress não informou se o push forçado atinge sites que desativaram as atualizações automáticas. Verifique o que você está realmente executando, em vez de presumir que caiu.
7.1 beta2 traz a mesma correção. Os sites que ainda estão na versão 6.8 também têm uma atualização aguardando, mas a versão 6.8.6 é para o segundo bug de injeção de SQL na mesma rodada, relatado por uma equipe diferente.
A postagem do Searchlight estima que mais de 500 milhões de sites rodam WordPress. Esse número é a base instalada total, não a população vulnerável: o código defeituoso só existe a partir do 6.9 e o 6.9 foi enviado em 2 de dezembro de 2025. Portanto, cada site afetado está executando uma versão com menos de oito meses, e nenhum aviso diz quantos sites isso cobre.
O WordPress é mais aberto sobre a classe de bugs do que o pesquisador. Sua postagem de lançamento descreve a descoberta de Kues como “uma confusão de rota em lote da API REST e um problema de injeção de SQL que leva à execução remota de código”. O lançamento cobre uma falha crítica e outra de alta gravidade, e o WordPress não diz qual é qual.
A página da versão lista os três arquivos 7.0.2 tocados, cobrindo ambas as correções: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php e /wp-includes/rest-api.php. O endpoint do lote não é novo. O WordPress o envia desde 5.6 em novembro de 2020 e documentou o formato da solicitação publicamente desde então. Nada publicado até agora explica o que mudou no 6.9 para abri-lo.
Nenhum dos comunicados traz um ID CVE ou uma pontuação CVSS, e nenhum registro CVE apareceu até 18 de julho. Os scanners e inventários com chave CVE não sinalizarão este, e a CISA precisa de um CVE antes de poder adicionar qualquer coisa ao catálogo KEV. Rastreie-o pelo número da versão.
Se você não puder atualizar hoje
Cada mitigação que o Searchlight oferece se resume a manter os chamadores anônimos fora do endpoint do lote. Três opções, todas elas paliativas até você atualizar, e todas elas capazes de quebrar integrações legítimas:
Em um WAF, bloqueie /wp-json/batch/v1 e rest_route=/batch/v1. A empresa deixa explícito que ambos precisam ser eliminados, porque uma regra que cobre apenas o caminho /wp-json deixa a rota da string de consulta aberta.
Desative a API WP REST, que elimina o acesso REST não autenticado no atacado.
Um pequeno plugin drop-in que publica e rejeita solicitações anônimas /batch/v1 em rest_pre_dispatch.
Nenhuma tentativa de exploração foi relatada até 18 de julho. Sem CVE para marcar e sem assinatura pública correspondente, ninguém está realmente procurando ainda.
A exploração em massa do WordPress é uma indústria agora. Antes de seu servidor vazar em junho, apenas uma falha no plug-in de cache levou a equipe do WP-SHELLSTORM a mais de 17.000 sites, segundo suas próprias contas. Esse bug já era público, já corrigido e só funcionava em uma configuração não padrão.
Quando o Drupal corrigiu uma injeção SQL anônima em seu próprio núcleo em maio, o Searchlight transformou essa correção pública em uma desmontagem no mesmo dia com duas provas de conceito funcionais. Esse foi o bug e o patch de outra pessoa, e nada obriga a empresa a fazer o mesmo com a sua. Mas foi preciso um dia, e as pessoas que acertaram esse relógio são as que agora apostam que o silêncio dá tempo aos defensores.
O núcleo do WordPress é de código aberto, e 7.0.1 e 7.0.2 estão no arquivo de lançamento público, então a comparação está disponível para quem quiser. Esse é o limite para todo projeto de código aberto: você não pode enviar a correção sem enviar o mapa para o bug, e a única alavanca que resta é a rapidez com que o patch chega aos sites antes que alguém o leia.
O WordPress puxou essa alavanca na sexta-feira. O tráfego em lote/v1 será exibido quando os invasores chegarem, e as próprias estatísticas da versão do WordPress mostrarão se o patch chegou primeiro. Apenas um desses números chega a ser notícia.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #nova #falha #principal #do #wordpress #wp2shell #permite #que #invasores #não #autenticados #executem #código
🎉 Obrigado por acompanhar, até a próxima notícia!
Postar um comentário