PolyShell ya entró en cientos de tiendas Magento sin pedir una sola contraseña. La falla de subida de archivos de Adobe Commerce y Magento quedó registrada el martes 27 de octubre en el Catálogo de Vulnerabilidades Explotadas Conocidas (KEV, por sus siglas en inglés) de la Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA), el listado oficial de fallos usados en ataques reales.
El registro lleva el código CVE-2026-48356 y una puntuación de 9,3 sobre 10 en la base nacional de vulnerabilidades. Adobe, dueña de la plataforma, le asigna 9,6 en su propio boletín. Las agencias federales estadounidenses tienen hasta el 10 de noviembre de 2026 para aplicar la corrección: cuando CISA fija un plazo tan corto, el ataque ya dejó de ser una posibilidad teórica.
Un archivo disfrazado de imagen abre la tienda
Ninguna cuenta hace falta para explotarlo. El fallo permite subir archivos de tipo peligroso sin restricción útil: un atacante envía por la interfaz de programación de la tienda un archivo que aparenta ser una imagen de producto, el servidor lo guarda en la carpeta de medios y, en muchas configuraciones de alojamiento, ese archivo se ejecuta como código. El resultado es control remoto del servidor con los permisos del usuario que corre la tienda.
Adobe publicó la corrección en julio de 2026 dentro del boletín APSB26-73, con paquetes de seguridad para las líneas 2.4.4 a 2.4.9 de Adobe Commerce y Magento Open Source. Miles de tiendas aplazan las actualizaciones por miedo a romper la pasarela de pago o un módulo de envíos, y esa ventana es la que la campaña aprovecha desde hace más de un año.
Sansec, firma neerlandesa especializada en seguridad de comercio electrónico, contó 471 tiendas infectadas en una sola hora durante una oleada de marzo de 2026, todas alcanzadas por la ruta de PolyShell. Otras cien recibieron archivos por esa misma falla o por SessionReaper (CVE-2025-54236), otro fallo de subida corregido antes. La explotación es automatizada: un barrido localiza tiendas sin parche y el archivo entra solo, tienda por tienda.
El cargador vive en la base de datos y esquiva los escáneres
La campaña completa suma 953 tiendas infectadas desde julio de 2025, casi todas con Magento, de acuerdo con el recuento de Sansec publicado el 24 de octubre. Al entrar, los atacantes dejan un cargador: un fragmento de código en JavaScript guardado en la tabla cms_block de la base de datos, el espacio donde Magento almacena piezas de contenido como cabeceras, pies de página y anuncios promocionales. Ese bloque se muestra en las páginas de la tienda: el código malicioso llega a cada visitante sin tocar los archivos del servidor.
A los escáneres de seguridad les cuesta verlo. El servidor de los atacantes examina la huella del navegador (procesador, memoria, pantalla, zona horaria e idioma) y decide si entrega algo: al comprador real puede servirle una carga maliciosa o una redirección, y a una herramienta de análisis no le entrega nada. Una versión guarda la carga en el almacenamiento local del navegador y sigue activa en visitas posteriores aunque el dominio externo caiga.
Cinco dominios rotaron en quince meses. El más reciente, deepveindrilling.com, se registró el 6 de octubre y apareció en 83 tiendas; 60 de ellas ya habían cargado una versión anterior del código, señal de que los operadores conservan el acceso y actualizan su infraestructura. Sansec no ha recuperado todavía la carga final de esta versión; las previas apuntaron a páginas falsas de criptomonedas, una imitando la marca de la billetera Ledger. Ese historial sugiere robo de datos de pago o fraude al comprador, aunque la carga final sigue sin confirmar: un punto abierto.
Un caso puntual cambia la respuesta habitual. Ese comercio corría Magento 2.4.7-p10 sin parches pendientes y recibió el cargador nuevo el 23 de octubre, una hora tras un escaneo limpio. La revisión posterior encontró una cuenta de administrador falsa creada el 16 de septiembre y una puerta trasera instalada el 24 de septiembre. Traducción práctica: el parche cierra la puerta de PolyShell, pero no expulsa a quien ya entró por ella ni borra el código escondido en la base de datos.
Parche, revisión de bloques y cambio de contraseñas, en ese orden
La ruta de salida que plantea Sansec empieza por preservar pruebas y buscar el cargador en las tablas cms_block y cms_page, además de revisar las carpetas de subida por archivos ejecutables disfrazados de imagen. Después toca auditar las cuentas de administrador y eliminar cualquier usuario desconocido: una cuenta falsa reabre la tienda aunque todo lo demás quede limpio.
Con la casa revisada se instala el paquete de julio de Adobe y solo entonces se cambian las contraseñas de la base de datos, del panel y de las integraciones por interfaz de programación. Cambiarlas antes de limpiar regala las claves nuevas a quien siga dentro. Para una tienda pequeña de la región, revisar bloques y administradores es trabajo de una tarde; descubrir meses después que el código ajeno acompañó cada compra sale mucho más caro.
CISA sumó el mismo martes el fallo de Brotli en Node.js al catálogo, un tema distinto que afecta a servidores. Para el comercio electrónico, la prioridad lleva nombre propio: PolyShell tiene fecha oficial, el 10 de noviembre, y 953 tiendas ya demostraron que esperar al siguiente ciclo de mantenimiento es justo la decisión que la campaña necesita.
Fuente: The Hacker News
Foto: The Hacker News
