PolyShell: falla crítica afecta todas las tiendas Magento

Actualizado el 05/05/2026 — Este artículo fue actualizado con información reciente, secciones de detección y auditoría, y detalles específicos sobre Adobe Commerce.

La vulnerabilidad PolyShell en Magento es una falla crítica de file upload sin restricción que permite ejecución remota de código (RCE) sin autenticación en todas las versiones de Magento Open Source y Adobe Commerce 2. Fue descubierta por Sansec en febrero de 2026, y desde entonces ha comprometido más de 15.000 sitios web identificados públicamente. El exploit aprovecha archivos polyglot (archivos que son válidos simultáneamente como imagen y como código PHP) subidos a través de la API REST del carrito de compras.

Qué es PolyShell: la vulnerabilidad que pone en riesgo a todas las tiendas Magento

PolyShell es una vulnerabilidad de validación insuficiente descubierta por el equipo de investigación de Sansec, empresa holandesa especializada en seguridad de plataformas de ecommerce. El nombre combina dos términos técnicos: «polyglot» (un archivo que es simultáneamente válido en múltiples formatos) y «shell» (una interfaz interactiva que permite ejecutar comandos en el servidor).

Lo que hace a PolyShell particularmente grave es que no afecta una versión específica ni requiere una configuración rara o antigua. Todas las versiones de Magento Open Source 2 desde la 2.0.0 hasta la 2.4.8-p3 son vulnerables. Todas las versiones de Adobe Commerce 2 en ese mismo rango también. Eso significa que hoy, en mayo 2026, hay cientos de miles de tiendas en producción expuestas a este vector de ataque.

El impacto depende de la configuración específica del servidor web. En el peor caso, un atacante sin ninguna credencial obtiene ejecución remota de código completa (RCE). Puede instalar backdoors, robar datos de clientes, alterar precios, modificar el contenido, o instalar malware silencioso. En configuraciones más endurecidas, la explotación resulta en stored XSS con capacidad de account takeover — lo que permite robar sesiones de administradores y tomar control total de la tienda.

Cómo funciona el exploit: archivos polyglot y la API REST del carrito

El vector de ataque es la API REST de Magento, específicamente el endpoint que maneja las opciones personalizables del carrito de compras. Cuando un producto tiene una opción de tipo «file» — por ejemplo, para que el cliente suba un logo para personalizar una remera — Magento acepta a través de la API un objeto JSON que incluye tres campos clave: los datos del archivo codificados en base64, el MIME type declarado, y el nombre del archivo.

El problema de seguridad es que Magento escribe ese archivo en el directorio pub/media/custom_options/quote/ sin validar adecuadamente dos cosas: el contenido real del archivo más allá de los primeros bytes, y la extensión del archivo versus el MIME type declarado. Esto abre la puerta a un ataque con archivos polyglot.

Un archivo polyglot es un archivo que contiene datos válidos para múltiples formatos simultáneamente. Por ejemplo, un atacante crea un archivo que tiene los magic bytes (los primeros bytes que identifican el formato) de una imagen JPEG al inicio — lo que engaña a cualquier validación superficial de MIME type. Pero embebido dentro del archivo, después de los datos JPEG válidos, coloca código PHP ejecutable.

Fijate que el atacante ni siquiera necesita una cuenta de cliente en la tienda. La API REST permite agregar items al carrito como guest — como usuario anónimo. El upload de archivos se procesa antes de cualquier checkout, antes de que se requiera pago. La request es un simple POST HTTP al endpoint del carrito con el payload malicioso en base64 y un MIME type falso.

GraphQL, por otro lado, no está afectado porque usa un path diferente para el manejo de archivos y tiene validaciones más estrictas. Si tu tienda expone GraphQL, ese endpoint está seguro. Pero si usa REST API (que es el default), está expuesta.

Una vez que el archivo polyglot está en el servidor en pub/media/custom_options/, el atacante solo necesita que el servidor web lo ejecute como PHP. Y acá es donde entra la configuración específica del servidor — porque no todos los servidores lo harán automáticamente.

Versiones afectadas: Magento Open Source y Adobe Commerce

Según el análisis detallado de BleepingComputer, el riesgo varía según la combinación de versión de Magento y configuración del servidor web. No todas las instalaciones tienen el mismo nivel de exposición, pero todas están vulnerables a por lo menos una variante del ataque.

Escenario	Versiones Magento	Versiones Adobe Commerce	Servidor Web	Impacto
RCE directo	2.0.0 a 2.2.x	2.0.0 a 2.2.x	nginx config stock	Ejecución remota de código sin autenticación
RCE por FastCGI	Todas 2.x	Todas 2.x	nginx con rutas no estándar	Ejecución remota de código sin autenticación
RCE por Apache	2.0.0 a 2.3.4	2.0.0 a 2.3.4	Apache sin flags de engine correctos	Ejecución remota de código sin autenticación
Stored XSS + ATO	Todas 2.x hasta 2.4.8-p3	Todas 2.x hasta 2.4.8-p3	Cualquier configuración	Account takeover de administradores vía XSS persistente

Ejemplo concreto: una tienda corriendo Magento 2.2.11 (versión aún en uso en marzo 2026 según nuestro análisis de market share) en nginx con la configuración que viene en el repositorio oficial es directamente vulnerable a RCE. El atacante sube el polyglot, accede a /media/custom_options/quote/archivo.php y obtiene una shell interactiva en el servidor.

Para versiones más recientes como 2.4.7 o 2.4.8 con nginx bien configurado — donde nginx está explícitamente configurado para NO routear archivos .php dentro de pub/media/ a PHP-FPM — el RCE directo no funciona porque el servidor rechaza la ejecución de PHP. Pero el archivo polyglot igual se sube y queda en el servidor. Si contiene JavaScript malicioso embebido dentro de un JPEG válido, el XSS se ejecuta cuando un administrador revisa un pedido con archivos adjuntos.

La campaña de defacement masivo: 7.500 sitios comprometidos en febrero-abril 2026

PolyShell no es una vulnerabilidad teórica o un proof-of-concept académico. Fue explotada activamente en campañas a gran escala desde el momento en que los detalles técnicos se conocieron públicamente. Según el reporte de Netcraft de abril 2026, desde el 27 de febrero se detectó una campaña de defacement (alteración visible de contenido) que afectó más de 15.000 hostnames distribuidos en 7.500 dominios únicos.

Lo que llamó la atención de los investigadores fue la escala y los targets específicos. Entre los dominios comprometidos había infraestructura asociada a marcas globales de primer nivel como Asus, FedEx, Fiat, Lindt, Toyota y Yamaha. No se trataba de tiendas chicas, abandonadas o con mala configuración — eran propiedades digitales de empresas multinacionales con equipos de seguridad formales y presupuesto dedicado.

El atacante o grupo se identificó públicamente como «Typical Idiot Security» y se dedicó a dejar mensajes de defacement (mensajes ofensivos reemplazando el contenido) en las tiendas comprometidas. El defacement es la forma más visible y «ruidosa» de explotación.

¿Cuántas de estas intrusiones aprovecharon específicamente PolyShell? No está confirmado al 100% que todas lo hayan hecho. El ecosistema de vulnerabilidades activas en Magento es amplio, y la campaña podría estar explotando múltiples fallas en paralelo. Pero el timing es sospechoso: la campaña arrancó justo cuando los detalles técnicos de PolyShell comenzaron a circular entre investigadores y hackers.

El dato más preocupante: defacement es probablemente la forma más obvia de explotación. Los ataques silenciosos — robo de datos de tarjetas de crédito, instalación de skimmers JavaScript que capturan credenciales, backdoors persistentes para acceso futuro — no dejan pantalla de aviso. Si 7.500 sitios fueron defaceados públicamente, ¿cuántos más fueron comprometidos de forma silenciosa sin que los propietarios se enteraran?

Sansec reportó en su seguimiento posterior que el 56,7% de todas las tiendas Magento vulnerables están siendo atacadas activamente. No es una predicción — es un dato basado en análisis de los servicios WAF y de detección de malware de terceros que monitorizan miles de tiendas.

Adobe Commerce específicamente: ¿por qué los ecommerce enterprise tampoco están protegidos?

Adobe Commerce es la versión empresarial de Magento, dirigida a grandes ecommerce que pagan suscripción mensual a Adobe. Comparte la base de código con Magento Open Source, incluyendo la arquitectura del carrito de compras y la API REST.

La vulnerabilidad PolyShell afecta a todas las versiones de Adobe Commerce 2 exactamente de la misma forma que afecta a Magento Open Source. Esto significa que tiendas enterprise que pagan seis cifras anuales por Adobe Commerce siguen siendo vulnerables desde febrero 2026, sin parche oficial disponible.

Adobe publicó un boletín de seguridad el 10 de marzo 2026 (APSB26-05) que cubre 19 vulnerabilidades en productos Magento, 6 de ellas clasificadas como críticas. PolyShell está en esa lista. El problema es que el fix existe únicamente en la rama pre-release de Magento 2.4.9-alpha2. Ninguna tienda seria corre una versión alpha en producción — eso es para entornos de desarrollo y testing, no para infraestructura que procesa transacciones reales.

Adobe no ha publicado un parche aislado (backport) para las versiones que están efectivamente en producción: 2.4.7, 2.4.7-p1, 2.4.8, 2.4.8-p1, 2.4.8-p3. El contraste con cómo WordPress maneja vulnerabilidades críticas es brutal: WordPress publica un hotfix que se aplica automáticamente en millones de sitios en horas. Magento sigue dependiendo de ciclos de release que toman semanas o meses.

Para ser justos: parchear Magento en producción es más complejo que parchear WordPress. Las tiendas de ecommerce enterprise tienen integraciones profundas de sistemas de pago, personalizaciones pesadas, procesos de QA rigurosos y ventanas de mantenimiento limitadas. Pero eso no justifica que Adobe no ofrezca un parche aislado que los equipos puedan evaluar, testear y aplicar por su cuenta según sus cronogramas.

Indicadores de compromiso: cómo saber si tu tienda fue atacada

Si tu tienda Magento estuvo expuesta a Internet desde febrero 2026, es probable que haya recibido al menos intentos de explotación. Acá están los indicadores técnicos que sugieren que el ataque fue exitoso.

Indicadores en logs de servidor web

• Requests POST a /rest/V1/carts/mine/items con payloads inusualmente grandes o codificados en base64 desde IPs no reconocidas.
• HTTP 200 responses seguidas de requests GET a /pub/media/custom_options/ — indica que el archivo fue subido exitosamente y luego accedido.
• Requests a rutas que no existen en tu tienda pero incluyen /pub/media/custom_options/quote/ — es un patrón clásico de fuzzing de directorios para confirmar la vulnerabilidad.

Indicadores en el servidor

• Archivos con fecha reciente en pub/media/custom_options/quote/ que no corresponden a usuarios legítimos — especialmente .php, .phtml, .php5, .phar o archivos sin extensión.
• Modificación de archivos de configuración de Magento como env.php, di.xml, o archivos de módulos personalizados.
• Nuevos usuarios administrativos creados en la base de datos que nadie reconoce.
• Alteraciones en cron jobs o tasks de background — los atacantes frecuentemente agregan tareas programadas para mantener acceso persistente.

Indicadores en la base de datos

• Registros en la tabla sales_order_payment con datos extraños o campos que fueron alterados después de que la tienda debería estar cerrada.
• Cambios no autorizados en la tabla catalog_product_entity — precios alterados, descripciones modificadas, o productos ocultados.
• Nuevas entradas en tabla de eventos de auditoría (si tu Magento tiene logging de cambios activado) que no corresponden a administradores legítimos.

Cómo auditar tu tienda: herramientas y checks manuales

No tenés que esperar a que Adobe publique un parche para verificar si tu tienda está vulnerable o si fue comprometida. Acá están los métodos concretos de auditoría.

1. Verificar la versión de Magento

Primero, confirmá que versión de Magento corrés. Si es cualquier versión 2.x hasta 2.4.8-p3, estás vulnerable. Podés encontrar la versión en:

• app/etc/config.php (campo 'version')
• composer.lock (si usás Composer)
• La consola de Magento admin en Sistema > Información de Herramientas (Tools Information)

2. Verificar directorio de uploads

Accedé vía SSH o FTP a tu servidor y revisá el contenido de pub/media/custom_options/quote/. Fijate en:

• Archivos .php, .phtml, .php5, .phar — estos no deberían estar ahí.
• Archivos sin extensión — pueden ser webshells sin extension visible.
• Timestamp reciente — si los archivos fueron modificados después de que tu tienda debería estar cerrada, es sospechoso.
• Tamaño inusual — un JPEG legítimo de carga de cliente tiene entre 50KB y 5MB. Si hay archivos de 1-2KB, probablemente sean shells.

3. Usar scanners de terceros

Algunos proveedores de seguridad ya tienen detección automática de PolyShell:

• Sucuri SiteCheck — sitecheck.sucuri.net. Es gratuito y detecta algunos patrones de compromiso.
• Wordfence Scan — si tenés Wordfence en tu servidor (lo recomendamos para WordPress, aunque es diferente de Magento), tiene capacidad de detectar anomalías de archivo.
• YARA rules de Sansec — Sansec publicó reglas YARA para detectar webshells conocidos asociados con PolyShell. Podés usarlas con herramientas como YARA CLI si tenés acceso al servidor.

4. Revisar logs de acceso

Descargá los logs de acceso HTTP de tu servidor y buscá patrones sospechosos. Si tenés acceso shell, podés hacer:

• grep «custom_options» /var/log/nginx/access.log — listá todos los accesos al directorio vulnerable.
• grep «POST /rest/V1/carts» /var/log/nginx/access.log — listá todos los POSTs a la API del carrito.
• grep » 200 » /var/log/nginx/access.log | grep «custom_options» — filtrá solo los accesos exitosos.

Cómo proteger tu tienda Magento ahora mismo

Mientras no haya parche oficial para tu versión de producción, estas son las mitigaciones concretas que podés implementar hoy. Ninguna es perfecta, pero en combinación reducen significativamente el riesgo.

Mitigación 1: Bloquear ejecución PHP en directorios de uploads

Esta es la mitigación más efectiva porque previene que archivos PHP subidos sean ejecutados. El archivo malicioso igual se sube, pero queda inerte — una imagen o un archivo inútil sin capacidad de ejecutarse.

En nginx: Agregá una regla en tu bloque de configuración (virtualhost) que devuelva 403 (Forbidden) para cualquier request a archivos .php dentro de pub/media/custom_options/:

• location ~ ^/pub/media/custom_options/.*\.php$ { deny all; }

En Apache: Crea un archivo .htaccess en el directorio pub/media/custom_options/ con el siguiente contenido:

• php_flag engine off (si PHP está como módulo Apache)
• O: <FilesMatch "\.php$"> Deny from all </FilesMatch>

Mitigación 2: Implementar WAF con reglas específicas

Un WAF (Web Application Firewall) como Cloudflare, Sucuri o tu proveedor de hosting puede filtrar requests sospechosos a la API REST del carrito en tiempo real, antes de que lleguen a tu servidor. Más sobre esto en al elegir tu proveedor de hosting.

En nuestro artículo sobre New «PolyShell» flaw allows unauthenticated RCE on all Magen cubrimos en profundidad este tipo de vulnerabilidades.

Configurá reglas que inspeccionen el body de los POSTs a /rest/V1/carts/ y bloqueen requests que: Nuestros colegas de donweb.news lo analizan en calcular el costo total de remediación.

• Contengan extension PHP o similar en el campo file_info.name.
• Tengan archivos codificados en base64 con tamaño sospechoso (muy pequeño para una imagen legítima).
• Incluyan palabras clave asociadas con shells web (system, exec, shell_exec, passthru, eval, base64_decode, etc.).

La mayoría de WAF comerciales ya tienen reglas predefinidas para PolyShell. Si usás Cloudflare, Sucuri o Imperva, actualizá tus reglas de seguridad. Lo complementamos en DRA + EFA en EKS: asignación de red con topología en K8s.

Lo que comentamos acá se profundiza en New «PolyShell» flaw allows unauthenticated RCE on all Magen.

Mirá también New «PolyShell» flaw allows unauthenticated RCE on all Magen, que es imprescindible si administrás WooCommerce.

Mitigación 3: Desactivar la opción de file upload en productos

Si no necesitás que tus clientes suban archivos a través del carrito (logos personalizados, diseños, etc.), desactivá la funcionalidad directamente en Magento admin: Más sobre esto en Azure Integrated HSM: Microsoft abre el código.

• Andá a Catálogo > Atributos > Administrar Atributos.
• Para cada atributo de tipo «File», cambiá el tipo de input a algo que no permita uploads (ej: «Text» o «Dropdown»).
• Si necesitás uploads pero solo desde admin (no desde clientes), setea el atributo como «Not Visible on Front».

Mitigación 4: Validación estricta de tipos de archivo

Si customizaste tu instalación de Magento, asegurate de que cualquier manejo de uploads de archivo implemente validación estricta:

• Whitelist de extensiones permitidas: solo .jpg, .jpeg, .png, .gif. Rechazá cualquier otra.
• Validación de magic bytes: no confíes solo en la extension ni en el MIME type declarado. Verificá los primeros bytes del archivo usando librerías como Fileinfo de PHP.
• Guardar fuera de la raíz web: si es posible, guardar uploads en un directorio fuera de la raíz de documentos web (fuera de public_html/), de modo que el servidor no pueda ejecutarlos aunque sean PHP.

Mitigación 5: Monitoreo activo de logs

Configurá alertas en tus logs de acceso para detectar intentos de explotación. Si usás un servicio administrado o hosting, verificá que tu proveedor ya tenga monitoreo:

• Alertas cuando se detecten POSTs a /rest/V1/carts/mine/items desde múltiples IPs diferentes.
• Alertas cuando aparezcan GETs a /pub/media/custom_options/ con User-Agent sospechosos (curl, wget, python).
• Alertas cuando la tasa de requests a la API REST suba repentinamente.

Timeline de parches: dónde está el fix y por qué tarda

Entender dónde está el fix y por qué tarda es clave para planificar tu estrategia de mitigación. Acá está el timeline oficial.

• 27 de febrero 2026: Se inicia la campaña de explotación masiva. Sansec y otros investigadores comienzan a analizar el ataque.
• 10 de marzo 2026: Adobe publica el boletín de seguridad APSB26-05 que documenta 19 vulnerabilidades, incluyendo PolyShell.
• 10 de marzo 2026 (mismo día): El fix es mergeado en la rama de desarrollo de Magento 2.4.9-alpha2. No en una rama de producción.
• 19 de marzo 2026: Campañas de explotación se aceleran. Sansec documenta que el 56,7% de tiendas Magento vulnerables están siendo atacadas activamente.
• Presente (05 de mayo 2026): El fix sigue siendo solo disponible en la rama alpha. No hay backport oficial para 2.4.7, 2.4.8, o 2.4.8-p1.

Adobe ha indicado que la próxima versión de producción será Magento 2.4.9. El timeline estimado es Q3-Q4 2026, pero no está confirmado. Eso significa que tiendas en producción esperarían entre 4-8 meses adicionales sin un parche oficial disponible.

Alternativas: considerar migraciones o actualizaciones forzadas

Para tiendas grandes o con datos sensibles, la exposición de 3+ meses sin parche oficial plantea una decisión difícil: ¿vale la pena esperar a que Adobe publique 2.4.9, o conviene hacer una migración o actualización forzada antes?

Opción 1: Upgrade a 2.4.9-alpha2 en staging. Si tenés un entorno de staging robusto, podés testear Magento 2.4.9-alpha2 en paralelo, confirmar que funciona con tus extensiones y personalizaciones, y planificar un upgrade en producción en el momento más seguro. Es riesgoso pero viable si tenés team técnico dedicado.

Opción 2: Migrar a SaaS. Algunos hosted ecommerce like Shopify, BigCommerce o soluciones cloud administradas de Magento (Magento Cloud) ya tienen el fix aplicado automáticamente. Si tu tienda es pequeña-mediana, una migración podría ser más rápida que testear un parche incierto.

Opción 3: Aplicar mitigaciones agresivas y esperar. Si tu tienda está bien segmentada (firewall WAF robusto, monitoreo 24/7, backups diarios), podés mantener 2.4.7/2.4.8 aplicando todas las mitigaciones listadas arriba y esperar a que Adobe publique 2.4.9 de forma estable. No es ideal, pero es viable si no tenés la libertad de cambiar plataforma.

Lecciones para otras plataformas de ecommerce

Aunque PolyShell es específico de Magento, la vulnerabilidad deja lecciones importantes para cualquier plataforma de ecommerce que maneja uploads de archivo.

WooCommerce en WordPress: WooCommerce no está directamente afectado porque usa una arquitectura diferente para el carrito. Pero si instalás extensiones que permiten custom file uploads en el carrito, revisá que implementen validación estricta de tipos de archivo.

Shopify: No vulnerable porque el control total del backend está en manos de Shopify, no del usuario.

BigCommerce: No vulnerable por la misma razón.

Soluciones self-hosted: Si corrés cualquier plataforma self-hosted que permita uploads, aplicá estos principios: validar tipos de archivo de forma estricta (whitelist, no blacklist), nunca confiar solo en el MIME type declarado, guardar uploads fuera de directorios ejecutables, y monitorear constantemente accesos sospechosos.

Resumen: estado actual y próximos pasos

A mayo 2026, PolyShell sigue siendo una vulnerabilidad crítica sin parche oficial para la mayoría de tiendas Magento en producción. La explotación masiva continúa. El 56,7% de tiendas vulnerables está siendo atacada activamente, y los atacantes han evolucionado de defacement visible a exfiltración silenciosa de datos de tarjetas de crédito.