Uma vulnerabilidade crítica foi identificada no Ally, plugin gratuito do WordPress voltado para acessibilidade digital. A falha permite que invasores acessem o banco de dados de um site sem qualquer tipo de autenticação, abrindo caminho para o roubo de informações sensíveis, incluindo senhas criptografadas.
O problema foi descoberto em 4 de fevereiro de 2026 pelo engenheiro de segurança Drew Webber, da empresa Acquia. A vulnerabilidade recebeu o identificador CVE-2026-2413 e foi classificada com nota 7.5 no sistema CVSS, indicando gravidade alta.
Como a vulnerabilidade funciona
O plugin Ally — anteriormente conhecido como One Click Accessibility — foi criado para ajudar desenvolvedores a tornar seus sites mais acessíveis. Entre seus recursos estão um scanner de acessibilidade com sugestões baseadas em inteligência artificial, um widget para visitantes e ferramentas para gerar declarações de acessibilidade automaticamente.
Atualmente, o plugin está instalado em mais de 400 mil sites, o que amplia significativamente o impacto potencial da falha.
O problema está em uma função chamada get_global_remediations(), responsável por montar consultas ao banco de dados com base na URL de uma página. Essa função cria uma consulta do tipo JOIN no banco de dados, mas trata o endereço de forma inadequada antes de inseri-lo no código SQL.
Para filtrar a URL, o plugin utiliza a função esc_url_raw(). Embora essa função seja útil para validar a estrutura de endereços da web, ela não foi projetada para proteger consultas de banco de dados.
Isso significa que caracteres usados em ataques de SQL Injection, como aspas e parênteses, passam pela filtragem sem serem bloqueados.
O método recomendado no WordPress seria utilizar a função wpdb->prepare(), que escapa corretamente os dados e os trata como valores dentro da consulta, impedindo que se tornem parte da lógica do código SQL.
Sem essa proteção, a URL enviada pelo atacante acaba sendo inserida diretamente na consulta executada pelo banco de dados.
O que um invasor pode fazer
Explorando a falha, um atacante pode executar uma técnica conhecida como injeção SQL cega baseada em tempo.
Nesse tipo de ataque, o invasor envia consultas manipuladas contendo comandos que provocam atrasos na resposta do servidor — por exemplo, utilizando funções como SLEEP().
Se o site demora a responder, significa que a condição testada na consulta era verdadeira. Se responde rapidamente, a condição era falsa.
Repetindo esse processo diversas vezes, o atacante consegue extrair informações do banco de dados bit a bit, sem que o sistema identifique o ataque de forma evidente.
Embora seja um método relativamente lento, ele permite acessar dados importantes armazenados no banco, como:
- hashes de senhas
- informações de usuários
- dados internos do site
Como a falha foi corrigida
O pesquisador Drew Webber reportou a vulnerabilidade de forma responsável por meio do programa de recompensas por bugs da Wordfence, recebendo US$ 800 pela descoberta.
A Wordfence notificou a Elementor, responsável pelo plugin, em 13 de fevereiro. A empresa confirmou o problema dois dias depois e publicou a correção em 23 de fevereiro de 2026.
A solução foi tecnicamente simples: substituir a concatenação direta de dados na consulta SQL pela função wpdb->prepare(), que trata corretamente os parâmetros antes de enviá-los ao banco de dados.
A vulnerabilidade foi corrigida na versão 4.1.0 do plugin. Sites que ainda utilizam versões até a 4.0.3 permanecem vulneráveis e devem atualizar o quanto antes.
Em segurança digital, esse tipo de falha mostra um detalhe curioso: às vezes não é preciso quebrar criptografia nem invadir servidores sofisticados. Basta um pequeno erro na forma como um dado é inserido em uma consulta de banco de dados para transformar um simples campo de URL em uma porta aberta para o sistema inteiro.
