WordPress zeigt seine Versionsnummer standardmäßig an mehreren Stellen an. Das allein ist keine kritische Sicherheitslücke. Aber es gibt Angreifern einen Vorsprung. Wenn jemand weiß, dass du WordPress 6.2.1 verwendest, kann er alle bekannten Exploits für genau diese Version nachschlagen und gegen deine Seite ausprobieren. Die Versionsinformation zu entfernen ist ein einfacher erster Schritt, der automatisierte Scanning-Tools weniger effektiv macht.
Wo WordPress die Versionsnummer offenlegt
WordPress ist überraschend freigiebig damit, welche Version es verwendet. Hier sind die häufigsten Stellen, an denen Angreifer (und jeder, der deinen Quellcode ansieht) sie finden können:
- Generator-Meta-Tag: WordPress fügt einen
<meta name="generator" content="WordPress 6.x.x">-Tag in den<head>-Bereich jeder Seite ein. Das ist die offensichtlichste Stelle und erscheint bei jedem einzelnen Seitenaufruf. - RSS- und Atom-Feeds: Der RSS-Feed deiner Seite (typischerweise unter
/feed/) enthält ein<generator>-Element mit der vollständigen WordPress-Versionsangabe. Viele Seitenbetreiber vergessen die Feeds komplett und lassen diesen Vektor offen. - Query-Strings an Scripts und Styles: WordPress hängt
?ver=6.x.xan CSS- und JavaScript-Datei-URLs an, wenn es sie einbindet. Selbst wenn du den Meta-Tag entfernst, verrät dieser Parameter deine Version in jeder Asset-Anfrage. - Die readme.html-Datei: WordPress wird mit einer
readme.html-Datei im Stammverzeichnis ausgeliefert. Diese Datei enthält die Versionsnummer im Klartext und ist für jeden zugänglich, der die URL kennt. - Die license.txt-Datei: Ähnlich wie
readme.htmlliegt dielicense.txt-Datei im WordPress-Stammverzeichnis und kann bestätigen, dass die Seite WordPress verwendet. - Der Quellcode der Login-Seite: Die WordPress-Login-Seite unter
/wp-login.phplädt Stylesheets und Scripts mit Versions-Query-Strings und ist damit eine weitere Quelle für Versionsinformationen. - REST-API-Antworten: Die WordPress-REST-API unter
/wp-json/kann ebenfalls Versionsdetails in ihren Antwort-Headern oder im Body offenlegen.
Warum das Verstecken der Version wichtig ist
Jede größere WordPress-Version hat ein öffentliches Changelog. Wenn ein Sicherheitspatch veröffentlicht wird, wird die Sicherheitslücke, die er behebt, öffentlich bekannt. Automatisierte Bots durchsuchen ständig das Web nach Seiten, die noch die alte, verwundbare Version verwenden. Wenn deine Seite "WordPress 6.2.1" anzeigt und eine kritische SQL-Injection in 6.2.2 gepatcht wurde, wird deine Seite innerhalb von Stunden nach dem Patch-Release zum Ziel.
Das Verstecken der Versionsnummer behebt die Sicherheitslücke selbst nicht. Es entfernt lediglich einen Datenpunkt, den Angreifer nutzen, um Ziele zu priorisieren. Stell es dir so vor: Du entfernst deine Hausnummer von einer Liste von Häusern mit unverschlossenen Türen. Die Tür ist vielleicht immer noch offen, aber zumindest stehst du nicht auf der Kurzliste.
Version aus HTML und Feeds entfernen
Füge den folgenden Code in die functions.php deines Themes ein oder, noch besser, in ein seitenspezifisches Plugin, damit er Theme-Wechsel übersteht:
// Generator-Meta-Tag aus dem HTML-Head entfernen
remove_action('wp_head', 'wp_generator');
// Version aus RSS-Feeds entfernen
add_filter('the_generator', '__return_empty_string');
// Versions-Query-String von Scripts und Styles entfernen
function remove_wp_version_from_assets($src) {
if (strpos($src, 'ver=' . get_bloginfo('version'))) {
$src = remove_query_arg('ver', $src);
}
return $src;
}
add_filter('style_loader_src', 'remove_wp_version_from_assets', 9999);
add_filter('script_loader_src', 'remove_wp_version_from_assets', 9999);Der remove_action-Aufruf entfernt den Meta-Tag. Der the_generator-Filter kümmert sich um RSS- und Atom-Feeds. Die beiden Loader-Filter entfernen den ?ver=-Parameter von allen eingebundenen Assets. Die Priorität 9999 stellt sicher, dass dies nach Plugins und Themes ausgeführt wird, die ihre eigenen Scripts hinzugefügt haben.
readme.html und license.txt löschen
Diese statischen Dateien liegen im WordPress-Stammverzeichnis und enthalten Versionsinformationen. Lösche sie:
rm /path/to/wordpress/readme.html
rm /path/to/wordpress/license.txtEs gibt allerdings einen Haken: WordPress erstellt diese Dateien bei Core-Updates neu. Du hast zwei Möglichkeiten. Du kannst sie nach jedem Update manuell löschen. Oder du fügst ein kleines Script in deinen Deployment-Prozess ein, das sie automatisch entfernt. Wenn du WP-CLI verwendest, funktioniert ein Post-Update-Hook dafür gut.
Plugin-basierte Ansätze
Wenn du lieber keine Code-Dateien bearbeitest, gibt es mehrere Plugins, die das Entfernen der Version für dich übernehmen. Sicherheits-Plugins wie Wordfence, iThemes Security und All In One WP Security bieten alle Optionen zum Verstecken der WordPress-Version. Leichtgewichtige Alternativen wie Meta Generator and Version Info Remover konzentrieren sich speziell auf diese Aufgabe, ohne zusätzlichen Overhead hinzuzufügen.
Achte bei der Plugin-Wahl darauf, dass es alle oben aufgeführten Stellen abdeckt, nicht nur den Meta-Tag. Manche Plugins entfernen nur den Generator-Tag und lassen die Query-Strings an Scripts unberührt.
Security by Obscurity reicht nicht aus
Das Verstecken der WordPress-Version ist eine gute Praxis, aber allein keine Sicherheitsstrategie. Ein entschlossener Angreifer kann deine WordPress-Version trotzdem ermitteln, zum Beispiel durch den Vergleich von Core-JavaScript-Dateien oder das Prüfen auf bestimmte Features, die in bestimmten Versionen eingeführt wurden.
Für echte Sicherheit musst du das Verstecken der Version mit den Grundlagen kombinieren:
- WordPress, Themes und Plugins aktuell halten: Das ist die wichtigste Einzelmaßnahme. Die meisten WordPress-Hacks nutzen bekannte Sicherheitslücken in veralteter Software aus.
- Starke Passwörter und Zwei-Faktor-Authentifizierung verwenden: Brute-Force-Angriffe gegen
wp-login.phpgehören nach wie vor zu den häufigsten Angriffsvektoren. - Eine Web Application Firewall (WAF) einsetzen: Dienste wie Cloudflare, Sucuri oder eine Plugin-basierte WAF können bösartige Anfragen blockieren, bevor sie WordPress erreichen.
- Login-Versuche begrenzen: Plugins wie Limit Login Attempts Reloaded verhindern, dass Angreifer automatisierte Passwort-Rate-Angriffe durchführen.
- XML-RPC deaktivieren, wenn nicht benötigt: XML-RPC ist ein weiterer häufiger Angriffsvektor für Brute-Force und DDoS-Verstärkung.
Änderungen mit InspectWP überprüfen
Führe nach der Implementierung dieser Änderungen einen neuen InspectWP-Scan deiner Seite durch. Prüfe den WordPress-Bereich des Berichts. Die Versionsnummer sollte nicht mehr im HTML-Quellcode erscheinen, und der Meta-Generator-Tag sollte verschwunden sein. Falls InspectWP weiterhin eine Version erkennt, überprüfe, ob der Code-Snippet korrekt geladen wird und ob Caching-Plugins nicht eine veraltete Version deiner Seiten ausliefern.