Proteger wp-config WordPress exige negar o acesso direto ao arquivo, movê-lo acima da raiz pública e travar a permissão em 400. Segundo a Patchstack (2024), há 64.782 vulnerabilidades WordPress catalogadas. Uma exposição vaza usuário e senha do banco em segundos. Comece pela permissão do arquivo hoje.

O wp-config.php guarda as credenciais do banco de dados, as chaves de autenticação e o prefixo das tabelas do seu site. Se ele vaza, o atacante não precisa quebrar nenhuma senha: ele lê o usuário e a senha do MySQL direto e assume o site inteiro. Por isso, proteger wp-config vem antes de qualquer plugin de firewall. Neste guia você vai aplicar quatro camadas concretas, da permissão de arquivo ao bloqueio no servidor, e validar cada uma. Para o contexto completo, veja os guias de segurança WordPress da FULL.

Legenda: a permissão 400 é a primeira camada e nunca quebra o site.

Por que o wp-config.php é o alvo mais valioso do seu site

O wp-config.php concentra usuário, senha e host do banco de dados em texto plano, o que o torna o arquivo mais visado numa invasão WordPress. Ler esse arquivo dispensa adivinhar qualquer senha, e é por isso que ele vale mais que o próprio painel administrativo. A gente vê no suporte da FULL que, quando um site cai, o atacante quase sempre já tinha lido essas credenciais antes de tentar força bruta no login.

A exposição raramente vem de falha do núcleo do WordPress. Ela chega por três caminhos: backups baixáveis deixados na raiz, arquivos installer.php de migração e plugins de arquivo com permissão excessiva. A falha CVE-2018-25095 (CVSS 9.8) no Duplicator deixava o installer.php acessível e permitia ler o wp-config remontado. Entender o arquivo wp-config é o primeiro passo defensivo, e é o que esse guia destrava camada a camada.

Tabela de risco: Como o wp-config.php vaza na prática

Três vetores reais respondem pela maioria das exposições de wp-config.php, e os três têm CVE registrada com correção já publicada. Ponto crítico: todas essas CVEs já foram corrigidas, ou seja, são risco apenas em sites desatualizados, nunca no plugin atualizado de hoje. A tabela cruza o vetor, a falha real catalogada no NVD e a ação defensiva correspondente.

Esses dados vêm do perfil público do WPVulnerability e do NVD, a base oficial do NIST. A FULL lê esse cenário com autoridade incomum: é a única empresa brasileira credenciada como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais. Quem escreve aqui sobre vulnerabilidade literalmente cataloga CVE. Na prática, a diferença entre um CVSS 9.8 e um 6.1 define a urgência: a falha crítica do Duplicator permitia leitura remota do arquivo sem autenticação, enquanto falhas médias exigem condições que raramente se combinam em produção.

Pré-requisitos: O que verificar antes de editar o arquivo

Antes de tocar no wp-config.php, faça um backup completo e confirme acesso ao servidor via SFTP ou pelo gerenciador de arquivos da hospedagem. Um único erro de sintaxe nesse arquivo derruba o site inteiro com tela branca, então trabalhar com rede de segurança não é opcional. Reserve cerca de 20 minutos e tenha as credenciais do painel em mãos antes de começar qualquer alteração no arquivo.

Você vai precisar de três coisas: acesso ao diretório raiz do WordPress (onde ficam wp-config.php, wp-load.php e a pasta wp-content), permissão para editar o .htaccess no Apache ou o bloco server no Nginx, e um backup recente guardado fora da raiz pública. Se a hospedagem usa arquivo htaccess, o bloqueio sai por lá, via acesso SFTP. Para um plano maior de blindagem, consulte o guia de hardening de segurança no WordPress antes de seguir.

Passo a passo: Como proteger wp-config em 4 camadas

A proteção do wp-config.php funciona por camadas, e quatro ações cobrem mais de 90% dos vetores reais de exposição. Cada passo abaixo é independente: você pode aplicar todos ou parar onde o ambiente permitir. A ordem importa, comece pela permissão de arquivo, que é a defesa mais rápida e nunca quebra nada no site, e avance até o bloqueio no nível do servidor.

Passo 1: Ajuste a permissão do arquivo para 400 ou 440

Defina a permissão do wp-config.php para 400 (somente leitura pelo dono) ou 440 se o grupo do servidor web precisar ler. No SFTP, clique com o botão direito no arquivo, escolha permissões e digite o valor. Via terminal, rode chmod 400 wp-config.php na raiz do site. Isso impede que outros usuários da mesma hospedagem compartilhada leiam o arquivo, um risco concreto em planos compartilhados onde vários sites dividem o mesmo servidor.

Passo 2: Negue o acesso direto via htaccess no Apache

No Apache, adicione o bloco abaixo ao .htaccess da raiz para retornar 403 a qualquer requisição direta ao arquivo de configuração:

<Files wp-config.php>
  Require all denied
</Files>

Em servidores com Apache 2.2 antigo, troque por Order allow,deny seguido de Deny from all. Esse bloqueio responde antes de o PHP processar a requisição, então protege o arquivo mesmo se o site estiver com erro de aplicação no momento.

Passo 3: Negue o acesso no Nginx via diretiva location

No Nginx não existe .htaccess: o bloqueio vai no bloco server do site. Adicione a diretiva abaixo e recarregue o serviço com nginx -s reload para aplicar sem derrubar conexões:

location ~* wp-config.php {
  deny all;
}

Confirme com o time de hospedagem antes de editar, porque um erro no bloco server derruba todos os sites daquele servidor de uma só vez, e não apenas o seu.

Passo 4: Mova o wp-config.php um nível acima da raiz

O WordPress procura o wp-config.php automaticamente um diretório acima da raiz pública. Se o seu site fica em /public_html, mova o arquivo para a pasta imediatamente acima, fora do alcance do navegador. Nenhuma requisição HTTP alcança arquivos acima da raiz pública, o que elimina o vetor de leitura direta de uma vez. Em hospedagem compartilhada, confirme antes que a sua conta tem acesso ao diretório pai.

Reforço extra: Chaves de segurança e prefixo de tabela

Além de blindar o acesso ao arquivo, dois ajustes dentro do próprio wp-config.php elevam a resistência do site. As chaves de autenticação (AUTH_KEY, SECURE_AUTH_KEY e companhia) embaralham os cookies de sessão; trocá-las invalida todas as sessões ativas, o primeiro movimento após qualquer suspeita de invasão. Gere chaves novas pelo gerador oficial do WordPress e cole no lugar das antigas em menos de um minuto.

O prefixo padrão das tabelas, wp_, é o primeiro alvo de um ataque automatizado de SQL injection, porque o atacante já assume o nome wp_options sem precisar descobrir. Definir um prefixo personalizado como $table_prefix = 'fs7x_'; numa instalação nova adiciona uma camada de obscuridade barata. A confiança aqui é média: não substitui um firewall, mas elimina a varredura cega mais comum que aparece nos logs de tentativa. Em sites já em produção, trocar o prefixo exige editar o banco com cuidado, então deixe esse ajuste para instalações novas.

A camada gerenciada que faz isso por você em escala

Aplicar quatro camadas manualmente num site é viável; fazer isso em dez sites e revalidar a cada atualização de plugin é onde o trabalho vira gargalo. O plano PRO da FULL inclui a camada de segurança gerenciada no bundle: você ativa os plugins de proteção e hardening direto pelo painel, sem licenciar cada um avulso. No plano PRO a R$849,90, o custo sai em torno de R$85 por site para dez sites, ante dezenas de dólares por licença anual avulsa de cada plugin. Conheça em FULL.services/planos. A gente vê no suporte que centralizar a segurança reduz o tempo de resposta a uma CVE nova de dias para minutos, porque a atualização sai para toda a base de uma vez.

Erros comuns ao proteger o wp-config.php

O erro mais frequente que chega ao suporte é a sintaxe quebrada no .htaccess ou no bloco Nginx logo após o hardening. Um sem fechamento ou um ponto e vírgula esquecido no Nginx retorna erro 500 e derruba o site na hora. Sempre teste a sintaxe antes de salvar em produção, de preferência primeiro num ambiente de homologação isolado da raiz pública.

O segundo erro é esquecer os arquivos de rastro. O wp-config-sample.php, backups com extensão .bak e o installer.php de migrações ficam legíveis e expõem a estrutura do site. Remova todos após cada operação de migração ou restauração. Plugins como o All In One WP Security automatizam essa varredura e avisam quando um arquivo sensível volta a ficar exposto. Para sites já comprometidos, siga o passo a passo de como limpar e recuperar um site WordPress hackeado.

Como validar que o wp-config.php está protegido

Depois de aplicar as camadas, valide acessando o arquivo direto pelo navegador: digite o endereço do seu site seguido de /wp-config.php. A resposta correta é um erro 403 (proibido) ou 404 (não encontrado), nunca o conteúdo do arquivo nem uma página em branco que baixa o arquivo. Esse teste leva 10 segundos e é o indicador mais confiável de que o bloqueio funciona de verdade.

Complemente com um scanner externo que checa headers e arquivos expostos sem instalar nada no site. O FULL Scan faz a varredura gratuita e cruza com a base oficial de CVEs; para conferir falhas conhecidas dos seus plugins, consulte o repositório de vulnerabilidades. Confirme também que as permissões seguem em 400 com ls -l wp-config.php no terminal antes de encerrar. Repita o teste do navegador após cada atualização grande de plugin, porque uma migração ou restauração pode reescrever o .htaccess e remover a regra de bloqueio sem aviso nenhum.

Perguntas frequentes sobre proteger wp-config

Próximos passos para blindar o seu WordPress

Proteger wp-config é a base sobre a qual toda a segurança do site se apoia, e as quatro camadas deste guia cobrem os vetores reais que aparecem na prática. Comece pela permissão 400 hoje, valide com o teste do navegador e avance para o bloqueio no servidor conforme o seu ambiente permitir. Cada camada que você adiciona reduz a superfície de ataque sem custo de licença. Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de segurança em um só lugar, e o guia de segurança para WordPress organiza a sequência completa de hardening.