PolyShell la explotación masiva que amenaza Magento y Adobe Commerce y cómo proteger tu tienda online ahora

Los operadores de tiendas en línea que usan Magento Open Source y Adobe Commerce versión 2 se enfrentan a una amenaza real y extendida: en las últimas semanas se ha observado una explotación masiva de una vulnerabilidad crítica conocida en la comunidad como «PolyShell». Según el equipo de investigación de seguridad de eCommerce Sansec, los ataques pasaron de ser pruebas puntuales a una campaña activa en cuestión de días después de que se hiciera pública la falla, y hoy afectan a una porción significativa de las tiendas vulnerables.

PolyShell aprovecha una debilidad en la API REST de Magento que permite la subida de archivos dentro de las opciones personalizadas del carrito. Ese canal de carga puede aceptar archivos "poliglotas" —archivos diseñados para ser interpretables de distintas formas por el servidor y el navegador— lo que en determinadas configuraciones del servidor permite ejecutar código de forma remota o inyectar scripts persistentes (stored XSS) que faciliten la toma de cuentas o la inyección de malware en las páginas de pago. Los investigadores de Sansec han detallado la técnica y mantienen un análisis público sobre cómo ocurren estos ataques: análisis técnico de Sansec.

La escala del problema es preocupante: Sansec indica que la explotación masiva comenzó alrededor del 19 de marzo y, desde entonces, han identificado actividad maliciosa en más de la mitad de las tiendas que aún son vulnerables. La firma además ha publicado indicadores de compromiso y una lista de direcciones IP usadas por los atacantes para escanear sitios en busca de puertas de entrada, información útil para los equipos de respuesta y los proveedores de seguridad que quieran bloquear tráfico sospechoso o detectar intentos de intrusión.

Adobe reaccionó liberando un parche en una versión beta del producto (la rama 2.4.9-beta1) el 10 de marzo de 2026, pero esa corrección todavía no estaba disponible en la versión estable al momento de los reportes, lo que deja a muchas instalaciones en producción sin una solución oficial inmediata. Adobe documentó los cambios y las notas de la versión en su portal de Experience League: notas de la versión 2.4.9-beta1. Mientras tanto, investigadores y periodistas han intentado obtener clarificaciones sobre el calendario de despliegue del parche en las ramas de producción.

Lo que complica aún más el panorama es la naturaleza del malware que algunos atacantes están instalando tras explotar PolyShell. Sansec ha encontrado un skimmer para tarjetas de pago que emplea Web Real-Time Communication (WebRTC) como canal para extraer datos. Usar WebRTC permite a los atacantes transmitir información por DTLS sobre UDP en lugar de por HTTP, lo que dificulta que controles basados en políticas de contenido (CSP) detecten o bloqueen la exfiltración. El cargador malicioso es un JavaScript muy ligero que establece una conexión con un servidor de mando y control (C2) usando un intercambio SDP falsificado, recibe una segunda etapa cifrada y la ejecuta en el contexto de la página. Para aumentar sus probabilidades de evadir detecciones, el componente retrasa su ejecución con técnicas como requestIdleCallback y reutiliza nonces de scripts legítimos o recurre a técnicas más arriesgadas como unsafe-eval o la inyección directa de scripts cuando es necesario.

Sansec incluso documentó la presencia de este skimmer en la tienda online de una gran compañía automovilística, con un valor de mercado de más de 100.000 millones de dólares, y alerta de que algunas notificaciones a las víctimas pueden no haber recibido respuesta. El informe de Sansec con el despiece técnico del skimmer y las direcciones IP implicadas está disponible aquí: WebRTC skimmer — Sansec.

¿Qué pueden hacer los responsables de tiendas y los equipos de seguridad? Aunque la única solución definitiva pasa por aplicar el parche oficial tan pronto como Adobe lo incorpore a la rama estable, existen medidas paliativas que reducen el riesgo. Entre las acciones urgentes está revisar y endurecer la configuración del servidor web para evitar que archivos subidos puedan ejecutarse, restringir o deshabilitar las cargas de archivos desde lugares no imprescindibles y vigilar los endpoints de la API REST que gestionan opciones de carrito. También es recomendable utilizar los indicadores de compromiso que Sansec ha puesto a disposición para detectar visitas de escáneres automatizados y bloquear direcciones IP maliciosas a nivel de perímetro. No hay que confiar únicamente en políticas CSP para este tipo de amenazas basadas en WebRTC, por lo que los equipos de seguridad deberían complementar con controles de salida de red y análisis de comportamiento en el frontend.

La lección es clara: las plataformas de eCommerce son objetivo privilegiado para ladrones de credenciales y skimmers porque un único compromiso puede traducirse en pérdida masiva de datos de pago y daños reputacionales. Mantenerse al día con los parches, monitorear anomalías en las transacciones y responder pronto a los indicadores de compromiso publicados por grupos de investigación aumenta drásticamente las probabilidades de detectar y mitigar estos incidentes antes de que causen un daño severo.

Para quienes quieran profundizar en los detalles técnicos y obtener las listas de IPs e IoCs publicadas, el informe de Sansec sobre PolyShell y el skimmer por WebRTC son recursos recomendados: PolyShell — Sansec y WebRTC skimmer — Sansec. Y para conocer el estado del parche oficial por parte de Adobe, conviene seguir las notas de la versión en su portal: notas de la versión 2.4.9-beta1.

Si gestionas una tienda basada en Magento o trabajas en la seguridad de una, no esperes a que el exploit aparezca en tus registros: prioriza la evaluación de riesgo y la puesta en marcha de controles compensatorios ahora mismo. Esta no es una vulnerabilidad teórica: el ataque está en marcha y los malos actores ya lo están usando para robar datos de clientes y montar campañas automatizadas contra tiendas desprotegidas.