readme.html und license.txt in WordPress sperren

Ruf eine beliebige WordPress Seite auf und häng /readme.html an die URL an. In den allermeisten Fällen bekommst du eine saubere HTML Seite, die in der Überschrift gleich die exakte WordPress Version verrät. Bei /license.txt sieht es ähnlich aus, etwas weniger konkret, aber es bestätigt zumindest, dass die Seite mit WordPress läuft, und gibt einen groben Hinweis darauf, wie aktuell die Installation ist.

Beide Dateien gehören zum WordPress Core. Sie werden bei jedem Update wiederhergestellt. Keine von beiden ist für den Betrieb der Seite nötig. Das einzige Publikum, das sie realistisch ansprechen, sind automatisierte Scanner, die Seiten anhand ihrer Core Version fingerprinten, um sie anschließend gegen Listen bekannter Schwachstellen abzugleichen. In dieser Anleitung erfährst du, warum das in der Praxis relevant ist und wie du die Dateien auf Apache, auf nginx und im Shared Hosting sauber sperrst.

Warum ist es ein Problem, dass readme.html erreichbar ist?

Ehrliche Antwort: Für sich genommen kein riesiges. Die WordPress Version einer Seite zu kennen, ist keine Schwachstelle. Die Version ist kein Geheimnis, und ein motivierter Angreifer kann sie sich meistens auch über andere Wege beschaffen, etwa über das Generator Meta Tag, den Version Query Parameter an eingebundenen Skripten und Styles oder über die Struktur der REST API Antworten.

Das Bild ändert sich, sobald man anschaut, wie Massenexploits heute ablaufen. Scanner suchen sich nicht erst ein Ziel und dann eine Lücke. Sie nehmen eine bekannte CVE, bauen sich eine Liste aller Domains im Netz, die eine betroffene Version laufen haben, und feuern den Exploit gegen die ganze Liste. Der billigste Weg, diese Liste zu bauen, ist, auf Millionen von Domains parallel readme.html aufzurufen und die Versionsnummer aus der Überschrift rauszulesen. Alles, was deine Seite in diesem Filterschritt unsichtbar macht, nimmt dich aus der Kandidatenliste raus, bevor der eigentliche Exploit überhaupt zum Einsatz kommt.

Readme.html zu entfernen macht die Seite also nicht sicher. Es nimmt aber einen der billigsten Fingerabdrücke vom Tisch, was in der Praxis bedeutet, dass du in automatisierten Listen "WordPress Seiten mit Version X.Y.Z" einfach nicht mehr auftauchst. Das sind ein paar Minuten Arbeit wert, auch wenn es nicht das wichtigste Security Hardening ist.

Was ist mit license.txt und den anderen Core Dateien?

Selbe Familie, etwas weniger interessant:

• license.txt enthält den GPL Lizenztext. Keine Versionsnummer drin, aber die schiere Existenz im WordPress Root ist ein deutliches Indiz, dass die Seite WordPress nutzt.
• wp-config-sample.php kommt mit jeder Installation mit. Sie enthält keine Zugangsdaten, signalisiert aber, dass nach dem Setup nicht aufgeräumt wurde.
• readme.html ist die mit dem eigentlichen Versions Disclosure Problem.

Die Sperrregel weiter unten deckt alle drei Dateien in einem Aufwasch ab. Es gibt keinen guten Grund, eine davon öffentlich erreichbar zu lassen.

Option 1: Per .htaccess sperren (Apache und LiteSpeed)

Wenn dein Hoster Apache oder LiteSpeed einsetzt (das deckt den Großteil des Shared Hosting Markts in DACH ab: All Inkl, IONOS, Strato, DomainFactory, Hostinger und die meisten Reseller), trägst du folgenden Block in die .htaccess im WordPress Wurzelverzeichnis ein:

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

Die Syntax oben ist Apache 2.4, also genau das, was praktisch jeder Hoster seit Jahren laufen lässt. Solltest du auf Apache 2.2 hängen (sehr selten im Jahr 2026, aber bei Legacy Hosting möglich), nimmst du die alte Syntax:

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

Trag den Block oberhalb der # BEGIN WordPress Marke ein. Alles zwischen # BEGIN WordPress und # END WordPress wird von WordPress selbst verwaltet und bei Permalink Änderungen oder Core Updates neu geschrieben. Was außerhalb dieser Marken steht, lässt WordPress in Ruhe.

Nach dem Speichern öffnest du https://deinedomain.de/readme.html in einem privaten Browserfenster. Du solltest ein 403 Forbidden bekommen. Dasselbe für /license.txt. Wenn du trotzdem noch den Inhalt der Datei siehst, ignoriert dein Hoster entweder .htaccess komplett (selten bei Apache, normal bei nginx) oder hat AllowOverride so eingestellt, dass FilesMatch herausgefiltert wird. Dann geht es bei Option 3 weiter.

Option 2: Per nginx sperren

Auf nginx gibt es keine .htaccess. Wenn du deinen Server selbst betreibst (VPS bei Hetzner, Netcup, DigitalOcean, oder Managed nginx Hosting mit Config Zugriff), kommt folgendes in den server Block deiner Seite:

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

Mit sudo nginx -t && sudo systemctl reload nginx nginx neu laden, dann mit curl -I https://deinedomain.de/readme.html testen. Die erste Zeile der Antwort sollte HTTP/2 403 lauten.

Einige Managed WordPress Hoster, die intern nginx einsetzen (Raidboxes, Kinsta, WP Engine, Cloudways), bringen solche Regeln ab Werk mit. Ein Blick in die Doku des Hosters lohnt sich. Falls die Regel nicht da ist, trägt der Support sie auf Anfrage in der Regel zügig ein.

Option 3: Shared Hosting ohne funktionierende .htaccess Overrides

Manche stark abgeschottete Shared Hoster betreiben nginx und ignorieren .htaccess komplett. Andere fahren Apache, beschränken aber AllowOverride so weit, dass FilesMatch nicht mehr greift. Wenn weder Option 1 noch Option 2 funktionieren, gibt es drei sinnvolle Fallbacks, sortiert nach Haltbarkeit:

1. Ein Security Plugin nutzen, das Core Datei Hardening übernimmt. Solid Security und All In One WP Security & Firewall haben jeweils einen Schalter zum Entfernen von Core Dateien beziehungsweise zum Verstecken der WordPress Version, der sich um readme.html mitkümmert. Wordfence im Extended Protection Modus kann die Dateien zusätzlich auf WAF Ebene blockieren. Der Vorteil: diese Einstellungen überleben WordPress Updates automatisch.
2. Inhalt per Must Use Plugin leeren. Wenn keine Webserver Regel möglich ist, ist ein kleines mu Plugin, das readme.html und license.txt nach jedem WordPress Update mit leerem Inhalt überschreibt, der zuverlässigste Weg. Siehe das passende Code Snippet in unserer Knowledge Base.
3. Dateien per Hand löschen. Die schnellste Lösung dauert per SFTP zehn Sekunden: einfach readme.html, license.txt und wp-config-sample.php aus dem WordPress Root entfernen. Haken: WordPress Core Updates stellen die Dateien wieder her. Nach jedem größeren Update musst du dran denken, sie erneut zu löschen. Genau deshalb ist ein Plugin oder eine Webserver Regel auf Dauer die bessere Antwort.

Was du nicht tun solltest

Ein paar Vorschläge, die in älteren Blogposts kursieren, in der Praxis aber schlechter sind, als sie wirken:

• Dateien umbenennen. readme.html in readme.html.old umzubenennen sieht ordentlich aus, hilft aber nichts. WordPress legt das Original beim nächsten Update einfach neu an, und du hast plötzlich zwei Dateien statt einer.
• Dateirechte auf 000 setzen. Blockiert auf den meisten Hosts den Lesezugriff, wird aber beim nächsten Core Update zurückgesetzt. Auf manchen Hosts bricht zusätzlich das Update selbst ab, wenn WordPress die Datei während des Vorgangs nicht lesen kann.
• Versionsnummer aus der Datei rausschneiden. Verlockend, aber sinnlos. WordPress stellt das Original beim Update wieder her, und selbst eine bearbeitete readme.html bestätigt immer noch, dass die Seite WordPress nutzt.

Das Muster ist immer gleich: Alles, was im WordPress Verzeichnis liegt und nicht durch eine Webserver Regel geschützt ist, wird beim Update zurückgesetzt. Auf Webserver Ebene blockieren, oder ein Plugin nutzen, das sich über Updates hinweg selbst aktiv hält.

So prüfst du dein Setup

1. Öffne https://deinedomain.de/readme.html in einem privaten Browserfenster. Erwartetes Ergebnis: eine 403 Forbidden Seite (oder 404, falls du den Löschweg gewählt hast).
2. Selbe Prüfung für https://deinedomain.de/license.txt und https://deinedomain.de/wp-config-sample.php.
3. Wenn du immer noch den Dateiinhalt siehst, leere alle Caches, die vor der Seite hängen (Cloudflare, Varnish, serverseitige Page Caches wie LiteSpeed Cache oder WP Rocket), und teste erneut. Gecachte Antworten können die Änderung stundenlang überdecken.
4. Starte einen frischen InspectWP Scan. Der Check zur exponierten readme.html im Sicherheits Bereich sollte auf grün wechseln.

Was du gleich mit absichern solltest

Dieselbe Art von FilesMatch oder location Regel lohnt sich auch für ein paar weitere Endpunkte, die in InspectWP Scans regelmäßig auftauchen: wp-config.php.bak, wp-config.php.swp, .git/, .env, phpinfo.php und alle info.php Dateien, die ein Entwickler beim Debuggen vergessen hat. Selber Mechanismus, dieselben fünf Zeilen Config, und du nimmst eine ganze Klasse von Fingerprinting und Credential Leaks in einem Aufwasch vom Tisch.