WordPress mueve más del 40 % de todas las webs del mundo y cualquier empresa que lo use es un objetivo por pura probabilidad estadística, sea cual sea su tamaño

Usar el software más extendido del planeta significa compartir también sus vulnerabilidades conocidas con la mitad de tus competidores.

Y esto no es solo un problema técnico, pues una brecha que exponga datos de clientes activa obligaciones legales concretas (en España, informar a la Agencia Española de Protección de Datos en un plazo de 72 horas), además de los costes de reputación y de recuperación del propio incidente.

Esta guía está organizada teniendo en cuenta por donde entran los distintos posibles ataques, que son cuatro grandes puertas, y en cada una encontrarás cómo entra el ataque, qué lo cierra (con soluciones gratuitas siempre que existen, que es casi siempre) y cómo comprobar que la puerta quedó cerrada.

Después encontrarás tres bloques transversales de distinta afectación, como son los riesgos propios de vender con WooCommerce, lo que te exige la ley aunque nadie te ataque, y el protocolo si ya han entrado.

Dicho todo esto, empezamos.

Puerta 1 – Las extensiones: por donde entra la inmensa mayoría de los ataques

El ataque típico contra un WordPress de empresa no lo lanza una persona contra tu web, lo lanza un bot contra millones de webs a la vez. El proceso es siempre parecido:

1. El bot rastrea internet buscando versiones concretas de plugins con vulnerabilidades publicadas.
2. Identifica la tuya por la huella que deja en el código fuente.
3. Explota el fallo (para el que suele existir exploit automatizado desde el mismo día del aviso).
4. Sube un pequeño archivo PHP a la carpeta de uploads que le da control remoto.
5. Crea un administrador con nombre discreto y empieza a inyectar redirecciones o spam SEO.

Tú no ves nada hasta que Google marca la web como comprometida o un cliente pregunta por qué al hacer clic en tu enlace acaba en una tienda de medicamentos que no es la tuya. Entre la infección y el descubrimiento pasan normalmente semanas.

Los números explican por qué esta puerta es la primera, y es que de todas las vulnerabilidades nuevas de WordPress la mayoría son del tipo XSS, que permite colar scripts ajenos en el navegador de tus visitantes.

Muy típico es el caso de los plugins abandonados, que no dejan de funcionar de golpe, siguen activos, y cada mes sin actualizarse acumulan más probabilidades de tener un fallo conocido que ya nadie va a parchear.

Y hay un agravante que es que WordPress.org cierra o retira plugins del repositorio con cierta regularidad por malware o vulnerabilidades sin corregir, y ese cierre no desinstala nada de tu servidor. El código sigue ahí, ejecutándose, y el aviso no te llega a ningún sitio salvo que lo busques activamente.

Esto mismo le pasó a un cliente mío con un plugin sencillo, una utilidad para mostrar imágenes del antes y el después, pero con una vulnerabilidad enorme, para la que me tocó preparar un parche, ante el abandono del plugin original.

Qué cierra esta puerta:

• Una política de actualizaciones por escrito: gratis y más eficaz que cualquier herramienta, con actualizaciones automáticas para versiones menores y plugins de confianza, prueba en staging para versiones mayores y plugins críticos (pasarela de pago, formularios, membresías), y cobertura semanal fija con copia de seguridad previa para todo lo demás.
• Una auditoría periódica de todo lo instalado: quién mantiene cada plugin y tema, cuándo se actualizó por última vez, si tiene vulnerabilidades conocidas en tu versión (consúltalo gratis en WPScan o Patchstack antes de instalar nada nuevo) y qué duplicidades funcionales puedes eliminar.
• Tolerancia cero con lo nulled o de procedencia desconocida, y decisión inmediata sobre cualquier extensión activa sin actualizaciones disponibles porque el desarrollador desapareció o la licencia caducó, pues eso es código congelado y sin parches, una decisión estratégica y no un detalle técnico.
• Desinstalar lo que no se usa, incluidos los temas de repuesto que se quedan «por si acaso», porque un tema desactivado sigue siendo código explotable presente en el servidor.
• Vigilancia diaria de los cierres del repositorio: Esta detección automática es, hoy por hoy, casi exclusiva de Vigilante, que consulta la API de wordpress.org cada día por cada plugin instalado, activo o no, y avisa con fecha y motivo si alguno ha sido cerrado o retirado.
• Un cortafuegos de aplicación como red de contención, activo desde el primer día aunque sea con la configuración por defecto, con esto bloqueas los patrones de explotación más comunes y la ejecución de PHP en la carpeta de uploads, de modo que frena el ataque incluso cuando el plugin vulnerable siga instalado.
• Ponérselo más difícil al escaneo automatizado: ocultar la versión de WordPress del código fuente, los feeds y las URL de scripts, y eliminar los readme.html y license.txt de la raíz, que la revelan a cualquiera.
• Si el tema es a medida, comprobar que usa tema hijo (un padre modificado directamente pierde los cambios en la próxima actualización) y que está claro quién paga y renueva cada licencia, además, documenta esa revisión con un informe como el que genera la auditoría de temas, te da la referencia para la siguiente.

Cómo comprobar que está cerrada:

• Abre el código fuente de tu portada y busca generator y ver=: si aparece tu versión exacta de WordPress, sigue visible.
• Sube un archivo PHP de prueba a la carpeta uploads por el medio que uses habitualmente e intenta ejecutarlo desde el navegador, debería devolver un error, no ejecutarse.
• Fecha de la última auditoría de extensiones y número de plugins desinstalados en ella: si la respuesta es «nunca» y «cero», ahí tienes el primer hueco.
• Comprueba que tu escáner de integridad tiene programada una exploración automática y cuándo fue la última.

Puerta 2 – Las personas y sus credenciales

La segunda puerta ni siquiera necesita una vulnerabilidad y es que WordPress regala por defecto la lista de nombres de usuario, puesto que su misma API REST responde en tudominio.com/wp-json/wp/v2/users a cualquiera que pregunte, y las URL del tipo ?author=1, ?author=2 redirigen al archivo público de cada autor.

Con esa lista y las colecciones de contraseñas filtradas que circulan por internet, un bot solo tiene que probar combinaciones en tu formulario de acceso, y si XML-RPC está activo puede probar cientos por petición gracias a su método system.multicall.

La otra variante ni siquiera requiere bots. Es el típico caso de la agencia de hace dos años que conserva un acceso de administrador, la cuenta compartida entre tres personas, el ex-compañero al que nadie dio de baja. El error humano, no un ataque brillante, es la causa más habitual de una brecha.

Qué cierra esta puerta:

• Identificación en dos pasos (2FA) obligatoria para todos los perfiles de editor para arriba, con aplicación de verificación (TOTP) o código por email, exigible por perfil desde tu plugin de seguridad.
• Mínimas capacidades con los perfiles por defecto (administrador, editor, autor, colaborador, suscriptor), creando un perfil a medida antes que subir a nadie a administrador por comodidad.
• Caducidad de contraseñas con historial que impida reutilizar las últimas, sobre todo en administradores, y límite de sesiones simultáneas por usuario si trabajas con externos que entran y salen de proyectos.
• Cierre de la enumeración y del XML-RPC desde tu plugin de seguridad o con código, y URL de acceso personalizada en lugar de /wp-login.php, que elimina la mayoría del tráfico automatizado contra el formulario.
• Un gestor de contraseñas con espacios compartidos por equipos (Bitwarden, por ejemplo, tiene versión gratuita para empezar y planes de equipo económicos), que acaba con las contraseñas en hojas de cálculo y en hilos de correo.
• Una lista de bajas para cuando alguien deja la empresa o termina un proyecto, donde reflejar quién tiene/tenía acceso a WordPress, panel del hosting, registrador del dominio, CDN, Search Console y cualquier servicio conectado. Un usuario por persona, con nombre real, o esta lista será imposible de aplicar.
• Un registro de auditoría que capture accesos, cambios de usuarios y activación de plugins, filtrable y exportable. Esto es lo que convierte «alguien tocó algo» en «este usuario hizo esto a esta hora».
• Formación básica del equipo: no reutilizar contraseñas, desconfiar de enlaces y adjuntos inesperados, saber a quién avisar ante algo raro, es gratis, y más rentable que cualquier herramienta.

Cómo comprobar que está cerrada:

• Visita por tu cuenta dominio.com/wp-json/wp/v2/users y dominio.com/?author=1: ninguna de las dos debería revelar nombres de usuario.
• Cuenta cuántos administradores hay y asegúrate, uno a uno, que de verdad lo necesitan.
• Busca cuentas sin acceso en los últimos seis meses y accesos de proyectos ya cerrados.
• Haz el simulacro de baja: si una persona concreta se fuera mañana, ¿cuántos servicios habría que tocar y tienes la lista?

Puerta 3 – El alojamiento y el servidor

La tercera puerta está fuera de WordPress. Aquí hablamos de que, por ejemplo, una versión de PHP al final de su vida útil deja de recibir parches de seguridad aunque todo lo demás esté al día.

Muy típico es también utilizar un hosting compartido sin aislamiento entre cuentas, lo que convierte el ataque al vecino en un ataque a tu web.

Otro caso habitual es un listado de directorios abierto, lo que permite a cualquiera pasearse por /wp-content/uploads/ y descargar lo que encuentre, y lo mismo pasa con permisos de archivo demasiado generosos, que dejan que un proceso comprometido escriba en wp-config.php o .htaccess, los dos archivos donde una sola línea inyectada sobrevive incluso a reinstalar WordPress.

Y hay un problema más en esta puerta, la disponibilidad, porque una caída también es un incidente y cuesta dinero. Según los cálculos que hice para una conferencia que di en GoDigital de Valencia en 2025, un e-commerce pequeño pierde entre 50 y 200 € por minuto caído, una web corporativa entre 20 y 50 contactos comerciales por hora, y un restaurante sin sistema de reservas entre 500 y 1.500 € por noche.

El día que tu web salga en televisión o una campaña funcione de verdad, la diferencia entre un hosting que escala y uno que se cae es facturación directa.

Qué cierra esta puerta:

• Un hosting que cumpla los mínimos exigibles: HTTP/2 o HTTP/3, versiones de PHP y MySQL o MariaDB actualizadas y cambiables por ti sin tiques de soporte, configuración de seguridad específica para WordPress, aislamiento real de cuentas incluso en planes compartidos, soporte técnico especializado en WordPress, recuperación automática ante caídas y capacidad de absorber picos de tráfico. Si el tuyo no los cumple cambiar de hosting es la medida de seguridad más rentable de esta sección.
• Tres constantes en wp-config.php (primer bloque de código más abajo): desactivan el editor de archivos, fuerzan HTTPS en el escritorio y evitan que los errores de PHP se muestren a los visitantes.
• HTTPS en todo el sitio con HSTS (segundo bloque de código de abajo), para que el navegador ni siquiera intente la conexión sin cifrar la próxima vez.
• El resto de cabeceras de seguridad (Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy), que puedes generar listas para Apache, Nginx o PHP con este generador de cabeceras gratuito.
• Permisos de archivo correctos: 644 para archivos, 755 para directorios, y 440 o 400 para wp-config.php si el hosting lo permite sin romper nada, además de Options -Indexes en el .htaccess para cerrar el listado de directorios.
• Un security.txt en /.well-known/ siguiendo el estándar RFC 9116, para que un investigador que encuentre un fallo sepa cómo avisarte de forma responsable en vez de publicarlo.
• Vigilancia de integridad de wp-config.php y .htaccess: tu plugin de seguridad debería guardar una copia de referencia con suma de verificación y avisarte con un diff línea a línea si algo cambia sin que hayas sido tú.
• Copias de seguridad verificadas y fuera del servidor: restaura una de prueba en un entorno aparte antes de necesitarla en serio, porque una copia alojada en la misma máquina que protege no vale nada el día que esa máquina falle.
• Monitorización de disponibilidad externa, para enterarte tú antes que tus clientes: servicios gratuitos como UptimeRobot comprueban la web cada cinco minutos y avisan por correo en cuanto deja de responder.

// Desactivar el editor nativo de plugins y temas
define( 'DISALLOW_FILE_EDIT', true );
// Forzar HTTPS en wp-admin
define( 'FORCE_SSL_ADMIN', true );
// Nunca mostrar errores a visitantes, solo registrarlos
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

El reparto de responsabilidad con tu hosting conviene confirmarlo por escrito, porque la letra pequeña cambia mucho de un proveedor a otro:

Área de seguridad	Qué suele cubrir un buen hosting gestionado	Qué te corresponde a ti
Parches del servidor y del sistema operativo	Sí, casi siempre	Nada, es su trabajo
Certificado SSL/TLS	Sí, la mayoría lo emite gratis hoy	Forzar HTTPS en todo el sitio y en el admin
Mitigación de DDoS a nivel de red	Depende mucho del hosting; mejor en los gestionados serios	Limitar peticiones a nivel de aplicación, cortafuegos, 2FA
Copias de seguridad	Suele venir incluida, pero revisa la retención real	Comprobar que restauran de verdad, backups propios antes de cambios grandes
Escáner de malware e integridad de archivos	Raro que venga de serie, salvo hostings premium	Escáner activo, revisión de plugins cerrados o abandonados
Actualizaciones de plugins y temas	Casi nunca, salvo que lo actives tú expresamente	Mantenerlos al día, probar en un entorno de pruebas antes

Cómo comprobar que está cerrada:

• Pasa un análisis externo de cabeceras y exposición: el análisis de seguridad hace más de 30 comprobaciones gratis y al instante, sin instalar nada.
• Pregunta a tu hosting, por escrito, qué versión de PHP ejecutas y hasta cuándo recibe parches de seguridad.
• Restaura un backup de prueba en un entorno aparte al menos una vez por semestre y anota cuánto tardaste y si todo se restauró perfecto.
• Recuerda la última caída: ¿te avisó tu monitorización o te avisó un cliente?

Puerta 4 – El perímetro: dominio, correo y proveedores

La cuenta del registrador del dominio sin identificación en dos pasos es el secuestro perfecto pues quien la controle cambia las DNS y se lleva tu web, tu correo y tu marca a otro servidor, con tu WordPress intacto y perfectamente asegurado en el hosting de siempre.

El correo del dominio es la variante silenciosa ya que WordPress y WooCommerce envían correos transaccionales a diario, y un dominio sin DMARC puede ser suplantado por cualquiera para hacer phishing a tus propios clientes con tu remitente y tu marca, sin tocar un solo archivo tuyo.

Los proveedores externos (la agencia, el desarrollador puntual, el servicio conectado por API) son accesos más que habituales que rara vez están inventariados.

Qué cierra esta puerta:

• 2FA y bloqueo de transferencia en el registrador del dominio, hoy mismo: es la cuenta más valiosa de toda tu infraestructura y suele ser la menos protegida.
• Inventario de quién controla qué: dominio, zonas DNS, correo y cada servicio conectado, con un responsable con nombre por fila. Vale una hoja de cálculo, lo que no vale es que la respuesta sea «creo que lo llevaba el informático anterior».
• SPF, DKIM y DMARC en el dominio: el SPF declara qué servidores pueden enviar correo en tu nombre, el DKIM firma cada mensaje (lo genera tu proveedor de correo desde su panel, no es un registro que puedas copiar de una guía) y el DMARC dicta qué hacer con lo que no pase esas comprobaciones. Empieza con el DMARC en modo observación y endurece cuando los informes vengan limpios; tienes los registros de ejemplo más abajo.
• Registro de licencias con titular y fecha de renovación de cada tema y plugin de pago: una licencia que caduca sin que nadie lo sepa es código congelado, y eso te devuelve directo a la puerta 1.
• Acceso de proveedores por escrito: qué puede tocar cada uno, con qué cuenta y hasta cuándo, revocable el día que termina el proyecto. Esto además conecta con el contrato de encargo de tratamiento del bloque legal.

Registros de ejemplo, adaptando dominio y proveedor de correo a los tuyos:

; SPF: declara quien puede enviar correo por ti
; (el include depende de tu proveedor: este es el de Google Workspace)
tudominio.com.  TXT  "v=spf1 include:_spf.google.com ~all"
; DMARC, fase 1: solo observar, nada se bloquea todavia
; (recibiras informes de quien envia correo usando tu dominio)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com"
; DMARC, fase final tras unas semanas de informes limpios
; (p=quarantine como paso intermedio si prefieres endurecer poco a poco)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@tudominio.com"

Cómo comprobar que está cerrada:

• Consulta tu registro DMARC con cualquier comprobador gratuito (MXToolbox o dmarcian, por ejemplo): si no existe es que tu dominio es suplantable desde ayer.
• Entra en la cuenta del registrador y verifica dos cosas: que pide segundo factor y que el bloqueo de transferencia está activo.
• Abre el inventario de accesos y licencias: si no existe, esa es la tarea urgente de esta semana.

Tiendas online con WordPress – Riesgos específicos de WooCommerce

El ataque más frecuente contra un WooCommerce pequeño no busca robarte, busca usarte. Me refiero a bots que prueban tarjetas robadas en tu pasarela de pago (lo que se conoce como card testing) haciendo cientos de micropedidos que a ti te generan comisiones por transacción fallida, disputas y, si se acumulan, la suspensión de la cuenta en la pasarela.

La segunda variante es el registro masivo de cuentas falsas, que ensucia tu base de clientes y prepara fraudes posteriores.

Y la tercera no es un ataque sino una acumulación. Cada pedido guarda datos personales, y una base con años de pedidos completos es superficie expuesta el día de una brecha y responsabilidad directa ante el RGPD.

Qué lo cierra, todo gratis:

• Verificación antibots en el pago y el registro: Cloudflare Turnstile es gratuito y menos molesto que un captcha clásico, y la mayoría de plugins de formularios y de seguridad lo integran.
• Límite de intentos de pago por IP y por sesión, desde el cortafuegos de tu plugin de seguridad o desde la propia pasarela, que suele incluir reglas antifraude configurables sin coste.
• Revisión semanal de patrones de fraude: rachas de pedidos fallidos de importe mínimo, muchas cuentas nuevas sin compra asociada, picos de registro a horas extrañas.
• Retención de datos con caducidad: WooCommerce trae herramientas de limpieza y anonimizado en «Ajustes → Cuentas y privacidad». Configúralas y deja de acumular pedidos identificables de hace cinco años que ya no necesitas.

Cómo comprobar que está cerrada:

• Consulta en el panel de tu pasarela la proporción de transacciones rechazadas del último mes: si supera con claridad a la de meses anteriores, ya te están usando.
• Cuenta las cuentas de cliente creadas en los últimos 30 días sin ningún pedido asociado.
• Abre un pedido de hace tres años y mira qué datos personales sigue guardando.

Obligaciones legales y de privacidad siempre aplicables

Si tu WordPress recoge datos personales de clientes, usuarios registrados o simples visitantes que rellenan un formulario, estás sujeto al RGPD y a la Ley Orgánica de Protección de Datos, con independencia del tamaño de la empresa.

El RGPD exige aplicar medidas de seguridad adecuadas al riesgo, así que una brecha de seguridad es casi siempre también una brecha de protección de datos, con plazos y sanciones concretos.

La notificación a la AEPD debe hacerse en un máximo de 72 horas, con multas de hasta 10 millones de euros o el 2 % de la facturación para las infracciones graves (entre ellas, no notificar a tiempo) y de hasta 20 millones o el 4 % para las más graves.

Las sanciones a autónomos y pymes suelen moverse en varios miles de euros, lejos de los titulares millonarios pero suficientes para hacerte un agujero importante.

Qué hacer:

• Documenta cualquier incidente de seguridad, aunque decidas no notificarlo: el RGPD exige registrar internamente el análisis que llevó a esa decisión, precisamente para poder demostrarlo si la AEPD pregunta.
• Deja por escrito, en un contrato de encargo de tratamiento, quién es el responsable y quién el encargado cuando trabajas con una agencia o un servicio externo.
• Aplica minimización de datos</s

Fernando Tellado