2026年11月12日
2026年11月12日
Permisos recomendados en WordPress: 755, 644 y wp-config.php
Este artículo es una edición localizada del original en japonés. Leer el original en japonés
Los permisos de archivos de WordPress se fijan, por lo general, en 755 para los directorios y 644 para los archivos. Para wp-config.php, que contiene los datos de conexión a la base de datos, se restringe aún más quién puede leerlo. Si además de los números compruebas quién es el propietario de los archivos y con qué usuario se ejecuta PHP, evitas tanto las filtraciones de información como el problema de "no se puede actualizar". Los valores recomendados de este artículo proceden de la guía oficial de WordPress "Hardening WordPress" (cómo hacer WordPress más seguro), consultada en noviembre de 2026.
Cómo se leen los números de los permisos
Los permisos se expresan en tres grupos, "propietario, grupo y otros", y cada uno es la suma de lectura (4), escritura (2) y ejecución (1).
| Valor | Notación | Significado |
|---|---|---|
| 755 | rwxr-xr-x | El propietario puede leer, escribir y entrar en el directorio; los demás solo pueden leer y entrar (para directorios) |
| 644 | rw-r--r-- | El propietario puede leer y escribir; los demás solo leer (para archivos) |
| 640 | rw-r----- | El propietario puede leer y escribir, el grupo puede leer y los demás no pueden hacer nada |
| 600 | rw------- | Solo el propietario puede leer y escribir |
| 440 / 400 | r--r----- / r-------- | Nadie puede escribir; la lectura es solo del propietario (y del grupo) |
La "ejecución (x)" de un directorio es el permiso para entrar en él. Si le quitas la x a un directorio, no se pueden leer los archivos que contiene.
Valores recomendados para WordPress
| Elemento | Valor recomendado | Nota |
|---|---|---|
| Directorios | 755 (750 si en un servidor compartido no quieres que los vean otros) | Incluso en las actualizaciones automáticas oficiales, los directorios se dejan en 755 |
| Archivos | 644 (640 en el caso anterior) | Incluso en las actualizaciones automáticas oficiales, los archivos se dejan en 644 |
| wp-config.php | Restringirlo para que solo lo lean tu usuario y el servidor web | La explicación oficial dice "en general, 400 o 440". En un entorno donde PHP se ejecuta con el mismo usuario que es propietario del archivo, también funcionan 600 o 400 |
| .htaccess | 644 | Si dejas que WordPress lo reescriba al guardar los enlaces permanentes, el usuario con el que se ejecuta PHP debe poder escribir en él |
| wp-content/uploads | Directorios 755, archivos 644 | Hay que dejarlo con un propietario en el que pueda escribir el usuario con el que se ejecuta PHP |
No hace falta poner 777 (escritura para cualquiera). En un servidor compartido, otros usuarios del mismo servidor podrían modificar tus archivos.
Algunos servidores de alojamiento compartido (hosting) fijan sus propios valores recomendados (porque la forma de ejecutar PHP varía según el servidor). Si el manual de tu servidor indica valores, dales prioridad.
Cómo pensar en el propietario
Según la explicación oficial, los archivos deben ser propiedad de tu propia cuenta de usuario y estar escribibles por ti. Solo los archivos en los que WordPress necesita escribir (uploads, los temas si usas el editor de temas, etc.) se ajustan, en cuanto a propietario o grupo, para que pueda escribir en ellos el usuario con el que se ejecuta el servidor web (PHP).
Si pones todo como propiedad del usuario del servidor web, por ejemplo con chown -R www-data:www-data, PHP podrá modificar todos los archivos. Cuando se aprovecha una vulnerabilidad de un plugin, el daño se extiende con más facilidad, así que primero comprueba el estado actual y luego decide.
Cuando en las actualizaciones de plugins o del núcleo se piden los "datos de conexión (nombre de host, usuario y contraseña de FTP)", en muchos casos la causa es que el propietario no coincide. WordPress solo elige escribir directamente en los archivos cuando el propietario de los archivos creados por PHP y el de los archivos de WordPress son el mismo. Si son distintos, pide actualizar por FTP. En lugar de ampliar los permisos a 777, corrige el propietario para que coincida.
Comprobar la configuración actual
Entra por SSH en el directorio de WordPress y comprueba los valores y el propietario con estos comandos. Adapta la ruta a tu entorno.
cd /var/www/html
# Valor, propietario y grupo de wp-config.php
stat -c '%a %U:%G %n' wp-config.php
# Buscar archivos y directorios en los que pueden escribir otros usuarios
find . -perm -o=w ! -type l
# Buscar archivos PHP dentro de uploads (normalmente no debería haber)
find wp-content/uploads -type f -name '*.php'
El usuario con el que se ejecuta PHP cuando se accede desde la web se comprueba en la configuración del servidor (el user del pool de PHP-FPM, etc.) o en el manual del hosting. No tiene por qué ser el mismo que el usuario con el que iniciaste sesión por SSH.
Si en uploads hay algún archivo PHP que no reconoces, sospecha de una manipulación y, antes de borrarlo, anota la fecha y el contenido del archivo.
Corregir los permisos de una vez
Se ejecuta en el directorio de WordPress. Haz una copia de seguridad antes de ejecutarlo.
cd /var/www/html
# Dejar los directorios en 755 y los archivos en 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
# Restringir wp-config.php (ejemplo para un entorno donde PHP se ejecuta con el propietario del archivo)
chmod 600 wp-config.php
El valor de wp-config.php se elige según el entorno, de esta manera.
- PHP se ejecuta con el mismo usuario que es propietario del archivo (muchos hostings compartidos, PHP-FPM por usuario): 600 o 400
- El propietario es tu cuenta y el servidor web lee como grupo: 640 o 440, con el grupo del servidor web como grupo del archivo
# Ejemplo: propietario tú, grupo el del servidor web (www-data) y 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php
Después de aplicarlo, abre el sitio y el panel de administración y comprueba que se ven y que puedes iniciar sesión. Si aparece una pantalla en blanco o un error, PHP no puede leer wp-config.php. Vuelve el valor a 644 y revisa el propietario y el grupo.
Con 400 o 440, fallarán los plugins que escriben en wp-config.php (por ejemplo, los que escriben ajustes de caché). Permite la escritura de forma temporal solo cuando vayas a configurar esos plugins.
Evitar que wp-config.php se lea desde la web
Si PHP funciona con normalidad, aunque accedas a wp-config.php desde el navegador no se muestra su contenido. Para evitar que se muestre el código fuente si PHP se detiene, por ejemplo, deniega también el acceso en el servidor web. En Apache 2.4, escribe lo siguiente en el .htaccess del directorio donde está WordPress (el antiguo Order Deny,Allow / Deny from all es la sintaxis de Apache 2.2).
<Files "wp-config.php">
Require all denied
</Files>
Los pasos detallados se explican en "Configuración para denegar el acceso a wp-config.php".
El propio .htaccess ya tiene el acceso denegado por la configuración estándar de Apache (<Files ".ht*"> de httpd.conf).
Según la explicación oficial, también puedes mover wp-config.php un nivel por encima del directorio donde está WordPress. Si no hay wp-config.php en el mismo directorio, WordPress lo busca en el directorio superior. Sin embargo, la propia guía oficial menciona opiniones de que el efecto es pequeño y que, si se hace mal, puede resultar incluso peligroso. Si lo mueves, asegúrate de que el directorio superior no sea un directorio público.
Impedir que se ejecute PHP en uploads
uploads es un directorio en el que escribe WordPress, así que es un lugar donde los atacantes colocan archivos con facilidad. Si evitas que se ejecute PHP aquí, aunque lo coloquen no funcionará.
En Apache 2.4, crea wp-content/uploads/.htaccess y escribe lo siguiente.
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
Para usar Require en .htaccess, el AllowOverride del servidor debe permitirlo. Si no está permitido, se produce un error 500 o se ignora la configuración. Después de escribirlo, abre la URL de un PHP inexistente como https://example.com/wp-content/uploads/test.php y comprueba que devuelve 403 (si sigue siendo 404, la configuración no está surtiendo efecto).
En Nginx, dentro del bloque server, coloca lo siguiente antes del location ~ \.php$ que procesa PHP. Esto se debe a que los location con expresión regular se evalúan de arriba abajo y se usa el primero que coincide.
location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
deny all;
}
Después de cambiar la configuración, comprueba la sintaxis con nginx -t y vuelve a cargarla.
Por otra parte, la subida de medios de WordPress no admite de forma predeterminada archivos que no sean de los tipos permitidos (imágenes, PDF, etc.). Subir un archivo PHP como medio no suele ser posible desde el panel de administración.
Puntos a tener en cuenta
- Antes de cambiar los permisos, haz una copia de seguridad de los archivos y de la base de datos.
- Si cambias los permisos con un programa de FTP, algunos servidores no admiten el cambio masivo. Cuando hay muchos archivos, usar
findpor SSH es más rápido y evita omisiones. - Si al actualizar se piden los datos de conexión de FTP, no amplíes los permisos: comprueba el propietario. Consulta también "Cómo solucionar los errores de permisos de WordPress".
- Si ejecutas con regularidad los comandos de comprobación de arriba (archivos en los que pueden escribir otros usuarios, PHP dentro de uploads), notarás antes que la configuración se ha desordenado o que hay una manipulación.
¿Dudas sobre WordPress? Quien publica este sitio está en Japón y responde en japonés. Contacto (en japonés)