Pentesting WordPress: vectores de ataque reales y cómo se analiza una instalación

Por Kike Gandia · Co-Fundador y CEO, OSCP

Un pentesting de WordPress no es pasar WPScan y esperar resultados. Es simular el recorrido que haría un atacante real: desde la enumeración inicial hasta la explotación de una vulnerabilidad en un plugin custom o la escalada de privilegios desde un usuario editor a administrador. Esta guía explica qué cubre un pentesting de WordPress técnico y por qué es diferente de cualquier herramienta automática.

Fase 1: Reconocimiento y enumeración

El pentesting comienza identificando todo lo que un atacante puede descubrir sin autenticación: versión de WordPress, plugins y temas activos (incluso los "hidden"), usuarios enumerables vía /wp-json/wp/v2/users o el author sitemap, rutas sensibles accesibles (/wp-config.php.bak, /wp-content/debug.log, /xmlrpc.php), y cualquier información de versiones en código fuente, headers o meta etiquetas.

Fase 2: Análisis de plugins y extensiones

Los plugins de terceros son el vector de entrada dominante en compromisos de WordPress. El análisis cubre:

CVEs conocidos: Cada plugin se contrasta con WPScan DB y NVD. Las versiones sin parchear con exploits públicos se prueban directamente.
Código custom: Si hay plugins o temas de desarrollo a medida, se revisa el código fuente buscando patrones de XSS, SQLi, path traversal, deserialización insegura y funciones PHP peligrosas (eval, system, exec).
Configuraciones incorrectas: Plugins que exponen endpoints REST sin autenticación, que permiten subida de archivos sin validación de tipo o que almacenan credenciales en opciones de WordPress accesibles.

Fase 3: Pruebas de autenticación y control de acceso

El panel /wp-admin es el objetivo más común. Las pruebas incluyen: enumeración de usuarios por múltiples métodos (API REST, XML-RPC, error messages), pruebas de fuerza bruta y credential stuffing contra wp-login.php, intentos de bypass de autenticación en plugins de login (SSO, 2FA mal implementado), y escalada de privilegios desde roles de bajo privilegio (Subscriber, Contributor) hacia Editor o Administrador aprovechando vulnerabilidades en plugins.

Fase 4: APIs y endpoints abusables

XML-RPC: Activo por defecto, permite autenticación remota y publicación de contenido. Se usa para fuerza bruta amplificada (múltiples credenciales por request) y como vector de SSRF en instalaciones vulnerables.

REST API: Los endpoints /wp-json/wp/v2/ exponen usuarios, posts, taxonomías y metadatos. Sin autenticación adecuada permiten enumeración masiva y, en algunos plugins, escritura no autorizada de contenido.

Qué diferencia un pentesting de WordPress de un escáner automático

Un escáner automático encuentra versiones desactualizadas y CVEs públicos. No detecta:

Vulnerabilidades en código custom sin CVE publicado
Fallos de lógica de negocio (escalada de roles, bypass de restricciones)
Vulnerabilidades que requieren interacción autenticada
Web shells activos camuflados en ficheros legítimos
Configuraciones de servidor que amplifican el impacto de otras vulnerabilidades

El pentesting manual sigue el razonamiento de un atacante, no solo una lista de firmas.

FAQ

¿Un pentesting de WordPress requiere acceso de administrador?

No necesariamente. El análisis de caja negra parte sin credenciales. Si se quiere mayor cobertura (análisis de lógica autenticada, escalada de privilegios entre roles), se proporcionan cuentas de prueba con diferentes niveles de acceso.

¿El pentesting afecta al SEO o al ranking de la web?

Un pentesting bien ejecutado no genera contenido indexable ni modifica datos en producción. Todos los tests se realizan en entorno controlado o staging. Si se trabaja en producción, las pruebas potencialmente destructivas se acuerdan expresamente y se realizan con supervisión.