GUÍAS
Permisos y archivos sensibles de WordPress: qué revisar sin romper la web
Permisos y archivos sensibles de WordPress: qué revisar sin romper la web
Los permisos suelen aparecer como causa de errores cuando WordPress no puede actualizar un plugin, subir una imagen o guardar una configuración.
La solución rápida suele ser aplicar 777 a una carpeta o cambiar toda la instalación a 755 y 644. Es una mala práctica. Puede ocultar el problema, ampliar la superficie de ataque o dejar la web sin poder leer sus propios archivos.
Los permisos correctos dependen del propietario, del usuario que ejecuta PHP y de la configuración del servidor. No existe una cifra universal que pueda aplicarse sin revisar el entorno.
Permisos y propietarios no son lo mismo
En Linux, los permisos indican qué puede hacer el propietario, el grupo y el resto de usuarios:
r: Leer.w: Escribir, modificar o borrar según se trate de un archivo o directorio.x: Ejecutar un archivo o acceder a un directorio.
Por eso se ven valores como 644 para archivos y 755 para directorios. El primer número corresponde al propietario, el segundo al grupo y el tercero al resto de usuarios.
Pero esos números no cuentan toda la historia. Un archivo 644 puede dar problemas si pertenece a un usuario distinto del que utiliza PHP. Y una carpeta 755 puede ser insuficiente si WordPress necesita escribir en ella con otro usuario.
La documentación de WordPress sobre permisos de archivos recomienda adaptar la configuración al servidor y evitar permisos más abiertos de lo necesario.
Antes de cambiar nada, comprueba:
- Quién es el propietario de los archivos.
- Qué grupo tienen asignado.
- Con qué usuario se ejecuta PHP-FPM o el servidor web.
- Si el hosting aplica ACL, cuotas o restricciones adicionales.
- Si el panel, como Plesk, administra automáticamente estos valores.
Cambiar solo los números suele tapar un problema de propietarios.
wp-config.php merece una revisión especial
wp-config.php contiene las credenciales de la base de datos y otras constantes importantes de WordPress. No debería poder modificarlo cualquier usuario o proceso del servidor.
Revisa también si existen copias accesibles desde internet:
wp-config.php.bak.wp-config.php.save.- Archivos temporales.
- Backups comprimidos.
- Exportaciones de configuración.
- Ficheros
.envexpuestos.
No importa que un archivo no termine en .php: si el servidor permite descargarlo, puede revelar credenciales o información interna.
La guía oficial de hardening de WordPress recomienda restringir el acceso a wp-config.php tanto como permita el entorno. No impongas 600 sin comprobar antes que el proceso web seguirá pudiendo leerlo.
uploads debe permitir escritura, pero no ejecución de PHP
wp-content/uploads necesita escritura porque allí se guardan imágenes y documentos. Eso no significa que deba permitirse ejecutar PHP desde esa carpeta.
Comprueba:
- Si el usuario de WordPress puede subir archivos correctamente.
- Si hay archivos PHP dentro de
uploads. - Si el servidor ejecuta esos archivos.
- Si existen copias de seguridad dentro de una ruta pública.
- Si algún plugin necesita una subcarpeta concreta para cachés o logs.
En Nginx, la documentación oficial de WordPress muestra cómo restringir la ejecución de PHP en directorios de contenido. En Apache se puede aplicar una regla equivalente, pero depende de la configuración del servidor.
Una carpeta uploads escribible no demuestra por sí sola que exista una intrusión. El riesgo depende también de qué archivos acepta la aplicación y de cómo los sirve el servidor.
Por qué no debes usar 777
777 permite leer, escribir y ejecutar al propietario, al grupo y a cualquier otro usuario. En una web compartida o en un servidor con varios sitios, es una exposición innecesaria.
Además, no resuelve la causa habitual del error. Si WordPress no puede escribir, puede deberse a:
- Propietario incorrecto.
- Grupo mal asignado.
- PHP ejecutándose con otro usuario.
- Cuota de disco agotada.
open_basedir.- Restricciones del panel.
- Políticas de seguridad del sistema.
Abrir todos los permisos puede hacer que una actualización funcione, pero también permite que un proceso comprometido modifique más archivos de los necesarios. La referencia de WordPress sobre el riesgo de 777 recomienda buscar una solución más limitada.
Qué revisar antes de cambiar permisos
Haz primero una revisión de solo lectura:
- Confirma la ruta real. No des por hecho que WordPress está en
/var/www/html. En Plesk, cPanel, contenedores y migraciones la ruta puede ser distinta. - Lista propietarios y permisos. Revisa la raíz,
wp-admin,wp-includes,wp-content,uploadsywp-config.php. - Busca escritura innecesaria. Identifica qué carpetas pueden modificar PHP y por qué.
- Revisa archivos inesperados. Presta atención a PHP dentro de
uploads, copias antiguas y cambios recientes. - Comprueba el servidor. Apache y Nginx no aplican las mismas reglas; en Nginx no existe
.htaccesspara controlar directorios. - Prueba una operación concreta. Si falla una subida, prueba una subida controlada. Si falla una actualización, utiliza staging o una copia recuperable.
No borres automáticamente un archivo extraño solo porque tenga una fecha reciente. Puede pertenecer a una actualización o a un plugin. Primero identifica su origen, compara el contenido y revisa los registros.
Plesk, hosting compartido y servidor propio
En Plesk, el panel puede gestionar propietarios, PHP-FPM y permisos. Un cambio manual puede entrar en conflicto con esa configuración o quedar sobrescrito.
En hosting compartido pueden intervenir cuotas, aislamiento entre cuentas y restricciones de PHP que no aparecen dentro de WordPress.
En un servidor propio tienes más control, pero también más responsabilidad. Un cambio recursivo mal dirigido puede afectar a varias webs. Trabaja siempre con rutas verificadas y conserva el estado anterior.
Checklist rápido
Antes de cerrar la revisión, confirma:
- La ruta de WordPress es la correcta.
- El propietario y el grupo están identificados.
- El usuario que ejecuta PHP está confirmado.
-
wp-config.phpno es escribible por usuarios innecesarios. - No hay backups ni copias de configuración accesibles desde internet.
-
uploadspermite las cargas necesarias. - El servidor no ejecuta PHP dentro de
uploads. - No hay archivos PHP sospechosos en directorios de contenido.
- Se han revisado cuotas, logs y restricciones del hosting.
- Los cambios se prueban antes en staging o con una copia recuperable.
Conclusión
Los permisos de WordPress no se corrigen aplicando una cifra universal. Hay que combinar permisos, propietarios, usuario de PHP, reglas del servidor y necesidades reales de la instalación.
Si una web no puede actualizarse o subir archivos, no abras toda la instalación. Averigua qué proceso necesita acceso, a qué ruta y durante cuánto tiempo, y concede solo lo necesario.
Si no puedes determinar quién modifica los archivos o por qué existen permisos globales, detén los cambios indiscriminados y revisa la instalación completa antes de continuar.
Fuentes
¿Crees que han comprometido tu web?
Antes de borrar archivos o restaurar una copia, conserva las evidencias y revisa qué ha ocurrido.
Analizar mi web
