Para quién es: empresas que gestionan tiendas en línea con Adobe Commerce (antes Magento Commerce) o Magento Open Source, las agencias que las construyen y mantienen, y los proveedores de alojamiento. Este artículo se basa en información pública de Adobe, CISA y NVD, y en informes de una empresa de seguridad de comercio electrónico. No aborda pasos de ataque ni código de explotación.
En desarrollo: esta página se actualizará conforme se publique más información
A 28 de octubre de 2026 (hora de Japón)Aún no se sabe
- Confirmación de la explotación por parte de Adobe (el boletín sigue diciendo que no tiene constancia)
- Alertas de organismos públicos japoneses (ninguna de JPCERT/CC ni de IPA)
- Víctimas entre las tiendas de Japón (ninguna revelada)
CISA añadió el fallo a KEV el 27 de octubre. La corrección de Adobe salió el 14 de julio. Los detalles de la explotación proceden de los informes de una empresa de seguridad de comercio electrónico, que Adobe no ha confirmado. Actualizaremos este artículo cuando haya nuevos anuncios.
Qué hacer hoy
Compruebe su versión y si la corrección está aplicada
Ejecute bin/magento --version en el servidor de la tienda para comprobar la versión. La corrección de julio se distribuye como un parche aislado que se aplica sobre la última versión de seguridad de cada línea (por ejemplo, 2.4.7-p10). Para comprobar si está aplicada, use Quality Patches Tool (vendor/bin/magento-patches -n status) en entornos alojados por Adobe y, en otros entornos, la Commerce Version Tool incluida con la corrección (disponible tras aplicar el parche CE) (notas de la versión de Adobe). Si una agencia o una empresa de mantenimiento gestiona su tienda, pregúnteles por ambos puntos.
Aplique la corrección
El procedimiento de Adobe consiste en pasar primero a la última versión de seguridad (la versión -p) de su línea (2.4.9 se queda como está) y luego aplicar la corrección de julio. Los parches no son acumulativos, así que aplíquelos en orden. Si usa el módulo Adobe Commerce Events, actualícelo a 1.21.0 o posterior. Para los entornos alojados por Adobe (Adobe Commerce on cloud infrastructure), Adobe afirma que la última versión de Magento Cloud Patches corrige el problema, y advierte de que aplicar el parche aislado encima puede hacer que la instalación falle. Siga las indicaciones de Adobe.
Revise las carpetas de subida
La empresa de seguridad de comercio electrónico informa de que se colocaron web shells en pub/media/custom_options/ (en especial en la carpeta quote que contiene) y recomienda revisar también pub/media/customer_address/. Busque archivos disfrazados con nombres de imagen y archivos ejecutables como .php, .phtml o .phar. Normalmente estas carpetas contienen cosas como los archivos que los clientes adjuntan a los pedidos.
Revise los bloques CMS, las páginas CMS y las cuentas de administrador
En la base de datos, revise las tablas cms_block y cms_page en busca de etiquetas <script> que usted no haya añadido y de entradas modificadas recientemente (update_time). El informe de la misma empresa enumera las cadenas que hay que buscar. Revise admin_user en busca de cuentas que no reconozca, y el servidor en busca de procesos desconocidos en ejecución.
Si encuentra indicios, limpie y luego cambie las credenciales
Tras eliminar los archivos y scripts maliciosos, cambie las contraseñas y los tokens de las cuentas de administrador, de la base de datos y de las integraciones de API. Eliminar solo un script deja abierta la vía de regreso del atacante (una web shell o una cuenta de administrador). Si se tocó la página de pago, contacte con sus emisores de tarjetas y su proveedor de pagos.
Medidas provisionales si no puede aplicar la corrección de inmediato (no detienen el ataque)
La misma empresa recomienda configurar el servidor web para denegar el acceso web a pub/media/custom_options/ e impedir que PHP se ejecute allí. Esto impide que los archivos subidos se ejecuten desde fuera, pero no impide que se suban archivos. La empresa afirma que se necesita una regla de WAF (un sistema que inspecciona el tráfico de las aplicaciones web) para bloquear las propias solicitudes de subida. Ambas son soluciones temporales hasta que aplique la corrección.
Versiones afectadas y corregidas
| Producto | Afectado | Corrección (notación de Adobe) |
|---|---|---|
| Adobe Commerce | 2.4.9, 2.4.8-p5 y anteriores, 2.4.7-p10 y anteriores, 2.4.6-p15 y anteriores, 2.4.5-p17 y anteriores, 2.4.4-p18 y anteriores | 2026-jul para cada una de 2.4.9, 2.4.8, 2.4.7, 2.4.6, 2.4.5, 2.4.4 |
| Adobe Commerce B2B | 1.5.3, 1.5.2-p5 y anteriores, 1.4.2-p10 y anteriores, 1.3.4-p17 y anteriores, 1.3.3-p18 y anteriores | 2026-jul para cada una de 1.5.3, 1.5.2, 1.4.2, 1.3.4, 1.3.3 |
| Magento Open Source | 2.4.9, 2.4.8-p5 y anteriores, 2.4.7-p10 y anteriores, 2.4.6-p15 y anteriores | 2026-jul para cada una de 2.4.9, 2.4.8, 2.4.7, 2.4.6 |
| Adobe Commerce Events | 1.6.0 a 1.20.0 | 1.21.0 |
«2026-jul» no es un nuevo número de versión. Significa la última versión de seguridad de cada línea con el parche aislado de julio aplicado. En las notas de la versión de Adobe, los archivos del parche están separados por versión de destino, por ejemplo «2-4-7-p10-jul-2026.zip». Los usuarios de Magento Open Source solo pueden descargar directamente los parches para 2.4.6 y posteriores.
La tabla de Adobe también incluye 2.4.9 como afectada. La empresa de seguridad de comercio electrónico escribe que 2.4.9 incluía la corrección de este fallo, pero el boletín abarca 14 fallos corregidos el mismo día. Recomendamos seguir la tabla de Adobe y aplicar la corrección de julio también en 2.4.9.
El fallo que permite subir archivos (la vía de entrada)
Corregido por la corrección de julio (2026-jul)
Web shells colocadas
La corrección no las elimina. Revise las carpetas de subida
Scripts inyectados en las páginas
La corrección no los elimina. Revise cms_block y cms_page
Administradores añadidos y credenciales posiblemente expuestas
La corrección no los elimina. Revise admin_user y cambie las credenciales
Qué se ha divulgado
- CVE
- CVE-2026-48356 (boletín de seguridad de Adobe APSB26-73)
- Tipo
- Subida sin restricciones de un archivo de tipo peligroso (CWE-434). Adobe indica como impacto la escalada de privilegios y como gravedad crítica, y afirma que no se requiere autenticación
- Gravedad
- CVSS v3.1 9,6 en la tabla del boletín de Adobe (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L). 9,3 en el valor que Adobe registró en el registro CVE y en la puntuación de NVD (idéntico salvo A:N)
- Impacto (descripción del CVE)
- Ejecución de código arbitrario en el contexto del usuario actual, que podría permitir tomar el control de la cuenta o la sesión de la víctima. Indica que la explotación requiere que la víctima abra una URL manipulada o interactúe con una página comprometida
- Corrección
- Publicada el 14 de julio de 2026 (actualizada el 11 de agosto). El mismo boletín corrige 14 vulnerabilidades, y esta es la única que está en KEV. La calificación de prioridad de Adobe es 2, la intermedia de tres niveles
- Explotación (Adobe)
- Adobe afirma que no tiene constancia de explotación (según lo publicado a 28 de octubre)
- Explotación (CISA)
- Añadida a KEV el 27 de octubre de 2026. El plazo para las agencias civiles federales de EE. UU. (FCEB) es el 10 de noviembre. Uso en campañas de ransomware: «Unknown». La evaluación SSVC de CISA en NVD califica la explotación como «active»
Los dos valores CVSS solo difieren en si el impacto en la disponibilidad (A) es «bajo» o «ninguno». Ambos están en el rango de 9 sobre 10, que es crítico, y la prioridad no cambia. La descripción del CVE dice que se requiere interacción del usuario (UI:R), pero el análisis de marzo de la empresa, descrito más abajo, dice que se pueden subir archivos sin iniciar sesión. Damos más peso a la inclusión en KEV que a los detalles de la puntuación (opinión de este sitio).
El otro fallo que CISA añadió a KEV el mismo día es una vulnerabilidad en el formato de compresión Brotli (CVE-2026-111497). Las organizaciones de Japón no están obligadas por el plazo estadounidense, pero CISA anima a todas las organizaciones a priorizar la corrección de las vulnerabilidades de KEV.
Informes de ataques (investigación de una empresa de seguridad de comercio electrónico)
Lo siguiente procede de una empresa de seguridad especializada en investigar tiendas en línea comprometidas. Adobe no lo ha confirmado.
17 de marzo de 2026
La empresa divulgó un fallo de subida de archivos en Magento y Adobe Commerce y lo llamó «PolyShell». Dijo que entonces la corrección solo existía en una versión preliminar (una versión preliminar de 2.4.9)30 de marzo de 2026
La misma empresa informó de un ataque a gran escala con PolyShell en el que se comprometieron 471 tiendas en una hora (este informe no da un número CVE)14 de julio de 2026
Adobe publicó APSB26-73 con correcciones para cada línea de versiones con soporte24 de octubre de 2026
La empresa informó de que web shells colocadas a través de PolyShell (CVE-2026-48356) y de otros fallos como SessionReaper se usaron para inyectar JavaScript en páginas de tiendas, en una campaña que ha alcanzado 953 tiendas en total, en su mayoría Magento, desde julio de 202527 de octubre de 2026
CISA añadió el fallo a KEV
Según el informe del 24 de octubre, tras colocar web shells, los atacantes inyectaron JavaScript en la tabla de la base de datos cms_block (los bloques que se muestran en las páginas de la tienda). El script carga código de sitios externos que devuelve una redirección u otro código para cada visitante. Las 953 tiendas son en su mayoría tiendas Magento e incluyen tiendas comprometidas a través de otro fallo (SessionReaper, CVE-2025-54236).
El informe dice que el código inyectado también llegó a tiendas corregidas. Como ejemplo, cita una tienda en 2.4.7-p10 sin parches del núcleo pendientes. También dice que eliminar el script no elimina el acceso del atacante. El informe no deja claro si ese acceso procedía de web shells colocadas antes o de otra vía.
Si PolyShell, como lo llama esa empresa, es lo mismo que CVE-2026-48356, el ataque masivo de marzo tuvo lugar antes de que Adobe publicara en julio las correcciones para las líneas con soporte (inferencia de este sitio; Adobe no ha confirmado la explotación). Si su tienda funcionaba antes de julio, es más seguro buscar rastros desde marzo.
La situación en Japón
A 28 de octubre, JPCERT/CC e IPA no han emitido alertas sobre este fallo. Dentro de lo que hemos comprobado, ninguna tienda de Japón ha revelado estar afectada.
Si se coloca un script inyectado en una página de pago, los datos de tarjeta que introducen los compradores pueden quedar expuestos. La norma que siguen las tiendas que manejan datos de tarjetas es PCI DSS, y la explicación sobre XSS (cross-site scripting) trata cómo llegan a ejecutarse scripts maliciosos en las páginas.
La opinión de este sitio
La característica distintiva de los fallos de subida de archivos es que el daño continúa después de la corrección. Los archivos colocados y el código inyectado en las páginas permanecen si se añadieron antes de la corrección. En este caso, el fallo entró en KEV tres meses y medio después de que Adobe publicara la corrección. Las tiendas que aplicaron la corrección de julio tampoco han terminado: deben buscar indicios de intrusión anteriores a la fecha en que la aplicaron.
En Magento, los lugares que hay que revisar están en gran medida definidos: las carpetas de subida, cms_block y cms_page, y admin_user. Al pedir a una empresa de mantenimiento que lo revise, nombrar estos tres lugares y pedir los resultados ayuda a evitar omisiones. Las defensas generales contra los fallos de subida de archivos se tratan en Vulnerabilidades de subida de archivos.
Lo que aún no se sabe
| Elemento | Estado |
|---|---|
| Confirmación de la explotación por parte de Adobe | El boletín (actualizado el 11 de agosto) sigue diciendo que Adobe no tiene constancia |
| Escala de la explotación | CISA no ha publicado detalles. Las cifras proceden solo de los informes de una empresa de seguridad de comercio electrónico |
| Si PolyShell es este CVE | Según el informe de esa empresa. Adobe no menciona el nombre |
| Situación de 2.4.9 | Afectada según la tabla de Adobe. La empresa dice que 2.4.9 incluía la corrección (siga la tabla de Adobe) |
| Víctimas en Japón | Ninguna revelada |
Fuentes
Todas consultadas el 28 de octubre de 2026.
- Adobe, «Security update available for Adobe Commerce | APSB26-73» (publicado el 14 de julio de 2026, actualizado el 11 de agosto) — adobe.com
- Adobe, «Security update available for Adobe Commerce - APSB26-73» (notas de la versión, KA-37421) — experienceleague.adobe.com
- CISA, «CISA Adds Two Known Exploited Vulnerabilities to Catalog» (27 de octubre de 2026) — cisa.gov
- CISA, «Known Exploited Vulnerabilities Catalog» (datos de la versión del 27 de octubre de 2026) — cisa.gov
- NVD, «CVE-2026-48356» — nvd.nist.gov
- Informe de una empresa de seguridad de comercio electrónico (24 de octubre de 2026, incluye cómo buscar rastros de intrusión) — sansec.io
- Análisis de PolyShell de la misma empresa (publicado el 17 de marzo de 2026, incluye medidas provisionales) — sansec.io / su informe sobre el ataque masivo de marzo (30 de marzo de 2026) — sansec.io
- JPCERT/CC, lista de alertas de 2026 (en japonés) — jpcert.or.jp
Historial de actualizaciones
2026-10-28: Primera versión, basada en información pública de Adobe, CISA y NVD y en los informes de una empresa de seguridad de comercio electrónico.
Lectura recomendada
- Defenderse de este tipo de fallo: Vulnerabilidades de subida de archivos: cómo evitar web shells y RCE
- Cómo llegan a ejecutarse scripts maliciosos en las páginas: Qué es XSS (cross-site scripting)
- Decidir la prioridad: Qué CVE parchear primero: CVSS, EPSS y KEV
- Cuando se anuncia una vulnerabilidad: Guía de remediación de CVE
- Añadida a KEV el mismo día: Vulnerabilidad de Brotli CVE-2026-111497
- Términos: Qué es una puerta trasera / Qué es PCI DSS / Qué es CVSS