Magecart convierte Stripe en su servidor de mando y control perfectamente camuflado

Cómo funciona el ataque de Magecart en tres etapas a través de Stripe

La campaña entrelaza tres etapas, cada una abusando de un servicio legítimo para evitar la detección .

Etapa 1: Inyectan el cargador a través de Google Tag Manager

Los atacantes primero comprometen un contenedor de Google Tag Manager (GTM) en la tienda objetivo. Insertan una etiqueta maliciosa que se carga en cada página. Debido a que el script se origina en googletagmanager.com, un dominio de análisis de confianza, elude las típicas Políticas de Seguridad de Contenido (CSP) y los bloqueadores de anuncios sin levantar alarmas . GTM se convierte en el mecanismo de entrega imposible de bloquear.

Etapa 2: Obtienen el 'skimmer' desde la API de Stripe

En lugar de llamar a un servidor sospechoso de terceros, la etiqueta de GTM solicita la carga útil del 'skimmer' desde api.stripe.com. Los atacantes almacenan el 'skimmer' completo en JavaScript dentro de un campo de metadatos de Cliente en su propia cuenta de Stripe, utilizando una clave secreta de modo de prueba (sk_test_...) para escribirlo y recuperarlo . El 'skimmer' llega desde un dominio en el que los operadores de tiendas confían implícitamente como parte de su sistema de pagos, por lo que el monitoreo de red y las reglas CSP rara vez marcan la llamada a la API.

Etapa 3: Exfiltran los datos robados a la misma cuenta de Stripe

Cuando un comprador introduce los datos de su tarjeta de crédito, información personal y dirección de facturación al finalizar la compra, el 'skimmer' inyectado captura los datos y los envía de vuelta a la cuenta de Stripe de los atacantes. Escribe la información como registros de Cliente falsos o entradas de metadatos utilizando la misma API de Stripe . Dado que el tráfico de exfiltración se enruta directamente a api.stripe.com, se camufla perfectamente con las llamadas legítimas a la API de pago, haciendo que el robo sea esencialmente invisible para los registros del firewall y las herramientas de detección de anomalías .

Toda la operación ha estado activa al menos desde el 24 de diciembre de 2025, según los indicadores observados por los investigadores .

Por qué las claves secretas de modo de prueba son tan peligrosas aquí

Las claves secretas de modo de prueba de Stripe (sk_test_...) otorgan acceso completo de lectura y escritura dentro del entorno de pruebas (sandbox) y permiten la creación ilimitada de clientes y campos de metadatos falsos sin costo alguno . Debido a que las claves de prueba nunca activan cargos reales, es fácil pasar por alto su abuso. Los atacantes confían en que muchas organizaciones tratan las claves de prueba como de bajo riesgo y no auditan la actividad del sandbox con el mismo rigor que aplican al tráfico en vivo.

Una amenaza relacionada pero separada es la exposición de claves secretas de producción (sk_live_...), lo que daría a un atacante acceso directo a datos transaccionales reales y la capacidad de emitir reembolsos o transferir fondos . Si bien esta campaña utiliza claves de modo de prueba por sigilo, el principio subyacente es el mismo: las claves de API de Stripe, en cualquier modalidad, son credenciales poderosas que nunca deberían aparecer en código del lado del cliente o en contenedores de Google Tag Manager .

CVE-2026-3300: RCE crítica en Everest Forms Pro

Mientras la campaña de Stripe apunta a los flujos de pago del comercio electrónico, los propietarios de sitios WordPress se enfrentan a una amenaza igualmente urgente por una vulnerabilidad en un plugin que ha sido explotada activamente desde el 13 de abril de 2026 .

CVE-2026-3300 es una falla de ejecución remota de código (RCE) no autenticada en el plugin Everest Forms Pro, que tiene aproximadamente 4,000 instalaciones activas . La vulnerabilidad tiene una puntuación de 9.8 en la escala CVSS y afecta a todas las versiones hasta la 1.9.12 inclusive .

El error reside en la función process_filter() dentro del complemento de Cálculo (Calculation Add-on). Cuando la función de "Cálculo Complejo" está habilitada, el plugin toma los valores proporcionados por el usuario desde campos de formulario de tipo cadena de texto, los concatena directamente en una cadena de código PHP y pasa el resultado a eval() sin el debido escapado . La función sanitize_text_field() aplicada a la entrada no neutraliza las comillas simples u otros caracteres que tienen un significado especial en un contexto de código PHP, lo que permite a un atacante romper la cadena prevista e inyectar comandos arbitrarios .

Wordfence ha bloqueado más de 29,300 intentos de explotación e informa que los atacantes están desplegando cuentas de administrador no autorizadas como parte del proceso posterior a la explotación . Los propietarios de sitios deben buscar indicadores de compromiso (IoC), como nuevos usuarios administradores con nombres inesperados, archivos inusuales en el servidor o conexiones salientes sospechosas .

Medidas defensivas para ambas amenazas

Bloquear la cadena de ataque de Magecart en Stripe

• Reforzar Google Tag Manager. Restringir los contenedores de GTM solo a etiquetas aprobadas y auditadas, y exigir una aprobación estricta de gestión de cambios antes de publicar .
• Ajustar la Política de Seguridad de Contenido (CSP). No incluir api.stripe.com como script-src a menos que sea estrictamente necesario. Si se debe incluir, aplicar hashes de integridad de subrecursos (SRI). Bloquear los scripts en línea proporciona otra capa de defensa .
• Auditar la actividad del sandbox de Stripe. Monitorear el panel de Stripe en busca de volúmenes inusuales de creación de objetos de Cliente o escrituras de metadatos bajo claves de modo de prueba. Tratar las anomalías del sandbox con la misma seriedad que las del modo en vivo.
• Rotar y proteger las claves de API. Nunca incrustar claves secretas de Stripe —de prueba o de producción— en JavaScript del lado del cliente, variables de GTM o repositorios públicos . Rotar cualquier clave que pueda haber sido expuesta .
• Desplegar monitoreo del lado del cliente. Utilizar verificaciones de integridad en el navegador que detecten la manipulación del DOM (Modelo de Objetos del Documento) en las páginas de pago por parte de scripts no autorizados .

Parchear la vulnerabilidad de Everest Forms Pro

• Actualizar de inmediato. Actualizar a la versión 1.9.13 o posterior de Everest Forms Pro, que contiene la corrección .
• Desactivar la función de riesgo si el parche se retrasa. Como solución temporal, desactivar la función de "Cálculo Complejo" en los ajustes del plugin para prevenir la explotación a través de la entrada no escapada a eval() .
• Escanear en busca de signos de compromiso. Buscar cuentas de administrador desconocidas, archivos inesperados, llamadas sospechosas a la función eval() y conexiones de red salientes a IPs no familiares. Es esencial realizar una verificación de integridad completa de WordPress en las sumas de verificación de los archivos del núcleo, temas y plugins después de la remediación .