Explotación activa de PolyShell, una RCE en Magento y Adobe Commerce (CVE-2026-48356)

Resumen

• CVE-2026-48356, denominada PolyShell por el equipo de investigación de Sansec que la descubrió, es una subida de archivos sin restricciones en la API REST de Magento y Adobe Commerce: un solicitante sin autenticar puede escribir un archivo ejecutable en el servidor a través de las rutas de artículos del carrito de invitados. El registro CVE de Adobe le asigna una puntuación CVSS v3.1 de 9,3 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N).
• Todas las ramas de producción están afectadas: Adobe Commerce de 2.4.4 a 2.4.9 y Magento Open Source de 2.4.6 a 2.4.9 en sus niveles de parche anteriores a julio de 2026, además de Commerce B2B y Adobe Commerce Events. Las versiones con parches de julio de 2026 (2.4.9-2026-jul, 2.4.8-2026-jul, etc.) son la corrección para las líneas con soporte.
• Se explota a gran escala en ataques reales. Sansec registró escaneos masivos automatizados desde el 19 de marzo de 2026 y, para el 14 de abril, PHP malicioso subido al 82 por ciento de las tiendas que supervisa. Estima que 471 de las 953 tiendas de la campaña posterior del cargador fueron inyectadas mediante PolyShell. CISA añadió CVE-2026-48356 a su catálogo Known Exploited Vulnerabilities el 27 de octubre de 2026, con fecha límite federal del 10 de noviembre de 2026.
• Aplique ahora la versión con parches de julio de 2026 correspondiente a su rama. Si no puede aplicar el parche hoy, bloquee el acceso web a pub/media/custom_options/ y filtre las rutas de la API del carrito de invitados en un firewall de aplicaciones web (WAF); después busque shells subidas y la puerta trasera accesson.php con las comprobaciones que se indican más adelante.

¿Estoy afectado?

Está afectado si ejecuta Adobe Commerce, Magento Open Source, Adobe Commerce B2B o Adobe Commerce Events en una de las versiones de la siguiente tabla y su API REST (incluidas las rutas del carrito de invitados) es accesible a través de la red.

El registro CVE de Adobe y Sansec discrepan sobre la versión de disponibilidad general 2.4.9: el registro marca 2.4.9 como afectada hasta el parche de julio, mientras que Sansec informa de que la versión de disponibilidad general 2.4.9 del 12 de mayo de 2026 ya incorpora la corrección.

Sansec añade que las versiones de julio trasladan la corrección a las líneas anteriores con soporte. Verifique dónde se sitúa su compilación antes de concluir que está a salvo.

Compruebe la versión en la instancia en ejecución, no en una imagen nueva:

# From the Magento root directory
php bin/magento --version

# From the composer lock file
grep -A1 '"name": "magento/product-community-edition"' composer.lock   # Open Source
grep -A1 '"name": "magento/product-enterprise-edition"' composer.lock   # Adobe Commerce

# In a container
docker exec <container> php bin/magento --version

¿Cómo lo corrijo?

Instale la versión con parches de julio de 2026 (APSB26-73) para su rama mediante su procedimiento habitual de actualización con Composer o la línea de comandos, y verifique después que php bin/magento --version indique el nivel corregido. El boletín de Adobe es la lista oficial de versiones corregidas. Sansec atribuye las adaptaciones de julio de 2026 a APSB26-73 y la versión de disponibilidad general 2.4.9 a la corrección anterior APSB25-94 de la rama preliminar 2.4.9.

Si no puede aplicar el parche hoy, dos mitigaciones reducen el riesgo. Ambas están adaptadas del aviso de Sansec:

• Bloquee el acceso web al directorio de subidas. Para nginx, añada este bloque dentro de la configuración del servidor antes de cualquier bloque location \.php$, para que el manejador de PHP no pueda tener prioridad:

location ~* ^/pub/media/custom_options/ {
    return 403;
}

Para Apache, verifique que exista pub/media/custom_options/.htaccess y contenga:

<IfModule mod_php.c>
    php_flag engine 0
</IfModule>
Deny from all

Sansec señala que la mayoría de las tiendas utilizan la configuración personalizada del servidor web de su proveedor de alojamiento en lugar del ejemplo de Adobe. - Bloquee las rutas de la API del carrito de invitados en un WAF. Es el único control que detiene la subida en sí, ya que los bloqueos de directorio dejan abierta la ruta de escritura.

Limitaciones: bloquear el acceso no bloquea las subidas. Los atacantes aún pueden escribir archivos en disco mediante la API, y un cambio posterior de configuración, una migración o un cambio de servidor web pueden hacer que se ejecuten. Incluso en configuraciones que bloquean la ejecución de PHP en el directorio de subidas, persiste la variante de XSS (cross-site scripting) almacenado de este fallo (archivo servido como contenido), según el análisis de versiones de Sansec.

¿Cuál es la causa raíz?

La API REST de Magento escribe en disco un archivo de una solicitud de artículo del carrito sin validar la opción, el tipo de opción ni la extensión del archivo. El análisis técnico de Sansec, publicado el 17 de marzo de 2026, describe el mecanismo: cuando una opción de producto tiene el tipo file, Magento procesa un objeto file_info incrustado que contiene los datos del archivo codificados en base64, un tipo MIME y un nombre de archivo, y escribe el archivo en pub/media/custom_options/quote/ en el servidor.

Según el análisis de Sansec, faltan tres comprobaciones:

1. No se valida el ID de la opción. El ID de opción enviado nunca se comprueba frente a las opciones reales del producto.
2. No se limita el procesamiento según el tipo de opción. La lógica de subida de archivos se activa con independencia de que el producto tenga realmente una opción de tipo archivo.
3. No se restringe la extensión del archivo. Extensiones como .php, .phtml y .phar no se bloquean; la única validación es una comprobación de la cabecera de imagen (getimagesizefromstring), que un archivo políglota que sea a la vez una imagen válida y PHP ejecutable supera fácilmente.

Los endpoints más peligrosos son las rutas anónimas del carrito de invitados, que no requieren credenciales:

Las mutaciones GraphQL utilizan una ruta de código distinta y no son vulnerables, según Sansec. Adobe no ha publicado un diff oficial del parche ni un análisis de la corrección para CVE-2026-48356, por lo que aquí no puede citarse la lógica exacta del parche; la corrección se distribuyó primero en la rama preliminar 2.4.9 (APSB25-94), después en la versión de disponibilidad general 2.4.9 del 12 de mayo de 2026 y en las adaptaciones de julio de 2026 para todas las líneas con soporte.

¿Cómo se explota?

La ruta de ataque, según el análisis de payloads publicado por Sansec, va de una única solicitud sin autenticación a una puerta trasera persistente:

1. El atacante envía un POST a /V1/guest-carts/:cartId/items con un objeto file_info cuyo payload en base64 es un archivo políglota: una imagen GIF o PNG válida que también incorpora PHP ejecutable y satisface la comprobación de la cabecera de imagen.
2. El archivo se escribe bajo pub/media/custom_options/quote/, habitualmente con un nombre como index.php o con el ID de la opción como prefijo, por ejemplo 780index.php.
3. En las configuraciones que entregan al manejador de PHP los archivos .php del directorio de subidas o sus subdirectorios, el archivo subido se ejecuta como el usuario del servidor web cuando se solicita. El análisis de versiones de Sansec vincula este comportamiento con la configuración de ejemplo de nginx distribuida con Magento de 2.0.0 a 2.2.x (mediante el nombre de archivo index.php), cualquier versión de Magento con una configuración personalizada de nginx que envíe todos los .php a fastcgi, y Apache en versiones de Magento anteriores a 2.3.5 sin php_flag engine 0.
4. El payload más habitual que capturó Sansec es una web shell index.php políglota GIF89a: verifica la cookie d frente al hash incrustado a17028468cb2a870d460676d6d6da3ad63706778e3, después ejecuta PHP arbitrario mediante eval(base64_decode()) e incluye una función de subida de archivos activada por $_POST["up"]. Una segunda variante utiliza hash_equals() con el MD5 incrustado 4009d3fa8132195a2dab4dfa3affc8d2 y pasa comandos directamente a system().
5. Para mantener la persistencia, los atacantes despliegan una puerta trasera secundaria llamada accesson.php, ubicada en <top-level directory>/assets/images/accesson.php en cada directorio de nivel superior en el que puedan escribir. Sansec enumera diez rutas de este tipo en una tienda, incluidas var/assets/images/accesson.php, app/assets/images/accesson.php, vendor/assets/images/accesson.php y pub/assets/images/accesson.php. Imprime la baliza 8194460 para que el operador pueda encontrar shells activas a gran escala y, por lo demás, funciona como el primer payload.
6. Por último, los atacantes inyectan un cargador JavaScript ofuscado en páginas o bloques del sistema de gestión de contenidos (CMS), que sirve otros payloads a los navegadores de los compradores.

Los nombres de archivo de PolyShell observados en ataques reales incluyen index.php, json-shell.php, bypass.phtml, c.php, r.php, rce.php, static.php, test.php, blocked-json.php, bypass-async.php, urlencode-shell.php y xx_malicious_file.php; también se ha observado ofuscación Unicode como \u0062\u0079\u0070\u0061\u0073\u0073.\u0070\u0068\u0070 (se decodifica como bypass.php).

El alcance fue inmediato. La telemetría de Sansec muestra que, para el 23 de marzo de 2026, los ataques ya se habían dirigido contra el 23 por ciento de sus tiendas protegidas, y para el 30 de marzo, contra el 79,5 por ciento. Se había subido PHP malicioso al 56,7 por ciento de las tiendas para el 24 de marzo y al 82 por ciento para el 14 de abril. Todo esto ocurrió antes de que existiera la primera corrección de disponibilidad general.

¿Qué puede hacer un atacante?

El impacto depende de la configuración del servidor web, y ambas posibilidades son graves. Donde se ejecuta PHP, el atacante ejecuta código como el usuario del servidor web: web shells, control total de la tienda y capacidad para leer y reescribir la base de datos. Sansec observó exactamente eso en ataques reales, con web shells disfrazadas de imágenes PNG ubicadas en pub/media/custom_options/quote/ junto a un cargador en bloques del CMS. Donde la ejecución está bloqueada, el archivo subido sigue en disco (un cambio futuro de configuración puede exponerlo), y la variante de XSS almacenado puede, en su lugar, tomar el control de una sesión de administrador.

Nota sobre la puntuación: El registro CVE de Adobe asigna al problema una puntuación CVSS v3.1 de 9,3 con cambio de alcance y señala que la explotación «podría provocar la ejecución de código arbitrario en el contexto del usuario actual, y potencialmente obtener acceso elevado o control sobre la cuenta o sesión de la víctima». El vector UI:R del registro puntúa las rutas que necesitan que una víctima visite contenido manipulado; la subida mediante el carrito de invitados no requiere credenciales ni interacción del usuario.

Las condiciones que necesita el ataque:

• Una API REST accesible en una versión afectada, incluidas las rutas anónimas del carrito de invitados.
• Para ejecutar código, en lugar de limitarse a colocar archivos, una configuración del servidor web que ejecute archivos PHP desde la ruta de subidas. Sansec descubrió que muchas tiendas exponen los archivos del directorio de subidas.
• Nada más: ninguna cuenta, ninguna autenticación ni ninguna acción del usuario para el paso de subida.

¿Está verificada la corrección?

No. Adobe no ha publicado un diff oficial del parche ni un análisis de la corrección, por lo que no es posible comprobarla frente a un diff. Lo que es público: la corrección llegó primero a la rama preliminar 2.4.9 bajo APSB25-94 (14 de octubre de 2025, corregido en 2.4.9-alpha3), se distribuyó en la versión de disponibilidad general 2.4.9 el 12 de mayo de 2026 y se adaptó a todas las líneas con soporte en las versiones con parches de julio de 2026 (APSB26-73), según el aviso de Sansec y el registro CVE de Adobe.

Una corrección completa del comportamiento descrito por Sansec debe cerrar las tres brechas: validar el ID de opción enviado frente al producto, aceptar file_info solo cuando el producto declare realmente una opción de tipo archivo y restringir los nombres y extensiones de archivo que se pueden escribir.

La telemetría de Sansec alcanzó un máximo del 82 por ciento de las tiendas supervisadas con subidas maliciosas para el 14 de abril, antes de la versión de disponibilidad general del 12 de mayo y antes de que las líneas anteriores tuvieran alguna adaptación del parche. La inclusión en KEV el 27 de octubre muestra que los sistemas sin parche siguen recibiendo ataques.

¿Cómo compruebo si sufrí un compromiso?

Estas comprobaciones e indicadores están adaptados del aviso de Sansec. Ejecútelos desde el directorio raíz de Magento en cada tienda cuyo nivel de versión esté afectado o sea anterior al corregido:

# Executable files in the custom options upload directory are a strong indicator.
find pub/media/custom_options/ -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)

# Stores that never offered file-type product options: any file other than
# .htaccess is suspicious. Legitimate customer file-option uploads land under
# pub/media/custom_options/quote/ and order/, so skip this on stores that use them.
find pub/media/custom_options/ -type f ! -name '.htaccess'

# The post-exploitation backdoor, placed under assets/images/ in top-level directories.
find . -name 'accesson.php' -type f

• Cualquier archivo .php, .phtml o .phar bajo pub/media/custom_options/ es un indicador sólido de compromiso. Inspeccione también los archivos GIF y PNG que haya allí: las shells políglotas tienen una cabecera GIF89a o PNG con PHP en su interior.
• Busque los dominios del cargador de la campaña (tabla siguiente) en las páginas del CMS y los bloques estáticos (las tablas cms_block y cms_page). La investigación anterior de Sansec de la época de PolyShell también enumera jslibrary[.]net y canevaslab[.]com.
• Audite las cuentas de administrador: Sansec documentó una tienda 2.4.7-p10 totalmente actualizada cuyo único signo de compromiso era una cuenta de administrador maliciosa utilizada para inyectar el cargador. Ese caso no era PolyShell, pero forma parte de la misma campaña.
• El aviso de Sansec enumera más de 50 IP de origen observadas en escaneos de PolyShell desde marzo de 2026 para revisar los registros perimetrales.

Cronología

• 2025-07: comienza la campaña del cargador; a lo largo de ella se infectan 953 tiendas, la mayoría con Magento (Sansec, publicado en octubre de 2026).
• 2025-10-14: la actualización APSB25-94 de Adobe distribuye 2.4.9-alpha3, la versión preliminar 2.4.9 en la que Sansec afirma que apareció la corrección por primera vez (APSB25-94, Sansec).
• 2026-03-16: se observan los primeros sondeos de PolyShell a las 12:00 UTC; Sansec añade protección de Shield ese mismo día (Sansec).
• 2026-03-17: Sansec publica su advertencia pública y su análisis técnico (Sansec).
• 2026-03-19: comienza el escaneo masivo automatizado; después participan más de 50 IP de escáneres (Sansec).
• 2026-03-23: los ataques alcanzan al 23 por ciento de las tiendas protegidas por Sansec.
• 2026-03-24: se ha subido PHP malicioso al 56,7 por ciento de las tiendas (Sansec).
• 2026-03-30: los ataques alcanzan al 79,5 por ciento de las tiendas (Sansec).
• 2026-04-14: se ha subido PHP malicioso al 82 por ciento de las tiendas (Sansec).
• 2026-05-12: Adobe publica Magento 2.4.9 con la corrección; aún no hay adaptación para las líneas anteriores con soporte (Sansec).
• 2026-07-14: se publica el registro CVE de Adobe y las versiones con parches de julio de 2026 trasladan la corrección a las líneas con soporte (registro CVE, APSB26-73).
• 2026-10-06: se registra deepveindrilling[.]com; está activo el 7 de octubre y presente en los bloques del CMS de 83 tiendas para el 24 de octubre (Sansec).
• 2026-10-27: CISA añade CVE-2026-48356 al catálogo Known Exploited Vulnerabilities; fecha límite federal del 10 de noviembre de 2026 (CISA KEV).
• 2026-10-28: esta publicación.

El intervalo entre la advertencia pública y la inclusión en KEV es de 224 días, y la corrección no llegó a las líneas anteriores con soporte hasta 119 días después de la advertencia.

Preguntas frecuentes

¿PolyShell es el mismo CVE que la campaña del cargador de Sansec?

Están relacionados, pero son distintos. CVE-2026-48356 (PolyShell) es la vulnerabilidad de subida de archivos en la API REST. La campaña del cargador que sigue Sansec (953 tiendas, cinco dominios desde julio de 2025) es la operación criminal que utiliza PolyShell como uno de sus vectores de entrada: Sansec estima que se inyectaron 471 tiendas mediante PolyShell y otras 102 mediante PolyShell o el fallo anterior SessionReaper (CVE-2025-54236). En al menos una tienda se entró mediante una cuenta de administrador maliciosa.

Mi servidor web bloquea PHP en el directorio de subidas. ¿Estoy a salvo?

No del todo. Bloquear la ejecución detiene la variante de ejecución remota de código (RCE), pero la API sigue escribiendo archivos del atacante en disco, la variante de XSS almacenado de Sansec persiste en algunas configuraciones y una futura migración del servidor o un cambio de configuración pueden convertir los archivos latentes en shells activas. Aplicar el parche es la corrección completa; los bloqueos del servidor web son una medida provisional.

¿Por qué CISA no añadió a KEV hasta octubre un fallo corregido en julio?

Porque la explotación continúa y la cantidad de sistemas sin parche sigue siendo grande. El fallo fue objeto de escaneos masivos pocos días después de la divulgación de marzo, la corrección no llegó a las líneas anteriores con soporte hasta julio y Sansec aún encontraba nuevos dominios del cargador en bloques del CMS de las tiendas en octubre. La entrada KEV de CISA, fechada el 27 de octubre de 2026, establece una fecha límite federal de corrección del 10 de noviembre de 2026.

¿Necesito una regla WAF si aplico el parche?

El parche elimina la vulnerabilidad, por lo que una regla WAF es opcional después. Antes de aplicar el parche, Sansec deja claro que solo una regla WAF que bloquee la llamada vulnerable a la API detiene las subidas, porque los bloqueos de directorio dejan abierta la ruta de escritura. El aviso de Sansec también señala que, en su última actualización, Cloudflare no había publicado ninguna regla WAF que cubriera PolyShell, así que no confíe en que un WAF en la nube bloquee PolyShell hasta haber confirmado que dispone de una regla correspondiente.

¿Esto afecta a Magento Open Source o solo a Adobe Commerce?

A ambos. El registro CVE de Adobe enumera versiones afectadas de Adobe Commerce, Adobe Commerce B2B, Magento Open Source (líneas de 2.4.6 a 2.4.9) y Adobe Commerce Events, y señala las versiones con parches de julio de 2026 como corrección para cada uno.

Encuentre tiendas Adobe Commerce y Magento expuestas con Ostorlab

Ejecute un escaneo web de Ostorlab en cada tienda: identifica la versión y el nivel de parche de Adobe Commerce o Magento que ejecuta cada una y si están expuestas las rutas de subida del carrito de invitados, para que pueda confirmar que todas ejecutan una versión corregida de la tabla anterior antes de la fecha límite de KEV del 10 de noviembre.

Referencias

• Entrada KEV de CISA para CVE-2026-48356, añadida el 27 de octubre de 2026, con fecha límite del 10 de noviembre de 2026: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado el 28 de octubre de 2026)
• Registro CVE, CVSS v3.1 9,3, matriz de versiones afectadas y corregidas: https://cveawg.mitre.org/api/cve/CVE-2026-48356 (consultado el 28 de octubre de 2026)
• Boletín de seguridad de Adobe APSB26-73 (las versiones con parches de julio de 2026): https://helpx.adobe.com/security/products/magento/apsb26-73.html
• Sansec, «PolyShell: subida de archivos sin restricciones en Magento y Adobe Commerce», 17 de marzo de 2026, con actualizaciones hasta octubre de 2026 (análisis técnico, análisis de payloads, IP de escáneres, mitigación): https://sansec.io/research/magento-polyshell (consultado el 28 de octubre de 2026)
• Sansec, «deepveindrilling.com: un cargador en bloques del CMS de Magento alcanza 953 tiendas», octubre de 2026 (atribución de la campaña: 471 mediante PolyShell, 102 mediante PolyShell o SessionReaper, 83 tiendas con el dominio del cargador de octubre): https://sansec.io/research/magento-cms-block-loader-deepveindrilling (consultado el 28 de octubre de 2026)
• Sansec, «SessionReaper, RCE sin autenticación en Magento y Adobe Commerce (CVE-2025-54236)», sobre el fallo relacionado: https://sansec.io/research/sessionreaper
• The Hacker News, «Los ataques PolyShell contra Adobe Commerce comprometen cientos de tiendas mientras surge tráfico de exploits de Brotli», 28 de octubre de 2026: https://thehackernews.com/2026/10/adobe-commerce-polyshell-attacks-breach.html
• The Hacker News, «Atacantes infectan 953 tiendas en línea con JavaScript que evade escáneres, la mayoría en Magento», 26 de octubre de 2026: https://thehackernews.com/2026/10/hackers-infect-953-online-stores-with.html
• The Hacker News, «El fallo PolyShell de Magento permite subidas sin autenticación, RCE y toma de control de cuentas», 20 de marzo de 2026, actualizado el 23 de marzo con el registro de explotación activa: https://thehackernews.com/2026/03/magento-polyshell-flaw-enables.html