Underc0de - La Casa de los Informáticos

Una nueva vulnerabilidad crítica en Magento Open Source y Adobe Commerce está siendo explotada activamente por atacantes para comprometer servidores de tiendas online sin necesidad de autenticarse. El fallo, denominado StyleSmuggler por la empresa especializada en seguridad de comercio electrónico Sansec, permite encadenar diferentes mecanismos de Magento hasta conseguir ejecución de código malicioso en el servidor y establecer una puerta trasera persistente.

La situación resulta especialmente preocupante porque, al momento de los primeros reportes, Adobe todavía no había publicado un parche, identificador CVE ni una solución oficial para corregir la vulnerabilidad. Sansec decidió hacer públicos sus hallazgos antes de lo previsto debido a que ya estaba observando ataques contra tiendas Magento en producción.

Los primeros ataques identificados comenzaron el 4 de septiembre de 2026, mientras que las investigaciones posteriores de Disrex Group aportaron evidencia independiente de compromisos reales en instalaciones de Magento Open Source.

¿Qué es la vulnerabilidad StyleSmuggler de Magento?

StyleSmuggler es el nombre utilizado por Sansec para identificar una cadena de explotación que afecta a instalaciones modernas de Magento Open Source. Según los investigadores, el ataque puede ejecutarse sin que el atacante disponga previamente de una cuenta válida en la plataforma.

Sansec consiguió reproducir la cadena de ataque en instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9, mientras que también se observó explotación contra una tienda que utilizaba la rama 2.4.6 con las actualizaciones de seguridad disponibles.

Uno de los elementos que incrementa el riesgo es que el problema no parece depender exclusivamente de utilizar una versión antigua. De acuerdo con las observaciones publicadas por Sansec y Disrex, el estado del parche no fue suficiente para evitar los ataques observados, lo que convierte a este incidente en una amenaza especialmente relevante para administradores de comercio electrónico.

No obstante, es importante diferenciar entre los productos afectados que han sido reproducidos por investigadores y aquellos cuya afectación todavía no ha sido confirmada públicamente. Sansec ha demostrado la cadena en Magento Open Source, pero no había publicado una reproducción equivalente para Adobe Commerce o Adobe Commerce Cloud.

Ejecución de código y puerta trasera persistente

Un ataque exitoso puede proporcionar al ciberdelincuente la capacidad de ejecutar código PHP en el servidor de la tienda. A partir de ahí, el atacante puede instalar un implante diseñado para mantener el acceso incluso después de determinadas acciones de limpieza.

La cadena descrita por los investigadores utiliza funcionalidades legítimas de Magento de una forma no prevista. En términos generales, primero se introduce código malicioso en un archivo que la propia plataforma puede generar, como determinados registros relacionados con informes de errores.

Posteriormente, el atacante provoca que Magento procese ese contenido mediante una funcionalidad relacionada con el envío del mensaje de "Recordatorio de Transacción Fallida de Pago". De esta manera, el código malicioso puede terminar ejecutándose durante la generación del correo electrónico, sin que sea necesario que un usuario abra el mensaje.

Este mecanismo resulta particularmente peligroso porque transforma componentes normales de una tienda Magento en piezas de una cadena de explotación.

Disrex confirma ataques contra tiendas Magento

La investigación de Sansec recibió una corroboración independiente por parte de Disrex Group, compañía especializada en alojamiento y desarrollo de Magento. La empresa informó que respondió a incidentes en dos tiendas comprometidas y detectó una tercera instalación que recibió actividad relacionada con el ataque, aunque no llegó a ser vulnerada.

Una de las tiendas utilizaba Magento Open Source 2.4.8 y contaba con Sansec Shield. La segunda utilizaba Magento 2.4.7-p2, una versión considerablemente más antigua dentro de esa rama.

Según Disrex, los dos compromisos ocurrieron durante un periodo de aproximadamente ocho horas entre la primera explotación observada por Sansec y la disponibilidad de defensas específicas contra la campaña.

La compañía destacó un aspecto importante para los comerciantes: actualizar Magento continúa siendo fundamental, pero en este incidente concreto disponer del último parche disponible no necesariamente impedía la explotación, debido a que el problema todavía no contaba con una corrección oficial del proveedor.

El malware utiliza persistencia mediante cron

Uno de los elementos encontrados durante el análisis forense fue un implante ejecutándose como usuario de la tienda y tratando de aparentar ser un proceso legítimo del kernel de Linux.

El malware fue observado utilizando nombres relacionados con kworker, aunque los investigadores señalaron diferencias importantes respecto a un proceso real del kernel. Entre ellas se encuentra que el proceso sospechoso pertenecía al usuario de la tienda en lugar de ejecutarse como root y presentaba memoria residente.

El implante también utilizaba archivos ocultos dentro del directorio del usuario y mecanismos de persistencia mediante cron, llegando a programar su ejecución aproximadamente cada cinco minutos.

Esta estrategia permite que el malware vuelva a iniciarse después de ser detenido, complicando las tareas de respuesta a incidentes. Disrex incluso observó una instalación en la que la misma entrada de cron había sido escrita repetidamente.

Posible acceso a las sesiones de Magento

La investigación de Disrex también encontró que, en uno de los compromisos, el implante no necesitaba establecer conexiones salientes evidentes para realizar determinadas actividades.

El malware tenía capacidad para interactuar con la instancia Redis utilizada por la tienda, concretamente con el puerto 6379, y acceder al almacenamiento de sesiones de Magento.

Este comportamiento es especialmente relevante desde el punto de vista de seguridad, ya que las sesiones pueden contener información sensible relacionada con usuarios y operaciones de la plataforma. Aunque Disrex indicó que no encontró evidencia de exfiltración de datos en las tiendas investigadas, el acceso al almacenamiento de sesiones justificó la invalidación de sesiones y la rotación preventiva de credenciales.

Una señal de alerta: correos electrónicos anómalos

Uno de los descubrimientos más interesantes del incidente fue que un correo electrónico generado por la propia tienda permitió detectar uno de los compromisos.

El mensaje correspondía a una notificación de transacción fallida de pago, pero presentaba variables de plantilla sin resolver y contenido anómalo. En lugar de mostrar correctamente la información de la transacción, aparecían etiquetas internas y valores inesperados.

Este tipo de comportamiento puede ser una señal temprana de explotación.

Por ello, los administradores de tiendas Magento deberían prestar especial atención a un aumento repentino o inusual de correos relacionados con transacciones fallidas, especialmente cuando contienen variables sin procesar, estructuras HTML inesperadas o información incoherente.

Naturalmente, una notificación defectuosa no significa automáticamente que exista una intrusión, pero puede justificar una investigación adicional.

¿Cómo proteger una tienda Magento frente a StyleSmuggler?

Ante la ausencia inicial de un parche oficial de Adobe, Sansec recomendó como medida temporal desactivar GraphQL en las tiendas que no utilicen su producto Shield.

Sin embargo, esta medida puede afectar a determinados tipos de instalaciones. Las tiendas tradicionales y algunas implementaciones basadas en Hyvä pueden no depender de GraphQL de la misma manera que las arquitecturas headless o progresivas.

Por ello, deshabilitar GraphQL debe evaluarse antes de aplicarse en producción.

Disrex también publicó mitigaciones no oficiales destinadas a impedir determinados caminos utilizados durante la cadena de explotación. Entre ellas se incluyen reglas para servidores web, modificaciones relacionadas con determinados escáneres de código de inyección de dependencias y endurecimiento de la configuración de PHP.

Estas medidas deben tratarse como mitigaciones temporales y no como sustitutos de un parche oficial.

Además, las reglas de servidor web pueden tener limitaciones. Disrex indicó que algunas de sus reglas bloqueaban determinados parámetros presentes en la cadena de consulta, pero que variantes transmitidas mediante cuerpos POST o JSON podían alcanzar PHP. Esto demuestra por qué bloquear únicamente patrones conocidos no constituye una solución definitiva frente a la vulnerabilidad.

Qué hacer si una tienda Magento ya fue comprometida

Si existen indicios de explotación, la respuesta debe comenzar con la preservación de evidencias. Disrex recomienda evitar reiniciar inmediatamente el servidor, ya que determinadas muestras del malware podrían encontrarse únicamente en memoria o en ubicaciones que se perderían durante el reinicio.

También resulta importante eliminar primero los mecanismos de persistencia antes de detener el proceso malicioso, debido a que el implante puede volver a generarlos.

Entre las acciones defensivas recomendadas se encuentran:

• Revisar procesos sospechosos ejecutándose bajo el usuario de la tienda.
• Buscar archivos ocultos y binarios inesperados fuera de la raíz web.
• Revisar las tareas cron asociadas a la cuenta de Magento.
• Analizar los registros de Magento y del servidor web.
• Investigar correos anómalos de transacciones fallidas.
• Invalidar todas las sesiones activas.
• Cambiar las contraseñas administrativas.
• Rotar claves API.
• Cambiar las credenciales utilizadas por proveedores de pago e integraciones.
• Revisar las credenciales almacenadas en app/etc/env.php.
• Analizar conexiones con Redis.
• Comparar hashes de archivos sospechosos con fuentes conocidas.
• Revisar procesos en ejecución y sus ejecutables.
• Conservar evidencias antes de realizar una limpieza agresiva.

En una tienda comprometida, la rotación de credenciales debe considerarse prioritaria porque no es posible asumir que las credenciales existentes continúan siendo confiables.

Los indicadores de compromiso pueden ayudar a detectar la infección

Los investigadores publicaron diferentes indicadores de compromiso relacionados con la campaña, incluyendo nombres de procesos, rutas de archivos, tareas cron, hashes de archivos, dominios e infraestructura de red.

Entre los elementos observados aparecen archivos ocultos dentro de directorios del usuario y procesos que utilizan nombres diseñados para confundirse con componentes legítimos de Linux.

Sin embargo, los indicadores de compromiso pueden cambiar rápidamente. Los atacantes pueden modificar nombres, hashes, dominios e infraestructura, por lo que una estrategia de detección no debería depender exclusivamente de una lista estática de IoC.

También es recomendable combinar los indicadores conocidos con análisis de comportamiento, revisión de logs, monitorización de procesos y comparación de archivos.

Adobe todavía debe publicar una solución oficial

Uno de los principales puntos de preocupación es la ausencia inicial de una actualización oficial específica para StyleSmuggler.

La siguiente actualización de seguridad de Adobe estaba prevista para el 8 de septiembre de 2026, aunque al momento de los primeros reportes todavía no estaba confirmado si incluiría una corrección para esta vulnerabilidad.

Los administradores de Magento deben seguir los canales oficiales de Adobe y aplicar la actualización correspondiente tan pronto como exista una solución validada.

Mientras tanto, las medidas de reducción de superficie de ataque, monitorización y respuesta ante incidentes pueden ser fundamentales para reducir el riesgo.

StyleSmuggler demuestra el riesgo de los zero-day en comercio electrónico

El caso StyleSmuggler pone de manifiesto un problema que va mucho más allá de Magento. Las plataformas de comercio electrónico concentran información de clientes, sesiones, credenciales, integraciones de pago y datos operativos, convirtiéndose en objetivos especialmente atractivos para los ciberdelincuentes.

La explotación activa de una vulnerabilidad zero-day sin autenticación reduce considerablemente la barrera de entrada para los atacantes. Cuando además existe la posibilidad de ejecutar código en el servidor e instalar mecanismos de persistencia, el incidente puede evolucionar rápidamente desde una vulnerabilidad de aplicación hasta un compromiso completo de la tienda.

Por este motivo, los administradores de Magento deberían considerar StyleSmuggler una amenaza prioritaria, vigilar cualquier comportamiento anómalo y mantenerse atentos a la publicación de una corrección oficial.

La recomendación más importante es clara: no esperar a que aparezcan síntomas evidentes de compromiso. La monitorización preventiva, el aislamiento de servicios, la correcta gestión de credenciales, el análisis de registros y la aplicación inmediata de los parches oficiales serán elementos esenciales para proteger las tiendas Magento frente a esta campaña.