RevSlider: la vulnerabilidad histórica que sigue explotándose

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Pocos ejemplos resumen mejor la seguridad y hardening de WordPress que Slider Revolution. La vulnerabilidad RevSlider WordPress se documentó públicamente en 2014 y, contra toda lógica, seguimos encontrándola explotada en auditorías forenses en 2026. No porque el fabricante no la parchease —lo hizo hace más de una década—, sino porque el plugin se distribuyó empaquetado dentro de miles de temas premium, quedando congelado en versiones que nadie actualiza. Es el arquetipo de deuda de seguridad: un fallo resuelto que sobrevive en la práctica.

Qué fue realmente la vulnerabilidad RevSlider WordPress

El problema original no fue uno, sino una cadena. Primero apareció una lectura arbitraria de ficheros (Local File Inclusion / arbitrary file download): mediante una petición al endpoint AJAX del plugin, un atacante sin autenticar podía descargar cualquier fichero del servidor, incluido wp-config.php. Ese fichero contiene las credenciales de la base de datos y las claves de sesión. Con eso en la mano, el compromiso del sitio deja de ser hipotético.

Poco después se sumó una subida arbitraria de ficheros: la posibilidad de escribir un archivo PHP en el servidor y, con ello, ejecutar código remoto (RCE). La combinación —leer secretos y luego plantar un webshell— convirtió a RevSlider en la herramienta favorita de campañas automatizadas. La más recordada, conocida como SoakSoak, barrió decenas de miles de instalaciones inyectando malware que redirigía tráfico y distribuía cargas maliciosas. No fue un ataque dirigido: fueron bots rastreando Internet en busca de la firma del plugin.

Por qué sigue viva doce años después

La respuesta es incómoda y se repite en cada informe que entregamos:

• Plugin embebido en temas. Muchos autores de temas incluían RevSlider como «extra gratuito». Al no aparecer como plugin instalado desde el repositorio oficial, WordPress no ofrece la actualización automática. La versión queda petrificada.
• Licencias sin mantener. Slider Revolution es de pago. Sin licencia activa, no hay actualizaciones. El propietario asume que «funciona» y lo deja igual durante años.
• Falta de inventario. El administrador no sabe que el plugin existe en su sitio porque nunca lo instaló conscientemente.

El resultado es que un fallo con parche disponible desde 2014 sigue siendo, hoy, un vector de entrada real. Bases de datos como la NVD del NIST registran el historial de este y otros CVE del plugin, pero registrar no es remediar: si la versión vulnerable sigue en disco, el registro no protege a nadie.

Cómo saber si estás expuesto

La detección es directa si sabes dónde mirar. Localiza el directorio del plugin en wp-content/plugins/revslider/ —o dentro de la carpeta del tema, en wp-content/themes/tu-tema/— y comprueba la versión en su cabecera. Cualquier versión anterior a las correcciones de 2015 debe considerarse comprometible. Señales adicionales de que ya te tocó:

• Ficheros PHP con nombres aleatorios en wp-content/uploads/, que no debería contener código ejecutable jamás.
• Entradas o usuarios administradores que nadie creó.
• Redirecciones intermitentes que solo se disparan para visitantes que llegan desde buscadores.
• Peticiones repetidas a admin-ajax.php con el parámetro de acción del plugin en tus logs de acceso.

Antes de sumar cualquier extensión nueva a tu sitio, conviene tener un criterio: nuestra checklist para auditar un plugin antes de instalarlo evita precisamente que una dependencia embebida y sin mantenimiento acabe siendo tu punto débil.

Remediación correcta, no cosmética

Actualizar el plugin es necesario pero insuficiente si ya hubo intrusión. El orden que aplicamos en un caso real es:

• Contener. Aislar el sitio o ponerlo en mantenimiento antes de tocar nada, para no dar más tiempo al atacante.
• Actualizar o eliminar. Si no usas los sliders, desinstala el plugin por completo; si lo necesitas, actualiza a la última versión con licencia válida.
• Rotar secretos. Cambia las claves de la base de datos y regenera las salts de wp-config.php: si expusieron ese fichero, las sesiones antiguas ya no valen.
• Erradicar el implante. Buscar y eliminar webshells, usuarios rogue y tareas programadas. Un plugin actualizado sobre un servidor ya comprometido sigue estando comprometido.
• Reforzar el acceso. Una capa de autenticación de doble factor bien configurada corta el reaprovechamiento de credenciales robadas durante el incidente.

Cuando el sitio afectado procesa pagos o maneja datos de tarjeta, la lectura de wp-config.php deja de ser un problema de un blog y pasa a ser un incidente con implicaciones regulatorias. En PathSentinel atendemos también entornos exigentes —banca y comercios con datos de tarjeta— donde una intrusión por un plugin embebido obliga a un análisis forense completo, no a un simple «actualiza y reza».

La lección que va más allá de RevSlider

El caso RevSlider enseña algo que aplica a todo tu stack: no basta con parchear lo que ves. Los componentes de terceros embebidos, las librerías copiadas dentro de temas y los plugins que «venían con la plantilla» son el verdadero perímetro. El hardening documentado por WordPress.org y las guías del Wordfence Learning Center insisten en lo mismo: inventario, mínimo de superficie y actualización disciplinada. RevSlider no cayó por sofisticación del atacante, sino por abandono del defensor. Ese patrón se puede romper.