Uma vulnerabilidade de SQL Injection de segunda ordem identificada no plugin Backuply, ferramenta de backup, restauração, migração e clonagem para WordPress, coloca em risco mais de 600 mil instalações ativas. A falha foi reportada em 17 de setembro de 2026 e permite que atacantes autenticados, mesmo com permissões básicas de assinante, armazenem um código SQL malicioso que só é executado quando um administrador restaura posteriormente um backup do banco de dados. Dessa forma, o invasor consegue elevar seus privilégios até o nível de administrador e assumir o controle completo do site.
O problema foi descoberto e reportado de forma responsável pelo pesquisador identificado como daroo, por meio do Programa de Recompensas por Bugs da Wordfence. Pela descoberta, ele recebeu uma recompensa de US$ 1.352,00. Iniciativas como essa reforçam a importância da pesquisa de vulnerabilidades e da colaboração com especialistas independentes como parte de uma estratégia de segurança em múltiplas camadas para o ecossistema WordPress.
Como a vulnerabilidade no Backuply funciona
Usuários dos planos Premium, Care e Response da Wordfence já receberam, em 24 de setembro de 2026, uma regra de firewall para bloquear tentativas conhecidas de exploração dessa falha no Backuply, disponibilizado no repositório oficial do WordPress.org. Já quem utiliza a versão gratuita da ferramenta de proteção receberá a mesma camada de defesa 30 dias depois, em 24 de outubro de 2026.
A vulnerabilidade foi comunicada à equipe responsável pelo Backuply em 28 de setembro de 2026, e o desenvolvedor lançou a versão totalmente corrigida já em 1º de outubro de 2026 — uma resposta considerada rápida e dentro do prazo esperado para esse tipo de correção. Por isso, recomenda-se fortemente que todos os usuários atualizem seus sites para a versão mais recente do plugin, a 1.5.9 até o momento desta publicação, o quanto antes.
Tecnicamente, trata-se de uma injeção SQL de segunda ordem: o dado malicioso é inserido em um momento e só se torna perigoso quando processado posteriormente, em uma ação distinta. Nesse caso, o ponto de entrada é o campo “Informação Biográfica”, presente no perfil de qualquer usuário cadastrado no site. O WordPress armazena esse conteúdo como texto simples na tabela wp_usermeta.
Da biografia ao controle total do site
Quando um backup do banco de dados é gerado, o Backuply exporta essa biografia como um valor normal dentro de uma instrução INSERT no arquivo de dump SQL, escapando corretamente o conteúdo como dado. O problema surge na etapa de restauração: o processo de importação executa cada instrução do dump e, em seguida, aplica uma expressão regular sem restrições adequadas para identificar o prefixo antigo das tabelas do site. Como essa expressão não se limita a um cabeçalho real de criação de tabela e não ignora valores entre aspas, ela acaba capturando também o texto presente na biografia armazenada.
Quando a instrução também contém o termo backuply_version, o texto capturado é inserido diretamente em uma segunda consulta UPDATE, sem qualquer validação. Assim, um atacante pode elaborar sua biografia de forma que o trecho capturado não seja um prefixo de tabela, mas sim uma instrução UPDATE completa, definida por ele mesmo. Ao encerrar esse trecho com um caractere de comentário, a parte restante da consulta original do plugin é descartada, restando apenas o comando malicioso.
A instrução injetada altera duas configurações na tabela wp_options: default_role, definida como administrator, e users_can_register, ajustada para 1. Como a tabela wp_options é restaurada antes da wp_usermeta, essas alterações já estão em vigor no momento em que a consulta maliciosa é executada e permanecem ativas após o término da restauração.
É justamente a combinação dessas duas opções que transforma uma simples escrita indevida no banco de dados em uma tomada total do site. Com o registro público de usuários habilitado, o WordPress passa a exibir o formulário de cadastro, e qualquer conta criada sem papel definido recebe automaticamente a função armazenada em default_role — nesse caso, administrador.
Dessa forma, após um administrador restaurar um backup contaminado pelo valor malicioso, basta ao atacante se cadastrar pelo formulário padrão de registro do WordPress para obter, de forma automática, privilégios administrativos completos sobre o site.
Atenção ao momento da restauração
Vale destacar que a exploração da falha depende de uma condição específica: um administrador precisa restaurar um backup criado após o atacante ter salvo a biografia maliciosa em seu perfil. É esse ato de restauração que dispara a execução do código injetado. Como criar e restaurar backups é justamente a função central do plugin, trata-se de uma ação rotineira — porém, enquanto não houver uma restauração, o comando malicioso permanece inativo.
Diante do cenário, especialistas em segurança digital reforçam a recomendação de atualização imediata para a versão corrigida do Backuply. Plustag IA destaca que episódios como esse reforçam a importância de manter plugins sempre atualizados e de contar com camadas adicionais de proteção, como firewalls de aplicação, especialmente em ferramentas que lidam diretamente com backups e restauração de bancos de dados, componentes sensíveis de qualquer site WordPress.
Com informações de wordfence.com.
