Como Bloquear readme.html e license.txt no WordPress

Abra qualquer site WordPress no mundo e adicione /readme.html à URL. Na grande maioria dos casos você obterá uma página HTML limpa que orgulhosamente anuncia a versão exata do WordPress no título. A mesma história para /license.txt, que é ligeiramente menos específico mas ainda confirma que o site roda WordPress e dá uma ideia aproximada de quão recente é a instalação.

Ambos os arquivos vêm com o núcleo do WordPress. Eles são restaurados a cada atualização. Nenhum deles é necessário para o site funcionar. O único público que eles realisticamente servem são scanners automatizados que fazem fingerprinting de sites pela versão do núcleo para que possam combinar o resultado com uma lista de vulnerabilidades conhecidas. Este guia explica por que isso importa na prática e como bloquear os arquivos de forma limpa no Apache, no nginx e na hospedagem compartilhada onde você tem menos controle direto.

Por que importa que readme.html seja acessível?

A resposta honesta é: por si só, não muito. Saber a versão do WordPress de um site não é uma vulnerabilidade. A versão do núcleo do WordPress não é um segredo, e um invasor determinado geralmente consegue descobri-la de qualquer maneira, por exemplo das meta tags geradoras, do parâmetro de versão em scripts e estilos enfileirados, ou da estrutura da resposta da REST API.

O que muda o cenário é a maneira como a exploração funciona em escala hoje. Scanners em massa não escolhem um alvo e depois procuram bugs. Eles escolhem um CVE, constroem uma lista de cada domínio na internet rodando uma versão afetada e disparam o exploit contra a lista inteira. A maneira mais barata de construir essa lista é buscar readme.html em milhões de domínios em paralelo e analisar a versão do título. Qualquer coisa que torne o site invisível para essa etapa de filtro o remove da lista de candidatos antes que o exploit real seja executado.

Então remover readme.html não torna o site seguro. Remove um dos fingerprints mais baratos, o que na prática significa que você para de aparecer em listas automatizadas de "sites WordPress rodando a versão X.Y.Z". Isso vale alguns minutos de trabalho, mesmo que não seja o fortalecimento de segurança mais crítico que você pode fazer.

E quanto a license.txt e outros arquivos do núcleo?

Mesma família de arquivo, ligeiramente menos interessante:

• license.txt contém o texto da licença GPL. Não inclui um número de versão, mas sua existência na raiz do WordPress é um forte sinal de que o site roda WordPress.
• wp-config-sample.php vem com toda instalação. Não contém credenciais, mas revela que ninguém arrumou após a configuração.
• readme.html é o que tem o problema de divulgação de versão.

A regra de bloqueio abaixo cobre os três de uma só vez. Não há boa razão para deixar qualquer um deles publicamente acessível.

Opção 1: Bloquear via .htaccess (Apache e LiteSpeed)

Se seu host roda Apache ou LiteSpeed (que cobre a maioria dos hosts compartilhados no mercado de língua alemã: All Inkl, IONOS, Strato, DomainFactory, Hostinger e a maioria dos revendedores), você pode adicionar o seguinte bloco ao arquivo .htaccess no diretório raiz do seu WordPress:

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
  Require all denied
</FilesMatch>

O trecho usa a sintaxe do Apache 2.4, que é o que todo host vem rodando há anos. Se você está preso ao Apache 2.2 (extremamente raro em 2026, mas possível em hospedagem legada), use a sintaxe mais antiga:

<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
  Order allow,deny
  Deny from all
</FilesMatch>

Coloque o bloco acima do marcador # BEGIN WordPress. Tudo entre # BEGIN WordPress e # END WordPress é gerenciado pelo próprio WordPress e é reescrito quando os permalinks mudam ou as atualizações do núcleo são executadas. Qualquer coisa fora desses marcadores é deixada em paz.

Após salvar o arquivo, abra https://seudominio.com/readme.html em uma janela privada do navegador. Você deve obter um 403 Forbidden. O mesmo para /license.txt. Se ainda vir o conteúdo do arquivo, seu host ou ignora .htaccess inteiramente (raro no Apache, normal no nginx) ou tem AllowOverride definido como um valor que remove diretivas FilesMatch. Pule para a Opção 3.

Opção 2: Bloquear via nginx

No nginx não há .htaccess. Se você roda seu próprio servidor (um VPS na Hetzner, Netcup, DigitalOcean, ou um host nginx gerenciado onde controla a configuração), adicione o seguinte dentro do bloco server do seu site:

location ~* ^/(readme\.html|license\.txt|wp-config-sample\.php)$ {
  deny all;
  return 403;
}

Recarregue o nginx com sudo nginx -t && sudo systemctl reload nginx, depois teste com curl -I https://seudominio.com/readme.html. A primeira linha da resposta deve ser HTTP/2 403.

Vários hosts gerenciados de WordPress que usam nginx internamente (Raidboxes, Kinsta, WP Engine, Cloudways) entregam regras desse tipo por padrão. Vale a pena verificar a documentação do host. Se não, o suporte geralmente adicionará a regra para você mediante solicitação.

Opção 3: Hospedagem compartilhada onde overrides de .htaccess não funcionam

Alguns hosts compartilhados restritos rodam nginx e ignoram .htaccess inteiramente. Outros rodam Apache mas com regras restritivas de AllowOverride. Se nem a Opção 1 nem a Opção 2 estão disponíveis, você tem três fallbacks razoáveis, ordenados pela durabilidade:

1. Use um plugin de segurança que lide com o fortalecimento de arquivos do núcleo para você. Solid Security e All In One WP Security & Firewall ambos têm um toggle "remover arquivos do núcleo" ou "ocultar versão do WordPress" que cuida do readme.html. Wordfence em modo Extended Protection também pode bloquear os arquivos na camada WAF. A vantagem é que essas configurações sobrevivem automaticamente às atualizações do WordPress.
2. Esvazie o arquivo via um Must Use plugin. Se uma regra no nível do servidor é impossível, a abordagem mais confiável é um pequeno mu plugin que sobrescreve readme.html e license.txt com conteúdo vazio após cada atualização do WordPress. Veja o artigo de trecho de código relacionado em nossa base de conhecimento.
3. Exclua os arquivos manualmente. A correção mais rápida leva dez segundos via SFTP: apenas exclua readme.html, license.txt e wp-config-sample.php da raiz do WordPress. O problema é que as atualizações do núcleo do WordPress restauram os arquivos. Você precisa lembrar de excluí-los novamente após cada grande atualização, e por isso um plugin ou regra do servidor web é a melhor resposta de longo prazo.

O que você não deve fazer

Algumas abordagens que aparecem em posts de blog mais antigos, mas são piores do que parecem:

• Renomear os arquivos. Renomear readme.html para readme.html.old parece arrumado, mas não ajuda. O WordPress simplesmente cria o original novamente na próxima atualização e agora você tem dois arquivos em vez de um.
• Definir permissões de arquivo como 000. Isso bloqueia leituras na maioria dos hosts, mas a próxima atualização do núcleo redefine as permissões e, em alguns hosts, também quebra a própria atualização se o WordPress não puder ler o arquivo durante o processo de atualização.
• Editar os arquivos para remover o número da versão. Tentador, mas inútil. O WordPress restaura o original na atualização e mesmo um readme.html editado ainda confirma que o site roda WordPress.

O padrão é o mesmo a cada vez: qualquer coisa que viva dentro do diretório de instalação do WordPress e não esteja protegida por uma regra do servidor web será redefinida na atualização. Bloqueie no nível do servidor web, ou use um plugin que saiba como manter-se ativo através de atualizações.

Como verificar sua configuração

1. Abra https://seudominio.com/readme.html em uma janela privada. Resultado esperado: uma página 403 Forbidden (ou 404 se você seguiu pelo caminho da exclusão).
2. Mesma verificação para https://seudominio.com/license.txt e https://seudominio.com/wp-config-sample.php.
3. Se ainda vir o conteúdo do arquivo, limpe quaisquer caches que ficam na frente do site (Cloudflare, Varnish, caches de página do lado do servidor como LiteSpeed Cache ou WP Rocket) e tente novamente. Respostas em cache podem ocultar a alteração por horas.
4. Execute uma nova varredura do InspectWP. A verificação de readme.html exposto na seção de segurança deve ficar verde.

Já que está nisso

O mesmo tipo de regra FilesMatch ou location vale a pena aplicar a alguns outros endpoints que aparecem regularmente nas varreduras do InspectWP: wp-config.php.bak, wp-config.php.swp, .git/, .env, phpinfo.php e qualquer info.php que um desenvolvedor tenha deixado para trás durante a depuração. Mesmo mecanismo, mesmas cinco linhas de configuração, e você remove uma classe inteira de fingerprinting casual e vazamentos de credenciais de uma só vez.