La explotación activa del CVE-2026-118539 en Drupal Commerce Core mantiene sin parchear miles de tiendas online en todo el mundo. El proyecto confirmó esta semana que hay atacantes usándolo en producción. No es una advertencia teórica: es una cuenta atrás.
Una autorización que no autoriza: así se fuerza la entrada al carrito
El fallo es un access bypass por comprobación insuficiente de permisos. Commerce Core no protege determinadas rutas ni determinados campos de entidad, de modo que un visitante sin privilegios alcanza funciones que deberían quedar reservadas al administrador o al propio cliente. El oficio lo llama navegación forzada: usted no revienta la puerta, simplemente comprueba que nunca tuvo cerradura.
El módulo no distingue quién debe ver la ruta, y esa ausencia de control es la que convierte un descuido de código en un agujero de caja. La nota oficial del proyecto lo dice sin rodeos: el módulo no protege suficientemente ciertas rutas y campos, lo que deriva en un bypass de acceso con impacto económico potencial para el vendedor.
Traducido a la operativa diaria de una tienda: pedidos, estados de pago, direcciones de envío y datos de cliente quedan al alcance de quien sepa pedirlos en el orden correcto. No hace falta un zero-day exótico ni un exploit de corrupción de memoria. Basta con conocer la ruta y saltarse el control que nadie programó. Le adelanto que este es el tipo de vulnerabilidad que más rápido se monetiza, porque no exige ingeniería: exige paciencia y un directorio de tiendas mal mantenidas.
El fallo lo reportaron Dan Puccetti, Marcus Johansson y Robert Snyder, tres nombres conocidos en el ecosistema Drupal. Los mantenedores del proyecto de código abierto confirmaron la explotación real en entorno salvaje y recomendaron actualizar de inmediato. No hay atribución pública del atacante, y conviene decirlo así: en comercio electrónico la autoría rara vez importa, porque el objetivo no es el prestigio sino la tarjeta.
En una tienda online el espía no busca secretos de Estado: busca el formulario de pago, y ese formulario nunca tuvo contrainteligencia.
Las versiones señaladas por el aviso van desde la 0.0.0 hasta la 2.41 y desde la 3.0.0 hasta la 3.3.13. Quien esté en la rama 3.x debe subir a la 3.3.13; quien venga de releases anteriores, a Commerce Core 8.x-2.41. Eso sí, la horquilla publicada genera una duda razonable sobre el corte exacto: si la 3.3.13 aparece como afectada y a la vez como solución, más vale verificar la build concreta antes de dar el parche por bueno.
Parchear no es opcional. Es contabilidad.
De Drupalgeddon a hoy: por qué el comercio electrónico siempre es el objetivo rentable
He seguido este ecosistema durante años y el patrón se repite con una fidelidad que asusta. En 2014, Drupalgeddon (CVE-2014-3704) permitió inyección SQL masiva en instalaciones sin actualizar. En 2018, Drupalgeddon2 (CVE-2018-7600) sirvió para desplegar mineros de criptomonedas y puertas traseras en miles de sitios. Ninguno de los dos era un prodigio de sofisticación. Ambos funcionaron por lo mismo: código expuesto durante meses en producción.
La diferencia de 2026 es el contexto económico. El ecosistema de web skimming que popularizó el colectivo conocido como Magecart —los compromisos de British Airways y Ticketmaster en 2018 son el manual— no necesita vulnerabilidades espectaculares. Necesita rutas accesibles y comerciantes que confían en que el módulo de turno ya lo resuelve todo. Cuando aparece un fallo de autorización como este, la fase de reconocimiento se reduce a un escaneo automatizado y una lista de objetivos.
Mi lectura es que estamos ante un problema de higiene, no de guerra. Y eso, en cierto modo, es peor: no hay un adversario estatal al que señalar, no hay célula que desmantelar, no hay nombre propio que llevarse a la portada. Hay decenas de miles de instalaciones que llevan meses sin tocarse y un aviso que solo lee quien ya estaba mirando.
El servicio de gestión de parches es el trabajo sucio del oficio. Nadie lo cuenta.
Dossier Moncloa: Ojos en la Sombra
El vector de amenaza es lo menos glamuroso del repertorio: explotación oportunista de una vulnerabilidad de autorización en un módulo de terceros, con impacto directo en la caja del vendedor. No hay un APT detrás, al menos no consta públicamente, pero la cadena de suministro de software es exactamente el terreno que SolarWinds y NotPetya convirtieron en doctrina. Quien controla una dependencia controla a todos los que dependen de ella, y el comercio electrónico es la dependencia más extendida y peor auditada de la economía digital.
En el reparto de papeles, el atacante sigue sin nombre: Drupal no atribuye la explotación y yo no voy a inventar una firma donde no la hay. Del lado defensivo aparecen los mantenedores del proyecto, los equipos de operaciones de cada tienda y, en España, el CCN-CERT, que monitoriza este tipo de fallos en servicios de la Administración pero no emite alertas por cada módulo contrib de terceros. Como terceros interesados, las pasarelas de pago y las aseguradoras de ciberriesgo, que son quienes acaban pagando la factura del descuido. Me consta que en el sector asegurador este tipo de siniestro se está mirando ya con lupa, porque el bypass no deja rastro de intrusión: deja rastro de venta.
La clasificación estimada del material afectado es baja en términos de secretos oficiales —nada aquí es Top Secret— y altísima en términos comerciales: datos personales de clientes, historiales de pedido y estados de pago. Reconozco el punto débil de cualquier análisis como este: sin una muestra forense pública no se puede afirmar qué están robando exactamente los atacantes ni cuántas instalaciones han caído. La atribución en ciberguerra exige respaldo técnico cruzado, y aquí solo hay un comunicado del proveedor y una explotación confirmada.
Lo veo como un aviso incómodo para el conjunto del ecosistema: la próxima revisión del catálogo de vulnerabilidades explotadas de CISA dirá si esto escala a incidente de referencia o se queda en nota de viernes. Si el CVE entra en esa lista, las tiendas afectadas tendrán además un problema de cumplimiento, no solo de parcheo.
Qué haría yo esta semana si usted vende con este módulo
Permítame el consejo operativo. Primero, inventario: saber qué versión de Commerce Core corre en cada instalación, incluidos los entornos de preproducción que nadie mira y que comparten base de datos con producción. Segundo, actualizar a 3.3.13 o a 8.x-2.41 y verificar después la versión real en el pie de administración, porque los procesos de despliegue mienten con frecuencia. Tercero, revisar registros de acceso a rutas de carrito y de entidades en las últimas semanas: si alguien estuvo dentro, ya hay huella.
Si usted gestiona una tienda pequeña y no tiene equipo técnico, este es el momento de llamar a quien sí lo tenga. La ventana de exposición no se cierra con buena voluntad. Se cierra con un número de versión distinto en pantalla.
