Como Proteger /wp-admin/install.php no WordPress

Toda instalação do WordPress inclui um arquivo chamado wp-admin/install.php. Em um site saudável, ele é em sua maioria inofensivo. O WordPress percebe que o site já está configurado e retorna uma curta página "Already Installed". Mas há um caso raro que muitos proprietários de sites subestimam. No momento em que algo dá errado com o banco de dados, esse mesmo arquivo se transforma em um assistente de configuração totalmente funcional. Um invasor que tropeçar nele no momento certo pode reinstalar o WordPress em cima do seu domínio, apontá-lo para um banco de dados que ele controla e sair com um controle completo.

Este guia explica quando install.php é realmente perigoso, quais plugins de segurança genuinamente cobrem esse caso (nem todos cobrem, apesar do que o marketing sugere) e como bloquear o arquivo corretamente. Isso inclui a situação menos confortável em que você está em uma hospedagem compartilhada sem acesso à configuração do servidor.

Quando install.php é realmente um problema?

Se você visitar https://seudominio.com/wp-admin/install.php em um site saudável, o WordPress verifica se a tabela wp_options já contém uma siteurl. Se sim, ele mostra a tela "Already Installed" e fim de história. Sem formulário, sem ação, sem tomada de controle.

O problema começa no momento em que o WordPress não consegue ler esse valor. Cenários típicos:

• As credenciais do banco de dados em wp-config.php foram quebradas (senha errada após uma migração de host, nome de DB digitado errado).
• Alguém apagou ou truncou a tabela wp_options, seja por acidente durante uma migração ou de propósito via uma injeção de SQL em um plugin vulnerável.
• Uma clonagem de staging falhou e deixou o sistema de arquivos no lugar, mas o banco de dados vazio.
• O usuário do banco de dados perdeu permissões em tabelas específicas.

Em todos esses casos, o assistente de configuração se torna disponível para qualquer pessoa na internet. Quem chegar primeiro pode escolher o nome de usuário, a senha e o e-mail do administrador, e efetivamente assumir o domínio. É por isso que essa verificação existe no InspectWP, mesmo que o arquivo seja "normal" em toda instalação do WordPress.

Quais plugins de segurança realmente podem proteger install.php?

Esta é a parte que confunde as pessoas, então vale a pena ser preciso. A maioria das pessoas presume que qualquer plugin de segurança do WordPress cobre automaticamente install.php. Isso é meia verdade. A resposta depende inteiramente de como o plugin carrega.

Um plugin WordPress regular inicializa dentro do WordPress. Ele precisa do banco de dados para começar. Se seu DB estiver quebrado ou vazio (que é o único cenário realista em que install.php se torna perigoso), o WordPress nunca inicializa o suficiente para carregar o plugin. A requisição cai diretamente em install.php e o PHP renderiza alegremente o assistente de configuração. Plugins de segurança que rodam como plugins normais não podem ajudar nessa situação, por definição.

No entanto, vários plugins usam um mecanismo do PHP chamado auto_prepend_file. Essa configuração diz ao PHP para executar um arquivo específico antes de qualquer outro script PHP no servidor. Quando um plugin de segurança se registra dessa forma, ele executa antes do wp-config.php, antes mesmo da conexão com o banco de dados ser tentada, e antes do install.php. Ele tem seus próprios arquivos de configuração e, quando necessário, sua própria conexão com o banco de dados. Uma instalação WordPress quebrada não o afeta.

Plugins que suportam esse modo (e podem, portanto, proteger o install.php mesmo quando o banco de dados do WordPress está caído):

• Wordfence no modo Extended Protection (às vezes chamado de Optimized Mode). Isso não é o padrão após a instalação. Você precisa habilitá-lo explicitamente nas configurações de firewall do Wordfence. Uma vez ativo, um arquivo chamado wordfence-waf.php é colocado na raiz do WordPress e registrado via .htaccess, .user.ini ou php.ini.
• NinjaFirewall (WP Edition). Usa auto_prepend_file como modo padrão. Está configurado dessa forma na instalação, sem necessidade de alternar nada.
• NinjaFirewall (Pro / Full WAF). Mesmo mecanismo, mas registrado no nível do servidor. Roda completamente fora do WordPress.
• BitFire Security. Suporta um modo "Always On Protection", também baseado em auto_prepend_file. Comportamento comparável ao Wordfence Extended Protection.
• Shield Security (ShieldPRO). Também carrega via auto_prepend_file, embora adote uma abordagem mais conservadora e não modifique .htaccess diretamente.
• MalCare. Usa auto_prepend_file como parte de sua configuração de WAF.

Plugins que não conseguem bloquear install.php quando o WordPress está quebrado, porque rodam como plugins normais do WordPress:

• Wordfence no Modo Básico padrão (antes de você habilitar a Extended Protection).
• Solid Security (anteriormente iThemes Security). Não vem com um WAF que rode antes do WordPress.
• All-In-One WP Security & Firewall. Bom em fortalecimento de arquivos e login, mas roda dentro do WordPress.
• A maioria dos firewalls baseados em plugin que não dependem de auto_prepend_file.

Uma consequência prática: se você usa Wordfence, vá em Wordfence, Firewall, Manage WAF, e verifique se a mensagem diz "Optimized" ou "Extended Protection Enabled". Se ainda diz Basic Mode, o assistente de otimização guia você na configuração do auto_prepend_file para seu servidor. Essa única alteração é o que transforma o Wordfence de um plugin reativo em um firewall genuíno pré-WordPress.

Uma ressalva para ambos os caminhos. O mecanismo requer que seu host realmente permita auto_prepend_file via .htaccess, .user.ini ou php.ini. Na maioria dos hosts compartilhados isso funciona prontamente. Em alguns hosts gerenciados mais restritivos, a configuração é restrita, e o assistente de otimização falhará silenciosamente ou mostrará um aviso. Nesse caso você volta à abordagem de regra do servidor web descrita abaixo.

Opção 1: Bloquear install.php via .htaccess (Apache)

Se seu host roda Apache (que é o que a maioria dos provedores de hospedagem compartilhada como IONOS, Strato, All-Inkl, Hostinger, DomainFactory, SiteGround, Bluehost usa), você pode adicionar o seguinte bloco ao arquivo .htaccess no diretório raiz do seu WordPress:

<Files "install.php">
  Require all denied
</Files>

Isso funciona no Apache 2.4 e superior, que é o que praticamente todo host vem rodando há anos. Se você está em algo mais antigo (Apache 2.2), use a sintaxe legada:

<Files "install.php">
  Order allow,deny
  Deny from all
</Files>

Coloque o trecho acima do marcador # BEGIN WordPress para que o gerenciamento automático de regras de reescrita do WordPress não o toque durante atualizações.

Após salvar o arquivo, visite https://seudominio.com/wp-admin/install.php em uma janela privada do navegador. Você deve ver uma resposta 403 Forbidden. Se ainda vir a página "Already Installed", os overrides de .htaccess estão desabilitados em seu host. Pule para a Opção 3.

Opção 2: Bloquear install.php via nginx

No nginx não há .htaccess. Se você gerencia seu próprio servidor (VPS, dedicado ou um host flexível como Hetzner Cloud), adicione isto dentro do bloco server do seu site:

location = /wp-admin/install.php {
  deny all;
  return 403;
}

Recarregue o nginx com sudo nginx -t && sudo systemctl reload nginx e teste com curl -I https://seudominio.com/wp-admin/install.php. Você deve receber um 403.

Alguns hosts gerenciados que usam nginx por baixo (como Raidboxes, Kinsta, WP Engine) já vêm com esse tipo de regra. Vale a pena verificar a documentação do seu host ou abrir um ticket de suporte. A resposta geralmente é "já está coberto" ou eles adicionam a regra para você.

Opção 3: Hospedagem compartilhada sem overrides do Apache

Se você está em um host compartilhado nginx e o .htaccess é ignorado, você tem menos opções, mas não está preso. Em ordem de preferência:

1. Instale um dos firewalls pré-WordPress listados acima. Em hosts compartilhados onde auto_prepend_file é permitido, um plugin como NinjaFirewall ou Wordfence em modo Extended Protection oferece a mesma proteção que uma regra de servidor, sem tocar em qualquer configuração de servidor. Esse é frequentemente o caminho mais pragmático.
2. Pergunte ao seu host. A maioria dos hosts gerenciados de WordPress adicionará uma regra no nível do servidor para você se você pedir. Leva cinco minutos para eles e fazem isso rotineiramente.
3. Substitua o conteúdo do arquivo. Você pode abrir wp-admin/install.php via SFTP e substituir o arquivo inteiro por uma única linha:

   <?php // intentionally disabled, see install.php.bak

   Mantenha um backup do original (install.php.bak) fora da raiz pública da web caso você precise legitimamente reinstalar. A desvantagem: as atualizações do núcleo do WordPress restaurarão o arquivo original, então você precisa reaplicar a alteração após cada atualização principal. Um pequeno must-use plugin pode automatizar isso (veja o trecho de código relacionado).
4. Negar por permissões de arquivo. Alterar o modo do arquivo para 000 via SFTP também bloqueia o acesso na maioria dos hosts. Mesma ressalva: as atualizações do núcleo redefinirão.

E quanto a renomear ou excluir install.php?

Tecnicamente você pode excluir install.php inteiramente. O WordPress não precisa dele para operação normal. Ele é usado apenas durante a configuração inicial e para algumas rotinas internas de atualização. O problema é que o arquivo é restaurado a cada atualização do núcleo do WordPress, então a exclusão não é uma solução permanente. Ele também ocasionalmente é referenciado pelo processo de atualização automática, então você pode ver avisos em seu log de erros se ele estiver faltando.

Renomear é ainda pior. O WordPress não encontrará o arquivo com seu novo nome, mas recriará alegremente o original durante a próxima atualização. Você acaba com duas cópias.

Bloquear o acesso no nível do servidor web, ou via um firewall pré-WordPress, é quase sempre a melhor resposta.

Como verificar sua configuração

Após aplicar uma das opções acima:

1. Abra https://seudominio.com/wp-admin/install.php em uma janela privada ou anônima.
2. Você deve ver uma página 403 Forbidden (ou 404 se removeu o arquivo, ou a página de bloqueio personalizada do firewall se foi pelo caminho do plugin).
3. Se você vir a página "Already Installed" ou, muito pior, um formulário de configuração real, a regra não está ativa. Verifique novamente o caminho do arquivo, limpe quaisquer caches (Cloudflare, Varnish, cache de página no nível do servidor) e tente novamente.
4. Execute uma nova varredura do InspectWP. A verificação "install.php exposto" na seção do WordPress deve ficar verde.

Verificações relacionadas que vale a pena rodar

Enquanto está bloqueando coisas, o mesmo tipo de bloqueio no nível do servidor web (ou regra de firewall pré-WordPress) vale a pena aplicar a alguns outros endpoints sensíveis: xmlrpc.php (a menos que você use ativamente), wp-config.php.bak, .git/, .env e quaisquer arquivos phpinfo.php que um desenvolvedor possa ter deixado para trás. O InspectWP sinaliza todos esses automaticamente em sua seção de segurança.

O caso install.php é um bom exemplo de defesa em profundidade. O WordPress se protege, um plugin de segurança bem configurado adiciona outra camada e uma regra de servidor web cobre o cenário em que ambos podem falhar. Escolha a combinação que corresponda ao seu host. Cinco linhas de configuração, ou um toggle em um plugin de firewall, são suficientes para fechar a brecha de vez.