PolyShell: falla crítica afecta todas las tiendas Magento

La vulnerabilidad PolyShell en Magento es una falla crítica descubierta por Sansec que permite ejecución remota de código (RCE) sin autenticación en todas las versiones de Magento Open Source y Adobe Commerce 2. El exploit aprovecha archivos polyglot subidos a través de la API REST para inyectar webshells en el servidor, y ya fue vinculado a una campaña de defacement que comprometió más de 7.500 dominios en marzo de 2026.

Qué es PolyShell: la vulnerabilidad PolyShell Magento que afecta a todas las tiendas

PolyShell es una vulnerabilidad de file upload sin restricción descubierta por el equipo de investigación de Sansec, empresa holandesa especializada en seguridad de ecommerce. El nombre combina dos conceptos: «polyglot» (un archivo que es válido simultáneamente como imagen y como código PHP) y «shell» (la webshell que se ejecuta en el servidor una vez subido el archivo).

Lo que hace a esta falla particularmente grave es su alcance. No afecta una versión específica ni requiere una configuración rara: todas las versiones estables de Magento Open Source 2 y Adobe Commerce 2 son vulnerables, desde la primera release 2.0.0 hasta la 2.4.8-p3. Eso incluye las versiones que hoy están en producción en cientos de miles de tiendas en todo el mundo.

El impacto se divide en dos escenarios según la configuración del servidor. En el peor caso, un atacante logra RCE completo — ejecución remota de código — sin necesitar ningún tipo de credencial. En el escenario «menos grave» (que sigue siendo crítico), se obtiene stored XSS con capacidad de account takeover, lo que permite robar sesiones de administradores y tomar control de la tienda.

Cómo funciona el exploit: archivos polyglot en la API REST

El vector de ataque es la API REST de Magento, específicamente el endpoint que maneja las opciones personalizadas 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 file_info que contiene tres campos: los datos del archivo en base64, el MIME type declarado y el nombre del archivo.

El problema es que Magento escribe ese archivo en el directorio pub/media/custom_options/quote/ sin validar adecuadamente ni el contenido real del archivo ni su extensión contra el MIME type declarado. Un atacante puede entonces subir un archivo polyglot: un archivo que tiene los magic bytes de una imagen JPEG al principio (para pasar las validaciones superficiales de MIME) pero contiene código PHP ejecutable embebido.

Fijate que ni siquiera necesitás una cuenta de cliente en la tienda. La API REST permite agregar items al carrito como guest, y el upload de archivos se procesa antes de cualquier checkout. La request es un simple POST al endpoint del carrito con el payload malicioso en base64. GraphQL, por otro lado, no está afectado porque usa un path diferente para el manejo de archivos. Si te interesa, podés leer más sobre instalar WooCommerce en tu sitio WordPress.

Una vez que el archivo polyglot está en el servidor, el atacante solo necesita que el servidor web lo ejecute como PHP. Y acá es donde entra la configuración del servidor.

Versiones afectadas y escenarios de explotación

Según el análisis 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 son iguales.

Ejemplo concreto: una tienda corriendo Magento 2.2.11 en nginx con la configuración que viene en el repositorio oficial de Magento es directamente vulnerable a RCE. El atacante sube el polyglot, accede a /media/custom_options/quote/archivo.php y tiene shell. Así de simple.

Para versiones más recientes con nginx bien configurado, el RCE directo no funciona porque nginx no routea archivos .php dentro de pub/media/ a PHP-FPM. Pero el archivo polyglot igual se sube, y si contiene JavaScript malicioso en lugar de PHP, el stored XSS permite robar cookies de sesión de administradores que revisen pedidos con archivos adjuntos.

La campaña de defacement masivo: 7.500 sitios Magento comprometidos

PolyShell no es una vulnerabilidad teórica. Según el reporte de Netcraft, desde el 27 de febrero de 2026 se detectó una campaña de defacement a gran escala que afectó más de 15.000 hostnames distribuidos en 7.500 dominios únicos.

Lo llamativo es la escala y los targets. Entre los dominios comprometidos hay infraestructura asociada a marcas globales como Asus, FedEx, Fiat, Lindt, Toyota y Yamaha. No son tiendas chicas ni abandonadas — son propiedades digitales de empresas con equipos de seguridad y presupuesto. El atacante (o grupo) se identificó como «Typical Idiot Security» y se dedicó a dejar mensajes de defacement en las tiendas comprometidas.

¿Cuántas de estas intrusiones aprovecharon PolyShell específicamente? No está 100% confirmado que todas usaron este vector. 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ó a fines de febrero, justo cuando los detalles técnicos de PolyShell empezaron a circular en la comunidad de seguridad. Si te interesa, podés leer más sobre acceder al panel de WordPress.

Hay otro dato que preocupa: defacement es la forma más visible y «ruidosa» de explotación. Los ataques silenciosos — robo de datos de tarjetas de crédito, instalación de skimmers JavaScript, backdoors persistentes — no dejan pantalla de aviso. Si 7.500 sitios fueron defaceados, ¿cuántos fueron comprometidos silenciosamente?

Estado del parche: por qué Adobe no protege a las tiendas en producción

Acá viene el tema más polémico. Adobe incluyó el fix para PolyShell en la rama pre-release de Magento 2.4.9 (específicamente en la alpha2). El boletín APSB26-05 de marzo 2026 cubre 19 vulnerabilidades, 6 de ellas clasificadas como críticas.

El problema es que Adobe no publicó un parche aislado 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. Ninguna tienda seria corre una versión alpha en producción — eso es para entornos de desarrollo y testing. El fix existe, pero está atrapado en una rama que nadie puede usar en producción.

El contraste con WordPress es brutal. Cuando WordPress detecta una vulnerabilidad crítica, publica un hotfix que se aplica automáticamente en millones de sitios en cuestión de horas. Magento, bajo la gestión de Adobe, depende de ciclos de release que pueden tardar semanas o meses. Mientras tanto, las tiendas quedan expuestas.

Para ser justo: parchear Magento es más complejo que parchear WordPress. Las tiendas de ecommerce tienen integraciones de pago, personalizaciones pesadas y procesos de QA rigurosos antes de aplicar cualquier update. Pero eso no justifica no ofrecer un parche aislado que los equipos puedan evaluar y aplicar por su cuenta.

Cómo proteger tu tienda Magento ahora mismo

Mientras no haya parche oficial para producción, estas son las mitigaciones concretas que podés implementar hoy: Si te interesa, podés leer más sobre guía para instalar WordPress desde cero.

Bloquear ejecución PHP en el directorio de uploads

La mitigación más efectiva. En nginx, agregá una regla que devuelva 403 para cualquier request a archivos .php dentro de pub/media/custom_options/. En Apache, un .htaccess con php_flag engine off o RemoveHandler .php en ese directorio. Esto no previene el upload del archivo malicioso, pero le corta las piernas al RCE porque el servidor no lo ejecuta.

Implementar WAF con reglas específicas

Un WAF como Cloudflare o Sucuri puede filtrar requests sospechosos a la API REST del carrito. Configurá reglas que inspeccionen el body de los POST a endpoints de cart que contengan file_info con extensiones ejecutables (.php, .phtml, .phar) en el campo filename. No es infalible (los polyglots pueden evadir inspecciones superficiales), pero suma una capa.

Escanear el servidor en busca de webshells

Si tu tienda estuvo expuesta, es probable que ya haya sido comprometida. Escaneá el directorio pub/media/ completo buscando archivos .php que no deberían estar ahí. Herramientas como php-malware-finder de NBS System o el scanner de Sansec (eComscan) están diseñadas para detectar webshells y backdoors en Magento.

Monitorear logs de la API REST

Revisá los logs de acceso buscando requests POST a endpoints tipo /rest/V1/guest-carts/*/items con payloads inusualmente grandes (un polyglot pesa más que un carrito normal). Automatizá alertas para este patrón.

Impacto en WordPress: qué pueden aprender los administradores de WP

Si tu tienda corre WooCommerce, podés respirar: PolyShell es exclusivo de Magento y no afecta a WordPress. Pero las lecciones que deja son directamente aplicables. Si te interesa, podés leer más sobre problemas frecuentes al actualizar WordPress.

WordPress maneja uploads de manera diferente y más segura por diseño. El directorio wp-content/uploads/ incluye un .htaccess que bloquea la ejecución de PHP por defecto. Además, WordPress valida el contenido real del archivo (no solo el MIME declarado) usando funciones como wp_check_filetype_and_ext(). Magento confió en la declaración del cliente sobre el tipo de archivo — un error de diseño fundamental.

Eso sí, WordPress no es inmune a vectores similares. Plugins de WooCommerce que aceptan uploads de usuarios (para productos personalizables, por ejemplo) pueden tener la misma clase de falla si no validan correctamente. Si usás un plugin que permite uploads en el frontend, verificá que: 1) valide el contenido real del archivo y no solo la extensión, 2) almacene los uploads fuera del webroot o en un directorio con ejecución PHP deshabilitada, y 3) renombre los archivos para evitar extensiones ejecutables.

Otro dato relevante: si administrás un ecommerce y buscás hosting para tu tienda WooCommerce, Donweb ofrece planes optimizados para WordPress con configuraciones de servidor que incluyen estas protecciones a nivel de infraestructura.

Historial de vulnerabilidades críticas en Magento: un patrón preocupante

PolyShell no es un caso aislado. Magento viene acumulando vulnerabilidades críticas que forman un patrón difícil de ignorar. En octubre de 2025, SessionReaper (CVE-2025-54236) fue activamente explotado para secuestrar sesiones de administradores. Los ataques Magecart, que inyectan skimmers de tarjetas de crédito en el checkout, llevan años siendo endémicos en el ecosistema. CosmicSting y el clásico Shoplift bug son otros capítulos de la misma historia.

¿Por qué Magento es un target recurrente? Porque maneja datos de pago. Una tienda Magento comprometida le da al atacante acceso a números de tarjetas de crédito, datos personales de clientes y credenciales de paneles de administración. El retorno de inversión para un atacante es directo y monetizable.

El patrón también refleja un problema estructural en cómo Adobe gestiona la seguridad de Magento desde la adquisición. Los ciclos de parches son lentos comparados con la comunidad de código abierto. Las actualizaciones son pesadas y riesgosas de aplicar. Y la comunicación con la comunidad de desarrolladores no siempre es ágil. Contraste eso con WordPress, donde un hotfix crítico se distribuye en horas y se aplica automáticamente. Si te interesa, podés leer más sobre realizar backups periódicos en WordPress.

Qué está confirmado y qué todavía no está confirmado

Confirmado

• La vulnerabilidad PolyShell afecta a todas las versiones estables de Magento Open Source 2 y Adobe Commerce 2 hasta 2.4.8-p3. Confirmado por Sansec y Adobe.
• El fix existe en la rama pre-release 2.4.9-alpha2. No hay parche aislado para versiones en producción al 21 de marzo de 2026.
• El boletín APSB26-05 de Adobe cubre 19 vulnerabilidades, 6 críticas, publicado en marzo de 2026.
• Netcraft detectó una campaña de defacement que afectó más de 7.500 dominios desde el 27 de febrero de 2026.
• GraphQL no es un vector de ataque para esta vulnerabilidad.

Pendiente de confirmación

• No está confirmado que la campaña de defacement de «Typical Idiot Security» use exclusivamente PolyShell como vector. Podría combinar múltiples vulnerabilidades.
• Adobe no anunció fecha concreta para un parche aislado para versiones en producción.
• El número real de tiendas comprometidas silenciosamente (sin defacement visible) es desconocido y probablemente mucho mayor que los 7.500 dominios reportados.

Errores comunes

«Mi tienda usa HTTPS, así que los uploads están protegidos» — HTTPS cifra el tránsito de datos entre el navegador y el servidor, pero no valida ni restringe qué archivos se suben. PolyShell funciona igual sobre HTTPS. La protección tiene que estar en la validación del archivo en el servidor, no en el canal de comunicación. También podés encontrar más noticias tech relacionadas en análisis técnico de la vulnerabilidad PolyShell.

Esto se conecta con New «PolyShell» flaw allows unauthenticated RCE on all Magen, donde lo cubrimos en detalle.

Además, es importante estar atento a lo que cubrimos en New «PolyShell» flaw allows unauthenticated RCE on all Magen para no ignorar riesgos de seguridad en tus implementaciones.

Para más contexto, mirá nuestro artículo sobre New «PolyShell» flaw allows unauthenticated RCE on all Magen.

Un fallo parecido fue el que cubrimos en New «PolyShell» flaw allows unauthenticated RCE on all Magen.

Para saber más sobre vulnerabilidades críticas como esta, consultá New «PolyShell» flaw allows unauthenticated RCE on all Magen.

Si querés profundizar en vulnerabilidades de código abierto, mirá New «PolyShell» flaw allows unauthenticated RCE on all Magen.

Podés profundizar en nuestro artículo sobre New «PolyShell» flaw allows unauthenticated RCE on all Magen.

«Si no tengo productos con opciones de tipo file, no estoy afectado» — El endpoint de la API REST existe y está activo independientemente de si tenés productos con opciones de upload configuradas. Un atacante puede hacer un POST directo al endpoint del carrito de compras con un payload de file_info construido a mano. No necesita que tu catálogo tenga productos con esa opción habilitada. También podés encontrar más noticias tech relacionadas en modelos open source como Mistral Small 4.

«Actualicé a la última versión estable, así que estoy cubierto» — La última versión estable (2.4.8-p3) es vulnerable. El fix solo está en la rama pre-release 2.4.9. Estar «al día» con los parches de Adobe no te protege en este caso, lo cual es parte del problema. La mitigación tiene que venir por configuración del servidor, no por actualización de Magento.

«Uso Cloudflare, así que mi WAF me cubre» — Un WAF genérico ayuda pero no garantiza bloqueo. Los archivos polyglot están diseñados específicamente para pasar validaciones superficiales de tipo de archivo. Necesitás reglas custom que inspeccionen los payloads base64 de la API REST de Magento, algo que las reglas genéricas de WAF no cubren por defecto.

Si administrás una tienda online, también te puede interesar cómo New «PolyShell» flaw allows unauthenticated RCE on all Magen, un problema que afecta a miles de sitios.

Si te interesa el panorama de vulnerabilidades críticas, cubrimos en detalle New «PolyShell» flaw allows unauthenticated RCE on all Magen.

Preguntas Frecuentes

¿Qué es la vulnerabilidad PolyShell y cómo afecta a mi tienda Magento?

PolyShell es una falla en la API REST de Magento que permite subir archivos PHP maliciosos disfrazados de imágenes sin necesitar autenticación. Si tu tienda corre cualquier versión de Magento 2 o Adobe Commerce 2 (hasta 2.4.8-p3), es vulnerable. El impacto va desde ejecución remota de código hasta robo de cuentas de administrador, dependiendo de la configuración del servidor. Si te interesa, podés leer más sobre migrar un sitio HTML a WordPress.

¿Cómo puedo proteger mi tienda si no hay parche oficial disponible?

La mitigación más efectiva es bloquear la ejecución de PHP en el directorio pub/media/custom_options/ a nivel de servidor web (nginx o Apache). Complementá con reglas de WAF que filtren uploads sospechosos en la API REST del carrito y escaneá el servidor en busca de webshells que ya se hayan subido.

¿Qué versiones de Magento y Adobe Commerce están afectadas por PolyShell?

Todas. Desde Magento Open Source 2.0.0 hasta Adobe Commerce 2.4.8-p3, toda la rama 2.x es vulnerable. El fix solo existe en la versión pre-release 2.4.9-alpha2, que no es apta para uso en producción. No hay parche aislado para las versiones estables al 21 de marzo de 2026.

¿Mi tienda WooCommerce está en riesgo por esta vulnerabilidad?

No. PolyShell es exclusivo de Magento y Adobe Commerce, no afecta a WordPress ni WooCommerce. Sin embargo, si usás plugins de WooCommerce que aceptan uploads de usuarios en el frontend, verificá que validen el contenido real del archivo y no solo la extensión declarada, porque el mismo tipo de ataque polyglot podría aplicarse a plugins mal desarrollados.

Conclusión

PolyShell expone un problema de diseño que lleva presente en Magento desde la versión 2.0.0 — una API REST que acepta archivos sin validación real y los almacena en un directorio potencialmente ejecutable. Que Adobe haya incluido el fix en una rama alpha sin ofrecer parche para producción deja a decenas de miles de tiendas en una posición incómoda: saben que son vulnerables pero no tienen una solución oficial que aplicar.

Si administrás una tienda Magento, la acción inmediata es clara: bloqueá la ejecución de PHP en pub/media/custom_options/, implementá reglas de WAF, y escaneá tu servidor hoy. No mañana. Los 7.500 dominios defaceados son solo la punta visible del iceberg.

Y si estás evaluando plataformas de ecommerce, esta situación refuerza algo que la comunidad viene señalando: el modelo de seguridad de Magento bajo Adobe necesita un cambio estructural en velocidad de respuesta. Mientras tanto, la seguridad depende de cada administrador.

Fuentes

• Sansec Research — Magento PolyShell: análisis técnico original de la vulnerabilidad
• BleepingComputer — New PolyShell flaw allows unauthenticated RCE on Magento e-stores
• Adobe Security Bulletin APSB26-05 — Parche de seguridad para Adobe Commerce y Magento
• Netcraft — Campaña de defacement masivo en sitios Magento
• The Hacker News — Magento PolyShell flaw enables unauthenticated code execution