CISA marca PolyShell como explotada mientras la campaña contra Magento alcanza cientos de tiendas

Una vulnerabilidad que Adobe corrigió en julio sigue produciendo brechas en noviembre. El 27 de octubre, la Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE. UU. añadió CVE-2026-48356 a su catálogo de vulnerabilidades explotadas conocidas y dio a las agencias federales hasta el 10 de noviembre para corregirla. La falla, que la firma de seguridad Sansec llama PolyShell, es una carga de archivos sin autenticación en Adobe Commerce y Magento que puede llevar a ejecución remota de código. NVD la califica con 9,3 sobre 10.

Lectura relacionada: El zero-day «StyleSmuggler» de Adobe Commerce golpeó tiendas tres días antes del parche · El Patch Tuesday de Microsoft de octubre de 2026 marca un récord con 1.407 correcciones.

La inclusión en KEV es el reconocimiento formal de una campaña que lleva meses en marcha. Sansec dice que los atacantes han usado la falla para colocar un cargador malicioso en 953 tiendas en línea, inyectándolo a través de un bloque CMS de Magento. La compañía advirtió por primera vez de la vulnerabilidad en marzo, vio empezar el escaneo masivo en cuestión de días y ha seguido la campaña a través del parche de Adobe y su retroporte de julio. Las tiendas que no actualizaron son las que siguen en riesgo.

The Hacker News informó de que el cargador está diseñado para traer y ejecutar una carga útil controlada por el atacante, pero que no se ha recuperado malware de la siguiente etapa. Esa laguna importa. Significa que el objetivo de la campaña no se conoce públicamente. Podría ser un skimmer de pagos, un esquema de redirección, un recolector de credenciales o una capa de preparación para otra cosa. Se estima que la actividad continúa al menos desde julio de 2025.

La falla: un campo de carga que confía en el cliente

PolyShell vive en la API REST de Magento. Cuando un producto tiene una opción personalizada de tipo archivo, la API acepta un objeto de archivo incrustado con datos codificados en base64, un tipo MIME y un nombre de archivo, y luego escribe el archivo en pub/media/custom_options/quote/ del servidor. Sansec encontró tres comprobaciones ausentes:

• Sin validación del ID de opción. El ID de opción enviado nunca se verifica contra las opciones reales del producto.
• Sin control del tipo de opción. La lógica de carga se ejecuta tenga o no el producto una opción de tipo archivo.
• Sin restricción de extensión. Extensiones como .php, .phtml y .phar no se bloquean.

La única validación es una comprobación de cabecera de imagen con getimagesizefromstring, que un archivo polyglot puede superar mientras sigue conteniendo PHP ejecutable. Los endpoints más peligrosos son las rutas anónimas del carrito de invitado, POST /V1/guest-carts/:cartId/items y PUT /V1/guest-carts/:cartId/items/:itemId, que no requieren autenticación. Las mutaciones GraphQL usan una ruta de código distinta y no son vulnerables.

Que el archivo cargado pueda ejecutarse depende del servidor web. Las configuraciones estándar de nginx en algunas versiones pasan archivos .php a FastCGI, y las instalaciones de Apache sin php_flag engine 0 pueden hacer lo mismo. Sansec dice que muchas tiendas usan configuraciones personalizadas de sus proveedores de alojamiento, por eso el impacto varía. Incluso cuando la ejecución está bloqueada, el archivo permanece en el disco. Un cambio futuro de configuración, una migración o un cambio de servidor pueden volverlo peligroso.

La campaña: 953 tiendas y una puerta trasera persistente

La cronología de Sansec empieza el 16 de marzo de 2026, cuando añadió la protección PolyShell a su producto Shield. Publicó una advertencia al día siguiente. Los primeros ataques aparecieron el 19 de marzo, y el escaneo masivo automatizado comenzó el 23 de marzo. Para el 24 de marzo, Sansec dijo que el 56,7% de todas las tiendas que protegía habían recibido código PHP malicioso. Para el 30 de marzo, el 79,5% había sido atacado. Para el 14 de abril, la cifra era del 82%.

Los atacantes no se detuvieron en la carga inicial. Sansec encontró una puerta trasera secundaria llamada accesson.php esparcida por varios directorios de las tiendas comprometidas, incluidos var/assets/images/, app/assets/images/, vendor/assets/images/ y pub/assets/images/. Las copias son una estrategia de persistencia. Limpiar un directorio no elimina los demás. La puerta trasera emite una señal imprimiendo un número fijo, acepta comandos mediante un eval de PHP autenticado por cookie y puede cargar más archivos.

La capa final es JavaScript. Sansec encontró un cargador ofuscado inyectado en páginas y bloques estáticos del CMS. El cargador guarda una carga útil en el localStorage del navegador, así sobrevive a las recargas de página incluso si la fuente externa cae, y trae una carga útil nueva desde dominios como lanhd6549tdhse[.]top. Ese diseño dificulta la limpieza: eliminar la inyección del lado del servidor impide que se infecten nuevos visitantes, pero no limpia los navegadores que ya guardaron la carga útil en caché.

PolyShell permite a los atacantes cargar archivos ejecutables en cualquier tienda Magento o Adobe Commerce a través de la API REST.

Por qué un parche de julio no lo detuvo

Adobe corrigió la falla subyacente en Magento 2.4.9, publicado el 12 de mayo de 2026, y trasladó la corrección a las líneas de versión compatibles el 14 de julio mediante APSB26-73. Esa es la secuencia correcta. También es el punto en que el parcheo suele frenarse.

Las tiendas que aplicaron la actualización ya no son vulnerables a la carga. Las que no lo hicieron, sí. Las instalaciones de Magento y Adobe Commerce suelen estar personalizadas por agencias y proveedores de alojamiento, lo que hace las actualizaciones más lentas y arriesgadas que una actualización de software rutinaria. Un minorista puede retrasar un parche porque un módulo personalizado depende del código antiguo, porque la ventana de actualización es estrecha antes de un periodo de ventas o porque nadie es responsable de la tarea. El catálogo KEV está diseñado para quitar esa discrecionalidad a las agencias federales. No obliga a los minoristas privados.

El resultado es una larga cola de tiendas vulnerables que los atacantes pueden escanear automáticamente. Los datos de escaneo masivo de Sansec muestran con qué rapidez se encuentra esa cola. Las 953 tiendas de la campaña del cargador son la parte visible. El número de tiendas sondeadas pero no comprometidas es mayor, y el número que sigue sin parchear es aún mayor.

Qué deben hacer los operadores de tiendas

El primer paso es confirmar la versión de Magento o Adobe Commerce. Las tiendas en 2.4.9 o en una línea de versión con el retroporte APSB26-73 tienen la corrección. Las tiendas en versiones anteriores no.

El segundo es bloquear la ruta de carga en el servidor web. La regla de nginx de Sansec deniega todo acceso a pub/media/custom_options/ antes de cualquier bloque de ubicación .php. El equivalente en Apache es un archivo .htaccess en ese directorio con php_flag engine 0 y Deny from all. Bloquear la ejecución no detiene la carga, pero elimina la ruta más fácil a la ejecución de código mientras se aplica el parche.

El tercero es escanear en busca de compromiso. Sansec recomienda buscar archivos .php, .phtml o .phar en pub/media/custom_options/ y accesson.php en cualquier parte de la raíz del documento. Los propietarios de tiendas también deberían buscar en las páginas del CMS y los bloques estáticos referencias a los dominios del skimmer y revisar los registros del servidor en busca de peticiones a los endpoints del carrito de invitado desde fuentes inesperadas.

El cuarto es rotar credenciales. Una puerta trasera que puede cargar archivos y ejecutar código puede haberse usado para leer archivos de configuración, claves de pago o sesiones de administrador. Eliminar el archivo no es lo mismo que expulsar al atacante.

Qué vigilar

El plazo de KEV del 10 de noviembre producirá una cifra de cumplimiento de parches para las agencias federales. No producirá una para el sector minorista. La señal más útil es si Sansec y otros respondedores de incidentes reportan nuevas infecciones de cargador después del plazo. Si la campaña continúa al mismo ritmo, el problema es la base instalada. Una falla fácil de explotar y lenta de parchear sigue siendo un objetivo incluso después de que el proveedor publique una corrección.

Adobe no ha publicado una estimación de cuántas tiendas siguen sin parchear. Los porcentajes de Sansec describen su propia base de clientes protegidos, no todo el mercado. Eso limita hasta dónde se pueden generalizar las cifras, pero no cambia la dirección. Una falla fácil de explotar, automatizada para escanear y lenta de parchear es un objetivo duradero, incluso después de que el proveedor publique una corrección.

Salvedades

• 953 es un recuento de tiendas con el cargador. No es un recuento confirmado de tiendas cuyos datos de clientes fueron robados.
• No se recuperó malware de la siguiente etapa. El objetivo, la carga útil y la atribución de la campaña no están confirmados.
• Los porcentajes son cuotas de tiendas protegidas por Sansec. No son cuotas de todas las tiendas Magento o Adobe Commerce.
• El plazo federal se aplica a las agencias federales de EE. UU. Los minoristas privados no tienen un plazo legal equivalente.
• Adobe corrigió la falla en mayo y trasladó la corrección en julio. Las tiendas sin parchear siguen siendo vulnerables; las parcheadas, no.
• El estado del WAF de Cloudflare puede haber cambiado. Sansec señaló que Cloudflare no había publicado una regla específica para PolyShell cuando escribió su análisis; la compañía sí lanzó una regla de emergencia para la falla separada de Brotli.
• La cronología es la de Sansec. Adobe y CISA no han publicado una historia completa de la campaña.

La inclusión en KEV convierte una vulnerabilidad de meses en un plazo. Para las tiendas que siguen con Magento sin parchear, el escaneo nunca se detuvo.

Portada: La sede mundial de Adobe en San José, California. Fotografía de Coolcaesar, CC BY-SA 4.0, vía Wikimedia Commons, recortada a 16:9.