Ir al contenido

Archivos del núcleo de WordPress generan errores al abrirlos directamente

Aviso Todo el dominio Seguridad

Instrucciones generales. Abre este artículo desde tu informe de PageCheck para verlo con la dirección de tu sitio y las reglas para su servidor web.

Qué es

Algunos archivos del núcleo de WordPress, como wp-settings.php y los de wp-includes/, solo deben cargarse desde el propio WordPress. Si se abren directamente en un navegador, se ejecutan y se detienen con un error de PHP.

Qué falla

Cada vez que se abre uno de estos archivos del núcleo, genera un error. Si la visualización de errores está activada, el error también aparece en la página con la ruta completa de la carpeta del sitio en el servidor, lo que indica a los atacantes cómo está organizado el servidor.

Por qué hay que corregirlo: cualquiera —bots o alguien con malas intenciones— puede abrir estos archivos una y otra vez. Cada petición ejecuta PHP y escribe otro error en el registro del servidor, así que los registros se pueden inflar a propósito: llenan el disco y entierran los errores que importan. Cada respuesta confirma además que el sitio usa WordPress.

Cómo arreglarlo

1. Oculta los errores de PHP en el sitio en producción. Los errores deben ir a un registro privado, nunca a la página. En el panel del hosting, pon display_errors en Off:

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

En wp-config.php, mantén la depuración activada pero envía cada error solo a un archivo de registro fuera de la carpeta pública del sitio, para que nada llegue a la página y nadie pueda descargar el registro:

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' );

Estas líneas no cubren los archivos que abre esta comprobación: abiertos directamente, se detienen antes de que WordPress lea wp-config.php, así que es el ajuste del hosting de arriba el que oculta sus errores. Rota el registro (por ejemplo a diario, guardando unas semanas): con la depuración activada también recoge avisos y puede crecer rápido.

2. Cierra los archivos del núcleo de WordPress a las peticiones directas. Usa las reglas de tu servidor web (tu hosting puede decirte cuál es):

Apache o LiteSpeed: en el archivo .htaccess de la carpeta principal del sitio, encima de la línea «# 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: en el bloque server del sitio, encima del bloque que procesa los archivos .php

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; }

Son las reglas de la guía de protección de WordPress.org, con un cambio: dejan abierto wp-includes/ms-files.php. Las redes WordPress Multisite creadas antes de WordPress 3.5 sirven sus archivos subidos a través de ese único archivo, y el consejo de la guía para Multisite —omitir toda la línea de wp-includes/*.php— volvería a abrir todos los demás archivos de esa carpeta. En un sitio individual, el archivo solo responde «Multisite support not enabled». Si WordPress está en una subcarpeta, pon esa carpeta en RewriteBase y en las rutas de nginx.

3. Compruébalo. Abre https://example.com/wp-includes/theme-compat/embed.php: ahora debería responder «Forbidden» (403) sin ningún texto de error. Abre algunas páginas del sitio y el área de administración para ver que siguen funcionando, y después vuelve a ejecutar esta comprobación. 

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

Revisa tu sitio para ver si tiene este problema. Revisar un sitio web