O administrador só precisa abrir o link. O resto o WordPress faz sozinho

Há uma pergunta que decide a urgência desse caso, e ela não é sobre a nota de gravidade. É sobre quem precisa fazer o quê para o ataque funcionar.

O atacante não precisa de conta no site. Não precisa de nonce de instalação, não precisa de privilégio administrativo próprio e não precisa que o site tenha plugin vulnerável instalado. O que ele precisa é que uma pessoa com sessão de administrador aberta abra uma URL preparada. Isso é tudo.

Essa característica reposiciona a falha. Ela sai da categoria "exposição de borda" — em que o controle é fechar porta, restringir origem e esperar a janela de manutenção — e entra na categoria "superfície humana", em que o controle é o comportamento de uma pessoa específica, em um momento específico, com uma aba aberta.

O tema não precisa estar ativo, e é aí que dói

A parte contraintuitiva do encadeamento é a segunda metade. Instalar um tema no WordPress sem ativá-lo é normalmente tratado como operação sem consequência: o código fica no disco, não roda. A pré-visualização do Customizer quebra essa premissa. Para mostrar como o site ficaria com outro tema, o WordPress carrega o PHP daquele tema no contexto do servidor. Um tema vulnerável do catálogo oficial, escolhido pelo atacante, executa o que ele quiser nesse momento.

Yibelo demonstrou o encadeamento com um tema específico, mas a falha do núcleo permite forçar a instalação de qualquer outro tema vulnerável do catálogo. A lista de candidatos não é fixa, e é exatamente por isso que a correção do núcleo importa mais do que remover um tema da lista de temas instalados.

O que acontece depois da execução é conhecido: leitura e alteração de arquivo, acesso ao wp-config.php — que guarda credencial de banco e os segredos de autenticação —, criação de conta administrativa nova e injeção de script nas páginas servidas aos visitantes. Nenhuma dessas etapas exige criatividade.

O que a correção fez

Data	Evento
22/08/2026	Reporte ao WordPress por Paulos Yibelo, da pwn.ai.
Semana de 14/09/2026	Liberação da versão 7.1.1, que escapa o slug do tema antes de usá-lo no seletor jQuery e restringe o seletor aos cartões de tema reais.
21/09/2026	Publicação do relatório técnico com prova de conceito completa e da análise independente da Patchstack.

A correção é pequena e específica, do tipo que passa despercebido em nota de lançamento. Quem leu o registro de mudanças da 7.1.1 procurando por "vulnerabilidade crítica" não encontrou essa expressão, porque não havia identificador CVE atribuído. Isso significa que boa parte do parque provavelmente não priorizou a atualização — e agora tem o encadeamento inteiro publicado.

Quem pode disparar, e quem não pode

A Patchstack apontou o limite que reduz o alcance: só a conta de administrador tem permissão para instalar tema. Perfis de Autor e Editor não conseguem completar a cadeia. Em site com separação de papéis bem feita, o alvo é um conjunto pequeno de pessoas.

O mesmo relatório aponta o caminho que amplia o alcance. O disparo não precisa ser phishing. Qualquer cross-site scripting já existente em uma tela do painel administrativo serve: basta que o navegador do administrador envie a requisição enquanto ele trabalha. Em um ambiente com dezenas de plugins de terceiros, a probabilidade de existir um XSS no painel não é pequena.

O que muda para quem opera no Brasil

• O parque é enorme e mal inventariado. WordPress sustenta site institucional, portal de notícia, loja, blog de produto e página de campanha em praticamente toda empresa de médio porte no país. Boa parte dessas instalações não está no inventário de ativos do time de segurança porque nasceu em uma agência de marketing.
• A defesa compensatória existe e é barata. Sites com DISALLOW_FILE_MODS habilitado não podem ser forçados a instalar tema ou plugin. É uma linha no wp-config.php e, em ambiente de produção com publicação via pipeline, não deveria haver motivo para mantê-la desativada.
• O site comprometido vira vetor para o visitante. Execução de PHP permite injetar script nas páginas. O padrão do trimestre em campanhas de comércio eletrônico tem sido exatamente esse: script injetado em loja legítima para coletar dado de pagamento ou empurrar falso passo de verificação.
• O prazo de resposta é hoje, não na próxima janela. Com prova de conceito pública e correção disponível há uma semana, a distância entre o relatório e a varredura em massa é curta.

Leitura LATAMSEC

Três perguntas, na ordem em que fazem diferença.

Para quem administra os sites: quantas instalações de WordPress a organização tem, e quantas estão na 7.1.1? A resposta precisa incluir os ambientes que não são "o site principal" — a página de campanha do semestre passado, o blog de produto, o portal de carreira. É lá que a versão antiga costuma estar.

Para o time de resposta: se um administrador clicou, o que ficaria registrado? Vale levantar agora a lista de temas instalados em cada site, comparar com o que deveria estar lá, e verificar contas administrativas criadas nos últimos trinta dias. Tema instalado e nunca ativado é exatamente o artefato que ninguém olha.

Para o comitê de risco: quantos sistemas da organização dependem de uma pessoa não clicar em um link para permanecerem íntegros? O WordPress é o caso do dia, mas a categoria inclui todo painel administrativo acessível pelo navegador sem segundo fator por operação sensível. É a mesma pergunta, feita uma vez para todos eles.