Magento en Riesgo: Ataque PolyShell Masivo Descubierto

Adobe Commerce y Magento Open Source están siendo masivamente explotadas por una vulnerabilidad crítica sin parche oficial para producción. Desde el 19 de marzo de 2026, atacantes usan PolyShell (APSB25-94) para subir archivos ejecutables directamente a través de la API REST sin necesidad de credenciales, afectando ya al 56,7% de todas las tiendas vulnerables según reportes de Sansec.

Qué es PolyShell y por qué es una amenaza crítica

PolyShell es una vulnerabilidad de carga de archivos sin restricción en el endpoint de custom options de la API REST de Magento. El nombre viene de “polyglot” — un archivo que parece una cosa (una imagen legítima) pero contiene código ejecutable que el servidor interpreta si la configuración lo permite. No requiere autenticación. Cualquiera con acceso a la API puede subir un polyglot.

Lo gratis acá es que según Sansec Forensics, el código vulnerable existe desde la versión 2.0 de Magento en 2015 — una década compartiendo la misma brecha sin saberlo. Adobe recién lo selló en la rama pre-release 2.4.9-alpha3, pero eso no es una versión de producción, es un canario.

Versiones afectadas: Magento Open Source y Adobe Commerce

Acá viene el dolor de cabeza. La vulnerabilidad impacta:

Todas las versiones productivas actuales de Magento Open Source y Adobe Commerce hasta 2.4.9-alpha2 (inclusive). Eso incluye 2.4.8, 2.4.7, 2.4.6, 2.4.5, 2.4.4, 2.4.3, 2.4.2, 2.4.1, 2.4.0 y todas las versiones anteriores a 2.3.5 con configuraciones de servidor web no estándar.

Adobe publicó la solución el 10 de marzo en la rama 2.4.9-alpha3 como parte del bulletin APSB25-94. Pero eso es pre-release. Para las versiones estables en producción (2.4.0 a 2.4.8), BleepingComputer reporta que no existe un parche aislado ni Adobe ha comunicado cuándo llegará uno. Contactaron a la empresa pidiendo fecha y no obtuvieron respuesta.

Cómo funciona el ataque técnicamente: la REST API como vector

El flujo es casi elegante en su simpleza. Ponele que tenés una tienda Magento 2.4.7 en vivo. El atacante: En como ocurre en plataformas GitHub profundizamos sobre esto.

1. Hace un POST a la API REST al endpoint de /V1/carts/mine/items o similar, pasando custom options.
2. En el payload de custom options, adjunta un archivo polyglot: un JPEG válido en los primeros bytes (para evadir validaciones superficiales) pero que contiene PHP, JavaScript o código ejecutable después.
3. El servidor guarda el archivo sin validar realmente si es lo que dice ser.
4. Dependiendo de cómo esté configurado nginx o Apache, ese archivo puede ejecutarse directamente como código (RCE) o quedar almacenado en el servidor listo para ser ejecutado después vía una segunda solicitud.

Si la configuración web usa fastcgi sin restricciones o pasa todos los archivos a un interpretador, vos terminás con remote code execution puro. El atacante corre comandos en tu servidor. Si no, al menos tiene un archivo ejecutable plantado en tu filesystem.

El kicker: Sansec observó que, en algunos casos, el código subido es un skimmer de tarjetas de crédito que usa WebRTC (Web Real-Time Communication) para exfiltrar datos de clientes a través de DTLS-encrypted UDP. A diferencia de un skimmer HTTP tradicional, esto no sale por tus logs de tráfico web ni se detecta fácilmente con un WAF convencional que monitorea HTTP. Es un canal lateral.

Estado de la explotación masiva: números reales de marzo 2026

Esto dejó de ser teórico hace una semana.

Según Sansec, la explotación masiva comenzó el 19 de marzo de 2026, apenas dos días después de que se divulgara públicamente en Twitter y en la investigación de Sansec del 17 de marzo. Los números:

• 56,7% de todas las tiendas Magento vulnerables ya fueron atacadas.
• Más de 50 direcciones IP activas están escaneando y explotando tiendas.
• Sansec publicó la lista pública de IPs maliciosas para que propietarios de tiendas puedan bloquearlas en firewall.
• El escaneo es automatizado y masivo — no es un ataque quirúrgico, es un barrido de “prueba rápida”.

Si tu tienda está en una versión vulnerable, fue probada. Si no tomaste medidas, fue comprometida.

Por qué Adobe no sacó un parche aislado para producción

Eso sí, acá hay un punto que genera fricción. Adobe corrigió PolyShell en el código fuente de la rama 2.4.9-alpha3 el 10 de marzo. Pero la política de Adobe es que los parches de seguridad críticos solo salen con las nuevas versiones de punto release estables, no como hotfixes aislados. La próxima versión estable será 2.4.9, que sigue siendo pre-release. Relacionado: en nuestra guía sobre privacidad de código.

Para usuarios de 2.4.0 a 2.4.8 — la mayoría de la instalbase — no hay opción de parche. La única ruta de salida es actualizar a 2.4.9-alpha3 o esperar a que Adobe lance 2.4.9 como estable (sin fecha anunciada). Ese timeline no existe.

Medidas de mitigación mientras esperás que Adobe resuelva

Aunque no tengas parche, hay acciones que limitan el daño. Aplicalas ahora:

1. Reconfiguración del servidor web (nginx/Apache): Adobe publicó una configuración de servidor recomendada que deniega ejecutar ciertos tipos de archivo en directorios de uploads. Si la aplicás — tanto en nginx como en Apache — reduces el riesgo de RCE directo a stored XSS o DoS, que es mejor que nada (si es que se puede llamar “mejor”).

2. Bloquea las IPs maliciosas: Sansec publicó la lista de IPs activas. Metelas en tu firewall WAF o iptables. No es defensa perfecta — los atacantes rotarán IPs — pero elimina los bots automáticos que hacen reconnaissance.

3. Monitorea logs de la API REST: Buscá requests a `/V1/carts/` o `/V1/products/` con custom options sospechosas, payloads grandes, o extensiones de archivo raras. Si ves un .php o .phtml subido al directorio `/media/`, activa la alarma.

4. WAF con reglas polyglot-aware: Si usás Cloudflare, donweb.com ofrece configuración de WAF, o managed WAFs como Imperva, asegurate de que tengan reglas que detecten polyglots (archivos con múltiples magic bytes).

5. Evalúa upgrade a pre-release (riesgo calculado): Algunos operadores ya pusieron 2.4.9-alpha3 en staging. Es pre-release, puede tener bugs, pero está parchado. Si tu tienda es crítica y no podés esperar, esa es la ruta nuclear. Sobre eso hablamos en soluciones empresariales similares.

¿Qué cambios trajo APSB25-94 en 2.4.9-alpha3?

El fix de Adobe en la rama 2.4.9-alpha3 no es publicado en detalle — es pre-release. Pero según Sansec, la solución está en los cambios al validador de tipos de archivo en la API REST, particularmente en cómo procesa custom options. Probablemente:

• Validación más estricta de MIME types (no solo por extensión).
• Restricción de qué archivos se permiten en uploads de custom options (whitelist en vez de blacklist).
• Separación de directorios entre código ejecutable y uploads de usuarios.

Pero nuevamente: eso es speculación basada en el nombre del bulletin. La verdad es que no hay fuente oficial de Adobe detallando qué se cambió.

Errores comunes que comete gente real

Error 1: “Mi tienda está en 2.4.8, debo estar protegida si tengo un WAF”. Incorrecto. PolyShell está en la API REST de core — no es un plugin vulnerable. Un WAF genérico no va a bloquear un POST legítimo a /V1/carts/ que lleve un polyglot bien formado. Necesitás reglas específicas polyglot-aware O la configuración web de Adobe. El WAF solo no salva.

Error 2: “Voy a esperar al parche oficial sin tomar medidas”. Mientras esperas, tu tienda se está scaneando activamente. Aplicá al menos la reconfiguración del servidor web. Es gratis, toma 20 minutos, y reduce significativamente el blast radius si algún atacante entra. Te puede servir nuestra cobertura de como sucede con dependencias npm.

Error 3: “Bloqueé los IPs de Sansec, ahora estoy seguro”. Es un paso. Pero no es suficiente. Los atacantes van a rotar IPs, usar proxies, o cambiar el payload. Ip blacklist es una defensa capas, no la defensa entera. Monitorea logs también. Lo complementamos en así como WordPress enfrentó hace poco.

En nuestro artículo describimos cómo PolyShell explota el 56% de tiendas Magento vulnerables con técnicas sofisticadas.

Podés leer más detalles en PolyShell explota el 56% de tiendas Magento vulnerables con , donde lo cubrimos con mayor profundidad.

Confirmado vs. Pendiente

Confirmado

• PolyShell permite subir archivos ejecutables sin autenticación vía API REST.
• El código vulnerable existe desde Magento 2.0 (2015).
• Adobe corrigió el fallo en 2.4.9-alpha3, lanzado el 10 de marzo 2026.
• La explotación masiva comenzó el 19 de marzo 2026 en al menos 56,7% de tiendas vulnerables.
• Más de 50 IPs activas escaneando y atacando.
• Algunos payloads incluyen skimmers WebRTC que evaden detección HTTP.
• No existe parche aislado para versiones productivas actuales (2.4.0-2.4.8).

Pendiente o sin respuesta oficial

• Cuándo Adobe lanzará 2.4.9 como versión estable productiva (no pre-release).
• Si Adobe sacará un hotfix aislado para 2.4.0-2.4.8.
• Cifra exacta de tiendas comprometidas (Sansec solo reportó que el 56,7% fue escaneado).
• Detalles técnicos específicos del cambio en el código de 2.4.9-alpha3 que lo parcha.

Preguntas Frecuentes

¿Qué es un archivo polyglot?

Un archivo que es válido en dos o más formatos simultáneamente. Ejemplo: un JPEG válido en los primeros 2KB, pero que contiene PHP ejecutable después. Si un servidor no valida el archivo completo (solo mira los primeros bytes), lo ve como JPEG. Si fastcgi ejecuta todo lo que pase a través, ejecuta el PHP. Es un truco que evade validaciones simples. Nuestros colegas de seguridadenwordpress.com lo analizan en herramientas para proteger tiendas online.

¿Cómo sé si mi tienda Magento fue atacada?

Revisá los logs de la API REST en `var/log/` en Magento (si los configuraste). Buscá requests POST a endpoints de custom options con timestamps recientes y payloads inusualmente grandes. Si vez un archivo con nombre raro en `/media/`, especialmente con extensión .php o .phtml, fue comprometida. También revisá para conexiones outbound a IPs desconocidas en tus logs de firewall (skimmers hacen exfiltración de datos).

¿Puedo seguir usando Magento 2.4.8 sin riesgo si aseguro la configuración del servidor?

Relativamente más seguro, pero no “sin riesgo”. La reconfiguración web limita el RCE a XSS o corrupción de datos — mejor que antes, pero seguís siendo vulnerable. Es una mitigación, no una solución. Si tu tienda procesa pagos, es ecommerce productiva, o maneja datos sensibles, la ruta correcta es upgrade a 2.4.9-alpha3 o esperar a 2.4.9 estable. No es solo seguridad: es cumplimiento y responsabilidad de datos.

¿Los plugins de seguridad (Wordfence, Sucuri) protegen contra PolyShell?

No todos igual. Wordfence y Sucuri son primariamente para WordPress. Magento usa arquitectura diferente. Algunos WAF de Sucuri pueden tener reglas de detección si las actualizaron después del 17 de marzo, pero no es garantizado. Seguí las medidas de mitigación específicas para Magento (reconfiguración web, bloqueo de IPs) antes de confiar en un plugin de seguridad genérico.

Conclusión

PolyShell es una de esas vulnerabilidades que debería haber sido letal hace una década. Estuvo ahí desde 2015, dormida en el código, hasta que alguien la encontró y la divulgó. Adobe corrigió el fallo en una rama pre-release que nadie usa en producción. Mientras tanto, 56% de las tiendas Magento fueron escaneadas y probablemente comprometidas en cuestión de días.

Si corrés Magento Open Source o Adobe Commerce en versiones productivas actuales (2.4.0 a 2.4.8), tu tienda está en riesgo hoy. No mañana. Hoy. La jugada inmediata: aplicá la reconfiguración de servidor web que Adobe publicó (es gratis y fácil), bloqueá las IPs de Sansec, monitoreá logs, y evaluá si podés saltarte a 2.4.9-alpha3 o si necesitás esperar a que Adobe saque 2.4.9 estable (fecha indefinida).

No es un problema de “hay un parche, actualizá y listo”. No hay parche oficial para producción. Es un problema de “Adobe se tomó su tiempo y la vulnerabilidad ya está siendo explotada a escala”. Movete rápido.

Fuentes

• Magento PolyShell: unrestricted file upload in Magento and Adobe Commerce — Sansec Forensics Team
• PolyShell attacks target 56% of all vulnerable Magento stores — BleepingComputer
• Magento PolyShell Flaw Enables RCE Without Authentication — The Hacker News