O Worm no Core: Um Dossiê Investigativo sobre o `wp-load.php
A primeira vez que vi o `wp-load.php` ser usado como arma, foi num servidor compartilhado na深夜 de 2017. Um plugin de cache com uma brecha minúscula estava carregando o core do WordPress a partir de um diretório público. O resultado? Uma backdoor silenciosa que permitia ler o `wp-config.php` de qualquer site no mesmo host.
Esse arquivo, que deveria ser um simples bootstrap, virou o calcanhar de Aquiles de milhares de sites. Vamos dissecar por que.
O que é e como (deveria) funcionar
`wp-load.php` é o coração do bootstrap WordPress. Sua função é trivial: incluir `wp-config.php`, carregar constantes, iniciar a sessão e chamar o `wp-settings.php`. Em teoria, ele só deveria ser executado pelo `index.php` na raiz. Mas a prática é outra história.
Muitos desenvolvedores, em busca de integrar o WordPress a sistemas externos (headless, CRMs, dashboards customizados), usam `wp-load.php` diretamente. Um exemplo clássico:
require_once('/caminho/absoluto/para/wp-load.php');Isso expõe o caminho real no servidor. Se o script estiver num subdiretório público, qualquer um pode acessá-lo e causar um erro fatal que revela o caminho absoluto. Mas o pior está por vir.
O Exploit Esquecido: Inclusão Remota e Local
Quando `wp-load.php` é incluído a partir de um local diferente da raiz, as constantes `ABSPATH` e `WP_CONTENT_DIR` podem ser manipuladas. Em plugins mal escritos, é possível forçar a inclusão de arquivos arbitrários via parâmetros GET ou POST.
Um caso real: um plugin de cache popular (que não nomearei) usava `wp-load.php` num script AJAX sem sanitização. Com um simples `?file=../../wp-config.php`, eu conseguia ler o arquivo de configuração. O erro era tratado, mas o conteúdo era exibido em parte.
Core Web Vitals e o Inimigo Invisível
O Google penaliza sites lentos. Agora imagine que seu `wp-load.php` está sendo chamado por um script externo a cada requisição de API. Isso duplica o bootstrap, aumenta o TTFB e destrói o LCP.
Um cliente meu tinha um site headless com React consumindo a REST API. O desenvolvedor colocou um `require(‘wp-load.php’)` no arquivo `api.php` para usar funções do WordPress. Resultado: cada requisição da API carregava o WordPress duas vezes (uma pela API, outra pelo script). O TTFB foi de 200ms para 1.2s.
A solução foi substituir o `wp-load.php` por uma chamada direta à REST API, eliminando o bootstrap duplicado. Mas a maioria dos sites nem sabe que isso está acontecendo.
Licenças GPL e a Falsa Segurança
Por ser GPL, muitos desenvolvedores se sentem à vontade para modificar `wp-load.php`. Já vi versões com `error_reporting(0)` e caminhos hardcoded. Isso quebra a portabilidade e introduz vulnerabilidades. Um exemplo: um tema premium usava um `wp-load.php` modificado que ignorava a constante `WP_DEBUG`. Quando ativado, erros de produção eram silenciados, mas o arquivo continuava vulnerável a ataques de inclusão.
Estudo de Caso Reverso: Como Matei um Site com um `require`
Não foi intencional, mas serviu de lição. Eu precisava integarrar um script de processamento de imagens ao WordPress. Usei `wp-load.php` diretamente num subdiretório. O script funcionava, mas após um pico de tráfego, o servidor ficou sobrecarregado. Cada requisição ao script carregava o WordPress inteiro, consumindo memória e CPU. O site caiu.
A análise mostrou que o `wp-load.php` estava sendo chamado centenas de vezes por minuto, cada uma iniciando sessão, carregando plugins e temas. A solução foi reescrever o script para usar a REST API, reduzindo o consumo em 80%.
Manifesto Técnico: Nunca Inclua `wp-load.php` Fora da Raiz
Depois de anos vendo esses problemas, minha recomendação é radical: proibir a inclusão de `wp-load.php` em qualquer contexto fora do `index.php`. Use a REST API, WP-CLI ou um micro-framework com as bibliotecas necessárias.
Se precisar de funções do WordPress em um script externo, considere:
- Usar a REST API com autenticação de aplicação
- Utilizar WP-CLI via shell_exec (com cuidado)
- Criar um plugin que exponha endpoints via WordPress Ajax
Em casos extremos, se a inclusão for inevitável, siga estas regras:
- Coloque o script em um diretório acima do public_html
- Use caminhos relativos baseados em `__FILE__`
- Desative erros e use `WP_DEBUG` falso
- Limite o acesso via `.htaccess` ou firewall
O `wp-load.php` não é seu inimigo, mas tratá-lo com descaso é cavar a própria cova digital.
O Futuro Headless e o Legado do `wp-load.php
Com o crescimento do headless WordPress, o `wp-load.php` se torna ainda mais perigoso. Cada micro-serviço que o inclui gera um bootstrap completo. A saída é usar a REST API com token JWT e cache de queries.
Um exemplo: um site de e-commerce headless que precise verificar o estoque. Em vez de incluir `wp-load.php` e chamar funções internas, crie um endpoint personalizado que retorne apenas os dados necessários. Isso reduz latência e evita riscos de segurança.
Lembre-se: o core do WordPress é maravilhoso, mas não foi feito para ser compartilhado em múltiplos contextos. Respeite sua arquitetura e ele te recompensará com velocidade e segurança.
E aquela história de 2017? O servidor foi migrado, as brechas corrigidas, e o `wp-load.php` nunca mais foi usado fora da raiz. Até hoje, quando vejo um script suspeito, lembro: o worm no core está sempre à espreita.