WordPress-Exposition: Version, readme.html, install.php, Verzeichnislisting

Angreifer raten nicht — sie prüfen 4 bestimmte Dateien. Die Tests #41 bis #44 zeigen, ob Ihre WordPress-Website ihre Schwachstellen der Welt preisgibt.

Bevor ein Hacker einen echten Angriff startet, folgt er der gleichen Checkliste. Er beginnt nicht mit Brute Force oder SQL-Injection. Er beginnt mit Aufklärung — Informationen über das Ziel sammeln. Und WordPress macht es ihm bemerkenswert einfach.

Standardmäßig zeigt WordPress seine Versionsnummer im HTML-Quellcode, lässt eine readme.html-Datei im Stammverzeichnis, hält das Installationsskript zugänglich und erlaubt es jedem, interne Verzeichnisse zu durchsuchen. Jedes davon ist ein kostenloser Hinweis für einen Angreifer.

Orilyt führt 4 ergänzende Tests durch, um diese Expositionen zu erkennen. Test #41 prüft das Versions-Fingerprinting. Test #42 testet readme.html und license.txt. Test #43 prüft, ob install.php erreichbar ist. Test #44 prüft das Verzeichnislisting bei wp-content, wp-includes, uploads, plugins und themes. Zusammen kartieren sie die gesamte Informationsleck-Oberfläche einer WordPress-Website.

Test #41: Ist Ihre WordPress-Version exponiert?

Test #41 sucht nach 4 verschiedenen Signalen, die Ihre WordPress-Version jedem offenbaren, der sich die Mühe macht zu schauen:

1. Meta-Generator-Tag — WordPress fügt standardmäßig <meta name="generator" content="WordPress X.X"> in den HTML-Head ein. Dies ist die direkteste Versionsoffenlegung. Jeder Scanner erkennt sie sofort
2. Asset-Versionsstrings — CSS- und JS-Dateien aus wp-includes und wp-content enthalten ?ver=X.X.X-Parameter. Diese Versionsstrings stimmen oft exakt mit der WordPress-Core-Version überein
3. REST-API-Endpoint — /wp-json/ ist standardmäßig zugänglich und bestätigt, dass WordPress läuft. Die Antwort enthält Namespace-Informationen, die die API-Version verraten
4. Link-Header — WordPress sendet einen Link-HTTP-Header mit Verweis auf wp-json und bestätigt damit das CMS, noch bevor der Seiteninhalt geladen wird

Bewertung: Wenn sowohl der Meta-Generator-Tag als auch die Asset-Versionsstrings vorhanden sind, fällt die Bewertung auf 30/100. Ein kritisches Signal plus REST-API = 50. Nur die REST-API (ohne Versionsdaten) = 80. Wenn alle Signale verborgen sind, beträgt die Bewertung 100.

Test #42: Sind readme.html und license.txt zugänglich?

Jede WordPress-Installation wird mit zwei Dateien im Stammverzeichnis geliefert: readme.html und license.txt. Sie dienen in der Produktion keinem Zweck — aber sie bestätigen das CMS und können Versionsdetails offenlegen:

1. readme.html — diese Datei ist eine formatierte HTML-Seite, die „WordPress" in großer Schrift anzeigt und oft die genaue Versionsnummer enthält. Es ist die einfachste Fingerprint-Prüfung: /readme.html anfragen und prüfen, ob 200 zurückkommt
2. license.txt — enthält den GPL-Lizenztext mit „WordPress" in der Kopfzeile. Weniger direkt nützlich für Angreifer als readme.html, bestätigt aber dennoch das CMS und dass keine Härtung durchgeführt wurde

Bewertung: beide Dateien zugänglich = 30/100. Nur readme.html zugänglich = 40. Nur license.txt = 60. Beide geben 403 oder 404 zurück = 100. Diese Dateien sollten in der Produktion einfach nicht ausgeliefert werden.

Test #43: Ist install.php erreichbar?

Der WordPress-Installer befindet sich unter /wp-admin/install.php. Auf einer korrekt konfigurierten Website leitet dieses Skript zur Login-Seite weiter oder gibt 403/404 zurück. Aber auf falsch konfigurierten Servern kann es direkt zugänglich sein:

1. Der Test fragt /wp-admin/install.php ab und prüft die HTTP-Antwort. Wenn die Antwort 200 ist und der Body „install WordPress" oder das Schlüsselwort „wp-install" enthält, ist das Skript exponiert
2. Ein zugänglicher Installer ist ein kritischer Befund. Im schlimmsten Fall könnte ein Angreifer eine Neuinstallation auslösen — die Datenbankverbindung zurücksetzen, ein neues Admin-Konto erstellen und die komplette Website übernehmen
3. Die meisten Hosting-Umgebungen schützen dies automatisch, aber benutzerdefinierte Serverkonfigurationen, Docker-Setups oder Nginx ohne entsprechende Regeln lassen es oft exponiert

Bewertung: Wenn die Installationsseite zugänglich ist und wie der WordPress-Installationsassistent aussieht, fällt die Bewertung auf 30/100. Eine 403/404-Antwort = 100. Eine Weiterleitung = 95.

Test #44: Ist das Verzeichnislisting aktiviert?

Verzeichnislisting (Autoindex) erlaubt es jedem, den Inhalt eines Ordners über den Browser zu durchsuchen. Test #44 prüft 5 kritische WordPress-Verzeichnisse:

1. /wp-content/ — das Hauptinhaltsverzeichnis. Es zu listen enthüllt alle installierten Plugins, Themes und Upload-Ordner auf einen Blick
2. /wp-includes/ — WordPress-Core-Dateien. Das Listing bestätigt die Installationsstruktur und Version
3. /wp-content/uploads/ — von Benutzern hochgeladene Dateien. Kann sensible Dokumente, Rechnungen oder Backup-Dateien enthalten, die nie öffentlich sein sollten
4. /wp-content/plugins/ — jedes installierte Plugin ist mit seinem genauen Verzeichnisnamen sichtbar, was die Suche nach bekannten Schwachstellen für jedes einzelne trivial macht
5. /wp-content/themes/ — alle Themes sichtbar, einschließlich inaktiver, die ungepatchte Sicherheitslücken haben können

Der Test fragt jedes Verzeichnis ab und sucht nach Autoindex-Markern in der Antwort: „Index of /", „Directory listing for", „Parent Directory"-Links. Wenn der Server eine HTML-Seite mit Dateiliste statt eines 403 zurückgibt, ist das Verzeichnis exponiert.

Bewertung: 3 oder mehr Verzeichnisse exponiert = 20/100. Zwei exponiert = 35. Eines exponiert = 50. Alle blockiert (403/404) = 100. Das Uploads-Verzeichnis erhält zusätzliches Gewicht, da es Benutzerdaten enthalten kann.

Häufige Korrekturen — alle unter 5 Minuten

Jede einzelne dieser Expositionen lässt sich mit einfachen Konfigurationsänderungen beheben. Kein Code, keine Plugins, keine Ausfallzeit:

1. Meta-Generator-Tag entfernen — fügen Sie remove_action('wp_head', 'wp_generator') in die functions.php Ihres Themes ein. Eine Zeile, sofortige Wirkung
2. Versions-Querystrings entfernen — fügen Sie einen Filter hinzu, um ?ver=-Parameter von eingebundenen Skripten und Styles zu entfernen. Oder verwenden Sie ein Sicherheits-Plugin, das dies automatisch erledigt
3. readme.html und license.txt blockieren — fügen Sie eine Deny-Regel in .htaccess hinzu: <Files "readme.html"> Require all denied </Files>. Oder löschen Sie die Dateien einfach (sie kommen bei Updates zurück, daher ist .htaccess besser)
4. install.php für Nicht-Authentifizierte blockieren — die meisten Managed-Hosts handhaben dies, aber wenn Ihrer es nicht tut, fügen Sie eine .htaccess-Regel in wp-admin/ hinzu, die den Zugriff auf install.php einschränkt
5. Verzeichnislisting deaktivieren — fügen Sie Options -Indexes in Ihre .htaccess im Stammverzeichnis ein. Diese eine Zeile blockiert Autoindex für die gesamte Website. Sie sollte bei den meisten WordPress-Installationen bereits vorhanden sein, aber viele benutzerdefinierte Konfigurationen vergessen sie

Das Muster ist gleichbleibend: alles sind Standard-Konfigurationsprobleme. WordPress wird in einem permissiven Zustand für einfache Installation ausgeliefert. Härtung ist ein separater Schritt, den die meisten Betreiber nie gehen.

Warum diese Befunde Wartungsverträge verkaufen

Für Freelancer und Agenturen sind diese 4 Tests kraftvolle Gesprächsstarter. Sie sind leicht zu demonstrieren, visuell offensichtlich, und der Kunde muss keinen Code verstehen:

Im Orilyt-Bericht generiert jeder Test eine FIA-Empfehlung:

1. Fakt: „WordPress-Version 6.4.1 ist im HTML-Quellcode sichtbar" oder „5 Verzeichnisse sind frei durchsuchbar"
2. Auswirkung: „Angreifer können bekannte Exploits für diese exakte Version suchen" oder „Alle installierten Plugins sind sichtbar, was gezieltes Schwachstellen-Scanning ermöglicht"
3. Aktion: „Meta-Generator-Tag entfernen und Versionsstrings bereinigen" oder „Options -Indexes zur .htaccess hinzufügen"

Diese Befunde erzeugen Dringlichkeit, weil sie greifbar sind. Sie können den Browser des Kunden öffnen, /readme.html eingeben und ihm die WordPress-Version auf dem Bildschirm zeigen. Sie können /wp-content/plugins/ durchsuchen und jedes installierte Plugin auflisten. Es ist nicht abstrakt — es ist eine Live-Demonstration der Exposition.

Die 4 Dateien, die Hacker zuerst prüfen — in Sekunden getestet

WordPress-Exposition dreht sich nicht um ausgeklügelte Angriffe. Es geht um niedrig hängende Früchte. Versionsnummern, Standarddateien, zugänglicher Installer, Verzeichnislisting — das sind die ersten Dinge, die jeder Scanner oder Angreifer prüft. Und alles ist in Minuten behebbar.

Die Tests #41 bis #44 decken diese gesamte Oberfläche ab. Sie erkennen jedes gängige Informationsleck, bewerten den Schweregrad und generieren klare Empfehlungen. Führen Sie sie durch, bevor ein Angreifer es tut.

Für kundenorientierte Audits sind WordPress-Expositions-Befunde der perfekte Einstiegspunkt. Sie sind visuell, dringend, und die Korrekturen sind schnell. Wenn eine Website bei diesen 4 Tests durchfällt, gibt es ein Sicherheitsgespräch zu führen — und wahrscheinlich einen Vertrag zu unterschreiben.