🔒 Seguridad en WordPress en 2026: una guía completa para la protección de sitios web

Un sitio WordPress es hackeado no porque el motor esté «lleno de agujeros». Es hackeado porque el propietario pospuso la actualización de un plugin, puso la contraseña admin123 y dejó abierto xmlrpc.php. Bots automatizados escanean internet continuamente.

No les importa si usted vende velas artesanales o gestiona una tienda en línea. Encontrarán y explotarán la vulnerabilidad. Fuerza bruta de inicio de sesión, inyección SQL, carga de shell a través de un plugin vulnerable, todo esto funciona las 24 horas.

La buena noticia: usted puede construir una protección básica en una tarde, sin conocimientos técnicos profundos. A continuación, un conjunto probado de medidas, desde instalar un firewall hasta el endurecimiento manual del servidor. Todo lo descrito aquí lo aplicamos en nuestros propios proyectos.

💡 Resumen rápido:

• Instale un firewall: BBQ o Wordfence, la primera línea de defensa bloquea la mayoría de los ataques antes de que lleguen a WordPress.
• Cierre los puntos de entrada típicos: xmlrpc.php, la API REST para usuarios no autenticados, el listado de directorios, el editor de archivos en el panel de administración.
• Configure las actualizaciones automáticas para el núcleo, los temas y los plugins. Una versión desactualizada de un plugin es el principal vector de ataque.
• Haga una copia de seguridad que se almacene FUERA del servidor. Sin una copia de seguridad, la recuperación tras un hackeo implica reinstalar WordPress desde cero.
• Active la autenticación de dos factores para todos los administradores. Una contraseña se puede adivinar; un segundo factor, no.

Dónde atacan primero: vectores de ataque típicos

La mayoría de la gente imagina a un hacker como alguien en una terminal, adivinando manualmente la contraseña del administrador. La realidad es más mundana: prácticamente todos los ataques los realizan bots que siguen un guion. Buscan vulnerabilidades conocidas en plugins y temas, llaman a xmlrpc.php, escanean /wp-content/uploads/ en busca de archivos PHP ejecutables.

Los principales vectores de ataque contra WordPress:

• Plugins y temas desactualizados. Según informes de Sucuri, alrededor del 40% de los sitios hackeados estaban usando una versión desactualizada del CMS, un plugin o un tema en el momento de la infección. Los desarrolladores cierran agujeros con parches, pero solo si usted aplica esos parches.

• Contraseñas débiles. Los ataques de fuerza bruta prueban decenas de miles de combinaciones por minuto. Una contraseña de 6 caracteres sin caracteres especiales se descifra al instante.

• Hosting inseguro. El hosting compartido barato escatima en el aislamiento de cuentas: si un sitio vecino en el servidor es hackeado, el ataque puede extenderse al suyo.

• Permisos de escritura excesivos. Cuando el servidor web puede escribir en cualquier archivo, un shell subido a través de un agujero obtiene control total sobre el sitio.

Comprender estos vectores es la mitad de la defensa. La otra mitad es la acción concreta.

Nivel 1: protección rápida que puede configurar en media hora

Por aquí debería empezar hoy. Cada acción lleva minutos, no requiere editar código y no romperá su sitio.

Instalar un firewall: BBQ Firewall

BBQ Firewall es un plugin de Jeff Starr que funciona bajo el principio de «instalar y olvidar». Sin ajustes, sin interferencia con .htaccess o la base de datos. Simplemente bloquea las solicitudes URL maliciosas antes de que lleguen a WordPress: eval(), base64_decode, cadenas excesivamente largas, intentos de inyección.

El plugin pesa menos de 10 KB y no genera carga. Al mismo tiempo, detecta inyección SQL, XSS, carga de archivos ejecutables y ataques a través de referidores «malos».

En la práctica, BBQ se instala a menudo ENCIMA de Wordfence o Solid Security; resuelven problemas diferentes y no entran en conflicto. Un firewall a nivel de solicitud más un plugin de seguridad completo le proporciona una defensa en capas.

Activar la autenticación de dos factores

Una contraseña se puede adivinar, interceptar o comprar en un volcado de bases de datos filtradas. Un segundo factor, un código de un solo uso de una aplicación autenticadora, rompe toda la lógica de los ataques de fuerza bruta.

WordPress no tiene 2FA integrado. El camino más fácil es instalar Solid Security (anteriormente iThemes Security) o Wordfence. Ambos incluyen 2FA en la versión gratuita. Tras la activación, vaya a Seguridad → Ajustes → Autenticación de dos factores y actívela para el rol de Administrador.

Estos mismos plugins cierran una docena más de vulnerabilidades de fábrica:

• Solid Security: cambia la URL de inicio de sesión (/wp-admin → su slug único), establece un límite de intentos de inicio de sesión, escanea archivos en busca de cambios, bloquea IPs tras una serie de inicios de sesión fallidos, verifica plugins y temas en busca de vulnerabilidades conocidas.

• Wordfence: Firewall de Aplicaciones Web con reglas actualizadas automáticamente, escáner de malware, protección de fuerza bruta, monitorización del tráfico en tiempo real. Es especialmente bueno para limpiar un sitio ya hackeado: encuentra puertas traseras, archivos del núcleo modificados, spam oculto.

Solo necesita UNO de ellos. En nuestros proyectos, instalamos Wordfence + BBQ: el primero proporciona un WAF y escáner, el segundo corta las solicitudes basura antes de que siquiera se acerquen.

Desactivar xmlrpc.php

XML-RPC es una interfaz para el trabajo remoto con WordPress a través de aplicaciones móviles y trackbacks. Hoy en día, la gran mayoría de los sitios no lo necesitan, sin embargo, sigue siendo uno de los puntos más atacados: los bots usan xmlrpc.php para hacer fuerza bruta de contraseñas y realizar ataques DDoS.

Puede desactivarlo de dos maneras. La forma rápida, mediante un plugin: Solid Security lo hace en un clic. La forma correcta, a nivel de servidor, en .htaccess:

1
<Files xmlrpc.php>
2
Order Deny,Allow
3
Deny from all
4
</Files>

Añada este bloque al .htaccess raíz y olvídese de xmlrpc. Si usa la aplicación móvil de WordPress o servicios externos que necesiten XML-RPC, compruebe primero si funcionan sin él. En 2026, las alternativas, la API REST con autenticación, cubren casi todos los escenarios.

Desactivar el listado de directorios

Abra вашсайт.com/wp-content/uploads/ en su navegador. Si ve una lista de archivos, tiene un problema. El listado de directorios muestra la estructura de su sitio a cualquiera que se moleste en mirar.

La solución: una línea en .htaccess:

1
Options -Indexes

Añada también un index.php vacío en cada directorio sospechoso: /wp-content/uploads/, temas, plugins que carezcan de su propio index.php.

Desactive el editor de archivos en el panel de administración

WordPress incluye la capacidad de editar archivos .php de temas y plugins directamente desde el panel de administración: Apariencia → Editor de archivos del tema y Plugins → Editor de archivos del plugin. Es práctico, hasta que alguien no autorizado accede al panel de administración. En ese momento se convierte en una herramienta lista para subir una shell.

Añada una constante a wp-config.php:

1
define('DISALLOW_FILE_EDIT', true);

Eso es todo. El editor desaparece del panel de administración. Use FTP/SFTP para editar archivos, menos práctico, pero más seguro.

Nivel 2: refuerzo manual de WordPress

Las siguientes medidas van un poco más allá: requieren editar archivos de configuración y entender la estructura del servidor. El resultado es un sitio que los bots ignoran porque no ven WordPress en él.

Actualice las sales de seguridad

Las sales, claves de seguridad y sales, son ocho líneas en wp-config.php que cifran las cookies de autenticación. Cambiarlas cierra instantáneamente la sesión de todos, incluido un posible atacante con una sesión robada.

Vaya a api.wordpress.org/secret-key/1.1/salt/, copie el bloque generado y reemplace la sección correspondiente en wp-config.php con él. Toma un minuto. Hágalo siempre que sospeche de un compromiso.

Cambie el prefijo de las tablas de la base de datos

Por defecto, todas las tablas de WordPress se llaman wp_posts, wp_users y wp_options. Las inyecciones SQL suelen estar diseñadas específicamente para el prefijo estándar.

En una instalación nueva, especifique un prefijo no estándar en wp-config.php:

1
$table_prefix = 'wp83x_';

Para un sitio existente, cambiarlo es más difícil: necesita renombrar las tablas en la base de datos y actualizar los valores en usermeta y options. No intente esto sin conocimientos sólidos de phpMyAdmin y SQL, el riesgo de tirar el sitio es demasiado alto.

Mueva wp-config.php por encima de la raíz web

wp-config.php contiene la contraseña de la base de datos y las claves de cifrado. Si el servidor web lo sirve accidentalmente como texto plano, lo que ocurre durante una actualización fallida de PHP, el atacante obtiene todo.

Solución: mueva wp-config.php un nivel por encima del directorio raíz del sitio, por ejemplo de /public_html/ a la carpeta principal del hosting. WordPress busca automáticamente la configuración en el directorio padre, el código no se romperá.

Oculte la versión de WordPress

El generador <meta name="generator" content="WordPress X.X.X"> en el código fuente de la página es un regalo para los bots. Ellos cruzan la versión con una base de datos de vulnerabilidades conocidas y atacan con precisión.

Elimine el generador mediante functions.php:

1
// Remove the WordPress generator meta tag from the page source code
2
function no_generator() {
3
    return '';
4
}
5
add_filter('the_generator', 'no_generator');

La función no_generator() devuelve una cadena vacía en lugar de la salida de versión estándar. El filtro the_generator intercepta la salida de la metaetiqueta y todas sus variantes, para feeds, RSS y la API REST.

Elimine también readme.html y liesmich.html de la raíz de la instalación, también exponen la versión. Después de una actualización de WordPress estos archivos pueden reaparecer, verifíquelo una vez al mes.

Configure los encabezados de seguridad HTTP

Los encabezados de respuesta HTTP le indican al navegador cómo manejar el contenido. Los encabezados de seguridad correctamente configurados bloquean el clickjacking, XSS y la suplantación de contenido.

Un conjunto mínimo para WordPress, añada estas líneas a .htaccess:

1
Header set X-Frame-Options "SAMEORIGIN"
2
Header set X-Content-Type-Options "nosniff"
3
Header set Referrer-Policy "strict-origin-when-cross-origin"
4
Header set X-XSS-Protection "1; mode=block"

El plugin HTTP Headers le permite hacer lo mismo a través del panel de administración si prefiere no tocar la configuración del servidor.

Para una configuración avanzada, utilice la Política de Seguridad de Contenido (CSP). Pero tenga en cuenta: una CSP incorrecta rompe el panel de administración, la carga de fuentes y la funcionalidad de los plugins. Impleméntela gradualmente, comenzando con el modo Content-Security-Policy-Report-Only.

Restrinja los permisos de archivos

Los permisos, la última línea de defensa. Si un atacante sube un archivo pero no puede ejecutarlo, el ataque se detiene.

Reglas básicas:

• Directorios: 755, el propietario lee, escribe, ejecuta; el grupo y otros leen y ejecutan.
• Archivos: 644, el propietario lee y escribe, otros solo leen.
• wp-config.php: 400, solo el propietario lee.
• .htaccess: 444, solo lectura para todos, si WordPress no lo edita automáticamente.

Evite absolutamente el 777. Sí, algunos plugins piden 777 en wp-content/uploads/. No lo conceda. 755 en la carpeta y 644 en los archivos dentro es suficiente para las cargas de medios.

Qué hacer si el sitio ya está hackeado

Un hackeo se descubre de diferentes maneras: una redirección a un casino, envío de spam, un aviso de «Este sitio puede estar hackeado» en los resultados de búsqueda de Google, una queja del proveedor de hosting. La secuencia de acciones:

• Cambie inmediatamente todas las contraseñas: administrador de WordPress, FTP/SFTP, base de datos, panel de control del hosting. Empiece por esta última. Si el hacker está en el panel de hosting, simplemente creará un nuevo administrador.

• Restaure el sitio desde una copia de seguridad hecha ANTES del hackeo. Una copia de seguridad reciente hecha después del compromiso probablemente contenga una puerta trasera. Si no hay copia de seguridad, siguiente paso.

• Instale Wordfence y ejecute un escaneo completo. El plugin encontrará archivos del núcleo modificados, código sospechoso, puertas traseras ocultas. Elimine todo lo que el escáner haya marcado, luego reemplace el núcleo de WordPress con una copia nueva: el botón «Reinstalar» en Escritorio → Actualizaciones.

• *Revise wp-content/uploads/ en busca de archivos .php.* No deberían estar ahí. Cualquier .php en la carpeta de cargas es casi con toda seguridad una shell.

Vea el video de arriba, desglosa los errores típicos de seguridad en WordPress y cómo solucionarlos, desde contraseñas débiles hasta permisos de archivo incorrectos.

• Conecte un monitoreo externo. Sucuri, un servicio en la nube con un WAF y un equipo de respuesta. El WAF filtra el tráfico antes de que llegue al servidor. Si ocurre una intrusión, el equipo de Sucuri limpia el sitio en cuestión de horas. El precio comienza en $199/año para el plan básico con limpieza y monitoreo. No es gratuito, pero cuando un sitio genera ingresos, el tiempo de inactividad cuesta más.

Asegúrese de registrar su sitio en Google Search Console. Si Google detecta código malicioso, recibirá una notificación antes de que el sitio desaparezca de los resultados de búsqueda.

Protección contra ransomware: por qué las copias de seguridad lo resuelven todo

El ransomware cifra los archivos del sitio y exige un rescate. Los sitios WordPress son un blanco frecuente: pedidos, bases de datos de clientes, contenido. Perderlo todo de la noche a la mañana es un escenario real sin una copia de seguridad.

Tres reglas:

• Copia de seguridad fuera del servidor. Nube o un FTP independiente. UpdraftPlus y Duplicator automatizan la descarga externa.
• Firewall y escáner. Wordfence + BBQ bloquean las cargas de archivos maliciosos en la etapa de la solicitud.
• Solo fuentes oficiales. El directorio de WordPress.org y sitios de desarrolladores con reputación. Nada de temas «gratuitos» de torrents.

Monitoreo automático de integridad de archivos

Protección del lado del servidor, no una acción puntual. Agrupe las comprobaciones en un script de shell en cron, una vez al día, resultados por correo electrónico:

1
SITE_ROOT="/absolute/path/to/public_html"
2
 
3
find "$SITE_ROOT" -mtime -1 -name "*.php" \
4
    -printf '%TY-%Tm-%Td %TT\t%p\n' >> /tmp/file-changes.log
5
 
6
find "$SITE_ROOT" -mtime -7 -name "*.php" \
7
    | xargs grep -l -i "eval\|base64_decode\|iframe\|file_get_contents" \
8
    >> /tmp/suspicious-code.log
9
 
10
find "$SITE_ROOT/wp-content/uploads" -name "*.php" -print \
11
    >> /tmp/php-in-uploads.log
12
 
13
find /home -type d -perm 0777 >> /tmp/perms.log
14
find /home -type f -perm 0777 >> /tmp/perms.log
15
 
16
mailx -s "Webserver File Audit $(date +%F)" admin@example.com \
17
    < /tmp/suspicious-code.log

El script se ejecuta una vez al día mediante cron. El primer bloque find -mtime -1 muestra los archivos PHP modificados en las últimas 24 horas, el detector principal de intrusiones. El segundo busca firmas de shell: eval, base64_decode, iframes ocultos. El tercero detecta PHP en la carpeta de uploads, donde el PHP legítimo nunca debería estar. El cuarto encuentra archivos y carpetas con permisos 777. El resultado se envía a correo electrónico. El monitoreo proactivo detecta una intrusión en una etapa temprana, antes de que Google lo note y prohíba el sitio en los resultados de búsqueda.

Sucuri: un firewall en la nube para cuando no tiene tiempo de trastear

Cómo funciona: el tráfico pasa a través del proxy en la nube de Sucuri con un WAF, las solicitudes maliciosas se bloquean antes de llegar al hosting. El sitio carga más rápido gracias al CDN. Capacidades clave: un WAF con firmas en tiempo real, protección DDoS, limpieza automática de malware.

Los planes comienzan en $199/año. No hay versión gratuita, pero el plugin de escáner de Sucuri verifica los archivos en busca de cambios sin el WAF. Para un sitio comercial, es una inversión justificada. Para un blog personal, Wordfence + BBQ es suficiente.

⁉️🤔 Preguntas frecuentes

¿Es WordPress seguro en sí mismo?

El núcleo de WordPress es revisado por cientos de desarrolladores y auditores de seguridad. El problema no es el núcleo; el problema son los plugins desactualizados, los temas de fuentes no confiables y las contraseñas 123456. Las actualizaciones periódicas más un firewall básico proporcionan protección suficiente para la mayoría de los sitios.

¿Puedo arreglármelas sin plugins de seguridad?

Puede, si está dispuesto a configurar manualmente un firewall a nivel de servidor: iptables, mod_security, 7G/8G Firewall en .htaccess, rastrear los CVE de cada plugin y escribir scripts cron para la monitorización. Para todos los demás, instalar Wordfence o Solid Security es una hora frente a docenas de horas de trabajo manual.

¿Son necesarias las actualizaciones si ya tengo un firewall?

Sí, absolutamente. Un firewall bloquea los ataques desde el exterior, pero si hay instalado un plugin con una vulnerabilidad conocida, tarde o temprano se encontrará un vector que el firewall no detecte. Actualizar todos los componentes de WordPress es la base sin la cual las demás medidas funcionan a medio rendimiento.

¿Qué plugin de seguridad debería elegir?

Para protección mínima: BBQ Firewall, bloquea solicitudes URL maliciosas, configuración cero. Para protección completa: Wordfence, WAF, escáner, 2FA, protección de fuerza bruta, todo en la versión gratuita. La combinación BBQ + Wordfence cubre ambas capas sin conflictos.

¿Y qué hay de la API REST, debería desactivarla?

La API REST la necesita WordPress para el editor de bloques Gutenberg, varios plugins e integraciones externas. Desactivarla por completo romperá el panel de administración. En su lugar, restrinja el acceso: deje solo los endpoints públicos para usuarios no autenticados. El plugin REST API Toolbox le permite configurar el acceso de forma flexible sin intervención quirúrgica.

¿Con qué frecuencia debo escanear el sitio en busca de virus?

Automáticamente, a diario mediante scripts cron: comprobando archivos modificados, buscando .php en la carpeta de subidas. Manualmente, una vez al mes: entre en Wordfence, ejecute un escaneo completo, revise la lista de plugins en busca de abandonados. Si no tienen actualizaciones en más de un año, elimínelos o sustitúyalos.

¿Puedo perder posicionamiento en Google a causa de un hackeo?

Puede, y rápidamente. Google escanea los sitios en busca de código malicioso y marca los infectados con una advertencia en los resultados de búsqueda. Si el hackeo no se soluciona en pocas semanas, el sitio es desindexado. Registre su sitio en Google Search Console y recibirá una notificación sobre el problema en cuanto se detecte.

¿Cambiar de hosting ayudará a prevenir hackeos?

Parcialmente. Un hosting de calidad añade sus propias capas: aislamiento de cuentas, monitorización de red, actualización automática de PHP. Pero el hosting no protege contra un plugin con fugas que usted mismo instaló, o la contraseña qwerty. La seguridad es un pastel de capas: hosting más actualizaciones más firewall más permisos de acceso más copias de seguridad.

Seguridad en WordPress: por dónde empezar hoy

La regla principal de la seguridad en WordPress es no intentar abordarlo todo de una sentada. Empiece con tres pasos:

• Si no hay firewall, instale BBQ Firewall. Un minuto.
• Si no hay copias de seguridad externas al servidor, configure UpdraftPlus con subida a la nube. Diez minutos.
• Si el 2FA no está activado para los administradores, actívelo mediante Wordfence. Cinco minutos.

Luego vuelva a la lista anterior: desactive xmlrpc, actualice las sales, desactive el editor de archivos, configure las cabeceras de seguridad. Un punto al día, y en una semana su sitio estará un orden de magnitud mejor protegido de lo que estaba ayer.

¿Qué medidas de seguridad están ya funcionando en su sitio? Cuéntemelo en los comentarios, tengo curiosidad por comparar enfoques.