WordPress Risco Alto

CVE-2026-19949: SQL injection no All-in-One WP Migration afeta milhões de sites

All-in-One WP Migration and Backup até 7.109 contém SQL injection não autenticado acionado durante restauração. Atualize para 7.110 ou superior.

Revisado em 04/09/2026 Leitura técnica
CVE-2026-19949
SeveridadeAlto
Versões afetadasAll-in-One WP Migration and Backup 7.109 e anteriores
Versões corrigidasVersão 7.110 ou superior
Status WebinHostAtualização urgente e revisão de restaurações

A CVE-2026-19949 afeta o plugin All-in-One WP Migration and Backup, instalado em milhões de sites. A falha permite preparar uma injeção SQL sem autenticação que é acionada quando um administrador exporta e posteriormente restaura o arquivo comprometido. A correção foi publicada na versão 7.110.

O que aconteceu

A vulnerabilidade é uma SQL injection de segunda ordem: a entrada hostil pode ser plantada antes, inclusive por trackback em um post que aceite pings, e permanecer armazenada. Durante o processo posterior de exportação e restauração, o plugin usa esse conteúdo de forma insegura em uma consulta ao banco.

Esse encadeamento não é uma SQL injection instantânea em qualquer página. Ele depende da presença do plugin, de conteúdo preparado e da ação de backup/restauração. Ainda assim, pode expor dados sensíveis, inclusive o segredo usado pelo plugin, e criar caminho para execução de código quando o arquivo malicioso é restaurado.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

Produto ou linhaAfetado / expostoCorrigido / protegido
All-in-One WP Migration and Backup7.109 e anteriores7.110 ou superior

Sites sem o plugin não são afetados. Desabilitar trackbacks reduz uma forma de plantar a carga, mas conteúdos já persistidos e arquivos de backup existentes continuam exigindo análise.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Alto. O CVSS informado é 8,8. A exploração demanda uma sequência e interação administrativa, mas pode revelar dados do banco, segredos do plugin e comprometer o site após restauração. Proíba a importação de arquivos de origem desconhecida.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Consulte a versão instalada, identifique backups recentes e verifique se posts públicos aceitam ping. Não importe um arquivo suspeito apenas para “testar”.

wp plugin get all-in-one-wp-migration --fields=name,status,version,update,update_version
wp option get default_ping_status
find wp-content -type f \( -iname '*.wpress' -o -iname '*.zip' \) -mtime -90 -print

Versão 7.109 ou anterior é vulnerável. A ausência de arquivos no caminho pesquisado não prova segurança porque o armazenamento pode estar fora do document root ou em extensão premium/remota. Registre a origem e o hash de cada backup antes de restaurar.

Faça somente inventário defensivo. Não execute prova de conceito em produção. Um exploit pode derrubar o host, alterar dados, apagar vestígios ou atingir outros clientes. Se o resultado for ambíguo, preserve as saídas e compare-as com o boletim do fornecedor.

Como corrigir ou mitigar

Atualize para 7.110 ou posterior. Suspenda restaurações até validar o pacote, a origem do backup e a versão usada. Desative pingbacks/trackbacks se não forem necessários e revise os procedimentos de migração para exigir hashes e cadeia de custódia.

wp plugin update all-in-one-wp-migration
wp plugin get all-in-one-wp-migration --field=version
wp option update default_ping_status closed

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Revise restaurações feitas durante a janela vulnerável, contas administrativas, opções, plugins e arquivos alterados. Consulte logs do banco e da aplicação quando disponíveis. Se um arquivo não confiável foi importado, trate o site como potencialmente comprometido.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

A WebinHost combina inventário e atualização com monitoramento do Imunify360 nos planos elegíveis. Backups operacionais são protegidos e testados, mas arquivos de migração enviados pelo cliente devem ter procedência confirmada. A camada gerenciada reduz a janela de exposição sem substituir a governança do conteúdo restaurado.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Escopo dos planos gerenciados: a WebinHost prioriza falhas críticas e altas na infraestrutura administrada. Sites, temas, plugins, código e credenciais do cliente continuam exigindo atualização e revisão pelo responsável da aplicação, salvo contratação específica. O status deve ser confirmado por servidor; possuir KernelCare ou Imunify360 não é, isoladamente, prova de que todo CVE foi corrigido.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais e técnicas

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.

Precisa validar seu ambiente?

Conte com gerenciamento técnico de servidores

A atualização de aplicações do cliente e a administração do servidor têm escopos diferentes. Fale com a equipe para avaliar o ambiente e o plano adequado.