El secuestro del checkout de HulkApps: cómo apps de confianza de Shopify se convirtieron en un embudo de phishing

Resumen: el secuestro del checkout de HulkApps en Shopify

• Qué pasó: desde el 2026-10-10, los compradores de varias tiendas Shopify que pulsaban Checkout acababan en una página de pago falsa en biliing[.]top, que se quedaba con los datos de su tarjeta y luego los reenviaba al checkout real.
• Cómo entró: el archivo de la app Hulk Product Options en cdn.shopify.com estaba limpio. El código del ataque llegaba desde la API de configuración de HulkApps en un campo de JavaScript personalizado y se inyectaba en tiempo de ejecución. Swym Wishlist Plus y Selleasy fueron atacadas del mismo modo.
• Por qué pasó desapercibido: solo se activaba con un clic real en Checkout, una vez por sesión del navegador, en dominios que ninguna lista de bloqueo conocía. Los escáneres, CSP y la mayoría de las pruebas manuales veían una tienda normal.

¿Poco tiempo? Consulta la monitorización de scripts del lado del cliente de cside. Cubre todo lo de abajo en un solo despliegue.

El 2026-10-10, el desarrollador Roman Zipp estaba comprando en una conocida tienda Shopify. Añadió un teclado al carrito, pulsó Checkout y llegó a lo que parecía un checkout de Shopify normal. La única pista fue que su gestor de contraseñas le ofreció rellenar el campo "Nombre" con el nombre de su tarjeta de crédito. Miró la barra de direcciones: biliing[.]top/check-out/.

El pedido se habría completado. Una vez que la página falsa tenía los datos de la tarjeta, lo enviaba directamente al checkout auténtico de la tienda. La tarjeta habría estado comprometida y nada en los datos de pedidos del comerciante habría parecido fuera de lo normal.

El código no estaba en el tema de la tienda, y el propio checkout de Shopify nunca se tocó. Llegó a través de Hulk Product Options, una app de personalización de productos de HulkApps con muchas instalaciones, como un bloque de "JavaScript personalizado" devuelto por la propia API del proveedor. En pocos días, comerciantes que nunca habían instalado un producto de HulkApps informaban del mismo checkout falso, rastreado hasta apps de otros proveedores. Es un ataque a la cadena de suministro del lado del cliente en su forma más pura: un tercero al que los comerciantes habían dado acceso legítimo a los navegadores de sus clientes se convirtió en el canal de entrega.

Cómo funcionó el ataque

Cada eslabón de esta cadena parecía legítimo por sí solo. Zipp lo rastreó paso a paso en Chrome DevTools.

1. Se carga un archivo de confianza. Hulk Product Options incluye una extensión de tema que carga hulkcode.js en las páginas de la tienda. El archivo se sirve desde cdn.shopify.com como parte del paquete de la extensión. No fue modificado.
2. El archivo pide su configuración. Al cargar la página, hulkcode.js envía una petición POST a productoption.hulkapps.com/api/v2/store/get_all_relationships con el ID de la tienda y el producto que se está viendo.
3. La configuración contiene código. La respuesta JSON incluye un campo advanced_users.custom_js, una función que permite a los comerciantes añadir su propio JavaScript. En las tiendas afectadas contenía unos 22,7 KB de código de ataque sin minificar.
4. El código se inyecta en tiempo de ejecución. La app escribe esa cadena en la página como un script. En DevTools aparece como un script VM anónimo sin archivo de origen, que es justo lo que lo hace difícil de detectar.
5. Se secuestra el clic en Checkout. El script registra un listener de clics. Cuando el comprador pulsa Checkout, una función llamada literalmente hijack cancela la navegación real y redirige a un checkout falso en un dominio del atacante.
6. El checkout falso recoge la tarjeta. La página falsa imita un checkout de Shopify y pide datos de pago y personales.
7. Los datos salen. El formulario envía todo a /api/submissions en el dominio del atacante, que responde con un ID de registro.
8. El comprador vuelve. La página falsa reenvía al comprador al checkout auténtico de Shopify, donde el pedido se completa con normalidad. El script también guarda __ctf_shim_handoff_done_v1 en el almacenamiento de sesión para no activarse dos veces en la misma sesión.

Los pasos 1 y 2 son exactamente lo que la app hace en todas las tiendas, todos los días. Todo el ataque estaba en los datos que devolvía la API del proveedor.

Las decisiones de diseño son deliberadas. Redirigir solo con el clic en Checkout hace que las cargas pasivas de página parezcan limpias. Activarse una vez por sesión hace que el comerciante, el proveedor de la app y cualquiera que investigue una queja de un cliente vean normalmente un checkout normal al intentar reproducirlo. Y como el pedido robado se completa en el checkout real, los paneles de ingresos no muestran nada raro.

Nunca fue solo HulkApps

HulkApps fue el primer nombre asociado a esta campaña, pero la historia no termina ahí. Varias apps populares de distintos proveedores entregaron la misma redirección a la misma familia de dominios, y en todos los casos la carga estaba dentro de datos de configuración que la app descargaba de los servidores de su proveedor.

Es tentador leerlo como la brecha de un solo proveedor. La evidencia apunta a algo más incómodo: alguien recorriendo sistemáticamente apps de Shopify que permiten que datos de configuración se conviertan en código ejecutable en la tienda. Aún no se sabe si fue por una debilidad compartida, credenciales robadas o varias intrusiones distintas. A 2026-10-16, las fichas de Hulk Product Options, Swym Wishlist Plus y Selleasy en la App Store figuraban como no disponibles, y una comerciante australiana contó a iTnews que Shopify le había aconsejado mantener su tienda cerrada.

Por qué esquivó las defensas habituales

El ataque no era código sofisticado. Era una ubicación sofisticada. Casi todos los controles en los que un comerciante podía confiar miraban la capa equivocada.

• El archivo del script nunca cambió. hulkcode.js llegaba desde cdn.shopify.com con el mismo contenido de siempre. Las comprobaciones de hash y Subresource Integrity habrían pasado, porque la parte maliciosa llegaba como datos, no como archivo.
• Los orígenes ya eran de confianza. El CDN y la API del proveedor son justo los hosts que la Content Security Policy de una tienda permitiría. No apareció nada nuevo en las listas de scripts ni de conexiones. Permitir esos hosts no basta por sí solo para que una tienda ejecute una cadena de código descargada de una API: un script-src estricto sin 'unsafe-inline' ni 'unsafe-eval' la habría rechazado. Pero los temas y las apps de las tiendas dependen mucho de scripts en línea, así que pocas tiendas pueden aplicar una política tan estricta.
• El robo ocurrió fuera del sitio. El formulario de pago estaba en el dominio del atacante, así que ningún dato salió de la propia página de la tienda. CSP no controla la navegación de nivel superior, y el connect-src de la tienda nunca vio la petición de exfiltración.
• El disparador necesitaba un clic real. Los escáneres sintéticos que rastrean páginas, o incluso cargan el carrito, no pulsan Checkout como un comprador. Para ellos, la carga permanecía inactiva.
• Se ejecutaba una vez por sesión. Las pruebas manuales de comerciantes y equipos de soporte solían salir limpias, lo que retrasó los avisos e hizo que las primeras quejas parecieran casos aislados.
• Las listas de bloqueo fueron lentas. El 2026-10-10, ninguno de los tres dominios que encontró Zipp estaba en Google Safe Browsing ni en URLhaus, y sus bloqueadores de anuncios y filtros DNS los dejaron pasar. Una publicación en Reddit había señalado el mismo dominio unos 18 días antes.
• El checkout de Shopify estaba bien. El checkout de Shopify nunca se vio comprometido, y esa es la cuestión. El ataque se ejecutaba en la tienda, antes de la página de pago, donde no llegan las protecciones de la plataforma.

El único lugar fiable para ver este ataque es donde realmente se ejecutaba: dentro del navegador de un comprador real, en el momento en que el script reconfiguraba el botón de checkout.

Indicadores de compromiso

Los dominios están neutralizados. No los visites.

Si encuentras cualquier clave __ctf_ en el almacenamiento de sesión de tu tienda, trátalo como un caso confirmado de esta campaña.

Qué deben hacer ahora los comerciantes

Si tienes una tienda Shopify con apps de terceros, da por hecho que debes revisarla, aunque nunca hayas instalado nada de HulkApps.

1. Prueba el checkout en una sesión nueva, más de una vez. Abre una ventana privada nueva, añade un producto, pulsa el botón Checkout normal y vigila la barra de direcciones. Cierra la ventana y repite. Hazlo también desde el carrito lateral y en un móvil. Tu checkout debe permanecer en tu propio dominio o en tu dirección myshopify.com.
2. Busca la marca de sesión. Tras una prueba, abre DevTools, ve a Application y luego a Session storage, y busca claves que empiecen por __ctf_.
3. Audita los ajustes de apps que aceptan código. Cualquier app con un campo de "JavaScript personalizado" o "HTML personalizado" es un sitio donde puede esconderse código. Abre cada uno y confirma que reconoces todo lo que contiene.
4. Haz inventario de tus app embeds. En el editor de temas, lista cada app embed activado. Desactiva y desinstala lo que no uses activamente y revisa el tema en busca de fragmentos sobrantes.
5. Cambia credenciales. Cambia tu contraseña de Shopify y la del panel de cada proveedor de apps, y activa la autenticación en dos pasos allí donde se ofrezca. Revisa el acceso de colaboradores.
6. Si lo encuentras, conserva primero las pruebas. Haz una captura de la página falsa con la URL visible, guarda un archivo HAR desde la pestaña Network y anota la hora. Después desactiva la app, contacta por escrito con el proveedor, abre un caso con el soporte de Shopify y avisa a tu procesador de pagos.
7. Pide asesoramiento sobre notificaciones. Los datos de tarjeta introducidos en una página falsa a la que se llegó desde tu tienda pueden generar obligaciones con clientes o marcas de tarjetas. Habla con tu procesador y tu asesor legal.

Una advertencia de los comerciantes afectados en el hilo de la Shopify Community: la confirmación del proveedor de que el código ya no está no siempre ha bastado para que Shopify autorice reabrir una tienda. Guárdalo todo por escrito.

La perspectiva de PCI DSS 4.0.1

Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 existen exactamente para este tipo de ataque. El 6.4.3 pide a los comerciantes inventariar cada script de las páginas de pago, justificar cada uno y confirmar que está autorizado e íntegro. El 11.6.1 pide un mecanismo que detecte cambios no autorizados en esas páginas tal como las recibe el navegador del comprador. Ambos son obligatorios desde el 2025-03-31.

Muchos comerciantes de Shopify asumen que estos requisitos son problema de Shopify. Para el propio checkout, en gran medida lo son, como explicamos en ¿Shopify te hace cumplir PCI?. Pero desde enero de 2025, los comerciantes que validan con el SAQ A deben confirmar que su sitio no es susceptible a ataques mediante scripts que puedan afectar a sus sistemas de comercio electrónico. Un script en la tienda que cambia silenciosamente tu checkout por el de otro es exactamente eso. Consulta con tu adquirente qué obligaciones te aplican.

Este incidente también muestra por qué un inventario estático de scripts no basta por sí solo. El inventario habría listado hulkcode.js, correctamente, como autorizado. Lo que cambió fue su comportamiento: descargó código nuevo, lo inyectó, añadió un manejador de clics y llevó al comprador a un dominio que la tienda nunca había usado. Ver eso exige observar lo que los scripts hacen realmente en sesiones reales, no solo qué archivos se cargan.

Cómo aborda cside este tipo de ataque

Sesiones reales, no rastreos sintéticos. cside monitoriza los scripts de terceros en sesiones reales de compradores en lugar de depender de un escaneo periódico. Una carga que solo se activa con un clic real en Checkout, una vez por sesión, se sigue ejecutando delante de nosotros.

Comportamiento, no solo origen. Seguimos lo que hace cada script: el código que inyecta, los listeners que añade, los datos que lee y adónde los envía. Un script de una app de confianza que de repente escribe código nuevo en la página y lleva a los compradores a un dominio que tu tienda nunca ha usado es una señal por sí misma, no algo oculto tras un host permitido.

Detenido en la sesión. Con Script Method, cside descarga cada script de terceros en el servidor para calcular su hash, archivarlo y analizarlo, y los bloqueos se aplican en tiempo de ejecución en el navegador, junto a CSP. Un script no autorizado, o una capacidad concreta que intente usar, se detiene en la sesión en lugar de notificarse a posteriori.

Ningún control por sí solo habría detenido todas las versiones de esta campaña. Pero la lección es la misma en todos los proveedores afectados: si código de terceros se ejecuta en los navegadores de tus clientes, necesitas visibilidad en los navegadores de tus clientes. Es la misma lección que dejó el ataque a la cadena de suministro de Polymarket a principios de este año, a través de otro proveedor y contra otro tipo de víctima.

Lo que aún no sabemos

• Cómo entraron los atacantes. HulkApps habla de un exploit y Logbase de acceso a una herramienta interna. Ninguno ha publicado la causa raíz.
• Si los incidentes están relacionados. Los dominios compartidos y las marcas __ctf_ idénticas apuntan al mismo operador, pero ni los proveedores ni Shopify lo han confirmado.
• Cuántas tiendas y compradores se vieron afectados. Shopify no ha publicado cifras.

Actualizaremos este artículo a medida que los proveedores y Shopify publiquen más información. El mérito del descubrimiento, la ingeniería inversa y la cronología pública es de Roman Zipp.

Los detalles anteriores reflejan la información pública y las declaraciones de los proveedores a 2026-10-16.

¿Quieres ver qué se está ejecutando realmente en los navegadores de tus compradores? Empieza gratis o reserva una demo para hablar con nuestro equipo.