Pasillo de centro de datos con racks iluminados en verde turquesa

BlockStrap (CVE-2026-103849): RCE CVSS 10.0 en Magento y Adobe Commerce, y cómo auditar tu tienda

octubre 20, 2026 Alfonso Moreno | Sysadmin Senior 4 Visitas 10 min de lectura

El 13 de octubre Adobe publicó APSB26-153 con cinco parches críticos para Adobe Commerce y Magento Open Source, y uno de ellos — CVE-2026-103849, bautizado BlockStrap por Sansec — trae una calificación CVSS 10.0 que no habíamos visto en e-commerce desde StyleSmuggler el mes pasado. Si administras una tienda Magento, una tienda de Adobe Commerce B2B, una implementación Mage-OS o cualquier proyecto heredado que tenga Magento como dependencia, lee esto antes de hacer cualquier otra cosa hoy.

La parte que más me preocupa como sysadmin no es el CVSS 10.0 en abstracto, sino el patrón: BlockStrap es una variante del mismo motor de plantillas que ya rompimos con el hotfix VULN-39341 en septiembre. El parche de StyleSmuggler firmaba las directivas que pasan por el motor {{block}}, pero deja una ventana: cuando una plantilla hija inyecta contenido controlado por un atacante, esa firma se respeta en el segundo recorrido y se vuelve a evaluar a nivel raíz. Resultado: el motor procesa de nuevo un {{block}} que vino “firmado” pero cuyo contenido nadie revisó otra vez. Adobe reemplazó el recorrido genérico de directivas por placeholders registrados, así que el atajo se cierra — siempre que apliques el parche de octubre.

TL;DR — Lo que vas a tener al final

Tiempo de auditoría y mitigación: 1 hora para validar, 3-6 horas para parchear Magento Open Source, hasta 24h si es Adobe Commerce con licencias atadas a un ticket.
Requisitos: acceso SSH a la raíz del Magento, Magento 2.4.4-2.4.9 (o Mage-OS 3.5.x-3.6.x, o Adobe Commerce B2B 1.3-1.5), y poder reiniciar cron + servicio de queue.
Resultado: saber si tu tienda tiene el parche aplicado o no, y un plan concreto para llegar al estado seguro antes de que aparezcan exploits en cadena.
Troubleshooting común: Composer instala la base vulnerable aunque digas “actualizado”, los parches plugin a veces omiten un hunk sin error, Mage-OS necesita path distinto al de Magento stock.

Qué es BlockStrap y por qué importa en este momento

BlockStrap es la vulnerabilidad registrada como CVE-2026-103849 en el boletín APSB26-153 de Adobe. La categoría CWE-1336 (“improper neutralization of special elements used in a template engine”) describe el problema exacto: el motor de plantillas de correo electrónico toma contenido que llegó firmado por una plantilla hija y lo vuelve a procesar a nivel raíz sin re-validarlo. El atacante logra que un {{block}} arbitrario se ejecute dentro del contexto de render de Magento, lo que en la práctica significa ejecución de PHP sin autenticarse.

Sansec — la misma firma holandesa que descubrió StyleSmuggler en septiembre — confirmó el 15 de octubre que reprodujo cuatro rutas de ataque distintas en menos de 24 horas partiendo del diff del parche. No han observado explotación masiva todavía, pero también subrayan que StyleSmuggler pasó de “hotfix priority 1” a “explotación en masa” en tres días. BlockStrap tiene una complejidad similar y un CVSS 10.0 igual al de su predecesor.

Lo que más me inquieta como sysadmin no es solo el diez de diez sobre el papel, sino el precedente: Adobe clasificó este boletín como “priority 2” (parche en 30 días), pero la historia de StyleSmuggler nos enseñó que cualquier RCE sin autenticación en una plataforma con 160.000 instalaciones termina quemando en horas, no en semanas. Si tu tienda está en producción con tráfico real, la regla operativa es tratarlo como priority 1 — apaga GraphQL hasta tener el parche aplicado, igual que la recomendación de Sansec el mes pasado.

Versiones afectadas y CWE del boletín

APSB26-153 corrige varias vulnerabilidades a la vez. La que activa la alarma es BlockStrap, pero hay tres CVEs critical más en el mismo parche que conviene conocer:

CVE	Severidad	CVSS	Categoría CWE	Impacto
CVE-2026-103849 (BlockStrap)	Critical	10.0	CWE-1336 (template engine)	Arbitrary code execution sin autenticación
CVE-2026-92909	Critical	9.8	CWE-863 (incorrect authorization)	RCE en Adobe Commerce B2B
CVE-2026-91013	Critical	9.3	CWE-79 (Stored XSS)	Escalada de privilegios por XSS
CVE-2026-100133	Critical	—	CWE-79 (Stored XSS)	Stored XSS persistente

Versiones afectadas en el producto Magento Open Source y Adobe Commerce (ramas legacy que necesitan parche explícito):

Adobe Commerce: 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8 y 2.4.9 — todas las versiones etiquetadas *-2026-sep y anteriores.
Adobe Commerce B2B: 1.3.3, 1.3.4, 1.4.2, 1.5.2 y 1.5.3, igualmente *-2026-sep y anteriores.
Magento Open Source: 2.4.4 hasta 2.4.9, todas vulnerables.
Mage-OS: hasta 3.5.0 inclusive. Mage-OS 3.6.0 (publicado el 14 de octubre) ya incluye la corrección.

Cómo funciona el segundo recorrido del motor de plantillas

Para entender por qué el hotfix VULN-39341 no es suficiente, hay que mirar de cerca cómo Magento procesa un correo transaccional como “Payment Transaction Failed”. El motor toma la plantilla raíz, sustituye las directivas {{block …}} que conoce y produce HTML. El parche de StyleSmuggler añadió una firma criptográfica a las directivas que viajan del root hacia los children templates, de modo que si un atacante intenta inyectar contenido malicioso, su firma no es válida y el motor lo descarta.

BlockStrap rompe esa cadena en sentido contrario: una plantilla hija firmada correctamente contiene un fragmento que, al renderizarse, vuelve a firmar y reenviar datos controlados por el atacante al motor raíz. El motor ve una firma válida, procesa el fragmento como si viniera del root, y termina ejecutando un {{block}} arbitrario dentro del contexto de PHP del servidor. Por eso Adobe no firma el contenido sino que reemplaza todo el recorrido genérico de directivas por una tabla de placeholders registrados: cualquier {{block}} que no esté en esa tabla no se ejecuta, sin importar la firma.

La consecuencia operativa es directa: el parche de octubre no es acumulativo con el de septiembre. Necesitas los dos. El boletín incluye el fix de BlockStrap, pero NO reemplaza VULN-39341 — Adobe los distribuye por separado porque StyleSmuggler cubre un vector distinto en el mismo motor.

Cómo verificar si tu tienda está parcheada

Antes de tocar nada, valida el estado actual. Sansec dejó dos comandos concretos para detectar si las correcciones están aplicadas:

# En la raíz de tu Magento (stock, no Mage-OS)
# Si devuelve 0, el parche de BlockStrap NO está aplicado
grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php

Para Mage-OS el archivo está en una ruta distinta:

# Mage-OS 3.6.0+ trae la corrección en esta ruta
grep -c resolveDeferredDirectives vendor/mage-os/framework/Filter/Template.php

Para el hotfix de StyleSmuggler (que también deberías tener instalado):

# Status del hotfix VULN-39341
vendor/bin/magento-patches -n status | grep -E "39341|Status"

Y un comando útil para auditoría de segundo CVEs del mismo boletín (CVE-2026-91013 afectaba a EmailAddress.php):

grep -c QUOTED_LOCAL_PART_PATTERN 
  vendor/magento/framework/Validator/EmailAddress.php
# Si imprime 0, falta el parche 248p5-2026-10-002-CE

Si tus deploys usan algún plugin de patches para Composer que ejecuta patch ... || true, corres estos checks aunque el deploy reporte cero errores — un hunk que no aplica no rompe el build, pero tampoco protege. El bug que vimos este mes precisamente fue ese: tres equipos parcharon “exitosamente” pero el archivo Template.php seguía sin resolveDeferredDirectives.

Aplicar el parche: Magento Open Source, Adobe Commerce y Mage-OS

El procedimiento depende de tu distribución. Si usas Magento Open Source en una versión soportada (2.4.7-p10, 2.4.8-p5 o 2.4.9) y Composer, el parche es una actualización de paquete:

# Modo mantenimiento
bin/magento maintenance:enable
# Forzar la versión parcheada (ejemplo 2.4.8-p5 corregida)
composer require magento/product-community-edition 2.4.8-p5 --no-update
composer update
# Re-validar
grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php
# Esperado: 1 o más
# Limpiar cachés
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:clean
bin/magento cache:flush
# Volver a operaciones
bin/magento maintenance:disable

Si tu Magento Open Source está en 2.4.6 o anterior (ramas sin parche público para Open Source), no tienes upgrade graceful: Adobe distribuye los parches para 2.4.4-p18, 2.4.5-p17 y 2.4.6-p15 solo a clientes con licencia activa de Adobe Commerce. La salida operativa es subir a 2.4.7-p10 o superior — o mantener GraphQL deshabilitado mientras coordinas la migración.

Para Mage-OS (la distribución comunitaria basada en Magento), el equivalente es:

composer require mage-os/product-community-edition 3.6.0 --no-update
composer update
bin/magento maintenance:enable
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush
bin/magento maintenance:disable

Para Adobe Commerce con licencia comercial, el parche se gestiona a través del portal de soporte. Necesitas abrir ticket con KB ka-49323 y descargar el archivo específico para tu rama — no es pública. Mantén VULN-39341 instalado antes de aplicar el parche de octubre: el orden importa porque el fix de Adobe modifica las mismas funciones que firma el hotfix anterior.

Troubleshooting: cuando Composer dice “actualizado” pero el archivo no cambia

Si ejecutaste composer update y el archivo Template.php sigue sin resolveDeferredDirectives, hay tres causas probables por orden de frecuencia:

Plugin de patches configurado con || true: tu pipeline CI ejecuta patch ... || true como red de seguridad. Si un hunk no aplica, Composer sigue pero el archivo queda igual. La validación con vendor/bin/magento-patches -n status debería detectarlo, pero algunos pipelines solo validan el exit code global.
Lockfile desactualizado: composer.lock apunta a una versión vulnerable porque se generó antes del 13 de octubre. composer update respeta el lock a menos que uses --no-cache o limpies ~/.cache/composer. Borra el lock y regenera después de fijar la versión parcheada.
Caché de opcode activado: si tienes OPcache o un preloader armado, el archivo en disco cambia pero PHP sirve la versión compilada vieja. Reinicia php-fpm o limpia OPcache con opcache_reset() en CLI.

Para descartar compromiso, los indicadores que vimos en ataques de StyleSmuggler siguen siendo válidos: procesos disfrazados de [kworker/u:8:0] o fc-cache, cron jobs ejecutándose cada 30 minutos desde usuarios sin contexto, archivos ~/.cache/fontconfig/fc-cache sospechosos, y ráfagas de correos “Payment Transaction Failed” que el equipo de marketing no haya programado. Si encuentras cualquiera de estos, rota las credenciales de Magento y revisa logs de PHP en busca de POST a endpoints de email transaccional que no reconozcas.

Preguntas frecuentes

¿Adobe dijo priority 2, eso significa que puedo esperar?

No. Adobe usa priority 2 para indicar ventana de 30 días según su clasificación interna, pero la historia de StyleSmuggler (priority 1 → explotación masiva en 3 días) demuestra que cualquier RCE sin auth en Magento se convierte en vector de ataque antes de la fecha límite. Trátalo como priority 1 si tu tienda está en producción.

Si tengo VULN-39341 instalado, ¿ya estoy protegido contra BlockStrap?

No, son vulnerabilidades distintas en el mismo motor. El hotfix de StyleSmuggler firma directivas en el recorrido root → child; BlockStrap explota un segundo recorrido child → root que el hotfix no cubre. Necesitas ambos parches, en este orden: primero VULN-39341, luego el fix de octubre.

¿Qué pasa con Magento Open Source 2.4.6 o anterior?

Adobe solo distribuye el parche de octubre para 2.4.7-p10, 2.4.8-p5 y 2.4.9 al público Open Source. Si corres 2.4.4-p18, 2.4.5-p17 o 2.4.6-p15, necesitas licencia de Adobe Commerce activa para acceder al ZIP. Sin licencia, la salida es planear un upgrade a 2.4.7-p10 mínimo, o mantener GraphQL deshabilitado como mitigación temporal.

¿Puedo aplicar el parche sin desactivar la tienda?

Técnicamente puedes parchar con la tienda en vivo, pero Magento recomienda bin/magento maintenance:enable antes de setup:upgrade + setup:di:compile porque esos pasos invalidan cachés y pueden dejar errores 503 transitorios. En operaciones grandes es estándar un mantenimiento de 5-15 minutos, mejor coordinado que un storefront que parpadea durante 20 minutos.

¿Cómo sé si mi tienda ya fue comprometida por BlockStrap?

Todavía no hay exploits públicos, pero comparte indicadores con StyleSmuggler: procesos [kworker/u:8:0] o fc-cache, cron jobs cada 30 minutos, correos “Payment Transaction Failed” no programados, archivos en ~/.cache/fontconfig/. Corre grep -r "resolveDeferredDirectives" vendor/magento/ — si devuelve cero, no tienes el fix instalado y debes asumir exposición.