El fallo en un párrafo, el resto es procedimiento
El aviso SA-CONTRIB-2026-254 afecta al módulo Commerce Core (drupal/commerce). Drupal.org lo clasifica como «Highly critical», 21 sobre 25, y describe una elusión de acceso: el módulo no protege lo suficiente ciertas rutas y ciertos campos de entidad. El aviso sitúa el nivel de autenticación requerido en «todos/anónimos» y precisa que el fallo puede tener consecuencias financieras para el vendedor. También afirma que se explota activamente.
El aviso no nombra ni las rutas ni los campos afectados. Por eso no deducimos nada: ni lista de rutas que bloquear, ni firma que buscar en los registros. El identificador CVE-2026-118539 se toma de la página del aviso; no lo hemos contrastado con la base NVD, así que cítelo como «identificador publicado por el aviso» mientras no se haga esa comprobación.
Tabla de referencia: rama, versión afectada, versión corregida
Desplace la tabla
| Su situación | Estado según el aviso | Acción |
|---|---|---|
| Commerce 3.x, de 3.0.0 hasta antes de 3.3.13 | Vulnerable | Pasar a 3.3.13 o posterior |
| Commerce 2.x (8.x-2.x), antes de 8.x-2.41 | Vulnerable | Pasar a 8.x-2.41 o posterior |
| Commerce 3.3.13 u 8.x-2.41 ya instalado | Corregido | Auditar igualmente los pedidos anteriores a la actualización |
| Drupal ^10.3 u 11 | Rama 3.x indicada como compatible | Actualizar dentro de la rama 3.x |
| Drupal ^9.3 o ^10 | Rama 2.x indicada como compatible | Actualizar dentro de la rama 2.x, sin cambiar de rama a la vez |
| Módulo ausente de `composer.lock` | Fuera del alcance de este aviso | Anotar la ausencia en el inventario |
| Tienda sin acceso a Composer o con código copiado a mano | Versión desconocida | Averiguar la versión antes de sacar conclusiones |
Por qué corregir no basta
El aviso lo dice con todas las letras: los sitios deben auditar sus pedidos, porque el fallo se explota. Una tienda que hoy pasa a 3.3.13 pudo ser visitada antes. La actualización cierra el acceso; no pone en orden un pedido cuyo importe, estado o situación de pago haya sido modificado. El aviso no dice desde cuándo se explota: elija una ventana de auditoría amplia, anótela en el expediente y no la reduzca al día de la actualización.
Luego viene un obstáculo corriente: sin inventario central, nadie sabe qué tiendas incluyen Commerce ni en qué rama. El método de inventario es el de un fallo de plugin de WordPress, descrito en nuestra guía de Bricksforge. El orden de trabajo es, pues: inventario, copia de seguridad, actualización, auditoría, prueba fechada. Las tiendas que más cobran van primero.
Inventariar la versión de Commerce en cada tienda
Leer la versión con Composer
cd /var/www/boutique-clientcomposer show drupal/commerce
El comando muestra la versión instalada. Para la rama 2.x, drupal.org habla de 8.x-2.41; Composer presenta el número sin el prefijo 8.x. Compare el número, no la cadena. La ruta es un ejemplo: adáptela a su alojamiento.Contrastar con Drush
drush pm:list --type=module --status=enabled --filter=commerce
La lista indica si Commerce está activado y en qué versión. Un sitio puede tener el código sin que el módulo esté activado: anótelo, porque la situación cambia si alguien lo activa más tarde.Leer el archivo de bloqueo en lugar de la carpeta
grep -A1 '"name": "drupal/commerce"' composer.lock
El archivocomposer.lockdice lo que está realmente instalado, sin arrancar Drupal. Es la lectura más segura en una tienda que no quiere solicitar durante la auditoría.Recorrer todas las tiendas de un servidor
find /home -name composer.lock -not -path '*/vendor/*' -exec grep -H -A1 '"name": "drupal/commerce"' {} +
Cada archivo citado contiene Commerce, y la líneaversionsigue al nombre. Revise la lista: una carpeta de pruebas olvidada o una copia de seguridad también cuentan.Anotar el resultado en una tabla
Una fila por tienda: cliente, alojamiento, ruta, rama, versión detectada, versión de Drupal, fecha y hora de la lectura. Añada dos columnas para rellenar más tarde, «actualización hecha» y «auditoría de pedidos hecha». Esta tabla se convierte en la pieza central del expediente que se entrega a los clientes.
Hacer copia de seguridad antes de tocar el código
Una actualización de módulo se deshace mal sin un punto de retorno. Antes de cada tienda: una copia de la base de datos y del código, en un soporte que la actualización no toque, con su fecha anotada en la tabla. En una tienda activa la base cambia con cada pedido: la copia fija el estado a partir del cual podrá comparar los pedidos después. No la sobrescriba con la siguiente mientras la auditoría no esté cerrada. Sirve dos veces: volver atrás y demostrar lo que contenía la tienda antes de la corrección.
Actualizar una tienda
Congelar el estado
drush sql:dump --gzip --result-file=/chemin/sauvegarde/boutique-avant.sql
Copie también la carpeta del proyecto: código,composer.json,composer.locky archivos. Anote en la tabla dónde queda la copia.Comprobar lo que permite la restricción de Composer
composer why-not drupal/commerce 3.3.13
Sicomposer.jsonfija una versión, este comando nombra lo que bloquea. Una tienda en 2.x sigue en 2.x y apunta a 8.x-2.41: cambiar de rama es un proyecto aparte, que se planifica por separado.Actualizar el módulo y sus dependencias
composer update drupal/commerce --with-dependencies
Revise la lista de paquetes modificados antes de confirmar: otro módulo de Commerce puede moverse con él.Aplicar las actualizaciones de base de datos
drush updatedb -ydrush cache:rebuild
El primer comando ejecuta las actualizaciones de esquema pendientes, el segundo vacía las cachés.Comprobar la versión instalada
Vuelva a lanzar
composer show drupal/commerce. La versión debe alcanzar 3.3.13 en la rama 3.x, o el número 2.41 en la rama 2.x. Anótela en la tabla, con fecha y hora.Hacer un pedido de prueba
En preproducción, o en el modo de prueba de la pasarela de pago, añada un producto al carrito, haga el pedido y compruebe el importe, el estado y el pago. Una actualización que rompe el proceso de compra debe verse antes que el cliente.
Un procedimiento por entorno
La misma corrección no se aplica igual en todas partes. La tabla siguiente fija, para cada entorno, el gesto esperado y la prueba que conservar. Una preproducción pública cuenta como una tienda.
Las actualizaciones automáticas del sistema, descritas en nuestra guía sobre Debian y Ubuntu, no tocan un módulo de Drupal: ese gesto sigue siendo de la agencia.
Desarrollo, preproducción, producción: el gesto y la prueba
Desplace la tabla
| Entorno | Gesto | Prueba que conservar |
|---|---|---|
| Producción | Copia de seguridad, actualización, `drush updatedb`, pedido de prueba y después auditoría | Copia fechada, versión detectada, resultado de la auditoría |
| Preproducción accesible desde Internet | Actualizar primero si el código es idéntico, o protegerla con contraseña mientras tanto | Versión detectada, protección elegida |
| Preproducción cerrada o local | Actualizar y repetir el pedido de prueba antes de producción | Captura del pedido de prueba, fecha |
| Desarrollo | Alinear `composer.lock` con producción para no reintroducir la versión antigua en el próximo despliegue | Commit del archivo de bloqueo, versión detectada |
| Copia o respaldo restaurado | No volver a ponerlo en línea sin la actualización | Mención en el expediente del cliente |
Auditar los pedidos sin presumir el método del atacante
Fijar la ventana
Elija una fecha de inicio amplia y anótela. El aviso no da fecha de inicio de la explotación: tome como mínimo el periodo cubierto por sus copias y sus registros, y escriba por qué.
Listar los pedidos de la ventana
Exporte los pedidos con su número, sus fechas de creación y de realización, su estado, su total y su moneda. Basta con la interfaz de administración. En la base de datos, empiece por leer los nombres de las columnas:
drush sql:query "DESCRIBE commerce_order"
Los nombres exactos dependen de su versión: no los suponga.Buscar discrepancias internas
Para cada pedido, compare el total con el cálculo de sus líneas y ajustes. Un total que no cuadra con sus líneas, un descuento que nadie configuró o un precio de línea distinto del catálogo: cada discrepancia debe investigarse.
Cruzar con la pasarela de pago
Un pedido terminado sin pago correspondiente en el proveedor, o un pago de importe distinto del total, merece un examen. El extracto del proveedor es la referencia para el dinero cobrado: haga el cruce con las exportaciones, no con lo que muestra la tienda.
Revisar los cambios de estado
Localice los pedidos cuyo estado cambió sin acción humana ni pago coherente: validados sin pasar por el pago, o llegados a un estado final en pocos segundos. Los registros de acceso ayudan a fechar lo ocurrido. El aviso no detalla ninguna ruta: una búsqueda por ruta es un indicio, nunca una prueba de ausencia.
Lo que la auditoría no demuestra
Una auditoría limpia dice que no se ve ninguna incoherencia en los pedidos. No dice que ninguna petición abusara del fallo: el aviso habla de rutas y de campos de entidad sin nombrarlos. Escriba en el informe lo que ha mirado y lo que no ha mirado.
Si un pedido es incoherente
- No borrar nada — conserve el pedido, sus pagos y la copia fechada: son las piezas del expediente.
- Suspender la entrega — bloquee el envío o el acceso al producto digital hasta que el pago esté confirmado en el proveedor.
- Avisar al cliente de la agencia — su informe indica el pedido, la discrepancia detectada, la fecha y el importe afectado.
- Consultar al proveedor de pago — él guarda el extracto de los cobros; pida el detalle de la transacción.
- Conservar los registros — copie los registros de acceso y de la aplicación del periodo antes de su rotación.
- Revisar las cuentas — si encuentra una cuenta o un rol que nadie creó, cambie las contraseñas de administración y las claves de la pasarela.
- Medir antes de restaurar — volver a una copia anterior al incidente borra también los pedidos legítimos realizados desde entonces.
Los otros avisos de Commerce del mismo día
El 28 de octubre de 2026, drupal.org publicó otros avisos que afectan al ecosistema Commerce, del número 255 al 265: Commerce Core, Commerce Shipping, Commerce License y Commerce Stripe. Están clasificados como menos graves que el 254, y solo el 254 declara una explotación activa. Uno de ellos, sobre Commerce Stripe, alcanza sin embargo «Critical» (15 sobre 25).
No actualice, pues, solo Commerce Core. Liste los paquetes de Commerce de cada tienda con composer outdated 'drupal/commerce*' y lea cada aviso en drupal.org/security antes de decidir.
Quién mantiene la relación con el cliente y qué se entrega
Cuando se encuentra un pedido fraudulento, el cliente llama a la agencia. Conserve ese papel: la agencia mantiene la relación, el informe de auditoría y la decisión de reembolso o restauración. La plataforma mantiene la infraestructura: una cuenta aislada por cliente, copias de seguridad que restaurar, acceso SSH o WHM para actualizar sin esperar un ticket. No modificamos el código de aplicación de una tienda en su lugar; actualizar Commerce sigue siendo un gesto de la agencia.
Entregue al cliente una página fechada: versión anterior, versión posterior, fecha y hora de la actualización, referencia de la copia, ventana de auditoría, número de pedidos examinados, discrepancias halladas o ausencia de ellas, y lo que no se ha mirado. Conserve la plantilla: el próximo aviso sobre un módulo de Drupal seguirá la misma secuencia, con otra fila en el inventario. El ritmo mensual de control se describe en la checklist de auditoría de un VPS de cliente.
