Intrusiones en WordPress: análisis más técnico y soluciones

WordPress rara vez se compromete por un único fallo del núcleo. Lo habitual es una cadena: un plugin o tema desactualizado, un endpoint expuesto, credenciales reutilizadas o un hosting mal configurado. Este análisis técnico desglosa los vectores más relevantes, los indicadores de compromiso que dejan y las medidas de contención, erradicación y endurecimiento.

Este artículo es la versión técnica. Si buscas una introducción menos detallada, consulta la guía introductoria sobre intrusiones en WordPress.

1. Modelo de amenaza y superficie de ataque en WordPress

Un WordPress expuesto combina, como mínimo, seis superficies: el núcleo, los plugins y temas, la autenticación, la API REST, la base de datos y el servidor/hosting. A esto se suma la cadena de suministro. La mayoría de los incidentes documentados por WPScan, Patchstack y Sucuri se originan en componentes de terceros o en credenciales comprometidas, no en un zero-day del core.

2. Fuerza bruta y enumeración de usuarios en WordPress

El abuso de autenticación sigue siendo rentable porque no requiere un fallo de código. Dos vectores destacan:

• XML-RPC: system.multicall permite empaquetar cientos de intentos de login en una sola petición HTTP, reduciendo el coste del ataque y evadiendo límites simples por request.
• Enumeración de usuarios: /wp-json/wp/v2/users, ?author=1 y las diferencias de respuesta en el login permiten obtener nombres de usuario válidos antes del ataque.

Detección: picos de POST /wp-login.php y POST /xmlrpc.php, respuestas 302 repetidas, user-agents vacíos o inconsistentes y gran volumen desde pocas IPs o desde rangos residenciales/proxy.

Mitigación:

• 2FA obligatorio para administradores y editores.
• Rate limiting en el borde (Cloudflare, WAF) y bloqueo progresivo.
• Deshabilitar XML-RPC si no se usa:

add_filter('xmlrpc_enabled', '__return_false');

Bloqueo a nivel de servidor (Apache 2.4):

<Files "xmlrpc.php">
  Require all denied
</Files>

Restringir la enumeración por REST si no la necesitas (verifica que no rompa el editor ni funcionalidades de autor):

add_filter('rest_endpoints', function ($endpoints) {
    unset($endpoints['/wp/v2/users']);
    unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    return $endpoints;
});

3. Vulnerabilidades en plugins y temas: CVE destacados

Los fallos más explotados suelen ser bypass de autenticación, escalada de privilegios, inyección SQL, carga arbitraria de archivos y LFI/RFI. La explotación masiva ocurre cuando el parche ya existe pero miles de sitios siguen en versiones antiguas.

Consulta siempre el aviso del proveedor para la versión corregida exacta. Estrategia:

• Parcheo virtual en el WAF para vulnerabilidades aún sin actualización disponible.
• Actualizaciones escalonadas: staging → producción, con verificación funcional.
• Eliminación de plugins/temas abandonados; desactivar no es suficiente.
• Inventario de versiones y alertas ante nuevos CVE (Patchstack, WPScan).

4. Webshells y persistencia en WordPress

Tras el acceso inicial, el atacante busca persistir. Los lugares habituales son:

• wp-content/uploads (PHP camuflado como imagen o archivo legítimo).
• wp-content/mu-plugins: se carga siempre, sin activación visible en el panel.
• Drop-ins: advanced-cache.php, object-cache.php, db.php.
• Plugins/temas falsos o modificados, y archivos dentro de wp-includes.
• Usuarios administradores creados por el atacante y eventos de cron persistentes.
• Reglas en .htaccess para redirigir o servir payloads.

Patrones de ofuscación frecuentes: eval(), base64_decode(), gzinflate(), create_function(), preg_replace() con modificador /e, funciones variables y cadenas hexadecimales.

grep -rIl --include='*.php' -E 'eval\(|base64_decode\(|gzinflate\(|create_function\(|preg_replace\(.*/e' wp-content/
find wp-content -type f -name '*.php' -mtime -7 -ls
ls -la wp-content/mu-plugins/
ls -la wp-content/advanced-cache.php wp-content/object-cache.php wp-content/db.php

Verificación de integridad con WP-CLI:

wp core verify-checksums
wp plugin verify-checksums --all
wp theme verify-checksums --all

5. Malware JavaScript y redirecciones

El malware moderno no siempre modifica archivos PHP. Campañas como Sign1 (más de 39.000 sitios) inyectaron scripts en widgets HTML y plugins legítimos para mostrar redirecciones y publicidad. Otras variantes usan CAPTCHAs falsos, iframes de “actualiza tu navegador” o perfiles de Steam como canal de mando y control, codificando payloads con caracteres Unicode invisibles.

Detección en base de datos (ajusta el prefijo):

SELECT option_name
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%base64_decode%';

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%';

Busca también scripts externos desconocidos, iframes ocultos y dominios que no reconoces. Mitigación: CSP restrictiva, Subresource Integrity (SRI) donde aplique, WAF y monitorización de integridad de contenido.

6. SEO spam, pharma hack y cloaking

El atacante inyecta enlaces y contenido oculto (farmacia, apuestas, palabras clave en japonés) y suele servirlo solo a buscadores mediante cloaking por user-agent o reglas de rewrite. El sitio se ve normal para el visitante humano.

• Revisa site:tudominio.com en Google y los sitemaps.
• Audita .htaccess, robots.txt y reglas condicionales por user-agent.
• Busca contenido oculto en wp_posts, wp_options y widgets.
• Tras limpiar, solicita revisión en Search Console.

7. Skimmers en WooCommerce

Los skimmers tipo Magecart inyectan JavaScript en el checkout para exfiltrar datos de tarjeta en tiempo real. El cliente completa el pago y no percibe anomalías. El vector suele ser un plugin vulnerable, un tema modificado o credenciales de administrador comprometidas.

• Usa pasarelas alojadas (Stripe, PayPal) y evita formularios propios de tarjeta.
• Monitoriza cambios en plantillas de checkout y en woocommerce.
• Aplica CSP y revisa peticiones salientes hacia dominios desconocidos.
• Mantén cumplimiento PCI y mínimo privilegio en cuentas de tienda.

8. Fallos del núcleo y API REST

Los fallos del core son menos frecuentes, pero de impacto alto. En 2026 se documentó la cadena wp2shell, que combinaba una confusión de rutas en el endpoint por lotes de la API REST (/wp-json/batch/v1) con una inyección SQL para lograr ejecución remota de código sin autenticación. También se corrigió un fallo de inclusión remota de archivos que permitía RCE no autenticado.

• Activa actualizaciones automáticas de seguridad del core.
• Prueba en staging y aplica parches críticos sin demora.
• Usa WAF con reglas para endpoints REST y patrones de explotación conocidos.
• Restringe rutas REST que no uses y bloquea batch/v1 en el borde si no es necesario.

9. Cadena de suministro y plugins “nulled”

Plugins y temas “nulled” incluyen backdoors de fábrica. También existen casos de plugins legítimos que, tras ser adquiridos por terceros, introducen código malicioso en actualizaciones posteriores. El ataque llega por una vía que el administrador considera confiable.

• Instala solo desde el repositorio oficial o proveedores verificados.
• Revisa el historial del desarrollador y los cambios de propiedad.
• Fija versiones y revisa diferencias antes de actualizar componentes sensibles.
• Verifica checksums cuando el componente provenga de WordPress.org.

10. Credenciales, hosting y secretos en WordPress

FTP/SFTP, cPanel, SSH, base de datos y correo son accesos de alto valor que a menudo quedan fuera del radar. Un malware en el equipo del administrador o un phishing pueden comprometerlos sin tocar WordPress.

• 2FA en hosting, correo y WordPress.
• SFTP/SSH con claves; desactivar FTP plano.
• Credenciales únicas por servicio y rotación tras cualquier incidente.
• Restringir el panel por IP cuando sea viable.
• No almacenar secretos en el repositorio ni en el historial de Git.

Tras una intrusión, rota también las sales de wp-config.php para invalidar cookies de sesión:

wp config shuffle-salts

11. Hardening de WordPress: configuración y permisos

wp-config.php

define('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
define('WP_AUTO_UPDATE_CORE', 'minor');
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);

DISALLOW_FILE_MODS bloquea instalaciones y actualizaciones desde el panel; úsalo solo si gestionas el ciclo de vida por WP-CLI/CI, porque también impide actualizar plugins y temas desde la administración.

Bloqueo de PHP en uploads

Crea wp-content/uploads/.htaccess con:

<FilesMatch "\.(?i:php|phtml|php3|php4|php5|php7|phps)$">
  Require all denied
</FilesMatch>

Cabeceras de seguridad

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Permisos y exposición

• Archivos 644, directorios 755; wp-config.php 600.
• Desactivar listado de directorios (Options -Indexes).
• Proteger wp-config.php, readme.html, license.txt y backups expuestos.
• Backups 3-2-1, con una copia fuera del hosting e inmutable; prueba la restauración.

12. Respuesta a incidentes en WordPress

1. Preserva evidencia: copia logs, snapshot de base de datos y archivos antes de modificar nada.
2. Aísla: modo mantenimiento, WAF en bloqueo y restricción de salida si hay exfiltración.
3. Determina el alcance: revisa checksums, usuarios admin, cron, drop-ins, mu-plugins, .htaccess y contenido inyectado.
4. Contén y erradica: elimina webshells, backdoors y código malicioso; si el compromiso es profundo, reconstruye desde cero.
5. Rota credenciales: base de datos, WordPress, FTP/SFTP, SSH, hosting, APIs y sales.
6. Restaura y verifica: vuelve a producción solo tras escaneos limpios y revisión funcional.
7. Post-mortem: documenta el vector, el alcance y las medidas correctivas.

Comandos útiles de triage:

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list
wp option get siteurl

Consulta de administradores en base de datos:

SELECT ID, user_login, user_email, user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Herramientas recomendadas

Preguntas frecuentes sobre intrusiones en WordPress

¿Cuál es la vulnerabilidad más común en WordPress?

Los plugins y temas desactualizados concentran la mayoría de las intrusiones. Un complemento sin parche puede permitir desde crear un administrador hasta ejecutar código en el servidor.

¿Cómo sé si mi WordPress ha sido hackeado?

Usuarios administradores desconocidos, redirecciones a dominios extraños, spam en Google, archivos PHP modificados o webshells en uploads. Verifica con wp core verify-checksums y revisa logs y Search Console.

¿WordPress es seguro?

El núcleo mantiene un buen historial cuando se actualiza. El riesgo real está en la superficie añadida: plugins, temas, credenciales y configuración del hosting.

¿Qué hago si mi WordPress está infectado?

Aísla el sitio, preserva logs y copias, identifica el vector, elimina webshells y backdoors, rota todas las credenciales y restaura desde un backup limpio si es necesario.

¿Cada cuánto debo actualizar WordPress?

Activa las actualizaciones automáticas de seguridad del núcleo y revisa plugins y temas al menos semanalmente. Aplica parches críticos en cuanto estén disponibles, probando antes en staging.

¿Un plugin de seguridad es suficiente?

No. Un plugin ayuda con WAF, escaneo y 2FA, pero no sustituye la gestión de parches, el mínimo privilegio, los backups probados ni la monitorización.

Las versiones y CVE citados evolucionan. Verifica siempre el estado actual de tus componentes y el aviso oficial del proveedor antes de aplicar cambios en producción.