APSB26-92: un secuestro de cuenta en Magento que no necesita iniciar sesión
Actualización, 13 de agosto: los ataques han empezado. Sansec informa de que su firewall Shield ya está bloqueando intentos de explotar CVE-2026-71362, y BleepingComputer lo cubrió el 12 de agosto, un día después de que saliera el parche. El aviso de Adobe sigue diciendo que no tiene constancia de exploits activos, y el boletín sigue calificado como prioridad 2. Parchee ahora.
La actualización de seguridad de agosto de Adobe para Adobe Commerce y Magento Open Source llegó el 11 de agosto, como boletín APSB26-92. Siete vulnerabilidades, cinco de ellas calificadas como críticas. La que más importa es CVE-2026-71362, así que por ahí empieza esto.
Un secuestro de cuenta que no necesita una cuenta
CVE-2026-71362 puntúa 9,1. Permite a alguien hacerse con una cuenta de cliente sin iniciar sesión.
El análisis de Sansec lo llama un cambio de sesión: un atacante mueve su sesión a la cuenta de otro cliente y obtiene todo lo que hay en ella, datos personales incluidos. Sin cuenta propia, sin acceso al admin, sin nada en lo que la víctima tenga que hacer clic. La corrección de Adobe cambia cómo Magento gestiona la identidad del cliente en la sesión de cuenta.
La mayoría de los fallos de Magento necesitan algo para arrancar, ya sea un inicio de sesión en el admin o al menos una cuenta de cliente registrada. Este solo necesita una petición.
El resto del boletín son fallos de XSS almacenado y de autorización. Adobe lista el impacto global como ejecución de código arbitrario, elusión de funciones de seguridad y escalada de privilegios.
Qué hay en el boletín
| Boletín | APSB26-92 |
| Publicado | 11 de agosto de 2026 |
| Vulnerabilidades | 7, cinco calificadas como críticas |
| La más grave | CVE-2026-71362 — secuestro de cuenta sin autenticación, CVSS 9,1 |
| Otros problemas | XSS almacenado, fallos de autorización |
| Calificación de prioridad de Adobe | 2, sin cambios a fecha de 13 de agosto |
| Explotación al publicarse | Ninguna reportada por Adobe |
| Explotación ahora | Intentos bloqueados por el WAF de Sansec desde el 12 de agosto |
Todas las líneas con soporte están afectadas:
- 2.4.9-2026-jul y anteriores
- 2.4.8-2026-jul y anteriores
- 2.4.7-2026-jul y anteriores
- 2.4.6-2026-jul y anteriores
- 2.4.5-2026-jul y anteriores
- 2.4.4-2026-jul y anteriores
Esos son los niveles de parche de julio, no números de versión. Haber parcheado el mes pasado no le quita de la lista: lo mismo pasó en julio, cuando 2.4.9 apareció unos dos meses después de su publicación.
Nosotros lo trataríamos como prioridad 1
Adobe calificó el boletín como prioridad 2 y no reportó exploits conocidos al publicarlo. Escribimos esta sección el 12 de agosto para argumentar que era la decisión equivocada, y tardamos más o menos un día en averiguarlo.
El firewall de Sansec empezó a bloquear intentos de explotación contra CVE-2026-71362 el 12 de agosto. El aviso de Adobe sigue diciendo que no tiene constancia de exploits activos, y la calificación no se ha movido de prioridad 2 con su sugerencia de 30 días.
El razonamiento que expusimos entonces vale igual para el boletín del mes que viene, así que aquí está.
| Nivel | Definición de Adobe | Ventana sugerida |
|---|---|---|
| Prioridad 1 | Vulnerabilidades «being targeted, or which have a higher risk of being targeted, by exploit(s) in the wild» | En 72 horas |
| Prioridad 2 | Un producto «historically at elevated risk», pero «there are currently no known exploits» y Adobe «does not anticipate exploits are imminent» | En 30 días |
| Prioridad 3 | Un producto que «has historically not been a target for attackers» | A discreción del administrador |
La prioridad 1 no exige que nadie haya escrito un exploit todavía. La redacción cubre fallos «being targeted, or which have a higher risk of being targeted». Un secuestro de cuenta sin autenticación en Magento es un caso tan claro como puede serlo esa segunda cláusula.
La prioridad 2 depende de que Adobe no anticipe exploits inminentes. Eso es una predicción, y es la que nosotros habríamos discutido. Magento está entre las plataformas más atacadas de la web, y este fallo no necesita credenciales.
CosmicSting
CVE-2024-34102 fue un fallo XXE sin autenticación con puntuación 9,8, divulgado en junio de 2024. Adobe lo calificó como prioridad 3 al principio, el nivel para productos que nadie ataca, y después lo subió a 2.
El escaneo masivo empezó en menos de dos semanas. Sansec dijo a los comerciantes que si no habían parcheado para el 25 de junio, doce días después de la corrección, debían dar por hecho que sus claves de cifrado ya habían volado. Más de 4.000 tiendas fueron comprometidas durante los meses siguientes, a veces a un ritmo de tres a cinco por hora.
Parchee el día 30, como sugiere la prioridad 2, y le habrían vulnerado dos semanas y media antes.
En defensa de Adobe
Adobe califica un producto, no su tienda, y los niveles se apoyan en patrones históricos de ataque en toda la plataforma. Marque todo como prioridad 1 y las calificaciones dejan de significar nada.
La calificación también se fija antes de que salga el boletín, cuando «sin exploits conocidos» todavía era cierto. Siguió siendo cierto unos dos días.
Parchee este en 72 horas de todos modos. Y si su proceso de release no puede moverse tan rápido, más vale que lo descubra ahora y no durante el siguiente.
Aplicarlo: julio va primero
Los parches aislados de Adobe se apilan. Agosto se apoya en julio en lugar de sustituirlo: «August does not replace July», como dice Sam James en su artículo sobre este parche. Si se saltó APSB26-73, necesitará aplicarlo antes que este.
Hay un segundo requisito por debajo. Cualquier parche aislado necesita que esté en la última versión -p de su línea, porque es contra la que Adobe lo construyó y lo probó.
Así que las preguntas reales son:
- ¿Estamos en la última versión
-pde nuestra línea? - ¿Aplicamos el parche de julio?
- Si no, ¿hasta dónde se remonta eso, y cuánto tardará ponernos al día?
Una tienda al día puede hacerlo en una tarde. En una versión -p del otoño pasado, primero hay una actualización de nivel de parche, con las pruebas de regresión que la acompañan, y la corrección de seguridad después.
Dónde conseguir los parches
Adobe sirve los archivos de agosto desde repo.magento.com:
| Línea | Archivo de parche aislado | Descarga |
|---|---|---|
| 2.4.9 | 2-4-9-aug-2026.zip |
Directa |
| 2.4.8-p5 | 2-4-8-p5-aug-2026.zip |
Directa |
| 2.4.7-p10 | 2-4-7-p10-aug-2026.zip |
Directa |
| 2.4.6-p15 | 2-4-6-p15-aug-2026.zip |
Directa |
| 2.4.5-p17 | 2-4-5-p17-aug-2026.zip |
Requiere claves |
| 2.4.4-p18 | 2-4-4-p18-aug-2026.zip |
Requiere claves |
Los archivos de 2.4.4 y 2.4.5 están detrás de una URL autenticada. Cuando el navegador lo pida, su clave pública de Composer es el usuario y su clave privada la contraseña: el mismo par que ya está en su auth.json. Los otros cuatro se descargan sin credenciales.
La guía de Adobe para aplicar un parche de Composer cubre el resto.
Adobe los publica como archivos de parche sin ningún paquete de Composer al lado, así que no hay ningún cambio de versión que ejecutar y cada mes es un trabajo manual. Es buena parte de por qué las tiendas se quedan atrás.
Sam James mantiene un paquete comunitario, samjuk/m2-meta-security-patches, que agrupa los parches de Community Edition de 2.4.6-p15 a 2.4.9 en un composer update. Práctico, aunque pone a un tercero en medio de su parcheo de seguridad, así que léalo antes de comprometerse. Tampoco cubre 2.4.4, 2.4.5 ni las ediciones Enterprise y B2B.
Los usuarios de Mage-OS reciben este de otra forma. El contenido de agosto salió como Mage-OS 3.4.0 el 11 de agosto, el mismo día en que Adobe publicó el boletín, portando el parche aislado 249-2026-08-001-CE, así que es un cambio de versión en lugar de un archivo de parche. La misma corrección, y sigue teniendo que desplegarla.
2.4.4 y 2.4.5 siguen recibiendo parches, lo que no es una razón para quedarse en ellas. Si ejecuta una de las líneas antiguas, nuestro artículo sobre la cronología del fin de soporte de 2.4.6 cubre en qué situación le deja eso.
Qué hacer esta semana
Averigüe dónde está en realidad. Ejecute composer show magento/product-community-edition, o el equivalente de Enterprise, contra lo que está desplegado y no contra lo que dice un ticket. Los dos discrepan más a menudo de lo que pensaría.
Aplique el parche de julio si no lo ha hecho. Sin saltárselo. Si va más atrás, recórralos en orden.
Parchee staging y pruebe los flujos de cuenta. La corrección toca la identidad del cliente en la sesión: inicio de sesión, registro, edición de cuenta y cualquier código a medida que lea la sesión del cliente. También el checkout y los pagos.
Compruebe que el parche sobrevive a su próxima ejecución de Composer. Sam James encontró archivos parcheados revirtiéndose en silencio cuando magento2-base se reinstala, así que un composer install posterior puede deshacer la corrección sin decir nada. Verifíquelo después de cualquier cambio de dependencias.
Después producción, en 72 horas.
Mire sus extensiones por separado. El boletín solo cubre el código de Adobe. Un módulo de terceros sin mantener con acceso a la base de datos y al checkout es una forma habitual de que las tiendas se vean comprometidas, y nadie publica un CVE cuando ocurre.
Si no puede decir en qué nivel de parche está y cuándo aplicó el último, empiece por ahí. Mantenerse al día lleva unas horas al mes. Ponerse al día después de un año saltándoselos es un trabajo en toda regla.
Emyrix hace soporte y mantenimiento de Magento, incluida la gestión de parches y el trabajo en Adobe Commerce en tiendas que se han quedado atrás. Si no está seguro de en qué nivel de parche está su tienda, o sabe que va por detrás y quiere un plan realista para ponerse al día, escríbanos.
Fuentes: Boletín de seguridad de Adobe APSB26-92 · Security update available for Adobe Commerce — APSB26-92 · Definiciones de severidad y prioridad de Adobe · Sansec: Adobe patches critical Magento account takeover · BleepingComputer: Hackers exploit critical Adobe Commerce flaw to hijack customer accounts · Notas de versión de parches de seguridad de Adobe Commerce
Preguntas frecuentes
¿Qué es APSB26-92?
Es el boletín de seguridad de Adobe para la actualización de Adobe Commerce y Magento Open Source publicada el 11 de agosto de 2026. Adobe lo describe como la corrección de vulnerabilidades críticas e importantes, con impactos que abarcan ejecución de código arbitrario, elusión de funciones de seguridad y escalada de privilegios. El análisis de Sansec cifra el recuento en siete vulnerabilidades, cinco de ellas críticas.
¿Qué es CVE-2026-71362?
Es el fallo más grave del boletín, con puntuación 9,1. Sansec lo describe como un secuestro de cuenta de cliente sin autenticación: un atacante cambia su sesión a la cuenta de otro cliente y accede a esa cuenta y a los datos personales que contiene. No necesita una cuenta propia, ni acceso al admin, ni ninguna acción de la víctima. La corrección de Adobe cambia cómo Magento gestiona la identidad del cliente en la sesión de cuenta.
¿Se está explotando CVE-2026-71362?
Sí. Sansec dice que su firewall Shield empezó a bloquear intentos de explotación el 12 de agosto de 2026, el día después de que Adobe publicara el parche, y BleepingComputer informó de lo mismo. El aviso de Adobe sigue afirmando que no tiene constancia de exploits activos. Si su tienda está sin parchear, dé por hecho que la están sondeando.
¿Ha publicado Adobe un parche de seguimiento o un hotfix para APSB26-92?
No a fecha de 13 de agosto de 2026. Adobe no ha publicado ningún archivo de parche corregido, hotfix ni boletín revisado desde la publicación del 11 de agosto, y la calificación de prioridad 2 no ha cambiado. Los seis archivos de parche aislados publicados el 11 de agosto siguen siendo la corrección.
¿Qué versiones de Magento y Adobe Commerce están afectadas?
Todas las líneas que reciben parches actualmente. Adobe lista 2.4.9-2026-jul y anteriores, 2.4.8-2026-jul y anteriores, 2.4.7-2026-jul y anteriores, 2.4.6-2026-jul y anteriores, 2.4.5-2026-jul y anteriores y 2.4.4-2026-jul y anteriores. Haber aplicado el parche de julio no le deja fuera de ese rango.
¿Cómo de urgente es este parche?
Parchee ahora. Sansec informó el 12 de agosto de que su firewall ya bloqueaba intentos de explotar CVE-2026-71362, un día después de que saliera la corrección. Adobe calificó el boletín como prioridad 2, su nivel de 30 días, y a fecha de 13 de agosto no lo ha revisado ni ha reconocido exploits activos. Trátelo como prioridad 1 y parchee en 72 horas.
¿Tengo que aplicar el parche de julio antes que el de agosto?
Sí. Los parches aislados de Adobe se apilan en secuencia, así que el de agosto se apoya en el de julio en lugar de sustituirlo. También necesita estar en la última versión de parche solo de seguridad, la última versión -p de su línea, antes de que un parche aislado se aplique siquiera.
¿Qué es un parche de seguridad aislado?
Es el término de Adobe para un archivo de parche independiente que contiene solo correcciones de seguridad, sin actualizaciones de funciones ni otros cambios incluidos. Permiten tomar una corrección de seguridad sin pasar a una versión de parche completa, y Adobe los distribuye como zips de parche para Composer, uno por línea de versión.
