APSB26-153: el parche de octubre de Magento cierra una forma de saltarse la corrección de StyleSmuggler

El boletín de octubre de Adobe, APSB26-153, salió el martes 13. Casi todo es rutina. Una línea no lo es: CVE-2026-103849, una inyección de plantillas sin autenticación con una puntuación de 10,0, en la misma parte de Magento por la que entró StyleSmuggler el mes pasado.

Sansec, que lo llamó BlockStrap, añadió una nota a su análisis de StyleSmuggler en la que lo describe como una forma de saltarse ese parche:

Applying the StyleSmuggler hotfix alone does not stop it.

Una tienda que aplicó rápido el hotfix de septiembre y se quedó ahí sigue expuesta. El parche de octubre tampoco contiene ese hotfix. De las notas de versión de Adobe:

The hotfix for CVE-2026-75650 is not included in the October Isolated patch file and must be applied separately.

Necesita los dos.

CVE-2026-103849 (BlockStrap)

Es la misma categoría, la misma puntuación y el mismo vector que StyleSmuggler. Remoto, fácil, sin cuenta, y nadie tiene que hacer clic en nada. Dicho de forma sencilla: alguien sin ningún acceso podría ejecutar su propio código en el servidor de la tienda y, desde ahí, llegar a los datos de clientes y al checkout.

Sansec describe BlockStrap como «a second-pass directive injection, like StyleSmuggler». Magento procesa las plantillas de email en más de una pasada, y los datos de un atacante que sobreviven a la primera se leen como código de plantilla en una posterior, donde se ejecuta una directiva {{block}} colada de contrabando. Según Sansec, la corrección de Adobe «replaces that generic rescan with registered placeholders».

Leímos los dos archivos de parche para ver dónde está cada corrección. El hotfix de septiembre (VULN-39341-249.diff) hace que BlockFactory compruebe que una clase es realmente un bloque antes de crearla, y añade comprobaciones de ACL a los bloques de vista previa de email y newsletter. No toca el filtro de plantillas. El parche de octubre sí: añade un DeferredDirectiveRegistry a Framework\Filter\Template y elimina el aplazamiento basado en firmas que Magento trae de serie desde al menos 2.4.7. Son dos capas distintas, lo que encaja con el consejo de Sansec de mantener las dos. No hemos reproducido el ataque, así que lo de saltarse el hotfix es un hallazgo de Sansec, no nuestro. El boletín de Adobe no relaciona CVE-2026-103849 con StyleSmuggler en ningún momento.

Por qué no esperaríamos 30 días

La prioridad 2 es el nivel de 30 días de Adobe. Su razonamiento es que nadie lo está explotando, y a 15 de octubre, cuando Sansec publicó su análisis, seguía siendo así.

Nosotros lo aplicaríamos esta semana. StyleSmuggler se estaba explotando antes de que Adobe tuviera una corrección, así que los atacantes ya conocen este código y tienen herramientas apuntando a él. Sansec dice que reprodujo cuatro vías de ataque distintas en menos de 24 horas, y cuestiona también la prioridad 2. La propia evaluación de CISA en el registro de NVD, del 14 de octubre, marca la explotación como ninguna, la automatización como sí y el impacto técnico como total. No está en el catálogo de vulnerabilidades explotadas conocidas de CISA.

Una tienda que está en la última versión -p y que ya aplicó julio, agosto y septiembre tiene el deploy más llevadero. Cuánto trabajo supone sigue dependiendo de sus personalizaciones, integraciones e infraestructura, así que dimensione las pruebas en consecuencia, pero no deje que eso se convierta en un motivo para aplazar el parche.

Todo lo que incluye APSB26-153

Once CVE. Cinco críticas, cinco altas y una media. Cuatro son XSS almacenado: alguien guarda un script en un campo de formulario y se ejecuta más tarde en el navegador de quien abra ese registro, que en Magento suele ser un administrador.

Los niveles de privilegio salen de la métrica PR de cada vector CVSS, porque la tabla de Adobe no dice si «requiere autenticación» se refiere a una cuenta de cliente o a una de administrador.

Si usa B2B, CVE-2026-92909 merece casi tanta atención como el 10,0. Es ejecución de código con 9,8 y sin iniciar sesión. El boletín de Adobe lo marca como B2B, pero el registro de parches que lee la propia herramienta de comprobación de Adobe lo incluye en el archivo CE de octubre de todas las líneas y en el archivo B2B. La corrección está repartida entre los dos, así que una tienda B2B necesita ambos. El registro hace lo mismo con CVE-2026-91013, que aparece en los archivos CE y EE, así que las tiendas Commerce necesitan también el archivo EE.

Versiones afectadas:

• Adobe Commerce de 2.4.4 a 2.4.9, cada una en 2026-sep y anteriores
• Adobe Commerce B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 y 1.5.3, cada una en 2026-sep y anteriores
• Magento Open Source de 2.4.6 a 2.4.9, cada una en 2026-sep y anteriores

Las versiones corregidas son las -2026-oct, más 2.4.10-alpha1 y B2B 1.5.4-alpha1.

Magento Open Source está en la misma situación que el mes pasado. Las versiones corregidas se quedan en 2.4.7, y las notas de Adobe dicen que los comerciantes de Open Source solo pueden descargar parches para 2.4.7 y posteriores. No hay parche de octubre para Open Source 2.4.6, que además ya está fuera de soporte. Adobe Commerce de 2.4.4 a 2.4.6 sí lo tiene, detrás de las claves de Composer.

Cómo obtener el parche: archivos aislados, no Composer

Un parche aislado es un diff sobre los archivos de vendor/, no una nueva versión de Magento. Las notas de versión de Adobe dicen que las correcciones de octubre se publican solo de esa forma y que no publicar paquetes de Composer es intencionado. El mirror de Mage-OS de los paquetes de Adobe no muestra ninguna versión nueva de magento/framework desde 2.4.9, así que en una instalación propia composer update no le trae octubre.

Para las descargas con claves, la clave pública de Marketplace es el usuario y la privada es la contraseña.

Cada zip trae un archivo por componente. El de 2.4.9 contiene 249-2026-10-001-CE.patch, 249-2026-10-001-EE.patch y 153-2026-10-001-B2B.patch. El orden es el que Adobe da cada mes: tiene que estar en la última versión -p de su línea, todos los parches mensuales anteriores tienen que estar aplicados ya, y dentro de cada mes va primero CE, después EE y después B2B. Para una tienda Commerce en 2.4.8-p5 que aplicó septiembre, eso es 248p5-2026-10-001-CE, después 248p5-2026-10-001-EE, y después B2B si lo usa. El nombre del archivo B2B sigue su versión de B2B, no la de Magento; el zip de 2.4.7-p10 trae archivos 152p5- y 142p10- para B2B 1.5.2 y 1.4.2. El hotfix de StyleSmuggler se queda donde está.

Las tiendas en Adobe Commerce Cloud reciben las dos correcciones mediante el paquete cloud patches: 1.1.21 aplica el hotfix de StyleSmuggler y 1.1.22, publicado el 13 de octubre, aplica APSB26-153. Adobe advierte que aplicar el parche aislado donde cloud patches ya trajo la corrección puede romper la instalación.

2.4.8-p5 tiene un segundo archivo CE

El registro de Adobe incluye dos parches CE de octubre para 2.4.8-p5. 248p5-2026-10-001-CE modifica 21 archivos. 248p5-2026-10-002-CE modifica uno, framework/Validator/EmailAddress.php, corrige CVE-2026-91013 y requiere antes -001. Sansec también lo señaló.

El zip de 2.4.8-p5 en repo.magento.com, tal como lo descargamos el 16 de octubre, contiene un único archivo -001-CE de 22 archivos, con el cambio de EmailAddress.php incluido. Su checksum no coincide con el del -001 del registro. Así que si una tienda en 2.4.8-p5 ya tiene la corrección de CVE-2026-91013 depende de qué -001 aplicó.

No aplique -002 a ciegas. Compruébelo primero:

grep -c QUOTED_LOCAL_PART_PATTERN vendor/magento/framework/Validator/EmailAddress.php

Cualquier valor mayor que 0 significa que el cambio está, y -002 fallará por estar ya aplicado, lo que puede detener un build que trate un parche fallido como error fatal. Un 0 significa que necesita -002. patch-status informa de lo mismo por CVE.

Aplicarlo para que se quede aplicado

Modificar a mano los archivos de vendor/ no es un deploy. El siguiente composer install devuelve los archivos antiguos, y el siguiente build los publica. Añada los archivos de parche a lo que ya gestiona los parches en su proyecto (cweagans/composer-patches, vaimo/composer-patches, o el directorio m2-hotfixes en Cloud) y haga commit, para que cada build los aplique. Las notas de versión de Adobe remiten a su guía para aplicar un parche de Composer.

Antes de meterlo en el build, una prueba en seco desde la raíz del proyecto muestra si todos los fragmentos se aplican, sin tocar nada:

patch -p1 --dry-run --fuzz=0 < 249-2026-10-001-CE.patch

La advertencia de Sansec va aquí: los plugins de parches de Composer pueden saltarse un fragmento sin que falle el build, y los scripts de deploy que ejecutan patch … || true ignoran los fragmentos que fallan. En ambos casos el deploy sale en verde con la corrección a medias.

Después, la aplicación en ejecución tiene que recoger el parche. Hay tres capas, y cada una puede quedarse por detrás de la anterior:

• Los archivos. El código parcheado está en vendor/. Es lo único que pueden ver patch-status y los grep de más abajo.
• El código generado y la configuración. El parche CE de octubre añade clases nuevas, dos plugins nuevos (RestrictedFieldsPlugin y AllowPersistentCustomerGuestCart) y configuración de DI. En modo producción, Magento no usa nada de eso hasta que se reconstruyen generated/ y la cache de configuración.
• Los procesos en ejecución. Con la validación de timestamps de OPcache desactivada, PHP-FPM sigue sirviendo los archivos antiguos hasta que se recarga o se reinicia OPcache. Los consumidores de colas también son procesos PHP de larga duración, y mantienen el código antiguo hasta que se reinician.

En instalaciones propias, use los pasos que su deploy ya ejecuta para un cambio de código. Para la mayoría de las tiendas en modo producción eso significa setup:di:compile y limpiar la cache, después recargar PHP-FPM o reiniciar OPcache donde no se validan los timestamps, y reiniciar los consumidores. En Cloud, las fases de build y deploy reconstruyen el código generado y las caches cuando hace push.

Volver atrás es sencillo. Ninguno de los archivos CE, EE o B2B de octubre que leímos para 2.4.7-p10, 2.4.8-p5 y 2.4.9 toca Setup/ ni db_schema.xml, así que no hay cambios en la base de datos que deshacer ni setup:upgrade que ejecutar. Revertir es revertir código. Haga de todos modos su copia de seguridad habitual antes.

El código personalizado puede anular la corrección. Un módulo que define su propia <preference> para una de las clases parcheadas sigue ejecutando su propia versión, y un plugin sobre ellas puede romperse cuando entre el parche. Este comando solo lee archivos:

grep -rnE --include=di.xml 'Magento\\(Framework\\Filter\\Template|Email\\Model\\Template\\Filter|Framework\\Validator\\EmailAddress|Framework\\Lock\\Backend\\FileLock)"' app/code vendor | grep -v '^vendor/magento/'

Cualquier resultado necesita que un desarrollador lo revise antes de aplicar octubre.

Cómo comprobar que el parche de octubre está aplicado

php vendor/bin/patch-status

Es la Commerce Version Tool de Adobe. Leímos su código: descarga el registro de parches de Adobe y cada parche desde repo.magento.com, los compara con sus archivos con patch --dry-run hacia delante y en sentido inverso, y muestra los parches aplicados, los que faltan y un PROTECTED, VULNERABLE o UNKNOWN por CVE. El registro incluye también el hotfix de StyleSmuggler, así que CVE-2026-75650 aparece en el mismo informe.

Lo que necesita:

• El parche aislado de julio de 2026. La herramienta llegó con él. Si el comando no está disponible, compruebe por separado la instalación del parche de julio y su proceso de deploy.
• Acceso de red a repo.magento.com, con un tiempo de espera de tres segundos. Un servidor de producción sin acceso de salida devolverá UNKNOWN.
• Las claves de Marketplace para los parches que las requieren (de 2.4.4 a 2.4.6 y algunas líneas de B2B), desde el entorno o auth.json.
• El binario patch en el servidor.

Trate UNKNOWN como «sin comprobar». Y tenga presente lo que significa PROTECTED: el código parcheado está en los archivos del disco. No puede ver si se reconstruyeron generated/ y la cache de configuración, ni si PHP-FPM sigue sirviendo los archivos antiguos desde OPcache. Ejecútelo cuando el deploy haya terminado, contra producción.

Para CVE-2026-103849 en concreto, Sansec propone:

grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php

El parche de octubre añade ese método, así que 0 significa que la corrección de BlockStrap no está. Confirmamos que aparece en los archivos CE de 2.4.7-p10, 2.4.8-p5 y 2.4.9. No dice nada de las otras diez CVE. En Mage-OS el archivo está en vendor/mage-os/framework/Filter/Template.php.

Ninguna de las dos comprobaciones toca la aplicación en ejecución. Una petición puede darle una señal desde ella, porque pasa por un plugin que añade el parche. Es una búsqueda, así que está pensada para ser de solo lectura, pero va contra la API de producción, así que debe ejecutarla alguien autorizado para probar esa API, con un token de administrador o de integración que tenga permiso para leer clientes. Busque clientes por el campo confirmation:

curl -sg -H "Authorization: Bearer $TOKEN" "https://your-store.example/rest/V1/customers/search?searchCriteria[filterGroups][0][filters][0][field]=confirmation&searchCriteria[filterGroups][0][filters][0][value]=x"

Según nuestra lectura del parche, una tienda que ejecuta el código de octubre debería rechazarla con «The search criteria filter field is invalid.» No la hemos ejecutado nosotros contra una tienda parcheada. Si la búsqueda funciona, aunque devuelva una lista vacía, eso indica que la restricción de octubre no está activa, diga lo que diga patch-status, y lo primero que hay que revisar es si generated/ o la cache de configuración están desactualizados. No interprete ninguna otra respuesta como un aprobado. Un error de autenticación o de autorización, una capa de API personalizada delante de Magento o cualquier otro error no dice nada sobre el parche. E incluso un rechazo correcto solo cubre esta restricción de la API, no el resto del parche de octubre.

Las tiendas en Adobe Commerce Cloud también pueden usar la Quality Patches Tool, que Adobe documenta para comprobar el hotfix solo en Cloud:

vendor/bin/magento-patches -n status | grep "39341\|Status"

Después de parchear encontrará un archivo vacío llamado 976bc24c08055e67a58cf491401c8b2f3d48ff55b8092f1ede196bac4756a228 en la raíz de Magento. Sansec lo detectó, y el parche lo explica: FileLock ahora nombra los archivos de bloqueo con el SHA-256 del nombre del bloqueo, y ese es el hash de /var/.regenerate.lock. Es el propio bloqueo de regeneración de Magento con un nombre nuevo. No es malware y no hay nada que limpiar.

Lo que cambia el parche y puede que note

Revisamos los 22 archivos del parche CE de 2.4.9. Casi todo es invisible. Esto no:

• Las plantillas de email se vuelven más estrictas al guardar. Un nuevo Magento\Email\Model\Template\Validator rechaza cualquier directiva {{...}} dentro de un atributo HTML o de un url() de CSS que apunte a una dirección externa absoluta: http:, https: o //. Magento ya bloqueaba una directiva colocada después del host en src, href y action. La nueva comprobación cubre todos los atributos, url() de CSS y también el campo de estilos de la plantilla. Una plantilla transaccional personalizada con algo como style="background:url(https://cdn.example.com/{{var store.code}}.png)" ya no se guardará, y mostrará «Content field contains restricted HTML elements». Se sigue renderizando. El error aparece la próxima vez que alguien la edite, así que abra sus plantillas personalizadas en staging y guárdelas una por una.
• Las vistas previas de email en el admin pasan la misma comprobación sobre el texto y los estilos enviados antes de renderizar.
• Las búsquedas de clientes no pueden filtrar por secretos. password_hash, rp_token y confirmation se rechazan como campos de filtro u ordenación en el repositorio de clientes por REST, SOAP y GraphQL. Una integración que buscaba clientes por confirmation para encontrar cuentas sin confirmar empezará a recibir un InputException.
• Se rechazan las direcciones de email con la parte local entre comillas, como "john smith"@example.com. Es raro, pero la dirección es válida según el RFC, así que un registro o un checkout podría fallar con una.
• Endpoints de carrito de invitado y carritos persistentes. El parche de julio añadió GetGuestCart, que solo deja a los endpoints de carrito de invitado cargar carritos que pertenecen a invitados. Octubre añade un plugin en Magento_Persistent que permite a una petición de carrito de invitado leer el carrito de un cliente recordado, pero solo con el carrito persistente activado, sin nadie con sesión iniciada y con la sesión persistente de ese mismo cliente. Según nuestra lectura, esto corrige un efecto secundario del cambio de julio, así que si los carritos persistentes fallaban desde julio, octubre podría arreglarlos. En cualquier caso, haga pasar por el checkout en staging a un cliente recordado pero sin sesión iniciada.
• El validador WYSIWYG detecta más patrones, incluidos comentarios HTML vacíos como <!--> y bytes NUL. El contenido CMS pegado desde fuentes raras puede necesitar limpieza antes de guardarse.

El archivo EE de Commerce toca un renderizador del módulo Reward, y el de B2B toca Company y los plugins de autorización de Purchase Order Rule. Si usa reglas de aprobación de órdenes de compra, pruebe una aprobación y un rechazo.

Mage-OS: actualice a 3.6.0

Mage-OS 3.6.0 salió el 14 de octubre con el parche de Adobe para 2.4.9 incorporado, más siete correcciones de errores:

composer require mage-os/product-community-edition 3.6.0 --no-update
composer update

Mage-OS dice que no hay forma de corregirlo actualizando un solo paquete, porque la corrección abarca el framework y los módulos Email, Customer, Persistent y Catalog. 3.5.0 se quedó sin soporte con esta versión. Si construyó sobre el endurecimiento adicional que añadió 3.5.0, lea sus notas para integradores. El aplazamiento basado en firmas desaparece, y SignatureProvider queda obsoleto para el aplazamiento. Lo dicho sobre el código generado y las caches vale también después de esta actualización.

Si StyleSmuggler sigue abierto en su tienda

Entonces ese es el primer trabajo. El hotfix, los archivos para su nivel de parche y la rotación de credenciales que pide Adobe están en nuestro artículo de septiembre. Aplique el hotfix y de julio a septiembre en orden, y después octubre encima.

Sansec vende un firewall a nivel HTTP, Shield, y dice que bloquea BlockStrap mientras programa el parche. No lo hemos probado contra este fallo. No tenemos ninguna relación comercial con Sansec, y nuestro análisis de sus herramientas explica dónde las hemos usado.

Qué hacer esta semana

Confirme que el hotfix de StyleSmuggler está aplicado. patch-status informa de CVE-2026-75650 junto a las CVE de octubre.

Añada el parche aislado de octubre a su gestión de parches para su línea: CE, después EE, después B2B. En 2.4.8-p5, compruebe el cambio de EmailAddress.php antes de decidir sobre -002. Las tiendas Cloud, actualicen cloud patches a 1.1.22.

Revise su código personalizado en busca de preferencias y plugins sobre las clases parcheadas.

Despliéguelo como un cambio de código, para que el código generado, las caches y PHP-FPM lo recojan.

Ejecute patch-status, el grep de BlockStrap y la comprobación REST contra producción después, y guarde el resultado. Investigue cualquier UNKNOWN.

Abra y guarde cada plantilla de email personalizada en staging, y haga pasar un pedido de invitado, un pedido con carrito persistente y cualquier flujo de aprobación B2B antes de llevarlo a producción.

Si está en Magento Open Source 2.4.6, no hay parche que aplicar. La opción es actualizar a 2.4.9 o pasarse a Mage-OS.

Emyrix hace trabajo de seguridad en Magento y soporte continuo, incluida la gestión de parches y la investigación de compromisos, y trabajo en Adobe Commerce en tiendas que se han quedado atrás. Si quiere que alguien aplique y compruebe el parche de este mes, o necesita saber si a una tienda le faltó el de septiembre, escríbanos.

Fuentes: Boletín de seguridad de Adobe APSB26-153 · Notas de versión: actualización de seguridad de octubre de 2026 (APSB26-153) · Registro de parches de Adobe · Notas de versión: Magento Cloud Patches · NVD: CVE-2026-103849 · Catálogo KEV de CISA · Sansec: BlockStrap, Magento and Adobe Commerce RCE · Sansec: StyleSmuggler 0-day under active attack · Notas de la versión Mage-OS 3.6.0 · Boletín de seguridad de Adobe APSB26-146 · Notas de versión: actualización urgente para CVE-2026-75650 (APSB26-146) · Definiciones de severidad y prioridad de Adobe