Por Canuto  

Una vulnerabilidad sin parche en Magento Open Source y Adobe Commerce permite ejecutar código de forma remota, instalar puertas traseras y comprometer tiendas sin credenciales.
***

  • Sansec detectó explotación activa de StyleSmuggler desde el 4 de septiembre de 2026.
  • La cadena de ataque utiliza archivos escritos por Magento y la plantilla de recordatorio de pagos fallidos.
  • Deshabilitar GraphQL, endurecer PHP y revisar registros son medidas provisionales mientras Adobe prepara una respuesta.

Una falla crítica sin respuesta del proveedor

La vulnerabilidad StyleSmuggler afecta a Magento Open Source y Adobe Commerce, dos plataformas ampliamente utilizadas para operar tiendas en línea, y permite ejecutar código arbitrario en el servidor sin autenticación. El problema no se limita a la exposición de información: un atacante puede aprovecharlo para instalar una puerta trasera persistente y mantener acceso al entorno comprometido, según la información publicada sobre los incidentes observados.

La empresa neerlandesa de seguridad para comercio electrónico Sansec descubrió la falla y difundió una alerta temprana el 5 de septiembre de 2026, después de observar que varias tiendas estaban siendo comprometidas en tiempo real. Al 7 de septiembre, Adobe todavía no había publicado un identificador CVE, un boletín específico, un parche ni una solución alternativa oficial para StyleSmuggler.

La ausencia de un CVE y de una puntuación CVSS dificulta comparar formalmente el riesgo con otras vulnerabilidades, aunque la explotación sin credenciales ofrece una señal de gravedad por sí misma. El índice de boletines de seguridad de Adobe tampoco mostraba, para esa fecha, una comunicación posterior a las actualizaciones de finales de agosto de 2026, por lo que los administradores enfrentaban una ventana de incertidumbre mientras los ataques continuaban.

Los detalles técnicos disponibles siguen siendo parciales porque Sansec no ha divulgado la cadena completa de explotación. Sin embargo, la información publicada describe una ruta que combina archivos generados por la propia plataforma, plantillas de correo electrónico y componentes internos de Magento, una combinación que puede convertir funciones normales de operación en puntos de entrada para código malicioso.

Cómo funciona StyleSmuggler

La cadena de ataque comienza cuando el agresor consigue que Magento escriba código PHP dentro de un archivo controlado por la aplicación, como un informe de errores o un registro del sistema. Esta primera etapa no requiere ingresar al panel de administración, de modo que el atacante solo necesita interactuar con la aplicación pública de la tienda para preparar el contenido que luego será ejecutado.

En la segunda etapa, el agresor activa la función integrada de Magento denominada Payment Transaction Failed Reminder, utilizada para enviar recordatorios relacionados con transacciones de pago fallidas. Mientras la plataforma procesa y renderiza la plantilla del correo, ejecuta el código que había sido introducido previamente en el archivo de informe o registro, incluso si el mensaje nunca llega a un destinatario.

El ataque tampoco depende de que el envío de correo termine correctamente, según los reportes disponibles, porque la ejecución ocurre durante el procesamiento interno de la plantilla. Esa característica reduce la visibilidad del incidente: una tienda puede sufrir la ejecución remota de código sin que exista un correo entregado, abierto o identificado por un empleado como sospechoso.

El código desplegado intenta utilizar seis funciones de PHP en secuencia para iniciar un proceso, descargar una carga binaria y poner en marcha el implante. La técnica aprovecha clases del escáner de código de inyección de dependencias de Magento y rutas diseñadas para el compilador de inyección de dependencias de línea de comandos, que terminan incorporando una ruta de archivo controlada por el atacante.

Puerta trasera y alcance del compromiso

El binario observado está escrito en Rust, enlazado de forma estática y despojado de información innecesaria, con un tamaño aproximado de 1,9 MB en sus compilaciones para arquitecturas x86-64 y arm64. Para ocultarse, adopta nombres que parecen corresponder a hilos del kernel de Linux, una maniobra que puede dificultar la revisión manual de los procesos activos en un servidor de comercio electrónico.

El implante instala una tarea de cron para reiniciarse cada cinco minutos y escribe directamente en el archivo de spool de cron. Al evitar la ruta normal de reemplazo del crontab y su registro asociado, la amenaza intenta reducir los rastros visibles para las herramientas y procedimientos habituales de administración del sistema.

Los reportes públicos también señalan que la puerta trasera puede leer el almacenamiento de sesiones de Magento a través de la instancia Redis de la tienda. El acceso a esas sesiones podría ampliar el impacto de una intrusión, aunque la información disponible no establece el alcance de cada caso ni confirma que todas las instalaciones comprometidas hayan sufrido el mismo nivel de extracción de datos.

En al menos un incidente observado, el implante permaneció activo sin establecer conexiones salientes con un servidor de comando y control. Esa ausencia no demuestra que el entorno esté seguro, porque el malware puede operar de forma local, esperar instrucciones por otros mecanismos o formar parte de una cadena de ataque cuya infraestructura todavía no ha sido identificada.

Explotación activa y versiones afectadas

Sansec observó explotación activa desde el 4 de septiembre de 2026 y publicó su aviso al día siguiente debido a que las tiendas estaban siendo atacadas en tiempo real. La evidencia independiente de respuesta a incidentes aportada por Disrex Group, una empresa de alojamiento especializada en Magento, confirmó compromisos en al menos dos tiendas que utilizaban Magento Open Source.

Ambas tiendas fueron vulneradas dentro de una ventana de ocho horas entre el primer ataque observado y la disponibilidad de medidas defensivas. El dato muestra la velocidad con la que una falla sin parche puede pasar de una alerta técnica a un incidente operativo, especialmente cuando los administradores no cuentan con instrucciones oficiales ni con una regla de detección validada por el proveedor.

Sansec reprodujo la cadena completa sin autenticación en instalaciones limpias de Magento Open Source pertenecientes a varias líneas de lanzamiento. Una víctima confirmada utilizaba el nivel de parche más reciente disponible y había aplicado las actualizaciones de seguridad correspondientes a julio y agosto de 2026, lo que indica que mantener la plataforma actualizada no bastaba para eliminar el riesgo de este zero-day.

Las versiones confirmadas como afectadas incluyen Magento Open Source 2.4.7, 2.4.8 y 2.4.9, todas sin parche disponible al 7 de septiembre. Adobe Commerce y Adobe Commerce on Cloud todavía no habían sido confirmados de manera específica por Adobe o Sansec, pero los defensores deben tratar sus despliegues como potencialmente vulnerables hasta que exista una aclaración oficial.

Medidas provisionales para los administradores

La principal recomendación provisional consiste en deshabilitar GraphQL en las tiendas afectadas hasta que Adobe publique una corrección. Esta decisión puede interrumpir escaparates headless y aplicaciones web progresivas que dependen de GraphQL, mientras que los escaparates clásicos de Magento y Hyva generalmente no requieren esa interfaz para funcionar.

Los administradores también pueden reducir la exposición con controles a nivel de servidor, aunque ninguna de estas medidas sustituye un parche del proveedor. Incorporar proc_open a la directiva disable_functions de PHP bloquea el método preferido por el dropper para iniciar el implante, mientras que montar /tmp, /var/tmp y /dev/shm con la opción noexec impide ejecutar binarios descargados desde esos directorios.

En GitHub aparecieron varias mitigaciones comunitarias no oficiales, incluidos cambios de código destinados a impedir que los métodos del escáner de inyección de dependencias se ejecuten fuera de la línea de comandos. Sansec y Adobe no han revisado ni respaldado esas propuestas, por lo que cada administrador debe probarlas cuidadosamente y evaluar el riesgo de aplicarlas en producción durante una respuesta activa.

La revisión de indicadores debe comenzar en var/report/ y var/log/system.log, donde conviene buscar contenido inesperado, marcadores inyectados o código PHP inusual. También es necesario revisar procesos con nombres parecidos a hilos del kernel, como aquellos entre corchetes, cuando pertenecen al usuario de la tienda y no a root, además de inspeccionar los archivos de spool de cron en busca de rutas ocultas dentro del directorio de inicio.

Qué hacer si la tienda muestra señales de intrusión

Las ráfagas inesperadas de correos Payment Transaction Failed Reminder pueden servir como una señal adicional, sobre todo cuando incluyen variables de plantilla sin resolver o totales de monto cero. Ese comportamiento no confirma por sí solo una intrusión, pero adquiere relevancia cuando coincide con archivos modificados, procesos extraños o entradas nuevas en cron, porque puede reflejar intentos de activar la segunda etapa de la explotación.

Cuando se detectan indicadores de compromiso, la respuesta debe incluir la purga del almacenamiento de sesiones y la rotación de la clave de cifrado de Magento, ubicada en crypt/key dentro de app/etc/env.php. También deben restablecerse las contraseñas de administrador, las claves de API de proveedores de pago y las credenciales de integración, ya que una puerta trasera persistente puede haber expuesto secretos utilizados por otros sistemas.

La rotación de credenciales debe acompañarse con una revisión del alcance de la intrusión y con la preservación de registros para el análisis forense. El simple reemplazo de un archivo sospechoso puede dejar activo el mecanismo de persistencia, especialmente si el atacante creó una tarea de cron, descargó un binario en un directorio oculto o aprovechó sesiones que todavía permanecen válidas.

La próxima actualización de seguridad programada por Adobe estaba prevista para el 8 de septiembre de 2026, aunque no se sabía si incluiría una solución para StyleSmuggler. Hasta que el proveedor publique instrucciones definitivas, los operadores deben vigilar sus boletines de seguridad y la alerta de Sansec, además de priorizar las tiendas expuestas directamente a internet.

Una amenaza que exige vigilancia continua

La campaña observada utilizó múltiples direcciones IP de origen, entre ellas infraestructura de alojamiento y grupos de proxies residenciales. Esa diversidad sugiere que los incidentes no se concentran en una sola dirección de atacante, aunque hasta el 7 de septiembre no se había publicado una atribución a un actor de amenazas específico.

CISA tampoco había incorporado StyleSmuggler a su catálogo de Vulnerabilidades Explotadas Conocidas, conocido como KEV, y la falta de un CVE podía retrasar la catalogación formal. La ausencia en ese listado no debe interpretarse como una señal de bajo riesgo, porque la explotación activa ya había sido observada por investigadores y equipos de respuesta a incidentes.

Las organizaciones que administran varias tiendas deberían identificar los despliegues de Magento y Adobe Commerce expuestos a internet, así como las tecnologías relacionadas, los escaparates públicos y los servidores que comparten credenciales o almacenamiento de sesiones. Esa revisión permite ordenar la respuesta por nivel de exposición, en vez de esperar a que cada tienda revele señales visibles de compromiso.

StyleSmuggler demuestra que una función aparentemente rutinaria, como el envío de recordatorios de pago, puede convertirse en una vía para ejecutar código cuando interactúa con componentes internos de una plataforma compleja. Mientras Adobe no publique una corrección, la combinación de mitigaciones, monitoreo de procesos y registros, rotación de secretos y vigilancia de nuevos avisos representa la defensa disponible para reducir el riesgo.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados