| Vetor | Mecanismo da falha | Sinal de exposição |
|---|---|---|
| Leitura de arquivo (LFI passiva) | Parâmetro de download com ../ lê wp-config.php fora da raiz. | GET com ../../ no log do Apache ou Nginx. |
| Escrita por travessia | Upload grava arquivo em pasta fora de uploads via path. | Plugin de backup ou mídia desatualizado. |
| Inclusão de arquivo (LFI ativa) | include() recebe caminho do usuário e executa o arquivo. | Parâmetro page= ou file= aceitando caminho cru. |
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 . 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 , 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.O directory traversal lê arquivos fora da pasta pretendida via ../; o upload malicioso grava um arquivo novo, como um web shell. Escolha o diagnóstico pelo sintoma: GET com ../../ no log do Apache indica travessia; PHP recente em wp-content/uploads indica upload. O CVE-2024-10932 no Backup Migration é travessia; o CVE-2020-25213 no WP File Manager é upload. O alvo da travessia é o wp-config.php; ferramentas como Wordfence e WPScan detectam ambos.
Porque o vetor não passa pelo formulário de login: ele explora um parâmetro de URL acessível por visitante anônimo. Quando o código entrega `?file=../../../wp-config.php` direto para readfile() sem sanitizar, o PHP sobe os níveis e devolve o arquivo. Com open_basedir desligado, não há cerca que bloqueie a leitura, e as credenciais do banco vazam sem nenhuma autenticação.
O directory traversal é a técnica de escapar da pasta com ../; o LFI (Local File Inclusion) é uma consequência possível dela. Na prática: a travessia que só lê o arquivo é passiva, mas se o caminho cai num include() do PHP, o arquivo é executado, e aí vira LFI ativa. O CVE-2024-10932 no Backup Migration é um exemplo de travessia de leitura registrada no NVD.
Sim, é totalmente possível, porque a falha não depende de software pirata. A travessia mora em plugins legítimos da loja oficial que receberam um parâmetro de caminho sem validação, como mostram os CVEs do Backup Migration e do WP File Manager. Rodar só plugins oficiais reduz o risco de backdoor, mas não imuniza contra um CVE de directory traversal sem patch.
A leitura por travessia pode rodar dias antes do dano visível, porque o atacante primeiro lê as chaves do wp-config.php e só depois as usa. Nos logs que vemos no suporte da FULL, o GET com ../../ aparece bem antes da invasão de fato. Um WAF que bloqueia a sequência ../ reduz essa janela para zero, barrando a tentativa na borda.