¿Qué es PolyShell?

El 17 de marzo de 2026, la empresa de seguridad Sansec publicó una vulnerabilidad crítica que bautizó como PolyShell (referenciada como APSB25-94 por Adobe). Afecta a todas las versiones estables de Magento Open Source y Adobe Commerce, desde la 2.0.0 original hasta la 2.4.8-p3. Es decir, prácticamente cualquier tienda que esté en producción hoy.

El nombre viene de polyglot (un archivo que es válido simultáneamente como imagen y como código PHP) y shell (la webshell que se instala en el servidor una vez subido el archivo).

Cómo funciona el ataque

El problema está en la API REST de Magento. Cuando un producto tiene una opción de tipo "archivo", la API acepta que el cliente suba un fichero codificado en base64 junto con el pedido. Magento escribe ese fichero en pub/media/custom_options/quote/ sin validar correctamente la extensión.

Un atacante sin ningún tipo de credencial puede subir un fichero PHP disfrazado de imagen (por ejemplo, añadiendo la cabecera GIF89a antes del código PHP). Si el servidor tiene nginx o Apache sin la configuración correcta, ese fichero es directamente ejecutable: el atacante accede a la URL y tiene control total del servidor.

El impacto varía según la configuración:

  • RCE completo en servidores con nginx en configuración estándar (2.0.x–2.2.x) o con Apache sin php_flag engine Off en el directorio de medios.
  • XSS persistente y robo de sesiones de administrador en servidores con nginx más reciente correctamente configurado.
  • En cualquier caso, el fichero malicioso queda alojado en disco.

La situación con Adobe

Adobe ha corregido el fallo únicamente en la rama de prerelease 2.4.9 (alpha3 en adelante). Para las versiones en producción —2.4.8 y anteriores— no existe hotfix aislado ni fecha anunciada para el parche estable.

Mientras tanto, los ataques automatizados ya llevan semanas activos. Sansec ha detectado explotación masiva desde el 19 de marzo, con más de 50 IPs escaneando activamente y el 79,5% de las tiendas ya siendo sondeadas. Más de 7.500 dominios han sido comprometidos.

La solución que aplicamos

En GuznelFlow llevamos gestionando respuestas a este incidente desde que se publicó el aviso. La solución que aplicamos combina tres capas:


1. Auditoría de ficheros subidos

Antes de cualquier otra cosa, comprobamos si la tienda ya ha sido comprometida.


2. Hardening del servidor web

Nginx — añadir este bloque antes de cualquier location ~ \.php$, de lo contrario el regex tiene prioridad.


3. Módulo de parche a nivel de aplicación

Tenemos un módulo que bloquea el exploit directamente en la capa de aplicación de Magento, sin tocar el core.

Las tres capas son complementarias. Aplicar solo el hardening del servidor deja la puerta abierta a que se sigan subiendo ficheros. Aplicar solo el módulo sin revisar si la tienda ya está comprometida puede dejar webshells existentes sin detectar.

¿Tu tienda ya está protegida?

Si no has aplicado estas medidas, la probabilidad de que tu tienda haya sido sondeada ya es muy alta. Los ataques automatizados no discriminan por tamaño ni sector.

Desde GuznelFlow auditamos y aplicamos estas correcciones en tiendas Magento 2 con un tiempo de respuesta de 24-48 horas. Si tienes dudas sobre el estado de tu instalación, escríbenos a hola@guznelflow.es.