Vulnerabilidade Crítica de Traversal de Caminho no Backup Guard//Publicado em 2026-04-17//CVE-2026-4853

EQUIPE DE SEGURANÇA WP-FIREWALL

Backup Guard Vulnerability CVE-2026-4853

Nome do plugin Backup Guard
Tipo de vulnerabilidade Vulnerabilidade de travessia de caminho
Número CVE CVE-2026-4853
Urgência Baixo
Data de publicação do CVE 2026-04-17
URL de origem CVE-2026-4853

Crítico: Travessia de Caminho + Exclusão Arbitrária de Diretórios no JetBackup / Backup Guard (CVE-2026-4853) — O que os Proprietários de Sites WordPress Precisam Saber e Como se Proteger

Publicado: 17 Abr, 2026
Plugin afetado: JetBackup / Backup Guard (slug do plugin: backup)
Versões vulneráveis: <= 3.1.19.8
Versão corrigida: 3.1.20.3
CVE: CVE-2026-4853
Gravidade: Baixo (prioridade do Patchstack: Baixo, CVSS: 4.9) — mas não se deixe enganar: o impacto prático pode ser significativo se um atacante obtiver ou já controlar uma conta de Administrador.

Como a equipe por trás do WP-Firewall, rastreamos vulnerabilidades do WordPress continuamente e aconselhamos proprietários de sites, desenvolvedores e hosts sobre respostas pragmáticas e priorizadas. Esta vulnerabilidade do JetBackup/Backup Guard é uma travessia de caminho autenticada que permite a um usuário de nível Administrador excluir diretórios arbitrários por meio de um valor elaborado no nome do arquivo parâmetro (comumente enviado para um endpoint de backup/exclusão). A falha foi divulgada de forma responsável e corrigida na versão 3.1.20.3 — atualizar é a remediação mais simples e eficaz. Abaixo, detalhamos os aspectos técnicos, cenários de risco realistas, estratégias de detecção e mitigação, regras práticas de patching virtual WAF, etapas de resposta a incidentes e recomendações de endurecimento a longo prazo para que você possa agir rapidamente e com confiança.

Nota: Este aviso é escrito para proprietários de sites WordPress, engenheiros de segurança e equipes de hospedagem gerenciada. Inclui configurações defensivas acionáveis e exemplos de código para ajudá-lo a mitigar o problema rapidamente e com segurança.


Resumo executivo (curto)

  • O que: Travessia de caminho no manipulador de exclusão de backup do plugin via nome do arquivo parâmetro. Um Administrador autenticado pode usar sequências de travessia de caminho (../) para direcionar diretórios fora das pastas de backup esperadas e acionar a exclusão.
  • Quem é afetado: Sites que executam o plugin em versões <= 3.1.19.8.
  • Impacto: Exclusão arbitrária de diretórios (arquivos do site, uploads, backups, logs) — destrutiva se explorada. Requer privilégios de Administrador para explorar, portanto, os ataques são mais prováveis após a violação ou uso indevido da conta de administrador.
  • Solução imediata: Atualize o plugin para 3.1.20.3 ou posterior.
  • Mitigações intermediárias: Aplique regras WAF para bloquear cargas de travessia de caminho, restrinja o acesso ao painel de administração a IPs confiáveis, desative o plugin ou o endpoint de exclusão vulnerável até que seja corrigido, endureça as permissões de arquivo e garanta backups robustos.

Como a vulnerabilidade funciona (visão geral técnica, explicação não explorável)

Em um nível alto, a vulnerabilidade surge da validação e sanitização insuficientes de um nome do arquivo parâmetro fornecido pelo usuário que o plugin usa para construir caminhos do sistema de arquivos para exclusão. Quando o plugin constrói um caminho como:

/wp-content/plugins/backup/backup-files/

e falha em normalizar ou restringir adequadamente nomeDoArquivo, um adversário pode incluir sequências de travessia de caminho, como ../../ no parâmetro. Se o plugin então passar esse caminho construído para funções de exclusão de sistema de arquivos sem verificar se o caminho resolvido está dentro de um diretório base esperado, ele pode remover diretórios ou arquivos arbitrários.

Causas raiz principais comumente encontradas nesta classe de bugs:

  • Sem verificação de canonização/caminho real — o plugin confia no caminho concatenado sem verificar se o caminho final resolvido está sob o diretório permitido.
  • Falta de verificação de basename ou lista branca — o plugin aceita valores de nome de arquivo arbitrários em vez de restringir a nomes de backup conhecidos.
  • Verificações inadequadas de capacidade/nonce ou falta de nonces em pontos finais sensíveis (embora aqui o atacante deva ser um administrador, então a capacidade está presente; prevenir CSRF e uso excessivo de privilégios ainda é relevante).
  • Falha em validar a existência de arquivos/diretórios e em prevenir a exclusão de diretórios (rmdir/unlink) para recursos não respaldados.

Como as chamadas de exclusão podem ser recursivas se o código wrapper usar implementações recursivas de rmdir, o efeito pode escalar de remover um único arquivo para apagar diretórios inteiros.


Cenários de exploração e impacto prático

Embora a vulnerabilidade exija privilégios de Administrador para ser acionada, aqui estão maneiras realistas de como a falha pode se tornar uma ameaça prática:

  1. Comprometimento de credenciais de administrador: Phishing, senhas reutilizadas, senhas vazadas ou engenharia social podem fornecer a um atacante uma conta de administrador. Uma vez que eles tenham acesso à interface de usuário em nível de administrador, podem elaborar uma solicitação para o ponto final vulnerável para excluir diretórios do site.
  2. Ameaça de administrador malicioso ou insider: Um administrador ou contratado desonesto com acesso legítimo pode abusar do recurso.
  3. Ataques encadeados: Um atacante que já controla um plugin de privilégio mais baixo ou um tema comprometido poderia escalar ou mudar para obter acesso de administrador quando combinado com outras fraquezas. Em tal exploração em múltiplas etapas, a capacidade de exclusão amplifica o dano.

O impacto potencial inclui:

  • Exclusão de diretórios de backup e backups armazenados (nega a recuperação).
  • Exclusão de uploads (imagens, mídia) e arquivos wp-content (temas/plugins).
  • Remoção de logs e artefatos forenses.
  • Exclusão de diretórios de configuração ou personalizados fora do webroot se a travessia de caminho permitir deixar o diretório base pretendido.
  • Interrupção de serviço e perda de dados levando a custos de inatividade e recuperação.

Mesmo com um CVSS “Baixo”, o custo operacional e o impacto reputacional de eventos de exclusão em massa podem ser altos — especialmente para sites sem backups recentes ou ambientes de staging.


Lista de verificação de ação imediata (o que fazer agora)

Se o seu site usa o plugin JetBackup / Backup Guard e você hospeda ou mantém sites WordPress, siga esta lista de verificação priorizada imediatamente:

  1. Atualize o plugin para 3.1.20.3 ou posterior.
    – Esta é a correção definitiva. Faça isso primeiro no staging, depois na produção. Teste os fluxos de backup/restauração após a atualização.
  2. Se não for possível atualizar imediatamente:
    – Desative o plugin ou desative a funcionalidade de exclusão de backup até que um patch possa ser aplicado.
    – Restrinja o acesso /wp-admin/ e os endpoints do plugin a endereços IP confiáveis, sempre que possível.
    – Aplique regras WAF temporárias (exemplos e modelos mais abaixo) para bloquear solicitações contendo padrões de travessia de caminho no nome do arquivo ou parâmetros semelhantes.
  3. Rode as credenciais de administrador e ative 2FA para todas as contas de administrador.
  4. Verifique os backups do site (fora do site) e assegure-se de ter um plano de recuperação testado antes de fazer alterações.
  5. Monitore os logs para solicitações de exclusão suspeitas e remoção repentina de arquivos.
  6. Comunique-se com as partes interessadas (proprietário do site, host, operações) e prepare um plano de resposta a incidentes se exclusões inesperadas forem detectadas.

Detecção: como detectar tentativas ou exploração bem-sucedida

Procure os seguintes sinais nos logs de acesso, logs de auditoria e atividade do sistema de arquivos:

  • Solicitações HTTP direcionadas a endpoints de plugin que lidam com backup ou exclusão de arquivos com parâmetros de consulta como nomeDoArquivo, nome do arquivo, arquivo, nome ou corpos POST contendo nomes. Exemplos de padrões de consulta suspeitos:
    • filename=../../
    • filename=..%2F..%2F
    • fileName=%2e%2e%2fwp-content%2fuploads
  • Solicitações com sequências de travessia de caminho em qualquer parâmetro:
    • ../
    • ..\\
    • equivalentes codificados em URL %2e%2e%2f ou %2e%2e%5c
  • Arquivos ou diretórios ausentes repentinamente em wp-content, uploads ou no diretório de backup do plugin.
  • Eventos inesperados de exclusão de arquivos observados em ferramentas de monitoramento de sistema de arquivos, ou picos em operações de “excluir”.
  • Logins de administrador de IPs / geolocalizações incomuns seguidos por solicitações a endpoints de backup.

Exemplos de regras de detecção (nível alto):

  • Correspondência de solicitações onde um parâmetro nomeado de forma insensível a maiúsculas e minúsculas como nome do arquivo, nomeDoArquivo, arquivo contém \.\./ ou %2e%2e%2f.
  • Correspondência de corpos POST que tentam excluir ou gerenciar backups que incluem sequências de travessia.
  • Alerta em rmdir ou desvincular erros nos logs do servidor correspondentes a caminhos inesperados fora do diretório base permitido.

Comando shell útil para encontrar itens recentemente modificados/excluídos (execute como um administrador, com cuidado):

# Encontrar arquivos na raiz da web modificados nos últimos 7 dias (ajuste conforme necessário)

Se você tiver monitoramento de integridade de arquivos (Tripwire, OSSEC, etc.), use isso para encontrar rapidamente exclusões.


Patching virtual e regras de WAF (assinaturas práticas que você pode aplicar agora)

Um Firewall de Aplicação Web (WAF) pode ser configurado para bloquear solicitações que tentam explorar a travessia de caminho. Abaixo estão modelos de regras defensivas seguras e exemplos práticos. Aplique-os para bloquear entradas maliciosas em vez de regras de permissão que possam quebrar fluxos de trabalho de administrador. Esses são padrões defensivos — teste-os em modo de monitoramento antes de bloquear.

Importante: adapte os nomes dos parâmetros aos endpoints do plugin e aos seus padrões de log. O parâmetro vulnerável é tipicamente nomeado nomeDoArquivo (variações insensíveis a maiúsculas e minúsculas podem existir).

Exemplo de regra estilo ModSecurity (conceitual):

# Block requests where any argument named filename (case-insensitive) contains ../ or encoded variants
SecRule ARGS_NAMES|ARGS "@rx (?i:filename)" "phase:2,deny,log,msg:'Block possible Backup plugin path traversal attempt', \
  chain"
SecRule ARGS "@rx (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)" "t:none,deny,status:403"

SecRule ARGS_NAMES|ARGS "@rx (?i:filename)" "phase:2,deny,log,msg:'Bloquear possível tentativa de travessia de caminho do plugin de Backup', \

if ($arg_filename ~* "\.\./|%2e%2e%2f") {
    return 403;
}
# Repeat for $arg_fileName or other param names

SecRule ARGS "@rx (\.\./|\.\.\\||)" "t:none,deny,status:403"

  • Nginx snippet de localização (bloquear strings de consulta com ../ no filename):.
  • if ($arg_filename ~* "\.\./|") {.
  • return 403;.
  • Registre eventos bloqueados com cabeçalhos completos e corpo da solicitação para revisão forense.

# Repetir para $arg_fileName ou outros nomes de parâmetros.


Sugestões genéricas de WAF/Regras:

Bloquear qualquer solicitação onde ARGS contém caracteres de travessia de caminho codificados e onde a solicitação visa o caminho do endpoint de exclusão do plugin (por exemplo, /wp-admin/admin-ajax.php?action=backup_delete ou rota ajax específica do plugin).

Importante: Detectar e bloquear cargas úteis de byte nulo ou caracteres de travessia codificados em Unicode.

Combinar detecção de padrões com limites de taxa e restrições de acesso ao painel de administração.

Registrar eventos bloqueados com cabeçalhos completos e corpo da solicitação para revisão forense.

  • Manter regras conservadoras para evitar falsos positivos; considerar colocá-las em modo de bloqueio apenas após monitorar por um ou dois dias.usuário_atual_pode)
  • Verificar
  • Uso de basename() Exemplo de código de endurecimento seguro para autores de plugins / equipes de desenvolvimento
  • Uso de realpath Se você mantiver uma integração personalizada ou um patch, certifique-se de que o lado do servidor use canonização e aplique rigorosamente diretórios base permitidos e listas brancas. Abaixo está um padrão seguro para PHP em um contexto WordPress (sanitizando o filename e verificando o realpath).

este é um código de exemplo defensivo para ilustrar o manuseio seguro; autores de plugins devem adaptar, sanitizar e testar antes da implantação.

<?php

  • // Exemplo: safe-delete.php (conceitual).
  • Usar open_basedir limitar processos PHP a diretórios permitidos.
  • Configurar permissões de arquivo para que o usuário do servidor web não possa excluir arquivos de sistema arbitrários (tenha em mente as necessidades de plugins e backups).
  • Usar perfis SELinux ou AppArmor para isolar processos do WordPress e limitar o acesso a arquivos.
  • Ativar auditoria em nível de processo (auditd) para capturar remoções de arquivos por processos PHP para análise forense.
  • Usar backups fora do site (armazenados fora do servidor web) para garantir recuperação segura mesmo se os backups em nível de site forem removidos.

Resposta a incidentes: se você suspeitar de exploração

Se você acredita que seu site foi explorado através dessa vulnerabilidade (ou qualquer outra), siga estas etapas:

  1. Isolar imediatamente o site (tirar do ar ou habilitar o modo de manutenção) para parar mais danos.
  2. Preservar logs e dados forenses do servidor — copiar logs de acesso, logs de erro e quaisquer logs de aplicação para um armazenamento separado e imutável.
  3. Restaurar a partir de um backup conhecido e bom armazenado fora do site (não em backups gerenciados por plugins se você suspeitar de exclusão).
  4. Rotacionar todas as credenciais para contas de Administrador e quaisquer chaves de API, tokens ou credenciais de banco de dados que possam ter sido expostas.
  5. Forçar redefinições de senha para usuários com funções privilegiadas e habilitar 2FA.
  6. Escanear em busca de backdoors adicionais, cron jobs suspeitos, novos usuários administradores ou arquivos de plugins/temas modificados.
  7. Reinstalar o núcleo do WordPress e todos os plugins/temas de fontes oficiais após a limpeza, ou restaurar um backup totalmente validado.
  8. Se você não tiver a expertise, contrate um fornecedor especializado em resposta a incidentes de segurança ou um provedor de WordPress gerenciado de confiança e compartilhe artefatos forenses.

Recomendações e melhores práticas a longo prazo

Para reduzir a chance dessa classe de vulnerabilidade causar danos significativos no futuro, siga estes princípios:

  • Privilégio mínimo: minimize o número de usuários com privilégios de Administrador. Use acesso baseado em funções e conceda apenas o que é necessário.
  • MFA em todos os lugares: imponha autenticação multifatorial para todas as contas com capacidade administrativa.
  • Atualizações regulares: estabeleça uma cadência (semanal/bissemanal) para atualizar o núcleo do WordPress, temas e plugins; teste as atualizações em staging primeiro.
  • Backups reforçados: mantenha múltiplos backups automatizados fora do site (diários/semanalmente) e teste periodicamente as restaurações.
  • Verificação de plugins: mantenha uma lista pequena e curada de plugins e remova plugins não utilizados. Prefira plugins mantidos ativamente com um histórico de segurança.
  • Patching virtual: mantenha regras de WAF que podem ser rapidamente atualizadas para bloquear padrões de ataque conhecidos até que os patches do fornecedor sejam aplicados.
  • Ciclo de vida de desenvolvimento seguro (SDLC): os desenvolvedores devem realizar validação de entrada, canonização e verificações de menor privilégio em todas as operações de arquivo.
  • Registro e monitoramento: tenha SIEM ou agregação de logs para alertar sobre atividades administrativas suspeitas e eventos de exclusão.

Exemplos práticos de regras de WAF (mais)

Abaixo estão vários exemplos de regras defensivas para diferentes ambientes. Por favor, valide essas regras em um ambiente de staging seguro antes de aplicá-las em produção.

  1. Bloqueio genérico de caracteres de travessia em nomeDoArquivo argumento (conceitual):
    • Condição: A solicitação contém um nome de parâmetro correspondente (?i:arquivo(Nome)?) e o valor corresponde a padrões de travessia.
    • Ação: Bloquear e registrar.
  2. Restringir ação AJAX específica do plugin (se o plugin usar admin-ajax):
    • Bloquear quaisquer chamadas admin-ajax com ação=backup_excluir a menos que a solicitação se origine de IPs na lista branca ou contenha um nonce de site válido.
  3. Bloquear travessia codificada:
    • Detectar tanto sequências brutas (../) quanto sequências codificadas em URL (%2e%2e%2f, %2e%2e/) e variantes Unicode.
  4. Limitação de taxa:
    • Limite ações destrutivas (excluir endpoints) a um baixo número por minuto por conta de administrador ou endereço IP.

Por que atualizar mesmo que o CVSS pareça “baixo”?

O CVSS é um fator, mas o risco no mundo real depende do contexto. Esta vulnerabilidade requer privilégios de Administrador — isso reduz o risco de exploração anônima remota — mas, na prática, muitos sites carecem de uma higiene rigorosa das contas de administrador. Contas de administrador são frequentemente comprometidas por meio de reutilização de credenciais, senhas fracas ou phishing. Uma vez que um atacante tem acesso de administrador, a capacidade de excluir diretórios remotamente pode ser catastrófica.

Também considere:

  • Atacantes podem encadear vulnerabilidades. Um pequeno ponto de apoio inicial + essa capacidade de exclusão = grande dano.
  • Excluir arquivos de backup remove seu caminho de recuperação.
  • Custos reputacionais e de recuperação podem ofuscar o rótulo de severidade “Baixa” original.

Portanto, trate isso como um risco prático de alta prioridade se você hospedar sites de produção ou muitos clientes.


Consultas e alertas de monitoramento de exemplo

  • Alerta quando um usuário administrador realiza uma chamada de exclusão direcionando endpoints de plugin com ../ em parâmetros.
  • Alerta quando grandes quantidades de arquivos são removidas de wp-content/uploads ou pastas de backup de plugins.
  • Resumo diário: lista de exclusões de arquivos iniciadas por processos PHP-FPM na raiz da web.

Exemplo de loggrep simples para encontrar solicitações suspeitas (Apache/Nginx):

# Look for traversal patterns in access logs
grep -E "(filename|fileName|file)=.*(\.\./|%2e%2e%2f)" /var/log/nginx/access.log | tail -n 200

Após o patch: verifique e valide

Após atualizar o plugin para 3.1.20.3 (ou posterior), valide:

  • A funcionalidade de exclusão do plugin ainda funciona como esperado para arquivos de backup legítimos, mas não pode atravessar para fora do diretório designado.
  • Nenhum erro inesperado ocorre nos fluxos de backup/restauração.
  • Realize um teste controlado: tente solicitar a exclusão com uma carga de travessia (em um ambiente de teste) e verifique se é rejeitada e/ou registrada.
  • Reative quaisquer regras temporárias do WAF somente após confirmar que o plugin está corrigido; mantenha as regras de detecção para alertar sobre atividades incomuns.

Cronograma e divulgação responsável (breve)

Esta vulnerabilidade foi identificada e relatada ao fornecedor antes da divulgação pública. O fornecedor emitiu um patch na versão 3.1.20.3. O CVE-2026-4853 foi atribuído para rastrear o problema. Sempre recomendamos atualizar para a versão corrigida como a principal remediação.


Exemplo prático: o que um administrador de hospedagem deve fazer em 15–60 minutos

Se você é um administrador de hospedagem ou proprietário de site acordando com este aviso, aqui está um breve “playbook dos primeiros 60 minutos”:

0–10 min:

  • Identifique os sites afetados (plugin instalado e versão <= 3.1.19.8).
  • Informe as partes interessadas (proprietários de sites, operações).

10–30 min:

  • Se atualizar imediatamente for viável, atualize o plugin no ambiente de teste e depois na produção.
  • Se você não puder atualizar, desative o plugin e/ou restrinja o acesso aos pontos finais de administração via lista de permissões de IP.

30–60 min:

  • Aplique regras temporárias do WAF para bloquear padrões de travessia de caminho contra os pontos finais do plugin.
  • Rotacione credenciais de administrador e ative 2FA.
  • Verifique se os backups fora do site estão intactos e faça um backup manual adicional, se possível.

Notas finais — equilibrando urgência com segurança

Atualize para 3.1.20.3 ou posterior assim que puder. Se você não puder atualizar imediatamente, use as mitig ações em camadas descritas acima: patch virtual do WAF, restrições de IP, desativação do plugin ou severidade das capacidades de exclusão até que o patch seja aplicado. Sempre garanta que você testou backups fora do site antes de fazer mudanças abrangentes de remediação.

Entendemos que as atualizações podem, às vezes, quebrar a compatibilidade. É por isso que as equipes de hospedagem e agências precisam de fluxos de trabalho previsíveis e testados para atualizações de plugins, patches virtuais de emergência e práticas de recuperação. Se você gerencia muitos sites WordPress, a automação e a gestão centralizada para atualizações, regras do WAF e backups reduzirão drasticamente o tempo de reação.


Comece a proteger seu site com o plano gratuito do WP­Firewall

Se você deseja uma maneira rápida e prática de adicionar uma camada de proteção enquanto lida com as atualizações do plugin, considere começar com nosso plano gratuito do WP­Firewall. Ele fornece proteções essenciais que ajudam a bloquear tentativas de exploração e monitorar comportamentos suspeitos enquanto você aplica o patch:

  • Básico (grátis) — Proteção essencial: firewall gerenciado, largura de banda ilimitada, um WAF, scanner de malware e mitigação dos riscos do OWASP Top 10.
  • Padrão — Todos os recursos básicos, além de remoção automática de malware e a capacidade de adicionar até 20 IPs à lista negra/branca.
  • Pró — Todos os recursos padrão mais relatórios de segurança mensais, correção virtual automática de vulnerabilidades e acesso a complementos premium: Gerente de Conta Dedicado, Otimização de Segurança, Token de Suporte WP, Serviço WP Gerenciado e Serviço de Segurança Gerenciado.

Veja os detalhes do plano e inscreva-se aqui: https://my.wp-firewall.com/buy/wp-firewall-free-plan/


Encerramento: o que recomendamos, por ordem

  1. Atualize o JetBackup / Backup Guard para a versão 3.1.20.3 ou posterior imediatamente.
  2. Se você não puder atualizar instantaneamente, aplique regras WAF para bloquear a travessia de caminho em nome do arquivo/nomeDoArquivo parâmetros e restrinja o acesso de administrador.
  3. Rode as credenciais de administrador, ative a 2FA e revise a lista de usuários administradores para contas desconhecidas.
  4. Verifique os backups fora do site e teste as restaurações.
  5. Reforce as configurações do servidor (open_basedir, SELinux/AppArmor, permissões rigorosas) e considere as capacidades de correção virtual para mitigação rápida futura.
  6. Mantenha registro, monitoramento e uma lista de verificação de resposta a incidentes para que você possa agir rapidamente se algo suspeito acontecer.

Se você precisar de ajuda para implementar regras WAF, escanear indicadores de comprometimento ou aplicar correções virtuais seguras em vários sites, a equipe do WP­Firewall pode ajudar. Oferecemos proteções gerenciadas que integram assinaturas WAF, correção virtual e monitoramento contínuo para que você possa se concentrar em administrar seu site, e não em buscar correções de emergência.

Fique seguro e, por favor, entre em contato se precisar de ajuda para auditar sites afetados ou implementar regras de proteção.


wordpress security update banner

Receba WP Security semanalmente de graça 👋
Inscreva-se agora
!!

Inscreva-se para receber atualizações de segurança do WordPress na sua caixa de entrada, toda semana.

Não fazemos spam! Leia nosso política de Privacidade para mais informações.