El fallo de autorización de Drupal Commerce Core ya se explota en ataques reales

Las tiendas online basadas en Drupal Commerce están siendo atacadas a través de una vulnerabilidad de autorización calificada como "highly critical" en el módulo Commerce Core. El equipo de seguridad de Drupal ha confirmado que el fallo ya se está explotando y hay versiones corregidas para las dos ramas con soporte.

Qué ha ocurrido

La vulnerabilidad, identificada como CVE-2026-118539, es un fallo de falta de autorización en Commerce Core, el módulo que aporta a un sitio Drupal el carrito, el flujo de pago y las API que usan las tiendas desacopladas (headless). Ciertas rutas y campos de entidad no están debidamente protegidos, de modo que una petición que debería rechazarse puede pasar. El resultado práctico es una elusión del control de acceso que puede golpear directamente el bolsillo del comerciante.

Versiones afectadas:

• Commerce Core 2.x (rama 8.x-2.x), hasta la 2.41 incluida
• Commerce Core 3.x, anteriores a la 3.3.13

Todavía no se ha asignado una puntuación CVSS, pero los mantenedores califican el problema como "highly critical", el nivel máximo de la escala de severidad de Drupal. La explotación en entornos reales está confirmada. No hay detalles públicos sobre quién está detrás, cuántas tiendas se ven afectadas ni qué hacen los atacantes una vez dentro.

Por qué importa

Los módulos de comercio están justo en el camino del dinero. Un hueco de autorización en esa capa no es un riesgo abstracto: dependiendo de qué rutas y campos queden expuestos, un atacante podría leer o alterar pedidos, manipular precios y promociones o acceder a datos de clientes que normalmente exigen una cuenta autenticada.

Además, este tipo de ataque es silencioso. No hay malware que detectar ni caídas que llamen la atención, solo peticiones HTTP que parecen tráfico normal de la tienda. Si la detección depende de anomalías en el comportamiento del servidor, una elusión de acceso puede pasar semanas sin que nadie la note.

Los parches de seguridad de Drupal se someten a ingeniería inversa muy rápido. En cuanto la corrección es pública, el diff indica a los atacantes exactamente dónde mirar, y por eso el intervalo entre "aviso publicado" y "explotación masiva" no deja de acortarse.

Mientras tanto, PHP2Shell sigue bajo prueba

El aviso de Drupal llega mientras dos fallos críticos del propio PHP, CVE-2026-109618 y CVE-2026-109619 (ambos con CVSS 9.2 y conocidos en conjunto como PHP2Shell), siguen atrayendo intentos de explotación.

A 25 de octubre, cerca del 52% de las organizaciones monitorizadas seguían considerándose significativamente expuestas, una cifra que baja pero que está lejos de cero. Destacan dos tipos de actividad: intentos que reproducen la cadena pública de prueba de concepto y herramientas "de marca PHP2Shell" que en realidad se apoyan en el envenenamiento de sesiones y en un fallo independiente de inclusión local de archivos, no en los errores de PHP.

La buena noticia, por ahora, es la fiabilidad. Provocar el agotamiento de memoria por sí solo no completa la cadena, y las diferencias entre compilaciones de PHP, límites de memoria y comportamiento de los procesos worker suelen romper las etapas posteriores. La mala noticia es que los atacantes oportunistas trabajan activamente para convertir las PoC públicas en herramientas fiables, y la historia dice que suelen conseguirlo.

Qué hacer

1. Actualice Commerce Core hoy. Lleve los sitios 3.x a la 3.3.13 y los 2.x a la 8.x-2.41. Trátelo como un cambio de emergencia, no como uno programado.
2. Si no puede actualizar de inmediato, restrinja el acceso a las rutas de Commerce en el proxy inverso o el WAF, revise los permisos de los roles anónimo y autenticado y valore dejar el checkout fuera de línea durante las pocas horas que necesita un despliegue.
3. Busque indicios de abuso. Revise los registros web en busca de peticiones no autenticadas o con pocos privilegios a rutas de pedidos, pagos, promociones y productos, y compruebe si hay cambios inesperados en precios, descuentos, pedidos o fichas de clientes.
4. Cierre también el hueco de PHP. Confirme que el runtime de PHP de cada servidor web está en una versión que corrige PHP2Shell y busque posibles fallos de inclusión local de archivos en su propio código, porque en ellos se apoya parte de las herramientas usadas en ataques reales.
5. Conozca todas las instancias Drupal que posee. Los sitios de staging, demo y marketing olvidados suelen ejecutar el mismo módulo Commerce sin ninguna de las protecciones de producción.

Fallos como CVE-2026-118539 son exactamente lo que nuestro servicio de escaneo de vulnerabilidades está diseñado para sacar a la luz: identifica versiones obsoletas del núcleo de Drupal y de los módulos contribuidos en todos sus hosts públicos, de modo que un checkout vulnerable queda señalado antes de que lo encuentre otro.