Em 17 de setembro de 2026, o WordPress publicou a versão 7.1.1 para corrigir 11 vulnerabilidades, entre elas a Click2Shell, uma falha que podia transformar um clique induzido em uma cadeia capaz de chegar à execução remota de código. O problema merece atenção porque começava fora do painel: um administrador autenticado podia abrir um link malicioso e, sem outra intervenção, instalar um tema do diretório oficial. Neste artigo, vamos desbugar o caminho entre o clique, a instalação e o risco para o servidor, além de separar o que a atualização resolve do que ainda depende de temas de terceiros. A pergunta prática é direta: seu site está protegido apenas porque o tema ativo parece confiável?

Como um link chegava ao painel

A porta de entrada era um link malicioso aberto no navegador de um administrador logado. De acordo com a SecurityWeek, esse clique podia acionar automaticamente a instalação de um tema disponível no diretório oficial do WordPress, sem que o usuário precisasse confirmar uma etapa adicional. Na prática, o navegador funcionava como uma ponte entre a página externa e a sessão já autenticada no painel, levando o sistema a interpretar uma ação de instalação como se tivesse sido solicitada pelo próprio administrador. É justamente essa combinação entre confiança na sessão e interação aparentemente banal que transforma o clique em um ponto de entrada relevante.

O aspecto mais perigoso está no fato de que a exposição não podia ser avaliada apenas olhando para o tema atualmente ativo. A instalação e a pré-visualização de um tema inativo também fazem parte da cadeia descrita pelas fontes, portanto a ausência de ativação permanente não elimina a necessidade de investigação. A descoberta foi atribuída à equipe pwn.ai, que recebeu a recompensa máxima de $300 oferecida pelo WordPress para o relatório. O detalhe ajuda a entender a natureza do problema: a falha estava na forma como o painel processava a interação, e não apenas no conteúdo visual que o visitante via no site.

Quando uma instalação vira execução de código

Para entender a escalada, é preciso olhar para a combinação descrita como CSRF, sigla para falsificação de requisição entre sites, e injeção de seletor. O CSRF permite que uma ação seja disparada no contexto de uma sessão autenticada quando o administrador interage com uma página preparada para isso. Já a injeção de seletor interfere no texto usado para localizar elementos da interface, fazendo com que uma entrada deixe de ser tratada somente como um identificador e passe a influenciar a consulta realizada pelo navegador. Em uma analogia simples, o primeiro mecanismo abre a porta usando a credencial existente, enquanto o segundo tenta alterar as instruções entregues ao painel depois que a porta foi aberta.

Essa ponte podia alcançar o servidor quando o tema instalado era combinado com um componente vulnerável de terceiros. O segundo estágio utilizava handlers AJAX, rotinas que recebem solicitações do navegador sem exigir o recarregamento completo da página, e podia forçar o carregamento de um payload PHP, ou seja, do código preparado para executar no ambiente do WordPress. Segundo a descrição da pesquisa, essa cadeia poderia permitir comandos arbitrários no servidor e evoluir para RCE, sigla em inglês para execução remota de código. Por isso, corrigir o núcleo interrompe a parte inicial do caminho, mas a revisão dos temas que possuem esses handlers continua necessária para fechar a ponte inteira.

O que a atualização 7.1.1 mudou

A correção central foi aplicada no arquivo wp-admin/js/theme.js, responsável pela lógica relacionada à interface de temas. Conforme o Patchstack, a versão 7.1.1 passou a limitar o seletor a elementos reais da DOM, a estrutura de elementos que forma a página no navegador, e adotou a função $.escapeSelector(). O objetivo é tratar o slug do tema, que funciona como seu identificador textual, como texto literal, impedindo que caracteres inseridos nele sejam interpretados como instruções de seleção. Em termos práticos, a atualização tenta garantir que o painel leia o nome recebido como dado, e não como uma ordem para procurar ou manipular elementos indevidos.

Essa alteração foi registrada no changeset 63664, conjunto de mudanças no código associado à versão 7.1.1. A correção não ficou restrita à edição mais recente: o WordPress disponibilizou patches retroativos desde a versão 4.7 até a versão atual, ampliando o alcance da medida para instalações que não acompanham cada lançamento imediatamente. Isso muda a decisão operacional do administrador, porque sites antigos também entram na fila de atualização e não devem ser considerados protegidos apenas por estarem fora da versão mais nova. A existência de uma correção para várias gerações do software permite tratar a atualização como uma tarefa de manutenção, não como uma escolha limitada a instalações recém-criadas.

A atualização não encerra a revisão de segurança

Para administradores, o primeiro passo é atualizar o núcleo do WordPress para a versão 7.1.1 ou para uma versão corrigida compatível com a sua instalação. Como medida temporária, as recomendações também citam o uso de DISALLOW_FILE_MODS, uma configuração apresentada pelas fontes como forma de mitigação enquanto a atualização e a análise do ambiente não são concluídas. Essa ação deve ser avaliada junto com a rotina de manutenção do site, porque a Click2Shell envolve a capacidade de instalar temas a partir do painel e o risco não termina na aparência da página inicial. A sequência mais segura é aplicar o patch, verificar o comportamento do painel e então revisar os componentes que recebem solicitações AJAX.

Também é preciso olhar além do tema ativo e investigar os temas instalados ou pré-visualizados durante o período de exposição. As fontes alertam que o administrador não deve avaliar o risco somente pela aparência do site, já que o ataque instala e visualiza temas inativos antes de avançar para a segunda etapa. Se uma conta administrativa acessou um link suspeito, a recomendação é realizar uma revisão de segurança no site, incluindo a análise dos temas de terceiros que possam conter handlers vulneráveis. A ausência de ativação permanente do tema malicioso não deve ser usada como prova de que nada aconteceu, porque a cadeia podia produzir efeitos durante a própria instalação ou pré-visualização.

O próximo passo para quem administra um site

A caixa de ferramentas começa pela atualização imediata do WordPress, passa pela verificação de temas de terceiros e inclui a análise de acessos administrativos que ocorreram depois de cliques em links suspeitos. Se o site estiver em uma versão antiga, o administrador deve procurar o patch correspondente, já que existem correções retroativas até a versão 4.7. Em paralelo, a configuração DISALLOW_FILE_MODS pode ser considerada como mitigação temporária, conforme a orientação publicada nas fontes. O ponto central é tratar a atualização como o fechamento da primeira porta, enquanto a revisão dos handlers verifica se existe outra passagem capaz de levar ao servidor.

Depois da versão 7.1.1, a entrada usada pela Click2Shell passa a contar com seletores restringidos a elementos reais da página e com o slug tratado como texto literal. Ainda assim, a proteção completa depende da atualização dos temas de terceiros que possam conter handlers AJAX vulneráveis, além da investigação de sites administrados por pessoas que acessaram links suspeitos. O próximo passo, portanto, é concreto: atualizar, revisar temas ativos e inativos e verificar os registros e componentes envolvidos antes de considerar o incidente encerrado. Quando cada camada é conferida, a ponte criada pelo clique deixa de conectar automaticamente a sessão do administrador ao código executado no servidor.