---
title: "WordPress corrige Click2Shell que podia abrir caminho para execução remota de código"
author: "Gustavo Ramos O. Klein"
date: "2026-09-23 10:00:00-03"
category: "Segurança & Privacidade"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/23/wordpress-corrige-click2shell-que-podia-abrir-caminho-para-execucao-remota-de-codigo/md"
---

## Resumo
- O WordPress lançou a versão 7.1.1 em 17 de setembro de 2026 para corrigir 11 vulnerabilidades, incluindo a Click2Shell.
- A falha permitia que um administrador autenticado instalasse automaticamente um tema do diretório oficial ao abrir um link malicioso.
- A cadeia combinava CSRF e injeção de seletor, podendo alcançar execução remota de código quando encontrava temas de terceiros vulneráveis.
- O ataque podia instalar e pré-visualizar temas inativos, sem depender da ativação permanente do tema malicioso.
- A correção usa $.escapeSelector() e restringe seletores a elementos reais da DOM para tratar o slug como texto literal.
- Há patches retroativos até a versão 4.7, e DISALLOW_FILE_MODS é citado como mitigação temporária.
- Administradores devem atualizar o núcleo, revisar temas de terceiros e investigar acessos feitos após links suspeitos.

---

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](https://www.securityweek.com/wordpress-patches-click2shell-vulnerability/), 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](https://patchstack.com/articles/click2shell-the-rce-wordpress-7-1-1-just-patched/), 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.