La vulnerabilidad crítica PolyShell, descubierta por especialistas de Sansec, afecta a todas las versiones actuales de Magento Open Source y Adobe Commerce 2.x. El fallo permite la carga de archivos arbitrarios sin autenticación a través del API REST, lo que abre la puerta a ejecución remota de código (RCE) y ataques de XSS almacenado, con potencial para tomar el control de cuentas de administradores y clientes de las tiendas afectadas.
Qué es PolyShell: vulnerabilidad de carga de archivos en Magento y uso de archivos “polyglot”
El origen de PolyShell se encuentra en el API REST de Magento encargado de procesar productos con opciones personalizadas. Cuando un artículo incluye una opción de tipo file, la plataforma acepta un objeto file_info que contiene el archivo codificado en Base64, su tipo MIME y su nombre. Tras la decodificación, el fichero se almacena en el directorio pub/media/custom_options/quote/ del servidor.
El elemento crítico es que este flujo de carga se ejecuta sin requerir autenticación. Es suficiente con enviar una petición correctamente formada al API para conseguir que el servidor guarde un archivo controlado por el atacante. El impacto concreto dependerá de la configuración del servidor web y de cómo se gestionen los recursos estáticos y ejecutables.
El nombre PolyShell alude al uso de archivos “polyglot”: ficheros diseñados para ser interpretados de forma válida como, por ejemplo, una imagen y simultáneamente como un script ejecutable. Si el servidor web está mal configurado, el archivo puede subirse como si fuera una imagen, pero al acceder a su URL ser procesado como código, abriendo un vector claro para RCE o para inyectar un payload de XSS almacenado.
Escenario técnico de explotación de la vulnerabilidad PolyShell
En un escenario típico de ataque, el adversario construye una petición al API REST que simula añadir un producto al carrito. En el campo file_info envía un archivo polyglot codificado en Base64. Magento almacena el fichero en pub/media/custom_options/quote/ y, a continuación, el atacante accede directamente a él mediante su URL pública.
Si el servidor permite la ejecución de scripts en directorios de medios o no restringe adecuadamente ciertas extensiones, ese archivo puede funcionar como una web shell, otorgando acceso remoto al sistema. En entornos ligeramente más protegidos, el fichero puede utilizarse para XSS almacenado, inyectando JavaScript malicioso en el panel de administración o en la tienda, con riesgo de robo de sesiones, datos de tarjetas y modificación de contenidos. Este patrón encaja con las debilidades de carga de archivos insegura señaladas de forma recurrente en el OWASP Top 10.
Estado del parche de Adobe y ventana de exposición para tiendas Magento
De acuerdo con Sansec, Adobe ha reconocido la vulnerabilidad e incorporado la corrección en el boletín de seguridad APSB25-94. No obstante, el parche solo está disponible por ahora en la rama previa al lanzamiento de la versión 2.4.9, sin actualización específica liberada aún para versiones de producción ampliamente desplegadas, lo que deja una ventana de exposición especialmente delicada.
En el contexto del comercio electrónico, una vulnerabilidad de ejecución remota de código (RCE) permite a un atacante ejecutar prácticamente cualquier comando: instalar puertas traseras, crear cuentas administrativas ocultas, alterar scripts de pago o redirigir transacciones a cuentas fraudulentas. A su vez, un XSS almacenado posibilita inyectar JavaScript malicioso de forma persistente en la interfaz de administración o en la tienda, capturando credenciales, tokens de sesión y datos sensibles de clientes.
Campaña masiva de defacement en sitios Magento: el caso “Typical Idiot Security”
En paralelo al hallazgo de PolyShell, Netcraft ha documentado una ola de defacement contra sitios basados en Magento. Desde el 27 de febrero de 2026, un atacante o grupo de atacantes ha publicado archivos de texto con “firmas” en más de 7.500 sitios web. La mayoría de los mensajes incluyen la marca Typical Idiot Security, también visible en registros de compromisos publicados en Zone-H para reforzar la reputación del actor en círculos clandestinos.
Entre los dominios afectados figuran subdominios y tiendas regionales de marcas como Asus, BenQ, Citroën, Diesel, FedEx, Fiat, Lindt, Toyota, Yamaha, además de organismos públicos y universidades. Aunque el defacement pueda parecer solo una sustitución de contenido, demuestra control de escritura en el servidor y, en muchos casos, constituye la fase inicial de una intrusión más profunda orientada al fraude o al robo de datos.
Relación entre el defacement y las vulnerabilidades de carga de archivos sin autenticación
Según el análisis de Netcraft, el atacante probablemente se apoya en vulnerabilidades de carga de archivos no autenticada, de naturaleza similar a PolyShell. Los investigadores señalan paralelismos con la vulnerabilidad SessionReaper, reportada en 2025, que también afectaba a sitios Magento explotando mecanismos inseguros de sesión y subida de archivos. Estas campañas muestran un patrón claro: cadenas de ataque que comienzan con una sencilla carga de archivo y escalan hasta la completa toma de control del entorno.
Medidas urgentes para proteger Magento y Adobe Commerce frente a PolyShell y ataques similares
Hasta que Adobe publique parches estables para todas las versiones de producción, resulta esencial aplicar de inmediato un conjunto de controles compensatorios que reduzcan drásticamente la superficie de ataque:
1. Restringir el acceso al directorio de subida. Bloquear el acceso directo a pub/media/custom_options/ desde nginx o Apache (por ejemplo, con deny all o reglas equivalentes) y asegurarse de que en ese directorio está prohibida la ejecución de cualquier tipo de script.
2. Analizar el sistema en busca de web shells y puertas traseras. Revisar pub/media/custom_options/quote/ y otros directorios de medios para detectar archivos sospechosos: extensiones inusuales, nombres extraños o contenido ejecutable incrustado en supuestas imágenes. Es recomendable emplear escáneres de seguridad para aplicaciones web y soluciones antimalware especializadas en servidores.
3. Endurecer la configuración del servidor web. Garantizar que en todos los directorios de contenido estático no se procesan archivos .php, .phtml ni otros tipos ejecutables. Asegurar que el tipo de contenido enviado al navegador se determina en función de la configuración del servidor y no puede ser manipulado por el usuario, reduciendo así los vectores de ataque basados en polyglot.
4. Limitar y monitorizar el API REST. Siempre que sea posible, restringir el acceso a los endpoints sensibles mediante listas de control de IP, autenticación reforzada o un Web Application Firewall (WAF). Activar el logging detallado de peticiones que incluyan cargas de archivos y revisar periódicamente estos registros para detectar patrones anómalos.
5. Planificar una actualización inmediata en cuanto exista parche estable. Una vez que Adobe publique la corrección definitiva para Magento / Adobe Commerce, debe aplicarse sin demora tras validarla en un entorno de pruebas. La experiencia demuestra que la demora en instalar parches críticos incrementa de forma significativa el riesgo de explotación, especialmente cuando el vector de ataque es público y ya se observa actividad maliciosa en la red.
PolyShell, junto con la campaña de defacement atribuida a Typical Idiot Security, refuerza la importancia de tratar las cargas de archivos no autenticadas como un riesgo de máxima prioridad en cualquier plataforma de comercio electrónico. Revisar la configuración del servidor, reforzar la seguridad del API, automatizar auditorías periódicas y seguir de cerca los boletines de Sansec, Adobe y Netcraft son pasos esenciales para reducir la probabilidad de compromiso. Actuar con rapidez y de forma preventiva es, hoy más que nunca, la clave para mantener la integridad, disponibilidad y confianza en las tiendas basadas en Magento y Adobe Commerce.
