Zum Inhalt springen

WordPress-Core-Dateien erzeugen beim direkten Aufruf Fehler

Warnung Ganze Domain Sicherheit

Allgemeine Anleitung. Öffnen Sie diesen Artikel aus Ihrem PageCheck-Bericht, um ihn mit der Adresse Ihrer Website und den Regeln für ihren Webserver ausgefüllt zu sehen.

Was es ist

Einige Core-Dateien von WordPress, etwa wp-settings.php und die Dateien in wp-includes/, sind nur dafür gedacht, von WordPress selbst geladen zu werden. Direkt im Browser geöffnet, laufen sie an und brechen mit einem PHP-Fehler ab.

Was falsch ist

Jedes Mal, wenn eine dieser Core-Dateien geöffnet wird, erzeugt sie einen Fehler. Ist die Fehleranzeige eingeschaltet, erscheint der Fehler auch auf der Seite, mit dem vollständigen Pfad des Website-Ordners auf dem Server, was Angreifern verrät, wie der Server aufgebaut ist.

Warum das behoben werden muss: Jeder – Bots oder jemand mit böser Absicht – kann diese Dateien immer wieder öffnen. Jede Anfrage startet PHP und schreibt einen weiteren Fehler ins Server-Log, sodass sich die Logs absichtlich aufblähen lassen: Sie füllen die Festplatte und verdecken die Fehler, auf die es ankommt. Jede Antwort bestätigt außerdem, dass die Website mit WordPress läuft.

So beheben Sie es

1. PHP-Fehler auf der Live-Website ausblenden. Fehler gehören in ein privates Log, nie auf die Seite. Stellen Sie im Hosting-Control-Panel display_errors auf Off:

  • Plesk: Websites & Domains → PHP Settings → display_errors aus.
  • cPanel: MultiPHP INI Editor → display_errors Disabled.

Lassen Sie in der wp-config.php das Debugging eingeschaltet, schicken Sie aber jeden Fehler nur in eine Log-Datei außerhalb des öffentlichen Ordners der Website, damit nichts auf der Seite erscheint und niemand das Log herunterladen kann:

wp-config.php

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/path/outside/the/web/root/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

Diese Zeilen gelten nicht für die Dateien, die diese Prüfung öffnet: Direkt aufgerufen, brechen sie ab, bevor WordPress die wp-config.php liest, deshalb blendet die Hosting-Einstellung oben ihre Fehler aus. Rotieren Sie das Log (zum Beispiel täglich, einige Wochen aufbewahrt): Mit eingeschaltetem Debugging sammelt es auch Hinweise und kann schnell wachsen.

2. Die WordPress-Core-Dateien für direkte Aufrufe sperren. Verwenden Sie die Regeln für Ihren Webserver (Ihr Hoster kann Ihnen sagen, welcher es ist):

Apache oder LiteSpeed: in der Datei .htaccess im Hauptordner der Website, über der Zeile „# BEGIN WordPress“

# BEGIN Block WordPress internal files
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/(?!ms-files\.php$)[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
<Files "wp-settings.php">
    Require all denied
</Files>
# END Block WordPress internal files

nginx: im server-Block der Website, über dem Block, der .php-Dateien verarbeitet

location ~* ^/wp-admin/includes/ { deny all; }
location ~* ^/wp-includes/(?!ms-files\.php$)[^/]+\.php$ { deny all; }
location ~* ^/wp-includes/js/tinymce/langs/.+\.php$ { deny all; }
location ~* ^/wp-includes/theme-compat/ { deny all; }
location = /wp-settings.php { deny all; }

Das sind die Regeln aus der Härtungsanleitung von WordPress.org, mit einer Änderung: Sie lassen wp-includes/ms-files.php offen. WordPress-Multisite-Netzwerke, die vor WordPress 3.5 eingerichtet wurden, liefern ihre hochgeladenen Dateien über genau diese Datei aus, und der Rat der Anleitung für Multisite – die ganze Zeile für wp-includes/*.php wegzulassen – würde alle anderen Dateien dort wieder öffnen. Auf einer einzelnen Website antwortet die Datei nur mit „Multisite support not enabled“. Liegt WordPress in einem Unterordner, tragen Sie diesen Ordner in RewriteBase und in die nginx-Pfade ein.

3. Prüfen. Öffnen Sie https://example.com/wp-includes/theme-compat/embed.php: Die Adresse sollte jetzt mit „Forbidden“ (403) und ohne Fehlertext antworten. Öffnen Sie einige Seiten der Website und den Admin-Bereich, um zu sehen, dass sie weiter funktionieren, und führen Sie diese Prüfung dann erneut aus. 

Stop WordPress's core PHP files on my site from running and generating errors when opened directly.
Why it matters: anyone (bots included) can request these core files repeatedly, and every request writes a PHP error to the server log, so the logs can be bloated on purpose.

Steps:
1. Turn display_errors off for the live site (hosting PHP settings or php.ini). In wp-config.php keep WP_DEBUG true, set WP_DEBUG_DISPLAY false, and point WP_DEBUG_LOG to a file outside the web root (not wp-content/debug.log), with log rotation. Do not set WP_DEBUG to false.
2. Deny direct HTTP requests to wp-admin/includes/, wp-includes/*.php, wp-includes/js/tinymce/langs/*.php, wp-includes/theme-compat/ and wp-settings.php — WordPress.org's hardening rules in .htaccess on Apache/LiteSpeed (above # BEGIN WordPress), or deny location blocks placed before the PHP handler on nginx. Exempt only wp-includes/ms-files.php (Multisite networks from before WordPress 3.5 serve uploads through it): use ^wp-includes/(?!ms-files\.php$)[^/]+\.php$ rather than dropping the wp-includes/*.php rule.
3. Verify those addresses answer 403 with no error text, and that the site, the admin area, the block editor and uploads still work.
Tell me exactly which files you changed.

Resources:
- Hardening WordPress, securing wp-includes (WordPress.org): https://developer.wordpress.org/advanced-administration/security/hardening/#securing-wp-includes
- Debugging in WordPress (WordPress.org): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
- display_errors (PHP manual): https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

Prüfen Sie Ihre Website, um zu sehen, ob sie dieses Problem hat. Website prüfen