Una vulnerabilidad crítica en el plugin Funnel Builder para WooCommerce está siendo explotada activamente desde mayo de 2026 para inyectar skimmers que roban datos de tarjetas de crédito en el checkout. Según The Hacker News, más de 40.000 tiendas WooCommerce con el plugin instalado quedaron expuestas, con casos confirmados de robo de datos en campo.
En 30 segundos
- La vulnerabilidad en Funnel Builder permite inyectar código malicioso en los ajustes globales de WooCommerce sin autenticación.
- Los atacantes disfrazan el skimmer como Google Tag Manager para evitar detección visual.
- El código captura números de tarjeta, CVV y dirección de facturación en tiempo real mientras el cliente escribe.
- La explotación activa fue confirmada por Sansec en mayo de 2026.
- La versión segura es 3.15.0.3: si no actualizaste, tu tienda puede estar comprometida ahora mismo.
WooCommerce es un plugin de WordPress desarrollado por Automattic que proporciona funcionalidades de comercio electrónico. Permite convertir un sitio WordPress en una tienda online para vender productos y servicios.
Qué es Funnel Builder y por qué es crítica esta vulnerabilidad
Funnel Builder es un plugin de WordPress que permite crear funnels de ventas integrados con WooCommerce: páginas de checkout personalizadas, upsells post-compra, formularios de captura. Lo usa cualquier tienda que quiera optimizar conversiones sin tocar código. Esa popularidad, más de 40.000 instalaciones activas, es exactamente lo que lo convierte en un blanco interesante para atacantes.
La falla es de control de acceso: un endpoint del proceso de checkout no validaba permisos correctamente, exponiendo métodos internos que permiten escribir en la configuración global del plugin. Sin estar autenticado. Sin ser admin. Sin nada.
Eso sí: el impacto no es «podés tirar el sitio». Es peor. Podés insertar código que se ejecuta silenciosamente en cada checkout, capturando datos de pago de cada cliente que complete una compra.
Cómo funciona el ataque: inyección de código sin autenticación
Poné que tenés Funnel Builder instalado y sin actualizar. Un atacante manda una request HTTP al endpoint de checkout del plugin, sin token, sin cookie de sesión. La request incluye un payload que modifica los ajustes globales de «External Scripts» en la configuración de checkout.
¿Y qué pasó cuando lo probaron en producción? Exacto: funcionó. Los métodos internos del plugin que manejan esa configuración no verificaban si quien llama tiene permisos para hacerlo.
El resultado práctico: el atacante escribe un script externo en la configuración. Ese script se carga en cada página de checkout de tu tienda. A partir de ahí, el skimmer está activo.
Lo que hace el skimmer es registrar eventos de input en los campos del formulario de pago mientras el cliente escribe, acumular los datos, y exfiltrarlos a un servidor de comando y control vía WebSocket. Sin recargar la página. Sin alertas al usuario. Sin que el sistema de pagos de WooCommerce detecte nada raro, porque el robo ocurre antes de que el formulario se envíe.
El patrón Magecart: disfrazarse de Google Tag Manager
Magecart es el nombre que el sector usa para este tipo de ataques: skimmers de JavaScript inyectados en sitios de e-commerce para robar datos de tarjetas. No es un grupo específico, es una técnica. Y en este caso la implementación tiene una característica concreta que la hace difícil de detectar: el script malicioso se carga con un nombre que imita Google Tag Manager.
El tag luce algo así: gtm-analytics-loader.js o variantes similares que un webmaster no-experto en seguridad vería y asumiría que es parte del setup de analytics. (Sí, en serio. GTM tiene tanto código legítimo flotando por ahí que una copia falsa pasa desapercibida.)
La comunicación con el servidor de comando y control usa WebSocket, lo que le da otra ventaja: muchas herramientas de monitoreo de red que buscan requests HTTP salientes no capturan conexiones WebSocket con el mismo nivel de detalle.
El servidor C2 recibe los datos capturados de forma incremental. No espera que el usuario termine de escribir el número de tarjeta completo para enviarlo; lo manda en chunks mientras el cliente tipea. Eso reduce la chance de que una herramienta de detección que analiza payloads completos lo identifique.
Robo de datos de pago: qué información capturan
Los campos objetivo son los del checkout estándar de WooCommerce:
- Número de tarjeta de crédito/débito
- Fecha de vencimiento
- CVV/CVC
- Nombre del titular
- Dirección de facturación completa
Todo lo que necesitás para hacer compras fraudulentas online sin tener la tarjeta física. El skimmer no roba credenciales de la cuenta de WooCommerce ni datos de envío directamente, pero con esa información de pago es suficiente para el fraude.
Peor: el cliente completa su compra normalmente. El pago se procesa. No hay error. El robo ocurre en paralelo, sin interferir con la transacción legítima. El cliente no sabe nada. Vos como dueño de la tienda tampoco, a menos que estés monitoreando activamente los scripts que se cargan en tu checkout.
Confirmación de explotación activa en mayo de 2026
Sansec, una de las empresas que monitorea ataques Magecart a escala, confirmó casos activos en campo durante mayo de 2026. La explotación no es teórica: hay tiendas comprometidas, hay datos de clientes siendo exfiltrados.
Según BleepingComputer, la campaña apunta específicamente a instancias de Funnel Builder sin actualizar, con un script de reconocimiento que prueba el endpoint vulnerable antes de insertar el payload completo. Es una operación con cierto nivel de automatización, no ataques manuales uno a uno.
La ventana de exposición es la que va desde versiones previas a 3.15.0.3. Si tu tienda tiene instalada cualquier versión anterior y no la actualizaste desde que salió el parche, hay riesgo concreto de que ya haya sido comprometida.
Cómo detectar si tu sitio está comprometido
Antes de actualizar, conviene revisar si el daño ya está hecho. Hay un camino directo:
Paso 1: Revisá los scripts externos en la configuración. En tu admin de WordPress, andá a la sección de ajustes de Funnel Builder, buscá «Checkout» y dentro de eso «External Scripts» o «Scripts externos». Si ves alguna URL que no reconocés, especialmente algo que imite Google Tag Manager con un nombre ligeramente distinto al dominio oficial de Google, ahí está el problema.
Paso 2: Analizá el código fuente del checkout. Cargá tu página de checkout sin estar logueado y mirá el código fuente. Buscá cualquier <script src= que no corresponda a tu configuración conocida. Comparalo contra lo que tenías antes si tenés historial en un plugin de monitoreo.
Paso 3: Revisá en WPScan y Patchstack. Tanto WPScan como Patchstack tienen la vulnerabilidad documentada con los indicadores de compromiso. Patchstack en particular tiene detalles sobre los patrones de nombres usados por los scripts maliciosos.
Paso 4: Revisá los logs de acceso del servidor. Buscá requests POST al endpoint de checkout del plugin que vengan de IPs que no correspondan a usuarios reales. Si usás un hosting con panel (el de donweb.com incluye esto en los planes), tenés acceso a los logs de acceso desde el panel de control.
Si encontrás el script malicioso, borralo de la configuración manualmente antes o después de actualizar. Actualizar el plugin no limpia los cambios que el atacante ya escribió en la configuración.
Parchear la vulnerabilidad en Funnel Builder: actualización a 3.15.0.3
El parche está en la versión 3.15.0.3. El proceso de actualización es el estándar de WordPress:
- Desde el admin: Plugins > Actualizaciones disponibles > Funnel Builder > Actualizar.
- Con WP-CLI:
wp plugin update funnel-builder - Con WP-CLI verificando la versión:
wp plugin get funnel-builder --field=version
Después de actualizar, revisá la configuración de External Scripts en Checkout (descripta arriba) para confirmar que no quedaron scripts inyectados. La actualización cierra la puerta, pero no limpia lo que ya entró.
Si encontrás scripts sospechosos, borralos, guardá los cambios, y hacé una revisión del historial de transacciones de los últimos días para evaluar si necesitás notificar a clientes sobre un posible compromiso de datos. Dependiendo de tu jurisdicción (y si operás con clientes europeos, por GDPR), puede haber obligación legal de notificación.
Tabla: versiones afectadas vs. estado del parche
| Versión de Funnel Builder | Estado | Acción requerida |
|---|---|---|
| Anterior a 3.15.0.3 | Vulnerable | Actualizar de inmediato + revisar config |
| 3.15.0.3 | Parcheado | Verificar que no haya scripts inyectados |
| No instalado / desactivado | No afectado | Sin acción requerida |
Mejores prácticas: auditoría continua de scripts externos
Este ataque funciona porque nadie monitorea qué scripts se cargan en el checkout. La solución al problema puntual es actualizar. La solución al problema estructural es tener visibilidad.
Algunas medidas concretas:
- Content Security Policy (CSP): configurar una política que solo permita cargar scripts desde dominios en whitelist. Cualquier script externo no listado se bloquea y se registra en el navegador. Es la defensa más efectiva contra este tipo de inyección.
- Monitoreo de integridad de archivos: plugins como Wordfence (que probablemente ya tenés instalado) tienen detección de cambios en archivos y configuración. Configurá alertas para cambios en settings del checkout.
- Revisión periódica de scripts activos: una vez por semana, mirá el código fuente de tu checkout. Lleva dos minutos. Si aparece algo que no pusiste vos, lo sabés rápido.
- Logs de acceso al admin: registrar cambios en configuraciones críticas, especialmente en settings de checkout y scripts externos.
Ninguna de estas medidas requiere un presupuesto especial. Requieren el hábito.
Errores comunes al manejar este tipo de incidente
Actualizar el plugin y asumir que el problema está resuelto
El parche cierra la vulnerabilidad pero no limpia la inyección que ya existe en la configuración. Si el atacante ya escribió el script malicioso antes de que actualizaras, sigue ahí. Tenés que revisarlo y borrarlo manualmente.
No revisar el rango de fechas comprometido
Si encontrás evidencia de compromiso, el paso siguiente es entender desde cuándo. Revisá los logs del servidor para identificar cuándo se realizó la request maliciosa que modificó la configuración. Eso te da el rango de tiempo durante el cual se estuvieron robando datos, información que necesitás para evaluar el alcance y potencialmente notificar a clientes.
Asumir que el «Google Tag Manager» en la config lo pusiste vos
Este es el gancho del ataque. El script malicioso se llama de forma que parece legítimo. Si ves un tag que imita GTM y no recordás haberlo configurado, no asumas que lo hizo alguien de tu equipo. Verificá contra tu configuración real de Google Tag Manager. Si el ID de GTM no coincide con el que tenés en tu cuenta de Google, es falso.
Preguntas Frecuentes
¿Qué es la vulnerabilidad de Funnel Builder?
Es un fallo de control de acceso en el plugin Funnel Builder para WooCommerce que permite a un atacante no autenticado escribir scripts maliciosos en la configuración global de checkout. Está activamente explotada desde mayo de 2026 para robar datos de pago de clientes. La versión 3.15.0.3 cierra la falla.
¿Cómo proteger mi tienda WooCommerce de robo de datos?
El primer paso es actualizar Funnel Builder a 3.15.0.3 y revisar la configuración de External Scripts en Checkout para eliminar cualquier script inyectado. A largo plazo, implementar una Content Security Policy y monitoreo de integridad de configuración reduce el riesgo de este tipo de ataques.
¿Cómo sé si mi sitio está comprometido por este exploit?
Revisá los ajustes de External Scripts en la configuración de Funnel Builder desde el admin de WordPress. También mirá el código fuente de tu página de checkout buscando scripts con URLs que no reconocés, especialmente los que imitan Google Tag Manager. WPScan y Patchstack tienen documentados los indicadores de compromiso específicos de esta campaña.
¿Cuál es la versión segura de Funnel Builder?
La versión 3.15.0.3 incluye el parche que corrige el control de acceso en el endpoint de checkout. Cualquier versión anterior está expuesta. Actualizando desde el admin de WordPress o con WP-CLI tenés el parche disponible de forma inmediata.
¿Cómo detectar scripts maliciosos disfrazados de Google Tag Manager?
Compará el ID de contenedor que aparece en el script con el ID real de tu cuenta de Google Tag Manager. Un GTM legítimo usa el formato GTM-XXXXXXX y el código se carga desde googletagmanager.com. Si el dominio de carga es diferente, o el ID no coincide con el tuyo, es falso. Cualquier script de «GTM» que no hayas configurado vos deliberadamente merece revisión inmediata.
Conclusión
La vulnerabilidad en Funnel Builder es el tipo de falla que en retrospectiva parece obvia: un endpoint que escribe en configuración global sin verificar quién hace la llamada. El resultado son tiendas WooCommerce comprometidas con skimmers activos robando datos de tarjetas en tiempo real, disfrazados de Google Analytics.
Si tenés Funnel Builder instalado, actualizá a 3.15.0.3 hoy. Luego revisá la configuración de scripts externos en el checkout. Si encontrás algo que no pusiste vos, asumí que el compromiso es real y revisá el rango de fechas afectado.
Y si esta campaña te resultó una sorpresa, es señal de que el monitoreo de scripts activos en tu checkout no existe como práctica. Es el momento para instalarlo.
Fuentes
- The Hacker News – Funnel Builder Flaw Under Active Exploitation
- BleepingComputer – Funnel Builder WordPress Plugin Bug Exploited to Steal Credit Cards
- WPScan – Vulnerabilidades documentadas del plugin Funnel Builder
- Patchstack – Base de datos de vulnerabilidades: Funnel Builder
- SC World – WordPress Funnel Builder Vulnerability Exploited to Steal Payment Data