SessionReaper en Magento (CVE-2025-54236): qué es, quién está afectado y cómo parchearlo ya

https://www.youtube.com/watch?v=75UT-dCoXVY

SessionReaper ya no es un riesgo teórico: está explotada activamente

⚠ Actualización crítica de septiembre de 2026: corregir SessionReaper no basta para considerar segura una instalación. Adobe exige aplicar cuanto antes el hotfix VULN-39341 de APSB26-146 y completar además APSB26-138 por la ruta correspondiente: en Adobe Commerce Cloud hay que comprobar primero cloud-patches y no duplicar una corrección ya instalada; en on-premises y en las ramas de Magento Open Source para las que Adobe sí publica archivo, se utiliza la actualización aislada de septiembre compatible de APSB26-138. Ambas medidas son necesarias. La FAQ operativa de Adobe para APSB26-138 confirma expresamente que VULN-39341 puede aplicarse antes o después del parche aislado de septiembre. CVE-2026-75650 está explotada activamente y, tras el hotfix, deben rotarse la clave de cifrado y todas las credenciales que pudieran haber quedado expuestas.

SessionReaper es el nombre utilizado por la comunidad de seguridad para referirse a CVE-2025-54236, una vulnerabilidad crítica que afecta a Adobe Commerce y Magento Open Source. El problema se encuentra en la validación de los datos procesados por la API REST y permite que un atacante sin autenticar eluda controles de seguridad y llegue a secuestrar sesiones de clientes.

Adobe publicó el boletín APSB25-88 el 9 de septiembre de 2025. La vulnerabilidad recibió una puntuación CVSS 3.1 de 9,1 sobre 10, con vector de red, baja complejidad, sin credenciales y sin interacción de la víctima. Aunque en los primeros avisos se indicaba que no había constancia de ataques, esa información quedó obsoleta pocas semanas después.

El 22 de octubre de 2025, Adobe modificó el boletín para reconocer que CVE-2025-54236 estaba siendo explotada en la práctica. Dos días después elevó la actualización a prioridad 1. El 24 de octubre de 2025, la vulnerabilidad también fue incorporada al catálogo de vulnerabilidades conocidas y explotadas de CISA, con una fecha límite de remediación del 14 de noviembre de 2025 para las organizaciones federales estadounidenses sujetas a la directiva correspondiente. Estos datos pueden comprobarse en el catálogo KEV de CISA y en la ficha de CVE-2025-54236 en NVD.

Por tanto, a fecha de actualización de esta guía, el 23 de septiembre de 2026, no es correcto presentar SessionReaper como una amenaza hipotética ni seguir preguntándose si existe explotación activa. La respuesta es clara: la explotación está confirmada oficialmente. Una instalación afectada que no haya aplicado una corrección debe tratarse como una incidencia prioritaria, y una tienda que permaneció expuesta durante la campaña de ataques necesita algo más que instalar un parche: también requiere una revisión de compromiso.

Resumen rápido: qué debes hacer si administras una tienda Magento

• Aplica las dos remediaciones de septiembre de 2026: aplica cuanto antes VULN-39341 de APSB26-146 y resuelve APSB26-138 según el entorno. En Cloud verifica primero cloud-patches; en on-premises y ramas Open Source con archivo publicado utiliza el parche aislado compatible. El hotfix puede ir antes o después del aislado y la rotación se realiza después del hotfix.
• Respeta los prerrequisitos de APSB26-138: antes del parche aislado de septiembre debes estar en el último nivel -p compatible de la rama y haber aplicado todos los parches mensuales aislados anteriores en orden de publicación. Dentro de cada mes respeta la secuencia de Adobe: en Community Edition aplica CE; en Enterprise Edition aplica CE y después EE; y, si existe B2B, aplica su archivo compatible después de CE/EE. No todos los ZIP incluyen archivos para todos los componentes; usa únicamente los presentes que coincidan con las versiones instaladas.
• Si utilizas Adobe Commerce Cloud, comprueba primero cloud-patches: la actualización más reciente puede contener ya la corrección de APSB26-138. No superpongas el parche aislado si la corrección ya está instalada mediante cloud-patches, porque Adobe advierte que puede causar fallos. En on-premises sigue la cadena de parches aislados aplicable. En Magento Open Source úsala solo para 2.4.7, 2.4.8 y 2.4.9; Adobe no publica un aislado de septiembre para Open Source 2.4.6.
• Identifica la versión exacta de Adobe Commerce o Magento Open Source, incluidos los sufijos de seguridad -pN.
• No apliques automáticamente el antiguo hotfix a cualquier rama. La tabla de solución de APSB25-88 presenta el hotfix como compatible con las versiones 2.4.4 a 2.4.7; sin embargo, la guía operativa actual de Adobe también incluye 2.4.8, 2.4.8-p1 y 2.4.8-p2 y permite aplicar VULN-32437 o actualizar. Para 2.4.8 se prefiere instalar el parche de seguridad más reciente compatible.
• Si utilizas 2.4.8, instala como mínimo una versión que incorpore la corrección, es decir, 2.4.8-p3 o posterior. La recomendación general de Adobe es utilizar el parche de seguridad más reciente disponible para la rama.
• Si utilizas una versión antigua corregida en octubre de 2025, no te quedes en aquella primera revisión si existe otra más reciente y compatible.
• Si tienes Adobe Commerce B2B, actualiza también la extensión a una versión de seguridad compatible con el núcleo instalado.
• Revisa extensiones propias y de terceros que expongan servicios REST, porque la corrección endurece la validación de parámetros de constructores.
• Utiliza el WAF como una capa adicional, no como sustituto de la actualización.
• Si la tienda estuvo expuesta después de conocerse la explotación, revisa sesiones, archivos, usuarios administrativos, integraciones y registros antes de considerar cerrado el incidente.

Adobe mantiene una relación actualizada de versiones y recomienda instalar el parche de seguridad más reciente de cada línea en su página de versiones publicadas de Adobe Commerce.

Qué es exactamente CVE-2025-54236

El impacto confirmado por Adobe

Adobe clasifica CVE-2025-54236 como un problema de validación inadecuada de entradas, identificado como CWE-20. El impacto descrito oficialmente es un bypass de funciones de seguridad capaz de permitir el secuestro de sesiones o cuentas de clientes a través de la API REST de Commerce. No requiere autenticación, privilegios administrativos ni interacción del usuario.

Este matiz es importante: el impacto oficialmente documentado por Adobe es el secuestro de sesión mediante la API REST. No conviene ampliar esa afirmación a GraphQL, SOAP u otros componentes sin disponer de documentación específica que demuestre que utilizan el mismo camino vulnerable.

Por qué la validación de constructores es relevante

La API web de Magento transforma los datos recibidos en las peticiones en objetos PHP que después son entregados a servicios y extensiones. La corrección introducida por Adobe restringe qué clases pueden construirse a partir del contenido de una petición REST. La documentación actual admite tipos simples y determinadas interfaces de datos, pero no permite que modelos, servicios u otros tipos complejos se instancien libremente desde el cuerpo de una petición.

Adobe explica el nuevo comportamiento y los patrones que deben revisar los desarrolladores en su documentación sobre validación de parámetros de constructores en servicios Web API. Esto significa que el parche no solo debe probarse contra el escaparate y el checkout: también hay que validar integraciones REST, módulos personalizados y extensiones que acepten objetos anidados.

RCE: una conclusión de investigación, no el impacto oficial del boletín

La empresa de seguridad especializada en comercio electrónico Sansec investigó SessionReaper y afirmó haber reproducido una cadena capaz de lograr ejecución remota de código sin autenticación bajo determinadas condiciones. Su análisis relaciona el ataque con una sesión maliciosa y una deserialización anidada a través de la API REST. Sansec indica además que el vector concreto de RCE que pudo reproducir parecía requerir sesiones almacenadas en archivos.

Esta parte debe atribuirse correctamente: Adobe no describe RCE como el impacto oficial de APSB25-88. La posibilidad de ejecución de código procede de la investigación técnica de Sansec sobre SessionReaper. Usar Redis o base de datos para las sesiones puede impedir la cadena concreta vinculada al almacenamiento en archivos, pero no convierte una versión afectada en segura ni elimina el riesgo oficial de secuestro de sesión.

Versiones afectadas cuando se publicó APSB25-88

El boletín de Adobe identificó como afectadas las siguientes versiones disponibles en septiembre de 2025:

• Adobe Commerce: 2.4.9-alpha2 y anteriores, 2.4.8-p2 y anteriores, 2.4.7-p7 y anteriores, 2.4.6-p12 y anteriores, 2.4.5-p14 y anteriores y 2.4.4-p15 y anteriores.
• Magento Open Source: 2.4.9-alpha2 y anteriores, 2.4.8-p2 y anteriores, 2.4.7-p7 y anteriores, 2.4.6-p12 y anteriores y 2.4.5-p14 y anteriores.
• Adobe Commerce B2B: 1.5.3-alpha2 y anteriores, 1.5.2-p2 y anteriores, 1.4.2-p7 y anteriores, 1.3.4-p14 y anteriores y 1.3.3-p15 y anteriores.

Esta lista sirve para saber qué instalaciones estaban expuestas en el momento de la publicación, pero no debe utilizarse como una guía actual de versiones recomendadas. Desde entonces Adobe ha publicado varias revisiones de seguridad y una versión estable 2.4.9. La decisión correcta en 2026 no consiste en instalar únicamente “el primer parche que arregló SessionReaper”, sino en actualizar a la revisión de seguridad más reciente que admita el proyecto.

Qué versión corregida corresponde a cada rama

Ramas que incorporaron la corrección en octubre de 2025

Adobe integró la solución de CVE-2025-54236 en las revisiones de seguridad publicadas el 14 de octubre de 2025. Las primeras versiones completas que incorporaron la corrección fueron:

Rama	Primera revisión con la corrección integrada	Recomendación actual
2.4.8	2.4.8-p3	Actualizar al último parche disponible de 2.4.8 o valorar 2.4.9.
2.4.7	2.4.7-p8	Actualizar al último parche disponible de 2.4.7.
2.4.6	2.4.6-p13	Actualizar al último parche compatible y planificar la migración a una rama con soporte adecuado.
2.4.5	2.4.5-p15	La rama está en provisión limitada de correcciones; conviene planificar una actualización mayor.
2.4.4	2.4.4-p16	Usar la última revisión disponible si se dispone del soporte correspondiente y preparar la migración.

Las notas oficiales confirman expresamente la inclusión de la corrección en 2.4.8-p3, 2.4.7-p8, 2.4.6-p13 y 2.4.5-p15. Las fechas de todas las revisiones pueden contrastarse en el historial oficial de versiones.

Qué hacer si estás en 2.4.8

La tabla de solución de APSB25-88 presenta el hotfix como compatible con Adobe Commerce y Magento Open Source entre 2.4.4 y 2.4.7. La guía operativa actual de Adobe también incluye 2.4.8, 2.4.8-p1 y 2.4.8-p2 entre las versiones para las que indica aplicar VULN-32437 o actualizar al último parche de seguridad. Para la rama 2.4.8, la opción preferente es actualizar al parche más reciente compatible; la corrección está integrada desde 2.4.8-p3 y la revisión vigente indicada por Adobe debe comprobarse antes del despliegue.

A fecha de esta revisión, la relación oficial de versiones muestra 2.4.8-p5 como el parche publicado más reciente de esa rama. Si sigues en 2.4.8-p2 o una versión anterior, la opción razonable es probar y desplegar el parche más reciente disponible, no detenerte necesariamente en p3.

Importante: 2.4.8-p5 incorpora la corrección de SessionReaper, pero no representa por sí sola el nivel de seguridad vigente en septiembre de 2026. Para esa rama, Adobe exige tanto la actualización aislada 2.4.8-2026-sep de APSB26-138 como el hotfix VULN-39341 de APSB26-146, sin un orden obligatorio entre ambos. La rotación de secretos se realiza después del hotfix.

Qué hacer si estás en 2.4.9

La versión afectada citada en APSB25-88 era una compilación preliminar, 2.4.9-alpha2. Adobe publicó la versión estable 2.4.9 el 12 de mayo de 2026, y su documentación de desarrollo indica que 2.4.9 y las versiones anteriores soportadas han recibido la validación de constructores. Si utilizas una alfa antigua, debes abandonarla y migrar a una versión estable y soportada.

Qué hacer con Adobe Commerce B2B

Actualizar el núcleo de Adobe Commerce no basta cuando la extensión B2B está instalada. Adobe exige instalar también la revisión de seguridad B2B compatible. La primera revisión de la línea moderna que incorporó las correcciones del boletín APSB25-94 fue B2B 1.5.2-p3, publicada el 14 de octubre de 2025 y asociada a Commerce 2.4.8-p3, 2.4.7-p8 y 2.4.6-p13. Para instalaciones antiguas de 2.4.4, la línea 1.3.3 recibió la revisión 1.3.3-p16.

La compatibilidad entre B2B y el núcleo no debe deducirse por el parecido de los números. Comprueba la matriz en las notas oficiales de Adobe Commerce B2B antes de ejecutar Composer.

Alertas adicionales de septiembre de 2026: APSB26-138 y CVE-2026-75650

Adobe publicó APSB26-138 el 8 de septiembre de 2026 para corregir vulnerabilidades críticas, importantes y moderadas capaces de causar ejecución de código arbitrario, elusión de funciones de seguridad y elevación de privilegios. La remediación consiste en instalar la actualización aislada 2.4.x-2026-sep que corresponda al producto y la rama. Adobe Commerce dispone de revisiones para 2.4.4 a 2.4.9; Adobe Commerce B2B tiene sus revisiones 1.x-2026-sep compatibles; y Magento Open Source dispone de 2.4.7-2026-sep, 2.4.8-2026-sep y 2.4.9-2026-sep. Magento Open Source 2.4.6 figura como afectado, pero Adobe no publica para esa rama un archivo aislado 2.4.6-2026-sep en la tabla oficial: no debe sustituirse por el paquete de Adobe Commerce ni extrapolarse su instalación. Ese entorno debe migrarse a una rama Open Source con parche aislado documentado o seguir una ruta de remediación oficial específica antes de intervenir. El boletín indica que el hotfix de APSB26-146 debe aplicarse además de estas actualizaciones. La FAQ operativa oficial confirma que VULN-39341 puede aplicarse antes o después del parche aislado; dado que CVE-2026-75650 está explotándose activamente, el hotfix debe aplicarse cuanto antes.

Prerrequisitos del parche aislado: Adobe exige estar en el último parche de seguridad -p compatible de la rama y haber aplicado previamente todos los parches aislados mensuales anteriores en orden de publicación. El ZIP puede contener archivos diferentes para CE, EE, B2B, Page Builder y otros componentes. Para cada mes, Community Edition aplica el archivo CE; Enterprise Edition aplica primero CE y después EE; y B2B se aplica después de CE/EE. No todos los ZIP incluyen un archivo para cada componente: utiliza solo los archivos presentes cuya versión coincida exactamente con la instalada.

Bifurcación por despliegue: en Adobe Commerce Cloud, actualiza y comprueba primero cloud-patches; si esa actualización ya incorpora APSB26-138, no apliques además el parche aislado porque la duplicación puede provocar fallos de instalación. En Adobe Commerce on-premises y Magento Open Source, utiliza los parches aislados y sus prerrequisitos. Esta excepción no elimina la obligación separada de aplicar VULN-39341.

Adobe publicó el boletín APSB26-146 el 7 de septiembre de 2026 y ya confirmó que CVE-2026-75650 estaba siendo explotada activamente. La guía operativa consultada fue actualizada posteriormente, el 21 de septiembre de 2026. Esta vulnerabilidad puede permitir ejecución de código arbitrario sin autenticación y es independiente de CVE-2025-54236.

La lista oficial distingue los productos: afecta a Adobe Commerce de las ramas 2.4.4 a 2.4.9 y a Magento Open Source de las ramas 2.4.6 a 2.4.9, con distintas revisiones y compilaciones, entre ellas 2.4.8-p5. Una versión que ya solucionó SessionReaper puede seguir necesitando esta remediación adicional.

• Aplica cuanto antes el paquete VULN-39341 asignado por Adobe a tu versión exacta, debido a la explotación activa de CVE-2026-75650.
• Determina el método de despliegue de APSB26-138: en Cloud comprueba y actualiza cloud-patches antes de descargar parches aislados; en on-premises u Open Source prepara la cadena de archivos aislados. Si cloud-patches ya contiene la corrección, no la dupliques con el parche aislado.
• Para APSB26-138, actualiza primero al último nivel -p compatible de la rama y aplica los parches aislados mensuales anteriores en orden de publicación.
• Instala después los archivos de septiembre que correspondan, respetando la secuencia mensual: CE para Community Edition; CE → EE para Enterprise Edition; y CE → EE → B2B cuando B2B esté instalado. No todos los ZIP contienen todos los componentes; no apliques por semejanza un archivo ausente o destinado a otra versión.
• VULN-39341 puede aplicarse antes o después de esa cadena de parches aislados, según confirma Adobe; la rotación de secretos debe hacerse después del hotfix.
• Comprueba que el parche figura como aplicado antes de continuar.
• Después del parche, rota la clave de cifrado, contraseñas administrativas, tokens REST/SOAP/GraphQL, secretos OAuth, credenciales de pasarelas de pago, base de datos, CDN, despliegue y servicios integrados que pudieran estar expuestos.
• No confundas esta rotación obligatoria con la recomendación contextual de SessionReaper: son incidentes y procedimientos distintos.

Consulta siempre la tabla oficial de parches APSB26-146 antes de intervenir en producción.

Cómo comprobar si tu instalación sigue expuesta

1. Identifica el producto y la versión exacta

Desde la raíz del proyecto puedes consultar la versión con:

bin/magento --version

También conviene revisar los paquetes instalados:

composer show magento/product-community-edition
composer show magento/product-enterprise-edition
composer show magento/extension-b2b
composer show magento/out-of-process-custom-attributes

No des por corregida una tienda porque alguien haya escrito “Magento 2.4.7” en un documento interno. Necesitas conocer el sufijo completo, por ejemplo 2.4.7-p7 o 2.4.7-p10, y comprobar si existen parches aislados aplicados.

2. Revisa el módulo Custom Attributes Serializable

La base de conocimiento de Adobe proporciona instrucciones específicas para el módulo magento/out-of-process-custom-attributes. Si el módulo no está instalado, se puede omitir ese paso concreto. Si está presente, hay que comprobar su versión y seguir las instrucciones actuales de Adobe antes de aplicar el resto de la remediación. No asumas que actualizar únicamente el núcleo modifica todos los componentes desacoplados.

3. Comprueba dónde se almacenan las sesiones

Revisa la configuración de app/etc/env.php y localiza la sección session. Un valor basado en archivos es especialmente relevante porque Sansec asoció a ese almacenamiento la cadena concreta de RCE que pudo reproducir. Sin embargo, Redis o base de datos no eliminan el riesgo de secuestro de sesión reconocido por Adobe.

La elección del backend de sesiones debe hacerse por arquitectura, rendimiento, disponibilidad y seguridad, no como sustitución improvisada del parche. Si necesitas revisar la infraestructura donde se aloja la tienda, esta guía sobre cómo elegir un hosting explica aspectos como copias de seguridad, soporte, aislamiento y escalabilidad.

4. Revisa servicios REST personalizados

Busca módulos propios o de terceros que declaren servicios en webapi.xml. Hay que prestar atención a interfaces que acepten objetos complejos, modelos o clases de servicio como parámetros. Después de actualizar, esas integraciones pueden devolver errores porque el framework ya no instancia tipos no admitidos desde el cuerpo REST.

Plan seguro para desplegar la corrección

Antes del cambio

• Documenta la versión del núcleo, B2B y módulos desacoplados.
• Guarda una copia de composer.json, composer.lock, app/etc, la base de datos y los archivos de medios.
• Verifica que la copia pueda restaurarse; una copia no probada no es un plan de recuperación.
• Congela cambios de catálogo, código y configuración durante la ventana de mantenimiento cuando sea posible.
• Replica producción en un entorno de staging que utilice las mismas versiones de PHP, base de datos, buscador, cola y caché.
• Prepara pruebas para login, creación de cuenta, recuperación de contraseña, carrito, checkout, pagos, envíos, administración e integraciones REST.

Elección de la remediación

Para el estado de seguridad vigente el 23 de septiembre de 2026, no basta con elegir el último parche acumulativo de la rama. Deben completarse tanto el parche aislado de septiembre compatible de APSB26-138 como el hotfix VULN-39341 de APSB26-146. Adobe confirma que el hotfix puede aplicarse antes o después del parche aislado, pero VULN-39341 debe priorizarse por la explotación activa; la rotación de credenciales se realiza después del hotfix.

En Adobe Commerce Cloud, comprueba primero la versión de cloud-patches y verifica si ya incorpora APSB26-138; si es así, no superpongas el parche aislado. En on-premises y Magento Open Source, verifica el último nivel -p de la rama y completa los parches mensuales aislados previos en orden. Después aplica, para cada mes, CE en Community Edition, CE seguido de EE en Enterprise Edition y B2B después de CE/EE cuando esté instalado. Como no todos los ZIP incluyen todos los componentes, usa solo los archivos presentes que coincidan con las versiones exactas y comprueba el resultado con Commerce Version Tool.

La opción preferente es instalar la última revisión de seguridad disponible y compatible. La tabla de solución de APSB25-88 presenta VULN-32437-2-4-X para las ramas 2.4.4 a 2.4.7, mientras que la guía operativa actual de Adobe incluye también 2.4.8, 2.4.8-p1 y 2.4.8-p2 y permite aplicar el hotfix o actualizar. En 2.4.8 debe priorizarse el parche acumulativo más reciente compatible; no se debe extrapolar ninguna instrucción a 2.4.9 sin comprobar la documentación vigente de esa rama.

La guía operativa de Adobe sobre la actualización crítica APSB25-88 contiene el enlace al hotfix y las condiciones relacionadas con el módulo de atributos personalizados. Esa misma página conserva una frase antigua que afirma que Adobe no tenía pruebas de explotación. Para conocer el estado actual de la amenaza debe prevalecer el boletín APSB25-88, revisado posteriormente para confirmar ataques reales.

Durante el despliegue

1. Activa el modo de mantenimiento conforme al procedimiento habitual de tu proyecto.
2. Instala la revisión del núcleo o el hotfix que corresponda exactamente a la rama.
3. Actualiza B2B y los módulos independientes cuando sea necesario.
4. Ejecuta los comandos de actualización, compilación y despliegue de contenido estático que correspondan al modo de producción de la tienda.
5. Limpia las cachés controladamente y verifica que los servicios dependientes siguen disponibles.
6. Revisa var/log, los registros del servidor web, PHP-FPM, la cola, el buscador y la plataforma cloud.

Pruebas funcionales posteriores

No basta con que la página de inicio responda. Debes comprobar, como mínimo:

• Inicio y cierre de sesión de clientes.
• Creación de cuenta y recuperación de contraseña.
• Direcciones de facturación y envío.
• Carrito, cupones, impuestos y checkout.
• Pasarelas de pago en modo de prueba o con una operación controlada.
• Pedidos desde administración.
• Procesos cron y consumidores de colas.
• Integraciones ERP, PIM, CRM, marketplaces y logística.
• Servicios REST personalizados, especialmente los que reciben objetos anidados.

Si una extensión falla después de la actualización, no desactives la validación de seguridad para recuperar compatibilidad. Adapta la interfaz del servicio a los tipos permitidos o solicita una versión corregida al proveedor.

El papel del WAF: útil, pero insuficiente por sí solo

Adobe desplegó reglas de firewall de aplicaciones web para clientes de Adobe Commerce en infraestructura Cloud. Estas reglas proporcionan una capa de mitigación mientras se actualiza la plataforma, pero Adobe sigue exigiendo aplicar la remediación. Un WAF puede bloquear peticiones que coincidan con patrones conocidos, pero no corrige el código vulnerable, puede sufrir evasiones y no protege necesariamente todas las rutas o configuraciones personalizadas.

En instalaciones autogestionadas, la protección perimetral debe formar parte de una estrategia más amplia: actualización del núcleo, mínimo privilegio, monitorización, copias verificadas y revisión de integridad. Puedes ampliar esta parte con la guía sobre cortafuegos para proteger sistemas informáticos y la explicación de cómo funciona un servidor proxy y un proxy inverso.

Qué revisar si la tienda estuvo expuesta

Parchear no elimina una intrusión anterior

Instalar la corrección evita que la misma vulnerabilidad siga utilizándose, pero no borra puertas traseras, usuarios, tokens o tareas programadas creadas antes del parche. Si la tienda permaneció vulnerable después del inicio de los ataques en octubre de 2025, debe someterse a una revisión de compromiso.

Archivos y directorios

• Compara el núcleo y las dependencias con artefactos limpios obtenidos de los repositorios oficiales.
• Busca archivos PHP nuevos o modificados en directorios que normalmente almacenan medios, contenido estático, sesiones, cachés o errores.
• Revisa especialmente las rutas que permitan escritura al usuario del servidor web.
• No te limites a buscar nombres conocidos: los atacantes pueden cambiar el nombre y ofuscar el contenido.
• Comprueba permisos excesivos y archivos ejecutables dentro de directorios de subida.

Sansec publicó indicadores observados durante las campañas, incluidos objetos serializados sospechosos y puertas traseras PHP. Esos indicadores son útiles para iniciar una investigación, pero no demuestran por sí solos que un sistema esté limpio si no aparecen.

Cuentas, sesiones e integraciones

• Revisa clientes con cambios de correo, dirección o contraseña no explicados.
• Audita usuarios administrativos, roles y permisos.
• Busca integraciones API desconocidas o tokens creados fuera de los procedimientos habituales.
• Invalida sesiones activas si existe sospecha de secuestro.
• Restablece las credenciales afectadas y fuerza cambios de contraseña cuando la investigación lo justifique.

Claves de cifrado

La rotación de la clave criptográfica no es un paso rutinario que deba ejecutarse sin planificación cada vez que se instala SessionReaper. Sansec la recomienda cuando se han encontrado puertas traseras o existen indicios de que el secreto pudo quedar expuesto. En ese escenario, la rotación debe acompañarse del restablecimiento de credenciales administrativas, la revocación de integraciones desconocidas y la eliminación completa de la persistencia.

Esta indicación se refiere únicamente a la respuesta a SessionReaper. Para CVE-2026-75650, Adobe exige aplicar primero el hotfix y después rotar la clave de cifrado y todas las credenciales potencialmente expuestas. Rotar solo la clave no invalida secretos que un atacante ya hubiera obtenido.

Registros y tráfico

• Analiza solicitudes REST anómalas, cuerpos muy grandes y objetos profundamente anidados.
• Busca subidas inesperadas a formularios o controladores accesibles sin autenticación.
• Revisa respuestas 4xx y 5xx, picos de actividad y conexiones salientes del servidor.
• Correlaciona registros del WAF, CDN, balanceador, servidor web, PHP y aplicación.
• Comprueba cron, procesos persistentes y cambios en la configuración del sistema.

Para entender cómo encajan estas medidas dentro de una estrategia más amplia, puedes consultar la introducción a los fundamentos de la seguridad informática.

Errores que debes evitar

• Presentar 2.4.8-p5 o cualquier versión corregida para SessionReaper como segura por sí sola en septiembre de 2026. También se necesita la actualización 2.4.x-2026-sep de APSB26-138, el hotfix de APSB26-146 y la rotación de secretos.
• Seguir afirmando que no existe explotación activa. Adobe confirmó ataques el 22 de octubre de 2025 y CISA añadió la vulnerabilidad a KEV dos días después.
• Interpretar una sola tabla sin revisar la guía operativa vigente. APSB25-88 muestra el hotfix para 2.4.4-2.4.7, pero la guía operativa también contempla 2.4.8, 2.4.8-p1 y 2.4.8-p2. En 2.4.8 debe priorizarse la actualización al parche de seguridad más reciente compatible; la corrección está integrada desde 2.4.8-p3.
• Actualizar solo el núcleo cuando utilizas B2B. La extensión tiene sus propias revisiones y compatibilidades.
• Confiar únicamente en el WAF. Es defensa en profundidad, no una reparación del software.
• Asumir que Redis elimina el riesgo. Puede romper una cadena concreta de RCE, pero no corrige el secuestro de sesión.
• Dar por limpia una tienda porque ahora está parcheada. Una intrusión anterior puede seguir activa.
• Desactivar controles para recuperar una integración antigua. Las extensiones incompatibles deben corregirse.
• Modificar producción sin staging ni copia verificada. Los cambios de validación pueden afectar a APIs personalizadas.

Preguntas frecuentes sobre SessionReaper Magento

¿SessionReaper sigue siendo importante en 2026?

Sí. Aunque la corrección se publicó en 2025, se trata de una vulnerabilidad explotada y registrada en el catálogo KEV de CISA. Las tiendas antiguas, restauradas desde copias vulnerables o que nunca completaron la actualización siguen necesitando revisión.

¿Existe explotación activa confirmada?

Sí. Adobe reconoció explotación en la práctica el 22 de octubre de 2025. CISA añadió CVE-2025-54236 a su catálogo de vulnerabilidades conocidas y explotadas el 24 de octubre de 2025.

¿El hotfix VULN-32437 sirve para Magento 2.4.8?

La tabla de solución del boletín APSB25-88 presenta el hotfix para las versiones 2.4.4 a 2.4.7. La guía operativa actual de Adobe incluye además 2.4.8, 2.4.8-p1 y 2.4.8-p2 y permite aplicar VULN-32437 o actualizar. Para 2.4.8, la opción preferente es instalar el parche de seguridad más reciente compatible; la corrección está integrada desde 2.4.8-p3.

¿Magento Open Source 2.4.9 está afectado?

El boletín original incluía 2.4.9-alpha2 y versiones anteriores. La versión estable 2.4.9 fue publicada posteriormente, en mayo de 2026, y la documentación de Adobe indica que incorpora la validación de constructores. No utilices versiones alfa antiguas en producción.

¿Usar Redis para las sesiones es suficiente?

No. Sansec relacionó la cadena concreta de RCE reproducida con sesiones en archivos, pero Adobe confirma un riesgo de secuestro de sesión en las versiones afectadas. Redis no sustituye la actualización.

¿Debo rotar la clave criptográfica?

No como paso automático e indiscriminado. Debe valorarse si hay indicadores de intrusión, puertas traseras o posible exposición de secretos. Si se rota por compromiso, también hay que revocar accesos persistentes, cambiar credenciales y limpiar el sistema.

¿Actualizar a 2.4.8-p5 resuelve todas las alertas actuales?

No. Esa revisión corrige SessionReaper, pero el estado vigente exige el parche aislado de septiembre compatible de APSB26-138 y el hotfix VULN-39341 de APSB26-146. Adobe confirma que el hotfix puede ir antes o después del parche aislado; VULN-39341 debe priorizarse y la rotación de claves y credenciales se realiza después del hotfix. Para APSB26-138, 2.4.8 debe estar en 2.4.8-p5 y tener aplicados en orden los parches mensuales aislados previos.

¿Cómo sé que el parche funciona?

Comprueba la versión instalada, revisa la documentación de la rama, valida los paquetes de Composer y ejecuta pruebas funcionales y de integración. Las herramientas que identifican vulnerabilidades solo por el número de versión pueden seguir alertando si se instaló un hotfix aislado, por lo que conviene conservar evidencias del parche aplicado.

Conclusión: actualizar, verificar y buscar persistencia

SessionReaper Magento no debe tratarse como una alerta antigua ya superada. CVE-2025-54236 es crítica, no necesita autenticación, fue explotada activamente y afecta a un componente expuesto de muchas tiendas: la API REST.

Estado actual: una instalación puede estar corregida frente a SessionReaper y seguir pendiente de APSB26-138 o CVE-2026-75650. La evaluación debe comprobar el entorno antes de prescribir APSB26-138: en Cloud valida cloud-patches; en on-premises verifica el nivel -p, la cadena mensual y los archivos por componente; y en Magento Open Source confirma que la rama dispone de parche publicado, porque 2.4.6 no tiene aislado de septiembre. Además debe comprobar VULN-39341; Adobe permite aplicar el hotfix antes o después del aislado y la rotación se verifica después del hotfix.

La estrategia correcta tiene tres partes. Primero, instalar la última revisión segura y compatible, sin aplicar un hotfix fuera de las ramas documentadas. Segundo, probar las integraciones REST y actualizar B2B y los módulos desacoplados. Tercero, investigar una posible intrusión si la tienda estuvo expuesta durante la campaña de explotación.

Un WAF, Redis o un cambio de permisos pueden añadir capas defensivas, pero ninguno sustituye el parche. Y el parche, por sí solo, tampoco demuestra que una tienda no fuera comprometida antes. En una plataforma de comercio electrónico, cerrar bien el incidente implica corregir el código, verificar el funcionamiento y revisar cualquier mecanismo de persistencia.

Transparencia comercial: el siguiente enlace es de afiliado. Si necesitas revisar una alternativa de alojamiento gestionado para un proyecto web, puedes consultar los planes de hosting de Raiola Networks. Una contratación desde ese enlace puede generar una comisión sin coste adicional para ti. El alojamiento gestionado puede facilitar soporte y copias de seguridad, pero no sustituye la administración de seguridad específica que requiere Adobe Commerce.