O directory traversal deixa o invasor ler arquivos fora da raiz do site, como o wp-config.php, sem precisar de login. Segundo a OWASP (2024), o path traversal entra no Broken Access Control, o risco web número 1. O vetor clássico é a sequência ../ num parâmetro de URL. Conhecer os 3 vetores antecede qualquer correção.

O directory traversal é uma falha que permite ler ou gravar arquivos fora da pasta que o código deveria acessar, usando sequências como ../ para subir de nível no sistema. Diferente de um upload malicioso, que injeta um arquivo novo, o directory traversal abusa de um caminho que já existe para alcançar o que não deveria. No WordPress, o alvo preferido é o wp-config.php, que guarda usuário, senha e chaves do banco. Este guia de conceito faz parte do hub de vulnerabilidades WordPress da FULL e mapeia os três vetores mais comuns de directory traversal, com CVEs reais e como corrigir cada um.

O que é directory traversal no WordPress: Os 3 vetores

O directory traversal no WordPress é uma falha de controle de acesso a arquivos que deixa a requisição escapar da pasta pretendida e alcançar o sistema. Nos tickets de invasão da FULL, 3 vetores concentram a maioria dos casos, e o ponto comum é a falta de sanitização: o código confia num parâmetro de caminho que o usuário controla.

A causa raiz quase sempre é um plugin que recebe um nome de arquivo pela URL e o usa direto, sem validar a sequência ../. A tabela abaixo resume os três vetores de directory traversal que dominam os casos reais, cada um com o mecanismo e o sinal de exposição. O que os une é que nenhum precisa de credencial válida: a travessia cria seu próprio caminho até o arquivo-alvo.

Legenda: cada vetor de directory traversal escapa da pasta pretendida por uma camada diferente do site.

Por que o directory traversal lê o wp-config.php sem login

O directory traversal alcança o wp-config.php sem nenhum login porque o vetor clássico é um parâmetro de URL acessível por qualquer visitante anônimo. Em boa parte dos casos que chegam ao suporte da FULL, o primeiro sinal não é a invasão, e sim um GET com ../../../../wp-config.php no log, dias antes do dano real. A falha não pede autenticação: ela explora a confiança do código no caminho.

O motivo é técnico: quando o PHP recebe ?file=../../../wp-config.php e passa esse valor direto para readfile() sem sanitizar, o sistema sobe três níveis e devolve o conteúdo do arquivo. Com open_basedir desligado, não há cerca que impeça a leitura. O wp-config.php expõe as credenciais do banco e as chaves de autenticação, e a partir daí o acesso deixa de depender da senha do painel. Se o seu site já foi comprometido por esse caminho, o passo a passo de o que fazer imediatamente após uma invasão detalha a resposta na ordem certa.

Como um CVE de directory traversal vira leitura de arquivo

A maioria dos casos de directory traversal entra por uma falha conhecida e já corrigida que o site nunca atualizou. Um vetor recente é o CVE-2024-10932 no Backup Migration (CVSS 8.8), na versão < 1.4.6.1: o endpoint de path do plugin aceitava caminho sem validação, deixando a requisição escapar da pasta de backup.

Em famílias de plugin de upload, o padrão se repete. O CVE-2020-25213 no WP File Manager (CVSS 9.8), na versão < 6.9, combinava controle de caminho com upload sem validação, e foi explorado em massa em 2020. Vale distinguir risco atual de histórico: segundo o perfil público do WPVulnerability, o WP File Manager hoje aparece como seguro com esses CVEs corrigidos, enquanto o Backup Migration ainda figura com pendência recente. A regra é direta: plugin que manipula arquivo por parâmetro de URL é o primeiro lugar onde uma travessia de diretório procura brecha.

Como detectar e corrigir directory traversal no site

Detectar directory traversal exige procurar pela sequência ../ na requisição, não só pelo arquivo em disco. Um firewall de aplicação como o Wordfence ou o módulo WAF do All in One Security bloqueia o padrão ../ na URL antes de a requisição chegar ao PHP, e em média barra a tentativa como 1 evento registrado por IP no log de firewall. A correção combina três camadas.

A primeira camada é manter plugins atualizados, porque quase todo CVE de directory traversal já tem patch. A segunda é o WAF, que bloqueia a travessia mesmo num plugin ainda vulnerável. A terceira é o hardening do servidor: ativar open_basedir no PHP cria uma cerca que impede a leitura fora da raiz, e ajustar permissões para 0644 em arquivos e 0755 em pastas remove o excesso de acesso. Um hardening de segurança bem feito e o uso de um tratamento correto de entrada do usuário, o mesmo princípio que evita o XSS, fecham a maior parte da superfície de travessia.

A FULL inclui WAF e segurança gerenciada no bundle

A segurança gerenciada da FULL parte de um princípio: bloquear a travessia na borda custa menos que rotacionar todas as chaves depois que o wp-config.php vazou. O plano PRO sai por R$849 e cobre 10 sites, o que dá R$85 por site, com o All in One Security e o firewall de aplicação já no bundle.

Em vez de pagar uma resposta a incidente por site invadido, você fica com o WAF e o monitoramento contínuo rodando. Conheça os planos da FULL e compare com o custo de uma única exposição de credenciais.

Vale o contexto de autoridade aqui: a FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, ou seja, está autorizada a atribuir IDs CVE oficiais. Quem escreve sobre directory traversal por aqui literalmente cataloga vulnerabilidade. Para um diagnóstico rápido, o FULL Scan verifica seu site sem instalação, e o repositório de vulnerabilidades lista os CVEs por plugin.

Perguntas frequentes sobre directory traversal no WordPress

Próximos passos para blindar o site contra directory traversal

Entender o directory traversal muda a prioridade da defesa: bloquear a sequência ../ na borda vale mais que reagir depois que as chaves vazaram. Um plano em camadas combina patch em dia, um plugin de segurança com WAF e o hardening de servidor, de modo que mesmo um plugin com travessia ainda aberta encontre pouca margem. A diferença entre uma leitura barrada e um wp-config.php vazado está no firewall de aplicação, não na força da senha. Para continuar aprendendo, o guia de segurança para WordPress reúne os próximos passos em sequência.