# File inclusion no WordPress: Os 2 tipos e como se proteger
File inclusion no WordPress carrega um arquivo arbitrário por meio de um parâmetro não tratado e pode virar execução de código. Segundo a Patchstack (2024), foram 7.966 novas vulnerabilidades no ecossistema. Quase todas moram em plugins, não no core. A defesa começa por validar todo caminho de arquivo.
File inclusion é uma falha em que um parâmetro controlado pelo visitante decide qual arquivo o PHP vai carregar, sem que o código valide esse caminho antes. Quando isso acontece, o atacante deixa de pedir uma página e passa a pedir um arquivo qualquer: o `wp-config.php` com as credenciais do banco, ou um arquivo que ele mesmo enviou e que contém código. O WordPress core não usa `include()` com dado do usuário, então o risco real quase nunca está no núcleo. Ele aparece em plugins de terceiros que montam o caminho do arquivo por concatenação. Antes de seguir, vale entender o panorama de vulnerabilidades WordPress da FULL.
---
## O que é file inclusion no WordPress na prática
File inclusion ocorre quando um valor enviado pelo visitante define qual arquivo o PHP carrega, sem passar por uma sanitização de caminho. Um exemplo direto: um plugin monta `include($_GET['page'] . '.php')`. Se o visitante envia `page=../../../../wp-config.php%00`, o código tenta incluir o arquivo de configuração e expõe usuário e senha do banco MySQL em tela.
A causa raiz é sempre a mesma, um parâmetro de caminho virando instrução de carregamento. O PHP não distingue um nome de template legítimo de um caminho de ataque disfarçado de template. Quem faz essa distinção é o código do plugin, na hora de resolver qual arquivo abrir. Quando esse passo é pulado, o servidor abre o que receber. Nos tickets da FULL, é um padrão caro de limpar: a falha costuma vazar credenciais antes de qualquer alerta soar no painel, e a contenção envolve rotacionar senha de banco e auditar o que foi lido.
## LFI e RFI: Os 2 tipos de file inclusion
File inclusion se divide em dois tipos, e a diferença está em onde o arquivo carregado mora. Na LFI (Local File Inclusion), o atacante força o PHP a abrir um arquivo que já existe no servidor, como `wp-config.php` ou um log com sessão válida. Na RFI (Remote File Inclusion), ele aponta o parâmetro para um arquivo hospedado em servidor externo, transformando a falha em execução de código remoto direta.
A RFI quase desapareceu no PHP moderno: desde o PHP 5.2 a diretiva `allow_url_include` vem desligada por padrão, e sem ela `include()` não busca URL externa. Por isso a esmagadora maioria dos casos reais hoje é LFI. A tabela abaixo resume os dois tipos lado a lado.
File inclusion no WordPress: LFI e RFI comparados
Tipo
Origem do arquivo
Condição necessária
Risco atual
LFI (Local)
Arquivo já presente no servidor
Parâmetro de caminho sem validação
Alto, é o caso comum hoje
RFI (Remote)
Arquivo em servidor externo
allow_url_include ativado no php.ini
Baixo, desligado por padrão
## Como uma inclusão real acontece: Cves do ecossistema
Em 2024 o WordPress acumulou 7.966 vulnerabilidades novas catalogadas pela Patchstack, e a file inclusion está entre as de maior severidade por levar a leitura de arquivos sensíveis ou a execução de código. O caso mais conhecido do ecossistema é o WP File Manager, que carregou a CVE-2020-25213 (CVSS 9.8), em que um endpoint sem checagem permitia incluir e executar um arquivo enviado pelo atacante. O Duplicator carregou a CVE-2020-11738 (CVSS 7.5), um directory traversal que lia arquivos arbitrários como o `wp-config.php`.
São CVEs históricas, não risco de hoje: a do WP File Manager foi fechada na versão 6.9 e a do Duplicator na 1.3.28. Um plugin com muitas CVEs corrigidas sinaliza manutenção ativa, não perigo. O perigo está em quem não aplicou o patch. A FULL acompanha esse fluxo de perto: por ser a única CNA brasileira sob a CISA desde maio de 2022, ela cataloga identificadores CVE oficiais.
## Por que a falha quase sempre vem de plugins, não do Core
O WordPress core raramente é o ponto de entrada de uma file inclusion porque ele carrega templates por funções internas com caminho fixo, nunca concatenando input do usuário direto num `include()`. O peso recai sobre extensões de terceiros: das 7.966 falhas de 2024, a esmagadora maioria foi em plugins e temas, com participação mínima do core.
Um plugin de gerenciamento de arquivos com parâmetro de caminho exposto, somado à ausência de um firewall de aplicação, é a combinação que permite ler o `wp-config.php` e vazar as credenciais do banco. Na base de 150 mil sites geridos pela FULL, a inclusão bem-sucedida quase nunca explora o núcleo: ela explora o plugin de arquivos, de backup ou de tema que ficou parado numa versão antiga. Pior ainda quando há upload sem checagem de extensão no mesmo plugin: o atacante envia um arquivo, usa a LFI para incluí-lo e ganha um shell remoto. A lição prática, o gargalo não é o WordPress, é a higiene de atualização das extensões.
## Como detectar file inclusion no seu WordPress
Detectar file inclusion antes do estrago exige olhar três sinais: requisições com `../` ou `%00` nos parâmetros, acessos inesperados a `wp-config.php` nos logs e arquivos novos em diretórios de upload. Um WAF como o Wordfence ou o All-in-One Security registra padrões de directory traversal e bloqueia a requisição antes de ela chegar ao `include()`.
Ferramentas de auditoria varrem o site contra a base de CVEs e apontam qual plugin está vulnerável. Quem prefere um diagnóstico imediato pode rodar o FULL Scan, que varre o site contra a base global de CVEs sem instalar nada, ou consultar a lista de ferramentas de verificação da FULL. A regra de campo é simples: parâmetro que termina em nome de arquivo e aceita `../` merece auditoria imediata, porque é exatamente o vetor que a LFI explora.
## Como corrigir e prevenir a falha de forma definitiva
Corrigir file inclusion no WordPress significa atacar a causa, não o sintoma: nenhum caminho de arquivo deve vir de input do usuário sem validação por allowlist, e o site precisa manter os plugins atualizados. Validar com allowlist é definir a lista fechada de arquivos que o código pode abrir e recusar qualquer valor fora dela.
Esse é o motivo de a allowlist resolver a raiz: mesmo que o atacante envie `../../wp-config.php`, o valor não está na lista permitida e o PHP nunca chega a incluí-lo.
Para quem não escreve o código dos plugins, a defesa em camadas é o caminho realista: manter um plugin de segurança WordPress ativo, fazer backup regular do site antes de cada atualização e aplicar o hardening de segurança. A configuração correta do Wordfence bloqueia directory traversal na borda. File inclusion é prima do cross-site scripting (XSS): as duas nascem do mesmo erro de tratar input não confiável.
Legenda: o WAF intercepta a requisição com padrão de traversal na borda, antes de o caminho malicioso alcançar a função include.
## Segurança gerenciada no bundle da FULL
A defesa contra file inclusion depende de manutenção contínua, e é aí que o modelo da FULL muda a conta. O plano PRO da FULL custa R$849 por ano e inclui uma camada de segurança gerenciada com WAF e plugins como o All-in-One Security já licenciados no bundle, somados ao monitoramento de CVEs.
Diluído nos sites que o plano PRO cobre, isso dá cerca de R$85 por site, com atualização e varredura acompanhadas em vez de manuais. É a diferença entre depender de lembrar de atualizar cada plugin e ter essa atualização vigiada por quem cataloga CVE oficialmente. Para o gestor de vários sites, esse acompanhamento contínuo costuma sair mais barato que uma única limpeza de invasão, que envolve restaurar backup, rotacionar credenciais e auditar o que foi lido. Conheça os planos da FULL.
---
Perguntas frequentes sobre file inclusion no WordPress
O que é file inclusion no WordPress em uma frase?
File inclusion no WordPress é a falha em que um parâmetro controlado pelo visitante decide qual arquivo o PHP carrega, sem validação de caminho. Acontece quando um plugin monta o include por concatenação, usando dado do usuário direto no caminho. O resultado típico é leitura do wp-config.php e vazamento das credenciais do banco MySQL.
Qual a diferença entre LFI e RFI no WordPress?
LFI (Local File Inclusion) força o PHP a abrir um arquivo que já existe no servidor, como o wp-config.php. RFI (Remote File Inclusion) aponta o parâmetro para um arquivo em servidor externo, o que exige a diretiva allow_url_include ativada. Como essa diretiva vem desligada por padrão desde o PHP 5.2, quase todos os casos reais hoje são LFI, não RFI.
Por que plugins de gerenciamento de arquivos causam file inclusion no WordPress?
Porque esses plugins lidam com caminhos de arquivo como tarefa central e às vezes expõem esse caminho num parâmetro sem validar a allowlist. O WP File Manager, por exemplo, carregou a CVE-2020-25213 de CVSS 9.8, fechada na versão 6.9. Quem ficou na versão antiga seguia exposto. Em 2024 a maioria das 7.966 vulnerabilidades catalogadas estava em plugins, não no core.
É possível sofrer file inclusion usando só o WordPress core sem plugins?
É improvável, porque o core carrega templates por funções internas com caminho fixo e nunca concatena input do usuário direto num include. O risco real surge quase sempre de plugins e temas de terceiros que montam o caminho do arquivo de forma dinâmica. Um site só com core e tema padrão atualizados tem superfície de ataque muito menor, embora nunca exatamente zero.
Quando vale a pena contratar um WAF gerenciado contra file inclusion?
Vale a pena quando o site roda plugins de terceiros e você não consegue auditar o código de cada um, que é o caso da maioria. Um WAF gerenciado bloqueia padrões de directory traversal na borda antes de chegar ao include e monitora CVEs novas automaticamente. No bundle da FULL, essa camada sai por volta de R$85 por site, contra a alternativa de revisar manualmente cada atualização de plugin.
## Próximos passos para blindar seu site contra inclusão de arquivos
File inclusion no WordPress não é um problema do WordPress, e sim da higiene das extensões instaladas. A falha vive em plugins que carregam arquivos a partir de input não validado, e a defesa real combina três hábitos: manter tudo atualizado, validar todo caminho de arquivo por allowlist e rodar uma camada de WAF que bloqueie directory traversal antes do include. As CVEs históricas como a CVE-2020-25213 mostram que o ecossistema corrige rápido; o risco fica com quem não acompanha esse ritmo e deixa o hardening de lado.
Para aprofundar a defesa, comece pela consulta ao repositório de vulnerabilidades e siga para os materiais reunidos no FULL Academy, que organiza guias, tutoriais e auditorias de segurança em um só lugar. O guia de segurança para WordPress conecta este conceito às práticas de hardening do dia a dia.