Empezó con el boletín de julio

Tras recibir la alerta de seguridad de Magento de julio, que por separado no era especialmente llamativa, me quedé con la mosca detrás de la oreja al mirar qué ficheros tocaba. Endurecía un montón de endpoints de carrito de invitado y la galería de producto, o sea las partes que cualquiera puede llamar sin tener cuenta. Cuando un parche se dedica precisamente a eso, suele significar que alguien ha estado mirando por ahí.

Así que me quedé pendiente el resto del verano, con la sensación de que iba a caer algo serio. Cayó.

Los cuatro parches del verano

Entre julio y septiembre acabaron saliendo cuatro parches de seguridad, uno detrás de otro:

  • El mensual de julio, 32 ficheros, con lo que comentaba arriba: endpoints de carrito de invitado (GuestPaymentInformationManagement, GuestShippingInformationManagement y similares) y galería de producto.

  • El mensual de agosto, 10 ficheros, casi todo del gestor de imágenes del admin y del guardado de reseñas.

  • El hotfix de StyleSmuggler (CVE-2026-75650), que Adobe sacó fuera del calendario mensual porque es una ejecución de código sin autenticar con CVSS 10.

  • El mensual de septiembre (APSB26-138), con un secuestro de carrito en PayPal Express, un problema de contexto de cliente entre webs y un XSS en el escaper.

El tercero es el que justifica este post.

StyleSmuggler y la confusión con GraphQL

StyleSmuggler afecta a todas las versiones desde la 2.4.4 hasta la 2.4.9, o sea a casi cualquier instalación que no estuviera recién actualizada. Permite ejecutar código en el servidor sin cuenta ni credenciales de nada. Con eso ya no hay debate sobre si merece la pena parchear ahora o la semana que viene.

Que Adobe lo publique fuera del calendario mensual, como hotfix suelto, es la señal de que no se podía esperar tres semanas al siguiente boletín. No llegó a ser un zero-day, que es cuando una vulnerabilidad se está explotando antes de que exista parche, pero la diferencia práctica es más pequeña de lo que parece: los primeros sondeos contra servidores que yo estaba mirando fueron del mismo día en que salió el aviso. Si tu instalación tarda una semana en parchearse, para ti ha sido un día cero igual.

Hay una confusión con este bug que yo mismo tuve que mirar dos veces, y que he visto repetida en varios sitios: la gente habla de la vulnerabilidad de GraphQL y de la de StyleSmuggler como si fueran dos distintas. Son la misma. GraphQL solo es por donde entra. El fallo está en el motor de plantillas de Magento, y lo que hace el atacante es colar un parámetro styles en una petición a /graphql para que Magento acabe construyendo una clase PHP que elige él. El disparador habitual es el email de pago fallido, porque es el que renderiza la plantilla.

Esto tiene una consecuencia práctica importante. Desactivar GraphQL reduce la superficie, pero no arregla nada: el agujero sigue estando en el motor de plantillas, y la entrada por GraphQL es solo la más cómoda. La única solución de verdad es el parche.

Los intentos, cuando llegan, se ven en los logs tal cual. Esto es de un caso real, y se contaban por cientos al día:

POST /graphql?styles[first]=..%2Fvar%2Flog%2Fsystem.log
   &styles[generatorClass]=Aws%5CS3%5CS3Client
   &styles[second]=Magento%5CFramework%5CDataObject HTTP/1.1

Lo que importa de ahí es generatorClass, que es donde el atacante pone la clase que quiere que Magento instancie.

Para provocar el renderizado que ejecuta eso, lo que hacen es crear carritos con datos inventados y forzar el envío del email de pago fallido, metiendo directivas de plantilla de Magento en la dirección de facturación. En base de datos se ve perfectamente: carritos con correos del tipo algo@nx.invalid y direcciones como esta:

firstname: A   lastname: B   company: Acme
postcode:  {{var postcode}}
street:    {{block class=Magento\Email\Block\Adminhtml\Template\Preview}}

Con el parche aplicado, esas directivas llegan al correo como texto y no se ejecutan. Sin el parche, ahí se acaba la historia y empieza otra bastante peor.

El parche son tres líneas

Lo que más me llamó la atención es lo pequeño que es el arreglo. Se limita a comprobar el tipo antes de crear el objeto, en vez de crearlo y comprobarlo después:

// vendor/magento/module-backend/Model/Widget/Grid/Row/UrlGeneratorFactory.php
public function createUrlGenerator($generatorClassName, array $arguments = [])
{
    // Validar el tipo ANTES de instanciar.
    if (!is_a($generatorClassName, GeneratorInterface::class, true)) {
        throw new \InvalidArgumentException('Passed wrong parameters');
    }

    return $this->_objectManager->create($generatorClassName, $arguments);
}

En la versión vulnerable la llamada al _objectManager iba primero y la comprobación después, cuando la clase ya estaba construida y ya había hecho lo que tuviera que hacer en su constructor. Mover la comprobación tres líneas hacia arriba es toda la diferencia entre estar expuesto y no estarlo.

Aplicar los parches en orden

Cuando llegan varios parches seguidos pueden solaparse entre ellos, y entonces el orden en que se aplican forma parte del arreglo. En esta tanda se veía muy claro, porque el de julio crea un fichero que el de agosto modifica después.

248p5-2026-07-001-CE   crea vendor/bin/patch-status
248p5-2026-08-001-CE   modifica ese mismo fichero, necesita el 07 antes
VULN-39341-248p5-CE    StyleSmuggler (CVE-2026-75650)
248p5-2026-09-001-CE   mensual de septiembre (APSB26-138)

Si los aplicas en otro orden, el de agosto no encuentra lo que espera. Si los gestionas con Composer (cweagans/composer-patches), el orden lo marcas tú en la configuración, así que conviene declararlos en el mismo orden en que Adobe los publicó y asegurarse de que aplicarlos otra vez sobre el mismo árbol da el mismo resultado.

¿Está la IA acelerando esto?

Un boletín de seguridad relevante en Magento era antes cosa de dos o tres veces al año, y ahora cae como mínimo uno al mes. Me cuesta creer que sea casualidad. Buscar una cadena de clases aprovechable dentro de un framework con inyección de dependencias es la lectura tediosa que a una persona le lleva semanas y a un modelo no le cuesta nada, y convertir el diff de un parche en un exploit que funcione ya no son días de ingeniería inversa.

Si llevas una tienda Magento y ahora mismo no sabrías decir en qué versión está ni cuándo se le aplicó el último parche de seguridad, ya tienes la respuesta. Si quieres que le echemos un ojo, escríbeme.