El 43% de internet corre sobre WordPress. Esa democratización tiene un precio: millones de instalaciones mal configuradas, sin actualizar y sin protección son el objetivo favorito de cualquier atacante.
Haz clic en cada vulnerabilidad para ver el detalle del ataque y cómo prevenirlo.
Las versiones pirata incluyen backdoors ocultos instalados por diseño. El atacante tiene acceso completo desde el primer día.
El atacante descarga el plugin nulled, extrae el backdoor (normalmente en wp-includes o en un archivo .php ofuscado) y obtiene acceso remoto a la shell. Tiempo medio de explotación: inmediato tras la instalación.
Usar exclusivamente plugins y temas del repositorio oficial de WordPress o de proveedores de confianza. Auditar el código antes de instalar cualquier plugin de fuente desconocida.
Sin límite de intentos ni 2FA, el panel de administración es objetivo directo de ataques de fuerza bruta automatizados.
Herramientas como WPScan o Hydra automatizan el ataque: prueban millones de combinaciones usuario/contraseña por minuto. Con un servidor sin rate limiting, una contraseña débil cae en minutos.
Contraseñas de más de 20 caracteres, 2FA obligatorio, cambio de la URL de login, límite de intentos con plugins como Limit Login Attempts.
Más del 50% de hackeos explotan vulnerabilidades con parche disponible que nunca fue aplicado.
Cuando se publica un CVE para un plugin popular, los atacantes automatizan el escaneo de millones de sitios en horas buscando instalaciones vulnerables. El tiempo entre publicación del CVE y explotación masiva es de menos de 24 horas.
Actualizaciones automáticas para plugins menores, revisión manual antes de actualizar plugins críticos (WooCommerce, Elementor), monitorización de CVEs en tiempo real.
wp-config.php, xmlrpc.php y /wp-content/ mal configurados exponen datos críticos.
Si wp-config.php tiene permisos 644 en un hosting compartido, otros usuarios del servidor pueden leer las credenciales de la base de datos. xmlrpc.php expuesto permite ataques de fuerza bruta amplificados.
wp-config.php con permisos 440 o 400, xmlrpc.php desactivado si no se usa, directorios sin ejecución PHP, cabeceras de servidor que oculten versiones.
Formularios sin sanitización permiten extraer toda la base de datos con una sola petición.
Un atacante introduce payloads como ' OR 1=1-- en campos de formulario. Si el plugin no sanitiza correctamente, la query devuelve todos los registros o permite extracción masiva con UNION SELECT.
Usar wpdb::prepare() en todas las queries, validar y sanitizar todos los inputs, nunca concatenar variables directamente en SQL, mantener actualizados los plugins de formularios.
La ausencia de CSP, X-Frame-Options o HSTS facilita XSS, clickjacking y ataques MITM.
Sin Content-Security-Policy, un XSS puede inyectar scripts que roban cookies de sesión. Sin X-Frame-Options, un iframe invisible puede capturar clics del usuario (clickjacking). Sin HSTS, un atacante en la red puede forzar HTTP.
Configurar cabeceras en el servidor o mediante un plugin de seguridad: CSP estricta, X-Frame-Options: SAMEORIGIN, HSTS con preload, X-Content-Type-Options: nosniff.
No es culpa de WordPress en sí. Es la forma en que se usa, mantiene y configura lo que crea el problema.
60,000+ plugins y miles de temas con niveles de seguridad muy dispares. Cualquiera puede publicar un plugin — no hay auditoría obligatoria de código.
"Si funciona, está bien". La mayoría no actualiza por miedo a romper algo. El 52% de los sitios WordPress hackeados tenían versiones desactualizadas.
Usuarios "admin", rutas predecibles (/wp-admin, /wp-login.php), xmlrpc.php activo. Todo conocido y explotable desde el primer día.
El dilema de actualizar o no actualizar deja instalaciones en versiones vulnerables meses después de la publicación del parche.
Tu seguridad puede depender de lo que haga el vecino en el mismo servidor. Un servidor comprometido puede afectar a todas las webs que aloja.
La mayoría de los afectados también creían que sí.