Backup do WordPress vira gatilho de invasão — 3,2 milhões seguem expostos
Em 3 de setembro de 2026, cerca de 3,2 milhões de instalações do All-in-One WP Migration and Backup ainda executavam versões vulneráveis a uma cadeia capaz de terminar no controle do site. A estimativa parte de mais de 5 milhões de instalações ativas e de uma taxa de atualização de apenas 35% para a versão corrigida, segundo os dados reunidos pela SecurityWeek.
Na mesma data, permaneciam afetadas todas as versões até a 7.109 pela vulnerabilidade CVE-2026-19949. O alerta técnico da Wordfence confirma que a versão 7.110 corrige a falha e que o código injetado só é executado quando um administrador restaura um arquivo — por isso, atualizar para a 7.110 ou posterior é a medida necessária.
A restauração transforma dados armazenados em SQL executável
A CVE-2026-19949 é uma injeção SQL de segunda ordem. O invasor não precisa executar a consulta maliciosa no momento em que envia os dados: ele pode plantar conteúdo preparado por meio da funcionalidade de trackback do WordPress, sem autenticação, e esperar que esse conteúdo seja incluído em um arquivo do site.
O gatilho ocorre depois, quando o administrador exporta e importa o ambiente. Durante a restauração, o plugin reescreve URLs e prefixos de tabelas no conteúdo SQL do arquivo. O tratamento incorreto de barras invertidas e aspas pode fazer com que os dados anteriormente armazenados deixem de ser interpretados como texto e passem a compor uma consulta executável.
Isso torna a palavra “dormente” importante para avaliar o risco. A presença da versão vulnerável não prova que houve invasão, mas a ausência de sintomas antes de uma restauração também não descarta que uma carga tenha sido plantada. Um backup gerado pelo próprio ambiente pode carregar esses dados se eles já estavam no banco no momento da exportação.
A chave secreta abre caminho para um arquivo malicioso
A primeira consequência da consulta injetada pode ser a exposição da ai1wm_secret_key, usada pelo plugin para proteger o processo de importação. Na cadeia detalhada pelos pesquisadores, o valor é copiado para um comentário aprovado e pode ser recuperado sem autenticação pela interface pública de comentários do WordPress.
De posse da chave, o atacante pode acionar a importação de um arquivo .wpress preparado. Esse pacote pode incluir um plugin “must-use” com código executável, extraído para o diretório correspondente e carregado na visita seguinte. O impacto possível é execução remota de código, com capacidade para instalar webshells, alterar arquivos, acessar dados e comprometer integralmente o site.
A cronologia publicada pela BleepingComputer registra que a ServMask recebeu os detalhes da falha em 15 de agosto e lançou a correção na versão 7.110 em 20 de agosto. A exploração continua dependendo da restauração, mas não exige que o invasor obtenha previamente uma conta administrativa.
Os 3,2 milhões representam exposição, não invasões confirmadas
A estimativa do título descreve instalações que ainda usavam uma versão afetada em 3 de setembro, e não 3,2 milhões de sites comprovadamente comprometidos. A diferença é essencial: para completar a cadeia, o atacante precisa plantar os dados e aguardar uma exportação seguida de importação, ou fazer com que um arquivo já contaminado seja processado.
Desativar o plugin reduz a janela em que o fluxo vulnerável pode ser acionado, mas não corrige o código instalado nem remove dados que possam ter sido gravados anteriormente. Se a versão antiga for reativada para uma migração ou recuperação, a restauração volta a oferecer o gatilho necessário. A correção verificável é instalar a versão 7.110 ou uma versão posterior já corrigida.
O recorte de 3,2 milhões também não deve ser tratado como uma medição permanente. Ele foi calculado a partir da distribuição de versões disponível em 3 de setembro e tende a mudar à medida que mais instalações são atualizadas.
A resposta exige atualizar e reconstruir o histórico de imports
O primeiro passo é conferir a versão do All-in-One WP Migration em cada instalação, incluindo ambientes de produção, homologação e cópias temporárias. Qualquer site na versão 7.109 ou anterior permanece no grupo afetado e deve ser atualizado para a 7.110 ou posterior.
Nos ambientes que passaram por exportação e restauração enquanto uma versão vulnerável estava ativa, a atualização resolve a falha, mas não demonstra que o período anterior foi seguro. A investigação deve relacionar as datas dos imports com alterações posteriores no banco de dados, nos arquivos e nas contas administrativas.
- Verificar comentários inesperados ou aprovados sem uma justificativa operacional, sobretudo registros ligados ao período anterior à restauração.
- Comparar o diretório de plugins “must-use” e os demais arquivos PHP com uma referência confiável anterior ao import.
- Revisar arquivos .wpress processados, origem, horário e responsável por cada operação de migração ou recuperação.
- Procurar usuários administrativos, tarefas agendadas, redirecionamentos e mudanças de configuração criados depois da restauração.
Arquivos recebidos de terceiros exigem atenção, mas limitar a análise a eles deixaria uma lacuna: o conteúdo malicioso pode ter entrado no banco antes da criação de um backup interno. O estado confirmado em 3 de setembro é que a correção já estava disponível, milhões de instalações ainda não a haviam adotado e uma restauração podia converter dados dormentes em uma cadeia de invasão. O número de compromissos efetivos, porém, não foi estabelecido.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.