Magento y los CVE críticos: SessionReaper, CosmicSting y por qué parchear ya

Magento (hoy Adobe Commerce y Magento Open Source) es la plataforma de eCommerce más potente para grandes catálogos y proyectos a medida, pero también la que protagoniza las campañas de ataque más masivas y sonadas del comercio electrónico. Cada pocos años aparece una vulnerabilidad crítica que compromete miles de tiendas en cuestión de días. La última, SessionReaper, es un ejemplo de manual de por qué en Magento parchear tarde no es una opción.

En este artículo repasamos los CVE críticos recientes de Magento, cómo funcionan estas campañas automatizadas, por qué a veces parchear no basta y qué debes hacer para que tu tienda no acabe en la próxima oleada.

Por qué Magento es un objetivo recurrente

Magento concentra varios factores que lo convierten en un imán para atacantes:

• Tiendas de alto valor. Magento lo usan comercios con volúmenes de venta grandes. Más facturación significa más tarjetas circulando y más incentivo para robarlas.
• Complejidad enorme. Es una plataforma gigante, con una API REST completa, extensiones, integraciones y personalizaciones. Más código y más superficie es igual a más sitios donde puede esconderse un fallo.
• Actualizaciones costosas. Aplicar un parche en Magento no es un clic: hay que probar que no rompa la tienda personalizada. Eso hace que muchas tiendas tarden semanas en parchear… y los atacantes lo saben.
• Historial explotable. Existe un ecosistema de atacantes especializado exclusivamente en Magento, con herramientas listas para lanzar en cuanto se publica un fallo.

SessionReaper (CVE-2025-54236): la última gran campaña

SessionReaper es el nombre que los investigadores de Sansec dieron a CVE-2025-54236, una vulnerabilidad crítica (CVSS 9.1) descubierta en agosto de 2025 que afecta a todas las versiones de Adobe Commerce y Magento Open Source hasta la 2.4.9-alpha2. El fallo reside en la API REST de Commerce: una deserialización anidada mal validada que permite a un atacante no autenticado secuestrar sesiones de clientes y, en determinadas condiciones (cuando las sesiones se almacenan en ficheros), llegar hasta la ejecución remota de código con la que subir webshells y tomar el control del servidor.

La cronología es la parte más instructiva:

• Agosto 2025: se descubre el fallo. Adobe rompe su calendario habitual de parches y publica un hotfix de emergencia (VULN-32437) a principios de septiembre.
• Adobe clasificó inicialmente el problema como un simple «security feature bypass», pero los investigadores confirmaron que permitía robo de cuentas y RCE completos.
• 22 de octubre de 2025: se publica el análisis técnico de la explotación. Los ataques masivos empezaron en cuestión de días.
• Se detectaron más de 250 tiendas comprometidas en una sola noche, con más de 130.000 instalaciones afectadas a nivel mundial. Según Sansec, los ataques automatizados llegaron a golpear a más de la mitad de las tiendas Magento del planeta.

El método de ataque observado consistía en subir puertas traseras (webshells PHP como variantes de WSO o b374k) a través del endpoint /customer/address_file/upload disfrazadas de sesión, para después desencadenar la vulnerabilidad. Este patrón de «CVE crítico → publicación del exploit → ataque masivo automatizado en días» es exactamente el que describimos en nuestro artículo sobre la IA ofensiva contra tiendas online.

SessionReaper no es nuevo: la historia se repite

Lo verdaderamente revelador de SessionReaper es que encaja en un patrón que se repite en Magento cada pocos años. Estos son los grandes hitos:

CosmicSting (CVE-2024-34102), del año anterior, merece mención aparte: fue una vulnerabilidad de tipo XXE que, encadenada con otros fallos, permitía tomar el control de la tienda, y dejó un reguero de tiendas comprometidas durante meses porque muchas no parchearon a tiempo. SessionReaper, de hecho, se comparó con CosmicSting desde el primer momento por su patrón de explotación.

Por qué parchear no siempre es suficiente

Aquí está la lección más incómoda de SessionReaper. Adobe corrigió la parte de deserialización de sesión, pero los investigadores advirtieron de que la subida de ficheros sin restricción por /customer/address_file/upload seguía siendo posible, por lo que se observaron backdoors subidas incluso en instalaciones parcheadas. Traducción práctica:

• Un parche corrige un vector, no necesariamente todos. Hay que seguir los avisos oficiales y aplicar los hotfixes adicionales.
• Si te comprometieron antes de parchear, el parche no te limpia. La puerta trasera ya está dentro. Parchear cierra la entrada original, pero el atacante puede volver por el backdoor que dejó.
• Un WAF ayuda, pero es un parche temporal. Filtrar peticiones maliciosas te da margen, no te exime de aplicar la corrección real.

Qué hacer si tienes Magento (checklist de respuesta)

1. Aplica ya el parche/hotfix oficial correspondiente a tu versión. En eventos como SessionReaper, Adobe publica hotfixes de emergencia fuera de calendario: no esperes al ciclo habitual.
2. Pon un WAF por delante como medida inmediata mientras validas y aplicas el parche en tu entorno personalizado.
3. Revisa el almacenamiento de sesiones. Las sesiones basadas en ficheros fueron el vector de RCE en SessionReaper; valora Redis o base de datos, aunque teniendo en cuenta que pueden existir otros vectores.
4. Invalida todas las sesiones activas tras parchear, para expulsar a cualquier atacante que ya tuviera una sesión secuestrada.
5. Rota credenciales y claves. Contraseñas de administrador, claves de la API, integraciones y accesos al servidor.
6. Audita en busca de webshells. Busca ficheros PHP sospechosos, especialmente en pub/ y var/, y cualquier fichero con fecha de modificación reciente que no reconozcas.
7. Si hay indicios de compromiso, restaura desde una copia limpia anterior al ataque y repite el endurecimiento. Limpiar «a mano» una tienda comprometida es arriesgado.

Cómo saber si ya te han comprometido

• Ficheros PHP nuevos o modificados en pub/media/, var/ o la raíz.
• Administradores o integraciones de API que no reconoces.
• Cambios en el checkout o en las plantillas de pago (posible skimmer).
• Tráfico anómalo hacia endpoints como /rest/ o /customer/address_file/upload.
• Reportes de fraude con tarjetas usadas en tu tienda.
• Pedidos, cuentas o tareas programadas (cron) que aparecen sin explicación.

¿Cambia el riesgo entre Adobe Commerce y Magento Open Source?

Es una duda habitual. La respuesta corta: ambas comparten el mismo código base y, por tanto, las mismas vulnerabilidades críticas. SessionReaper, CosmicSting y compañía afectaron tanto a la versión de pago (Adobe Commerce) como a la gratuita (Magento Open Source). Pagar la licencia de Adobe Commerce te da funciones y soporte, pero no te vuelve inmune: sigues necesitando parchear a tiempo, monitorizar y respaldar.

La diferencia práctica está en el ritmo de los parches y en el soporte oficial, pero en ambos casos la responsabilidad de aplicar el parche en tu tienda (y de hacerlo rápido) recae en ti o en tu proveedor de hosting. Ninguna de las dos versiones se autoparchea.

El coste real de no parchear a tiempo

Cuando una tienda Magento cae en una de estas campañas, el daño va mucho más allá del susto:

• Fuga de datos de tarjetas. Un skimmer inyectado roba tarjetas durante días o semanas antes de que nadie lo note.
• Sanciones y pérdida de PCI-DSS. Una brecha con datos de pago puede acarrear multas y la pérdida de la capacidad de cobrar con tarjeta.
• Lista negra y caída de ventas. Si Google marca tu tienda como peligrosa, el tráfico se desploma.
• Coste de limpieza forense. Investigar, limpiar y reconstruir una tienda comprometida cuesta mucho más que la prevención.
• Daño reputacional. Recuperar la confianza de los clientes tras una fuga de datos es lento y caro.

Comparado con eso, el coste de un hosting gestionado con parcheo ágil y monitorización es una fracción mínima. La seguridad en Magento no es un gasto: es un seguro.

Cómo lo hacemos en Sysprovider

Con Magento, la velocidad de respuesta lo es todo: entre que se publica un exploit y llega la oleada automatizada apenas hay margen. Por eso nuestro hosting gestionado para Magento parte de un servidor endurecido, con WAF y una arquitectura preparada para aplicar parches con rapidez y sin tumbar tu tienda personalizada.

Sobre esa base, SysSecure 360 aporta lo que estas campañas exigen:

• NOC con monitorización 24/7 y gestión de CVEs: seguimos los boletines de Adobe y los avisos de la comunidad, y reaccionamos ante hotfixes de emergencia como el de SessionReaper.
• Copias verificadas y Disaster Recovery: para restaurar una tienda limpia si hubo compromiso, sin improvisar.
• Compliance (PCI-DSS, RGPD, NIS2 y ENS): especialmente relevante cuando manejas pagos, como es el caso en Magento.

Y si quieres una visión más amplia de las amenazas de tu plataforma, tienes nuestra guía de seguridad en PrestaShop y Magento, complementaria a este artículo y al de vulnerabilidades de PrestaShop.

Preguntas frecuentes

¿SessionReaper afecta a mi tienda si ya la parcheé?

El parche de Adobe corrige el vector de deserialización de sesión, pero los investigadores advirtieron de que la subida de ficheros por el endpoint vulnerable seguía siendo posible, y se vieron backdoors incluso en tiendas parcheadas. Aplica todos los hotfixes, revisa que no haya webshells y considera un WAF. Y si te comprometieron antes de parchear, el parche no limpia: hay que revisar y restaurar.

¿Es seguro seguir con Magento?

Sí, siempre que asumas que es una plataforma que exige mantenimiento profesional. Magento es la mejor opción para grandes catálogos y proyectos complejos, pero no es «monta y olvida». Con parcheo ágil, monitorización y backups, es perfectamente segura.

¿Cada cuánto salen vulnerabilidades críticas en Magento?

No hay un calendario fijo, pero el historial muestra una gran campaña de explotación masiva cada uno o dos años, además de los boletines de seguridad periódicos de Adobe. Lo prudente es asumir que habrá otra y estar preparado para reaccionar en horas.

Conclusión

La historia de Magento demuestra que las grandes campañas de ataque no son un accidente puntual, sino un patrón previsible: cada cierto tiempo aparece un fallo crítico y, en días, hay explotación masiva automatizada. Las tiendas que sobreviven no son las que tienen suerte, sino las que parchean rápido, monitorizan de forma continua y pueden restaurar desde copias limpias.

Si tu Magento factura lo suficiente como para no poder permitirte un parón —o una fuga de tarjetas—, deja la seguridad en manos de un equipo que vigila estas amenazas a diario. En Sysprovider te ayudamos a blindar tu tienda antes de la próxima SessionReaper. Hablemos.