Drupal Commerce Core: fallo explotado, actualice a 3.3.13 ahora

Atacantes están explotando un fallo de criticidad alta en Drupal Commerce Core, el módulo de carrito de compras del sistema de gestión de contenidos Drupal, para hacer pedidos que nunca pagan. El equipo de seguridad de Drupal publicó el aviso SA-CONTRIB-2026-254 el 28 de octubre de 2026 y dice que el error «se está explotando activamente». Toda tienda que use el módulo necesita dos cosas esta semana: la actualización 3.3.13 u 8.x-2.41, y una auditoría de los pedidos recientes.

El fallo se identifica como CVE-2026-118539. Drupal lo puntúa con 21 de 25, su franja «Highly critical», con el vector AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All. En lenguaje llano: no hace falta iniciar sesión ni tener acceso especial, los datos se pueden leer y cambiar, y existe un exploit.

Qué permite hacer el fallo a un atacante

El módulo «no protege suficientemente ciertas rutas y campos de entidad», dice el aviso. Eso es una elusión de acceso: un visitante puede llegar a páginas y campos de datos que deberían haber estado bloqueados. BleepingComputer informa de que un atacante sin autenticar puede usarlo para saltarse las reglas de acceso de la tienda.

Centarro, la empresa que mantiene Drupal Commerce, describió los ataques en una entrada de su CEO Ryan Szrama el 29 de octubre. Los comerciantes vieron cuatro tipos de abuso:

• Pedidos creados directamente, saltándose el pago, de modo que el pedido existe pero nunca se pagó.
• Pedidos que aparecen como pagados en la pantalla de gestión sin ningún registro de pago detrás, sobre todo en sitios que exponen el servicio web JSON:API.
• Precios de productos rebajados antes de pasar por caja.
• Descuentos, cargos u otros ajustes que ningún empleado ni promoción añadió.

«Recibimos dos informes de intentos de usuarios malintencionados de hacer pedidos fraudulentos», escribió Szrama. Algunos pedidos tenían precios claramente erróneos, como 0,01 dólares. Otros usaban precios normales. «Por ahora no creemos que fuera automatizado ni que se explotara más allá de los sitios iniciales», añadió. El equipo de seguridad de Drupal coordinó las pruebas, el empaquetado y la publicación de la corrección el 28 de octubre.

A quién afecta y qué instalar

Drupal acredita a Dan Puccetti, Marcus Johansson y Robert Snyder por informar del fallo. Seis personas, entre ellas Szrama, figuran como autoras de la corrección. BleepingComputer cifra la base instalada del módulo en más de 42.000 sitios web, citando la página del proyecto en drupal.org.

Rama	Versiones afectadas	Versión corregida	Requisito de Drupal (según Rescana)
Commerce Core 3.x	Desde 3.0.0 hasta 3.3.13, sin incluirla	3.3.13	Drupal 10.3 o posterior, o Drupal 11
Commerce Core 8.x-2.x	Toda versión anterior a 8.x-2.41	8.x-2.41	Drupal 9.3 o posterior, o Drupal 10

La corrección no se detiene en Commerce Core. Centarro dice que Commerce API, Commerce License, Commerce Shipping y Commerce Stripe también recibieron versiones de seguridad el 28 de octubre y deben actualizarse al mismo tiempo. Rescana señala que Drupal publicó en paralelo cinco avisos de Commerce Core de menor gravedad, SA-CONTRIB-2026-255 a 259. Un aviso aparte de Stripe, SA-CONTRIB-2026-263, está calificado como crítico y podría permitir a un atacante marcar un pedido como pagado sin pagar.

Centarro también recuerda a los usuarios de 8.x-2.x que el soporte de esa rama termina cuando salga Drupal 12. «Recomendamos actualizar a 3.x lo antes posible», dice la entrada.

Cuánto tiempo lleva abierto el agujero

El error es antiguo. Centarro dice que los exploits han sido «teóricamente posibles» desde Commerce Core 8.x-2.18, publicada el 26 de mayo de 2020, en sitios que usan JSON:API. Para los demás sitios, la ventana se abrió con 8.x-2.25 el 30 de junio de 2021. Centarro presenta esas fechas como las más tempranas posibles, no como fechas de ataque confirmadas.

El fallo no estaba en el catálogo de vulnerabilidades explotadas conocidas (KEV) de la CISA en la edición del 29 de octubre, informa Rescana. La etiqueta de «explotado activamente» viene de Drupal y de la propia Centarro. La CISA ha marcado cinco fallos de Drupal como explotados a lo largo de los años, dice BleepingComputer, el más reciente un error de inyección SQL, CVE-2026-9082, añadido en mayo de 2026. El propio núcleo de Drupal corrigió un fallo crítico de ejecución de código en Field UI hace apenas dos semanas.

Cómo auditar sus pedidos

El parche cierra la puerta. No deshace los pedidos que ya entraron por ella. El aviso de Drupal dice que los sitios «deben auditar sus pedidos en busca de incoherencias». La entrada de Centarro ofrece cuatro comprobaciones de base de datos, cada una como una consulta que los dueños de tiendas pueden ejecutar:

1. Pedidos creados fuera del proceso de pago que aún tienen saldo pendiente.
2. Pedidos cuyo importe pagado registrado es mayor que los pagos completados que constan.
3. Líneas de pedido con el precio unitario sobrescrito. Centarro señala que la primera comprobación pasaría por alto un precio rebajado a 0,01 dólares y luego pagado.
4. Ajustes, como cargos o descuentos personalizados, que no proceden de una promoción.

Una coincidencia no prueba un fraude. Los pedidos creados por el personal y los productos de «ponga su precio» también coinciden, así que cada pedido marcado necesita una revisión humana. Rescana añade que cruzar las direcciones IP y las horas de los pedidos marcados con los registros de acceso de las rutas normales de pago ayuda a separar unos de otros.

El consejo operativo de Centarro es más directo: no envíe un pedido porque se haya creado o porque el pago se haya completado. Confirme primero el pago. Y si su sitio no necesita que JSON:API acepte cambios, póngalo en modo de solo lectura.

Qué significa esto para los desarrolladores

• Parchee hoy y luego audite hasta 2020. La corrección es una actualización corriente de composer a 3.3.13 u 8.x-2.41, más los cuatro módulos complementarios. La auditoría es la parte lenta. Si su sitio ha expuesto JSON:API desde mayo de 2020, las cuatro consultas tienen que recorrer cinco años de pedidos, no la semana pasada.
• Trate «aparece como pagado» como una afirmación, no como un hecho. El segundo tipo de ataque crea pedidos que la pantalla de administración reporta como pagados sin entidad de pago detrás. Cualquier automatización de envíos que dependa solo del estado del pedido confiaba en un campo que el atacante podía fijar. Compruebe que su paso de envío lee los registros de pago, no el estado del pedido.
• Las tiendas headless corren más riesgo. Los dos tipos de ataque ligados a JSON:API, y la fecha de inicio más temprana de 2020, se aplican a los sitios desacoplados. Si la API solo sirve datos de productos a un front end, póngala en solo lectura ahora, sea cual sea su versión de Drupal.
• Vigile los avisos complementarios. La corrección crítica aparte de Commerce Stripe importa a cualquiera que use Stripe como pasarela. Actualícela en el mismo despliegue que Commerce Core.
• Informe de cualquier cosa rara. Centarro dice que «siempre preferiría revisar informes falsos positivos o duplicados antes que no enterarse de una vulnerabilidad potencial». Dos informes de comerciantes encontraron este error tras cinco años en el código.