🚨 NOVA NOTÍCIA EM DESTAQUE! 🚨
A notícia que você procurava está aqui!
Apoie esse projeto de divulgacao de noticias! Clique aqui
O WordPress corrigiu uma falha de cross-site scripting (XSS) refletida na pré-autenticação em sua tela de login que afeta todas as versões do sistema de gerenciamento de conteúdo. pwn.ai demonstrou como a falha pode ser encadeada à execução de código PHP no servidor quando um administrador logado interage com uma página controlada pelo invasor.
Rastreada como CVE-2026-64638 (pontuação CVSS: 8,9), a vulnerabilidade de alta gravidade não requer privilégios de invasor. De acordo com pwn.ai, que descobriu a falha e compartilhou detalhes técnicos com o The Hacker News, o XSS da página de login não requer autenticação. Depois que um nome de usuário criado chega à página de erro de login com falha, o JavaScript resultante é executado no navegador do visitante sem necessidade de interação adicional nessa página.
O caminho de execução do código requer uma vítima já logada como Administrador e interação explícita com uma página controlada pelo invasor. Na demonstração do pwn.ai, essa interação é um clique comum.
Os pesquisadores disseram ao The Hacker News que o ataque funciona contra instalações padrão do WordPress e não requer hospedagem incomum ou configurações de implantação. Os pesquisadores disseram que têm vários caminhos do XSS para a execução do código, incluindo variantes que instalam um plugin ou carregam um ZIP arbitrário.
O próprio comunicado do WordPress tem uma visão mais cautelosa da explorabilidade, observando que o escalonamento para RCE envolve condições fora do controle do invasor e requer engenharia social bem-sucedida, além de interação explícita com a vítima.
O problema foi corrigido em 6 de agosto no WordPress 7.0.3, com correções suportadas pela versão 4.7. O WordPress recomenda a atualização imediata, e os sites que suportam atualizações automáticas em segundo plano devem receber a versão de segurança automaticamente. Versões anteriores a 4.7 permanecem afetadas, mas estão fora do intervalo de backport atual do projeto.
Os pesquisadores, que chamam a cadeia de ataque de XSS2Shell, disseram que seu sistema autônomo descobriu e reproduziu a cadeia de vulnerabilidade após receber a pesquisa 2022 Same Origin Method Execution (SOME) de Paulos Yibelo como ponto de partida.
A empresa disse que o trabalho durou quase quatro dias usando modelos de código aberto e um fluxo de trabalho multiagente. Ele disse que a cadeia foi reproduzida em 26 de julho e reportada ao WordPress no dia seguinte.
A falha começa na maneira como o WordPress lida com o nome de usuário de uma falha de login. Segundo os pesquisadores, o valor passa por sanitize_user() e wp_strip_all_tags(), que depende de strip_tags() do PHP. Uma string semelhante a uma tag contendo espaços em branco após a abertura < pode sobreviver a esse analisador como texto. Mais tarde, o WordPress passa o valor por wp_kses_post(), cujo analisador separado interpreta a mesma entrada que o HTML permitido. O resultado são elementos DOM ativos controlados pelo invasor na página de login com falha.
Esses elementos interagem com o user-profile.js do próprio WordPress, um script de gerenciamento de perfil que também é carregado na página de login porque a página lida com redefinições de senha.
Alguns elementos de perfil que o script espera estão ausentes: duas entradas ausentes são resolvidas como indefinidas, permitindo a aprovação de uma verificação de igualdade, enquanto a variável ajaxurl, de outra forma indefinida, pode ser substituída por um elemento DOM injetado. Isso direciona o próprio JavaScript do WordPress para uma solicitação REST de mesma origem selecionada pelo invasor.
Os pesquisadores usam o suporte REST JSONP do WordPress para transformar essa solicitação em JavaScript executado na origem do site. Para implantações em que solicitações REST anônimas retornam HTTP 401, o parâmetro _envelope=1 pode envolver a negação em uma resposta HTTP 200 externa, permitindo que o jQuery continue processando a resposta como script.
Os pesquisadores também descobriram em seus testes que uma política de segurança de conteúdo baseada em nonce usando estrito-dinâmico não bloqueou o caminho demonstrado.
O caminho do XSS para a execução do PHP baseia-se na técnica SOME anterior de Yibelo, que usa uma cadeia de propriedades JSONP permitida para invocar um método em outra janela do navegador.
Um caminho demonstrado por pwn.ai usa o XSS de origem WordPress para invocar o controle de aprovação de senha de aplicativo nativo dentro de uma sessão de administrador logado. O WordPress então cria uma credencial de API e a redireciona para um HTTPS success_url selecionado pelo invasor.
As senhas do aplicativo são credenciais revogáveis destinadas ao acesso à API. Portanto, esse caminho não precisa roubar a senha principal do administrador. Os pesquisadores usaram a credencial de acesso REST autenticado para publicar uma página WordPress contendo JavaScript da mesma origem. Quando a sessão do administrador retido abriu essa página, seu script obteve o plugin-upload nonce do WordPress e carregou um ZIP fornecido pelo invasor. O PHP poderia então ser solicitado diretamente do plugin extraído. O plugin não precisou ser ativado.
As evidências de produção fornecidas ao The Hacker News param no XSS. Os pesquisadores separadamente
Rastreada como CVE-2026-64638 (pontuação CVSS: 8,9), a vulnerabilidade de alta gravidade não requer privilégios de invasor. De acordo com pwn.ai, que descobriu a falha e compartilhou detalhes técnicos com o The Hacker News, o XSS da página de login não requer autenticação. Depois que um nome de usuário criado chega à página de erro de login com falha, o JavaScript resultante é executado no navegador do visitante sem necessidade de interação adicional nessa página.
O caminho de execução do código requer uma vítima já logada como Administrador e interação explícita com uma página controlada pelo invasor. Na demonstração do pwn.ai, essa interação é um clique comum.
Os pesquisadores disseram ao The Hacker News que o ataque funciona contra instalações padrão do WordPress e não requer hospedagem incomum ou configurações de implantação. Os pesquisadores disseram que têm vários caminhos do XSS para a execução do código, incluindo variantes que instalam um plugin ou carregam um ZIP arbitrário.
O próprio comunicado do WordPress tem uma visão mais cautelosa da explorabilidade, observando que o escalonamento para RCE envolve condições fora do controle do invasor e requer engenharia social bem-sucedida, além de interação explícita com a vítima.
O problema foi corrigido em 6 de agosto no WordPress 7.0.3, com correções suportadas pela versão 4.7. O WordPress recomenda a atualização imediata, e os sites que suportam atualizações automáticas em segundo plano devem receber a versão de segurança automaticamente. Versões anteriores a 4.7 permanecem afetadas, mas estão fora do intervalo de backport atual do projeto.
Os pesquisadores, que chamam a cadeia de ataque de XSS2Shell, disseram que seu sistema autônomo descobriu e reproduziu a cadeia de vulnerabilidade após receber a pesquisa 2022 Same Origin Method Execution (SOME) de Paulos Yibelo como ponto de partida.
A empresa disse que o trabalho durou quase quatro dias usando modelos de código aberto e um fluxo de trabalho multiagente. Ele disse que a cadeia foi reproduzida em 26 de julho e reportada ao WordPress no dia seguinte.
A falha começa na maneira como o WordPress lida com o nome de usuário de uma falha de login. Segundo os pesquisadores, o valor passa por sanitize_user() e wp_strip_all_tags(), que depende de strip_tags() do PHP. Uma string semelhante a uma tag contendo espaços em branco após a abertura < pode sobreviver a esse analisador como texto. Mais tarde, o WordPress passa o valor por wp_kses_post(), cujo analisador separado interpreta a mesma entrada que o HTML permitido. O resultado são elementos DOM ativos controlados pelo invasor na página de login com falha.
Esses elementos interagem com o user-profile.js do próprio WordPress, um script de gerenciamento de perfil que também é carregado na página de login porque a página lida com redefinições de senha.
Alguns elementos de perfil que o script espera estão ausentes: duas entradas ausentes são resolvidas como indefinidas, permitindo a aprovação de uma verificação de igualdade, enquanto a variável ajaxurl, de outra forma indefinida, pode ser substituída por um elemento DOM injetado. Isso direciona o próprio JavaScript do WordPress para uma solicitação REST de mesma origem selecionada pelo invasor.
Os pesquisadores usam o suporte REST JSONP do WordPress para transformar essa solicitação em JavaScript executado na origem do site. Para implantações em que solicitações REST anônimas retornam HTTP 401, o parâmetro _envelope=1 pode envolver a negação em uma resposta HTTP 200 externa, permitindo que o jQuery continue processando a resposta como script.
Os pesquisadores também descobriram em seus testes que uma política de segurança de conteúdo baseada em nonce usando estrito-dinâmico não bloqueou o caminho demonstrado.
O caminho do XSS para a execução do PHP baseia-se na técnica SOME anterior de Yibelo, que usa uma cadeia de propriedades JSONP permitida para invocar um método em outra janela do navegador.
Um caminho demonstrado por pwn.ai usa o XSS de origem WordPress para invocar o controle de aprovação de senha de aplicativo nativo dentro de uma sessão de administrador logado. O WordPress então cria uma credencial de API e a redireciona para um HTTPS success_url selecionado pelo invasor.
As senhas do aplicativo são credenciais revogáveis destinadas ao acesso à API. Portanto, esse caminho não precisa roubar a senha principal do administrador. Os pesquisadores usaram a credencial de acesso REST autenticado para publicar uma página WordPress contendo JavaScript da mesma origem. Quando a sessão do administrador retido abriu essa página, seu script obteve o plugin-upload nonce do WordPress e carregou um ZIP fornecido pelo invasor. O PHP poderia então ser solicitado diretamente do plugin extraído. O plugin não precisou ser ativado.
As evidências de produção fornecidas ao The Hacker News param no XSS. Os pesquisadores separadamente
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #novo #xss #de #préautenticação #do #wordpress #pode #levar #à #execução #de #código #php #– #patch #o #mais #rápido #possível
⚡ Fique ligado: novidades e promoções em breve por aqui! ⚡
Postar um comentário