Las tiendas en línea hechas con Magento o Adobe Commerce tienen un fallo pendiente de parchear que merece prisa. Se llama BlockStrap (CVE-2026-103849), tiene la puntuación máxima de gravedad, 10.0, y permite a un atacante ejecutar código PHP en el servidor de la tienda sin iniciar sesión. Adobe lo corrigió el 13 de octubre y dice que no conoce ataques. La empresa de seguridad Sansec tampoco los ha visto todavía, pero cree que es cuestión de días y recomienda no esperar al plazo de 30 días que sugiere Adobe.
Magento es una de las plataformas de comercio electrónico más usadas del mundo. Tiene una versión libre, Magento Open Source, y otra de pago, Adobe Commerce, que Adobe vende desde que compró la empresa en 2018. Existe además Mage-OS, una distribución de la comunidad basada en el mismo código. Al gestionar pagos, datos de clientes y pedidos, las tiendas Magento son un objetivo habitual: un atacante que entra en el servidor puede, por ejemplo, inyectar código para robar las tarjetas en la página de pago.
BlockStrap llega en el boletín APSB26-153, que corrige 11 vulnerabilidades, siete de ellas críticas. Además de esta, destaca CVE-2026-92909 (9.8 sobre 10), que también permite ejecutar código sin iniciar sesión, aunque solo en la edición B2B. Adobe atribuye el hallazgo de BlockStrap a un investigador que firma como «vozec», y fue Sansec quien le puso nombre: el 14 de octubre, al día siguiente del parche, ya había reproducido cuatro formas distintas de ejecutar código con él.
Claves de BlockStrap
- Dónde está el fallo: en el motor de plantillas de los correos electrónicos de Magento, el que rellena los mensajes que la tienda envía al cliente. Adobe lo clasifica como «neutralización incorrecta de elementos especiales en un motor de plantillas» (CWE-1336).
- Cómo funciona: según Sansec, es una inyección en una segunda pasada. El parche de septiembre firma las directivas de confianza de las plantillas, pero el texto que controla el atacante dentro de una plantilla secundaria acaba firmado y se vuelve a procesar en la plantilla principal. Ahí, una directiva
{{block}}colada de contrabando se ejecuta dentro del propio Magento. El arreglo de Adobe sustituye ese reprocesado genérico por marcadores registrados. - Segundo fallo en seis semanas: es el segundo agujero crítico en ese mismo motor desde septiembre. El anterior, StyleSmuggler (CVE-2026-75650), se corrigió con un hotfix el 7 de septiembre. Son arreglos distintos y hacen falta los dos: el parche de octubre no sustituye al de septiembre (identificado como VULN-39341).
- Versiones afectadas: según Adobe, todas las de septiembre de 2026 y anteriores de Adobe Commerce 2.4.4 a 2.4.9, Adobe Commerce B2B 1.3.3 a 1.5.3 y Magento Open Source 2.4.6 a 2.4.9. Sansec añade Mage-OS hasta la 3.5.0.
- Versiones corregidas: las publicaciones con la etiqueta
2026-oct(por ejemplo, 2.4.9-2026-oct) o el parche aislado de Adobe; en Mage-OS, la 3.6.0. Para Magento Open Source hay parches públicos de 2.4.7-p10, 2.4.8-p5 y 2.4.9; los de 2.4.4, 2.4.5 y 2.4.6 solo están disponibles con licencia de Adobe Commerce, así que en esas versiones la alternativa es actualizar al menos a la 2.4.7-p10. - Un parche que se cambió sobre la marcha: el 14 de octubre Adobe reemplazó el archivo del parche de la 2.4.8-p5 por otro con el mismo nombre y publicó una versión nueva,
248p5-2026-10-002-CE. Quien aplicó el del día 13 debe comprobar que el arreglo está realmente instalado. - Estado de los ataques: Adobe dice que «no tiene constancia de exploits en circulación» y le da prioridad 2, que equivale a parchear en un plazo de 30 días. Sansec escribe que no ha observado ataques aún y que actualizará su análisis cuando detecte oleadas masivas, que espera pronto.
Por qué no conviene esperar los 30 días de Adobe
Sansec discute la prioridad que le asigna Adobe con un precedente reciente: StyleSmuggler, de complejidad parecida, pasó en unos pocos días del hotfix a explotarse de forma masiva. Y añade un argumento que ya se ha repetido este mes con PHP2Shell: «cualquiera con un agente de IA puede convertir el parche en un exploit funcional en relativamente poco tiempo», según recoge BleepingComputer. Comparar el código antes y después del arreglo enseña exactamente dónde estaba el agujero, y esa tarea ya no exige semanas de trabajo de un especialista.
El segundo problema es práctico: haber actualizado no garantiza estar protegido. Sansec explica que una instalación normal con Composer sigue trayendo la versión base vulnerable si no se aplica la publicación 2026-oct o el parche aislado. Y los complementos de Composer que aplican parches pueden saltarse un fragmento sin que falle el despliegue, igual que los guiones que usan patch ... || true. Por eso recomienda comprobarlo directamente en el código de la tienda:
- ¿Está el arreglo de BlockStrap? Desde la carpeta raíz de Magento,
grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php. Si devuelve0, falta. En Mage-OS, la ruta esvendor/mage-os/framework/Filter/Template.php. - ¿Sigue el de StyleSmuggler?
vendor/bin/magento-patches -n status | grep "39341\|Status". - Ojo con las falsas alarmas en los registros: Sansec aclara que las cargas de Twig con
registerUndefinedFilterCallbackno son BlockStrap, porque Magento no usa Twig, y que las peticiones que llaman abxss.meson del escáner Acunetix.
Con dos fallos críticos seguidos en el mismo componente, una tienda Magento que se haya quedado en la versión de septiembre está, en la práctica, a la espera de que alguien publique el exploit. Para quien la administra, la tarea de esta semana es aplicar la publicación de octubre, verificar el archivo con la orden de arriba y conservar el hotfix de septiembre.
Más fuentes: Sansec, «BlockStrap: Magento and Adobe Commerce RCE (CVE-2026-103849)» (funcionamiento, versiones, Mage-OS, comprobaciones y estado de los ataques) y BleepingComputer, «Critical BlockStrap flaw lets hackers run code on Magento servers» (cita sobre los agentes de IA). Logotipo de Magento: Wikimedia Commons.
Fuente: Adobe, boletín de seguridad APSB26-153 para Adobe Commerce, 13 de octubre de 2026