Drupalgeddon y RCE en Drupal: por qué no actualizar te deja expuesto
Vulnerabilidad de Drupal con ejecución remota: qué fue Drupalgeddon, cómo se explotan los fallos RCE sin autenticar y por qué no actualizar deja tu web expuesta.
Pocas familias de fallos han marcado tanto la historia de un CMS como las que dieron nombre a «Drupalgeddon». Una vulnerabilidad de Drupal con ejecución remota (RCE) sin autenticar significa que cualquiera en Internet puede ejecutar código en tu servidor sin necesidad de usuario ni contraseña. Cuando aparece un fallo así, el margen entre la publicación del parche y la explotación masiva se mide en horas. Este artículo forma parte de nuestro radar sobre seguridad de e-commerce y multi-CMS y explica por qué el retraso en actualizar es el auténtico riesgo.
Qué enseñó Drupalgeddon sobre la ejecución remota en Drupal
El término engloba varios episodios. El primero, en 2014, fue una inyección SQL en la capa de abstracción de base de datos (CVE-2014-3704) que permitía escalar hasta ejecución de código. Años después, en 2018, llegaron los fallos conocidos como Drupalgeddon 2 (CVE-2018-7600) y su continuación (CVE-2018-7602), ambos RCE explotables sin autenticación. La lección común: no hacía falta ser administrador, ni conocer credenciales, ni un objetivo concreto. Bastaba con enviar una petición cuidadosamente construida a una web con la versión vulnerable.
Lo que convirtió estos fallos en un evento sísmico fue la velocidad de la industrialización:
- Prueba de concepto pública a las pocas horas del aviso.
- Escaneo masivo de Internet buscando versiones vulnerables.
- Cargas útiles automatizadas: instalación de mineros de criptomonedas, puertas traseras y web shells en cadena.
Por qué el RCE sin autenticar es la peor categoría
No todas las vulnerabilidades son iguales. Un fallo que exige ser usuario registrado tiene una superficie limitada; uno que exige ser administrador, todavía más. La ejecución remota sin autenticación elimina todas esas barreras: es el equivalente a dejar la puerta abierta a la calle. Con código ejecutándose en el servidor, el atacante puede leer la base de datos, robar credenciales, pivotar a otros sitios del mismo alojamiento e instalar persistencia que sobrevive a las actualizaciones posteriores.
El problema no es el fallo, es la ventana
Los proyectos serios publican parches el mismo día del aviso. El compromiso no ocurre porque no existiera solución, sino porque transcurrieron días o semanas hasta aplicarla. Cada hora de esa ventana es tiempo en el que los bots ya están probando el exploit contra tu dominio. En los incidentes que hemos analizado, la mayoría de las webs comprometidas por Drupalgeddon 2 lo fueron después de que el parche estuviera disponible.
Cómo blindar tu Drupal frente a la ejecución remota
- Actualiza en cuanto se publique un aviso de seguridad: para los RCE sin autenticar, trata cada parche como una emergencia, no como una tarea de mantenimiento rutinario.
- Suscríbete a los avisos oficiales: el equipo de seguridad de Drupal reserva los miércoles para publicaciones; ten un proceso listo para reaccionar ese día.
- Capa de mitigación en el borde: un WAF con reglas actualizadas compra tiempo, pero nunca sustituye al parche.
- Principio de mínimo privilegio: limita permisos del usuario de base de datos y de la cuenta del servidor web para reducir el impacto de una ejecución exitosa.
- Verifica integridad tras el parche: si la versión estuvo expuesta, asume que pudo comprometerse y busca puertas traseras, no solo apliques la actualización.
La superficie de ataque también depende del modelo de alojamiento. Nuestra comparativa entre Shopify y tienda autoalojada analiza quién asume la responsabilidad de parchear en cada caso. Y si no estás seguro de qué tecnología corre bajo un dominio, saber qué CMS usa una web es el primer paso para evaluar su exposición: no puedes proteger lo que no sabes que tienes.
Para datos verificados sobre otras plataformas, el Joomla! Security Centre y la documentación de seguridad de PrestaShop muestran cómo cada proyecto gestiona sus avisos; y si tu Drupal procesa pagos, el PCI Security Standards Council define las obligaciones tras un compromiso con datos de tarjeta.
Un RCE sin autenticar en un entorno exigente —banca o comercio con datos de tarjeta— no es una incidencia menor: es un incidente reportable. En PathSentinel abordamos estos casos con enfoque forense para determinar si la ventana de exposición dejó una puerta trasera. Si tu Drupal estuvo sin parchear, escríbenos desde contacto antes de dar el sitio por seguro.
Comprueba si tu Drupal expone una versión vulnerable o señales de explotación tras un RCE conocido, en segundos y sin instalar nada.
Cada semana, las vulnerabilidades de plugins de WordPress que de verdad importan y un caso real de investigación, en español. Sin ruido, sin spam.