Guía de solución

Configurar correctamente los permisos de archivo en WordPress

14 de julio de 2026

Los permisos de archivo determinan quién puede leer, escribir o ejecutar un archivo o directorio. En Linux se representan como un número octal de tres dígitos: el primer dígito se aplica al propietario, el segundo al grupo y el tercero a todos los demás. Cada dígito se compone de lectura (4), escritura (2) y ejecución (1). Los permisos mal configurados –ante todo el extendido pero peligroso 777– permiten que usuarios arbitrarios o cuentas vecinas comprometidas en un servidor compartido modifiquen tus archivos e inyecten código malicioso. La recomendación de WordPress es: 755 para directorios, 644 para archivos y un valor más estricto de 600 o 640 para wp-config.php. Esta guía muestra cómo establecer estos valores por SSH o SFTP y qué casos especiales hay que tener en cuenta.

¿Qué significan 755 y 644?

ValorSignificadoUso
755Propietario: leer+escribir+ejecutar; grupo/otros: leer+ejecutarTodos los directorios (ejecutar = entrar)
644Propietario: leer+escribir; grupo/otros: solo leerTodos los archivos normales
600solo propietario: leer+escribirwp-config.php (estricto)
640Propietario: leer+escribir; grupo: leerwp-config.php (si el grupo debe leer)
777cualquiera: leer+escribir+ejecutarNo usar nunca

Paso 1: Poner los directorios en 755

Conéctate por SSH al directorio raíz de WordPress y establece todas las carpetas de forma recursiva:

cd /pfad/zu/wordpress
find . -type d -exec chmod 755 {} \;

Paso 2: Poner los archivos en 644

find . -type f -exec chmod 644 {} \;

Estos dos comandos establecen toda la instalación en valores predeterminados seguros. Ejecútalos en este orden (primero los directorios, luego los archivos).

Paso 3: Tratar los casos especiales

wp-config.php

El archivo más sensible recibe un permiso más estricto:

chmod 600 wp-config.php
# oder, falls der Webserver-Prozess über die Gruppe lesen muss:
chmod 640 wp-config.php

.htaccess

El .htaccess se queda en 644. No lo hagas escribible para otros, o los atacantes podrían manipular las reglas de reescritura.

wp-content/uploads

La carpeta de subidas debe ser escribible por el servidor web para que funcionen las subidas de medios. 755 para las carpetas suele bastar; lo decisivo es que el propietario sea correcto (ver paso 4). Aquí no asignes 777. Importante: en uploads no debe poder ejecutarse ningún archivo PHP. Para asegurarlo, añade:

# .htaccess in wp-content/uploads/ (Apache)
<Files *.php>
    Require all denied
</Files>

Paso 4: Establecer el propietario correcto

Casi más importante que los números es el propietario de los archivos. Todos los archivos de WordPress deben pertenecer al usuario con el que se ejecuta el servidor web o el proceso PHP (a menudo www-data, apache, nginx o tu usuario SFTP). Comprobar y establecer:

# Aktuellen Eigentümer anzeigen
ls -l

# Eigentümer und Gruppe rekursiv setzen (Beispiel www-data)
sudo chown -R www-data:www-data /pfad/zu/wordpress

Si el propietario es correcto, WordPress puede realizar actualizaciones y subidas sin que tengas que debilitar los permisos. Un error habitual es recurrir precipitadamente a 777 ante problemas de actualización, cuando en realidad solo el propietario está mal.

Todo de una vez (script)

#!/bin/bash
# Im WordPress-Stammverzeichnis ausführen
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
echo "Dateiberechtigungen gesetzt: 755 Ordner, 644 Dateien, 600 wp-config.php"

¿Cómo compruebo los permisos?

  1. Comprobar un solo archivo:
    ls -l wp-config.php index.php
    # Erwartet: -rw------- für wp-config.php, -rw-r--r-- für index.php
  2. Buscar permisos 777 inseguros:
    find . -type d -perm 0777
    find . -type f -perm 0777
    # Erwartet: keine Ausgabe
  3. Comprueba que PHP no se ejecuta en la carpeta de subidas solicitando un archivo de prueba (debería devolver 403).

Errores frecuentes

  • 777 como solución rápida: Aparenta resolver los problemas de actualización, pero abre la puerta de par en par. Casi siempre el propietario es el problema real.
  • Scripts ejecutables en uploads: Sin bloqueo de PHP en la carpeta de subidas, un archivo malicioso subido puede ejecutarse.
  • Olvidar los permisos tras una migración: Tras un cambio de servidor o de hosting, el propietario y los permisos a menudo ya no coinciden; vuelve a establecerlos.
  • Hosting compartido sin SSH: Ahí estableces los permisos en el cliente SFTP (clic derecho » permisos) o en el administrador de archivos del panel de hosting.

Preguntas frecuentes (FAQ)

¿Qué permisos de archivo se recomiendan para WordPress?

La recomendación de WordPress es 755 para todos los directorios, 644 para todos los archivos normales y un valor más estricto de 600 o 640 para wp-config.php. Los directorios necesitan el permiso de ejecución para poder entrar en ellos, por eso se usa 755 en lugar de 644.

¿Por qué el permiso 777 es peligroso en WordPress?

777 permite que cualquier usuario del servidor lea, modifique y ejecute el archivo o la carpeta. En hosting compartido, una cuenta vecina comprometida puede inyectar código malicioso en tu instalación de esta forma. En casi todos los casos la causa real de los problemas de actualización no es el permiso, sino un propietario de archivo incorrecto.

¿Por qué el propietario del archivo es más importante que los números?

Todos los archivos de WordPress deben pertenecer al usuario con el que se ejecuta el servidor web o el proceso PHP (a menudo www-data, apache o nginx). Si el propietario es correcto, WordPress puede realizar actualizaciones y subidas sin que debas debilitar los permisos a valores inseguros como 777.

¿Cómo evito que se ejecuten archivos PHP en la carpeta de subidas?

Crea un .htaccess en wp-content/uploads que deniegue el acceso a los archivos PHP (en Apache con un bloque <Files> y Require all denied). Así un archivo malicioso subido no puede ejecutarse como PHP aunque llegue a la carpeta de subidas.

¿Cómo ayuda InspectWP con los permisos de archivo?

InspectWP no puede leer los permisos del sistema de archivos desde fuera, pero comprueba consecuencias sintomáticas de configuraciones inseguras: por ejemplo, si hay archivos sensibles accesibles públicamente, si se ejecuta PHP en el directorio de subidas o si un listado de directorios queda expuesto. Tales hallazgos en el informe son una señal clara para revisar los permisos de archivos y carpetas.

Analiza tu sitio de WordPress ahora

InspectWP analiza tu sitio de WordPress en busca de problemas de seguridad, SEO, cumplimiento del RGPD y rendimiento, gratis.

Analiza tu sitio gratis