AccelerateWP: exposição de wp-config.php.backup corrigida na versão 1.9-38

O AccelerateWP até 1.9-37 podia criar wp-config.php.backup no diretório público ao habilitar Object Cache. O arquivo podia ser baixado sem autenticação e expor banco, chaves e salts. A versão 1.9-38, lançada em dezembro de 2025, interrompe a criação e remove cópias existentes.

O que aconteceu

O fluxo de ativação do cache de objetos preservava uma cópia do wp-config.php diretamente no document root. Como a extensão .backup costuma ser servida como texto estático, uma requisição à URL conhecida podia devolver o conteúdo integral sem executar PHP.

O arquivo contém nome, usuário e senha do banco e as chaves/salts de autenticação. Credenciais de banco podem permitir leitura ou modificação remota quando a rede aceita a origem; salts expostos também exigem rotação porque podem ajudar a forjar ou atacar sessões.

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

Duas condições precisavam coexistir: pacote afetado e Object Cache habilitado. A atualização remove o arquivo conhecido, mas não pode revogar uma cópia que já tenha sido baixada.

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

Crítico quando o arquivo existiu. A leitura é não autenticada e o conteúdo contém segredos capazes de levar a comprometimento completo. O risco atual é menor na maioria das instalações já atualizadas, porém a verificação histórica e a rotação são essenciais onde o arquivo foi encontrado.

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

Confirme o RPM e procure o nome exato sob os document roots. A busca deve ser feita localmente; não solicite a URL pública em massa porque isso pode registrar ou expor o conteúdo.

rpm -qa | grep '^accelerate-wp'
find /home -type f -name 'wp-config.php.backup' -print
find /home -type f -name 'wp-config.php.backup' -exec stat {} \;

O esperado é accelerate-wp 1.9-38 ou posterior e nenhuma ocorrência. Se um arquivo existir, registre caminho, horários e permissões antes de removê-lo; analise logs HTTP para pedidos ao nome e considere os segredos comprometidos.

Como corrigir ou mitigar

Atualize o pacote. A versão corrigida remove arquivos existentes automaticamente. Quando houver ocorrência, apague após preservação forense, altere a senha do usuário do banco, atualize o wp-config.php, gere novos salts oficiais e encerre sessões.

dnf update accelerate-wp
rpm -qa | grep '^accelerate-wp'
find /home -type f -name 'wp-config.php.backup' -print

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

Teste WordPress e Object Cache/Redis. Revise acesso ao arquivo nos logs, conexões do banco, administradores, sessões e mudanças no site. A simples remoção não invalida segredos previamente obtidos.

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 verifica versão e arquivos residuais nos ambientes aplicáveis. O Imunify360 bloqueia requisições diretas a wp-config.php.backup como defesa em profundidade, conforme CloudLinux, mas o procedimento correto continua sendo atualizar, remover o arquivo e rotacionar segredos se ele existiu.

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.

Tutoriais, downloads e serviços relacionados

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

Referências oficiais e técnicas

• CloudLinux — advisory AccelerateWP
• CloudLinux Docs — AccelerateWP
• WordPress.org — gerador oficial de salts

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.