PolyShell en el catálogo de CISA: la falla de Magento que ya infectó cientos de tiendas tiene plazo al 10 de noviembre, tres días antes del Buen Fin

Si tu tienda en línea corre en Magento, el calendario se acaba de apretar. Este martes 27 de octubre de 2026, la agencia de ciberseguridad de Estados Unidos (CISA) agregó CVE-2026-48356, la falla conocida como PolyShell, a su catálogo de vulnerabilidades explotadas conocidas (KEV). La describe como una carga de archivos de tipo peligroso sin restricción en Adobe Commerce y Magento, y da a sus dependencias federales hasta el martes 10 de noviembre para corregirla. El Buen Fin 2026 arranca el 13.

El catálogo KEV no obliga a empresas mexicanas, pero CISA solo incluye fallas con explotación comprobada. Y en este caso hay evidencia de sobra: un día antes, el 26 de octubre, la firma Sansec, especializada en seguridad de comercio electrónico, publicó el análisis de una campaña que lleva 953 tiendas infectadas desde julio de 2025, la mayoría en Magento. Según Sansec, en marzo esa misma banda infectó 471 tiendas en una hora usando PolyShell.

No es la misma falla que StyleSmuggler (CVE-2026-75650), la de calificación 10 que contamos en septiembre. Son dos puertas distintas, y quien solo cerró una sigue expuesto.

Cómo funciona PolyShell

Sansec la reveló el 17 de marzo de 2026. El problema está en la API REST del carrito de compras para invitados: las rutas que agregan o modifican productos del carrito aceptan un archivo codificado en base64 y lo escriben en la carpeta pub/media/custom_options/quote/. La única revisión es que el archivo empiece como imagen. Un archivo políglota, que es imagen y código PHP al mismo tiempo, la pasa. Las mutaciones de GraphQL usan otro camino y no están afectadas.

Que el archivo se ejecute depende del servidor web: Sansec señala como vulnerables ciertas configuraciones de nginx que mandan cualquier .php a PHP y Apache sin la regla que apaga PHP en esa carpeta. Hay un desacuerdo que conviene conocer: el registro oficial del CVE, con calificación 9.3 (CVSS 3.1), dice que la explotación requiere interacción del usuario; Sansec la describe como explotable sin autenticación, y los ataques de marzo fueron automatizados.

Sansec usa de forma inconsistente "todas las tiendas" y "tiendas protegidas" al dar sus porcentajes; tómalos como orden de magnitud, no como censo.

Qué versiones corrigen

Según el boletín APSB26-73 de Adobe, publicado el 14 de julio de 2026 (lo consultamos a través del resumen de Meetanshi, porque la página de Adobe no respondió), estas son las versiones afectadas y las que corrigen:

Dos detalles. Primero, Sansec dice que 2.4.9 ya venía corregida, pero Adobe la lista como afectada en ese boletín (que corrige otras cuatro fallas críticas), así que no te quedes en 2.4.9 a secas. Segundo, cuando salió APSB26-73, Adobe lo marcó con prioridad 2, sin explotación reportada; la entrada al KEV cambia esa lectura. Si en septiembre aplicaste el hotfix de StyleSmuggler, confirma de todos modos que tu versión base sea la -2026-jul o posterior.

La campaña que la usó: código que se esconde de los escáneres

Lo que Sansec describe, según la nota de Security Affairs del 26 de octubre, explica por qué muchos dueños de tienda no se enteran:

• El código vive en la base de datos, no en los archivos. Los atacantes insertan un cargador pequeño en los bloques CMS (la tabla cms_block), no en el tema ni en la configuración. Revisar los archivos del servidor no lo encuentra.
• Distingue clientes de escáneres. El navegador del visitante consulta al servidor de los atacantes, que decide si es un comprador real o una herramienta de seguridad. A los escáneres no les muestra nada. La versión más reciente detecta herramientas de automatización como Selenium y ChromeDriver, y revisa tarjeta gráfica, pantalla, zona horaria e idioma.
• Persiste aunque caiga el dominio. Guarda una carga (fpCode) que vuelve a ejecutarse en visitas posteriores.
• Cambia de dominio cada pocos meses. El más reciente, deepveindrilling.com, se registró el 6 de octubre de 2026, apareció en tiendas el 7 y ya estaba en 83; el 23 de octubre los operadores reescribieron sus cargadores y sumaron 9 tiendas más.

Sansec todavía no captura la carga final que reciben los compradores reales. Campañas así suelen terminar en robo de datos de pago o en redirecciones a fraudes; en etapas previas esta misma banda sirvió scripts con temática de criptomonedas. Para una tienda mexicana, eso se traduce en clientes defraudados en plena temporada alta y en una conversación difícil con tu pasarela de pago.

Qué hacer antes del 10 de noviembre

1. Confirma tu versión exacta. En el panel de administración aparece al pie; en el servidor, bin/magento --version. Si no termina en -2026-jul o algo posterior, programa la actualización esta semana, en una copia primero.
2. Cierra la carpeta de PolyShell mientras actualizas. En nginx, un bloque que niegue todo acceso a pub/media/custom_options/, antes de cualquier bloque que mande archivos a PHP. En Apache, confirma que exista el .htaccess de esa carpeta que apaga PHP y niega el acceso. Sansec advierte que esto no impide que suban archivos: solo un firewall de aplicaciones web que bloquee la llamada a la API lo hace.
3. Busca lo que ya pudieron dejar. Archivos .php, .phtml o .phar dentro de pub/media/custom_options/, y accesson.php en cualquier parte del sitio. En la base de datos, busca en cms_block y cms_page las cadenas fpCode, se_referrer y dominios en base64.
4. Revisa cuentas y puertas traseras. Cuentas de administrador que nadie reconoce, procesos extraños en el servidor y la otra falla que Sansec ve en tiendas infectadas, SessionReaper (CVE-2025-54236), que se corrige con APSB25-88.
5. Si encuentras algo, limpia completo. Quitar el script no basta: hay que cerrar la falla o la puerta trasera por donde entraron y, al final, cambiar contraseñas de la base de datos, del administrador y de las integraciones por API (tu ERP conectado a la tienda, la paquetería, el PAC).
6. Prueba la tienda ya parchada. Antes del 13 de noviembre, corre una prueba de carga sobre la versión nueva y repasa nuestro checklist técnico del Buen Fin.

Si tu tienda está en WooCommerce, el aviso no es para ti, pero la revisión sí: en septiembre vimos un complemento que dejaba subir webshells.

Contexto

Esta nota se basa en la alerta de CISA del 27 de octubre de 2026 y su catálogo Known Exploited Vulnerabilities (fecha límite: 10 de noviembre de 2026); el aviso de Sansec sobre PolyShell (17 de marzo de 2026, con actualizaciones hasta julio); la nota de Security Affairs del 26 de octubre de 2026 sobre el análisis de Sansec de la campaña de 953 tiendas; el registro público de CVE-2026-48356 (publicado el 14 de julio de 2026), y el resumen de Meetanshi del boletín APSB26-73 de Adobe. Las cifras de tiendas son de Sansec y no tienen verificación independiente. En e-commerce y ciberseguridad hacemos la actualización, la limpieza y la revisión de la tienda antes de la temporada alta.