Nombre del complemento	Constructor de Embudos por FunnelKit
Tipo de vulnerabilidad	Secuencias de comandos entre sitios (XSS)
Número CVE	CVE-2025-12878
Urgencia	Bajo
Fecha de publicación de CVE	2026-02-01
URL de origen	CVE-2025-12878

Urgente: XSS almacenado en Funnel Builder (FunnelKit) <= 3.13.1.2 — Lo que los propietarios de WordPress necesitan saber y cómo WP‑Firewall te protege

Autor: Equipo de seguridad de firewall WP
Fecha: 2026-02-02

Resumen ejecutivo

Una vulnerabilidad de scripting entre sitios almacenada (XSS) que afecta a Funnel Builder (FunnelKit) versiones <= 3.13.1.2 fue divulgada públicamente el 2 de febrero de 2026 (CVE‑2025‑12878). La vulnerabilidad permite a un usuario autenticado con privilegios de Contribuyente almacenar JavaScript dentro del wfop_phone parámetro de shortcode que luego se ejecuta en los navegadores de los visitantes cuando se renderiza el shortcode afectado. El proveedor lanzó un parche en la versión 3.13.1.3.

Esta publicación explica, en términos prácticos:

• qué es la vulnerabilidad y por qué es importante;
• quién está en riesgo y escenarios de ataque realistas;
• cómo confirmar si tu sitio está afectado utilizando búsquedas de WordPress/WP‑CLI/SQL;
• mitigaciones inmediatas y endurecimiento de la seguridad a largo plazo;
• cómo WP‑Firewall protege tu sitio tanto ahora (parcheo virtual/WAF) como en el futuro.

Esta guía está escrita desde la perspectiva del equipo de seguridad de WP‑Firewall y asume que deseas pasos pragmáticos que puedes aplicar hoy (primero en staging, siempre).

---

Qué sucedió — hechos rápidos

• Plugin afectado: Funnel Builder de FunnelKit (plugin de WordPress).
• Versiones vulnerables: <= 3.13.1.2
• Corregido en: 3.13.1.3
• Tipo de vulnerabilidad: Scripting entre sitios almacenado (XSS)
• CVE: CVE‑2025‑12878
• Privilegio requerido para explotar: Contribuyente
• CVSS: 6.5 (medio)
• La explotación requiere interacción del usuario (visitar una página que renderiza la carga útil), pero la carga útil se almacena del lado del servidor (por lo que persiste y puede afectar a muchos usuarios).

---

Por qué el XSS almacenado es peligroso (recordatorio)

El XSS almacenado ocurre cuando un atacante puede inyectar JavaScript (o HTML con controladores de script) que se almacena en el servidor (en publicaciones, meta, configuraciones de plugins, etc.) y se sirve posteriormente a otros usuarios sin la debida sanitización o escape. Las consecuencias incluyen:

• Robo de sesión y toma de control de cuentas (robo de cookies, tokens de sesión);
• Escalación de privilegios si los administradores ven o editan el contenido afectado;
• Entrega de cargas útiles de segunda etapa (malware, scripts de criptominería, formularios de phishing);
• Desfiguración o inyección de contenido que socava la confianza y el SEO;
• Puertas traseras persistentes a través de configuraciones maliciosas de administrador inyectadas por XSS inicial.

Aunque el Contribuyente tiene un privilegio relativamente bajo, el XSS almacenado eleva el riesgo: un atacante con una cuenta de Contribuyente puede crear contenido que contenga la carga útil que luego se ejecutará en el navegador de cualquier usuario — incluidos los administradores — que vea las páginas de frontend o admin afectadas que renderizan el shortcode.

---

Resumen técnico (qué está sucediendo)

La vulnerabilidad proviene de una insuficiente sanitización/escape de entrada para los datos pasados a través del wfop_phone parámetro shortcode. Un usuario Contribuyente (que normalmente no puede publicar, pero puede agregar contenido que puede ser guardado en formularios de plugins, borradores u otras entidades gestionadas por plugins) puede incluir cargas útiles HTML/JS dentro de ese parámetro. Cuando el plugin renderiza más tarde el shortcode en una página, esas cargas útiles se muestran sin escapar, permitiendo que el navegador las ejecute.

Ejemplo (sanitizado por seguridad):

• Carga útil maliciosa como entrada almacenada (mostrada escapada): <script>/* JS malicioso */</script>
• Cuando el shortcode se renderiza sin escapar, el script se ejecuta en el contexto del navegador del visitante.

Debido a que esto está almacenado (no reflejado), el código inyectado persiste hasta que se elimina, y puede afectar a muchos visitantes o incluso a administradores del sitio que abren el contenido en sus navegadores.

---

Escenarios de ataque realistas

1. El atacante registra (o compromete) una cuenta de Contribuyente — muchos sitios permiten el registro o tienen controles de incorporación débiles.
2. El atacante crea contenido o actualiza una configuración de embudo/elemento/formulario donde wfop_phone se persiste con una carga útil de script.
3. El sitio publica más tarde el embudo/formulario o un administrador lo previsualiza, causando que la carga útil se ejecute en el contexto de usuarios registrados (incluidos los administradores) o invitados.
4. El script del atacante realiza acciones como:
   • Robar cookies/tokens de sesión (lo que lleva a la toma de control de la cuenta).
   • Crear un nuevo usuario administrador a través de cualquier punto final accesible por JS disponible.
   • Inyectar un backdoor o redirigir a los visitantes a phishing/malware.
   • Modificar la configuración del plugin/tema, incrustar una página de spam SEO, etc.

Incluso si el sitio requiere publicación de administrador, un Colaborador a veces puede crear contenido que un administrador previsualizará — y las previsualizaciones pueden ejecutar scripts en el navegador del administrador.

---

Cómo verificar si su sitio está afectado

Primero — siempre prueba en una copia de staging o fuera de línea de tu sitio. No ejecutes cargas útiles inseguras en producción.

1. Confirmar la versión del complemento
   • Ve a WordPress Admin → Plugins y verifica la versión de Funnel Builder / FunnelKit.
   • Si no puedes acceder al administrador, inspecciona wp-content/plugins/funnel-builder los encabezados del plugin en los archivos del plugin; verifica readme.txt o funnel-builder.php.
2. Si tienes acceso SSH, usa WP‑CLI:
   • Lista la versión instalada:

     wp plugin get funnel-builder --field=version

   • Actualiza el plugin (ver sección posterior) si es vulnerable.
3. Busque en su base de datos wfop_phone ocurrencias
   Usando phpMyAdmin, Adminer o cliente MySQL, ejecuta (ajusta el prefijo de la tabla si no es_):

   SELECT ID, post_title, post_status;

   Buscar postmeta:

   SELECT post_id, meta_key, meta_value;

   Opciones de búsqueda y otras tablas:

   SELECT option_name, option_value;

4. Usa WP‑CLI para buscar publicaciones y opciones:
   • Publicaciones:

     wp post list --post_type='any' --format=ids | xargs -I % wp post get % --field=post_content --raw | grep -n "wfop_phone"

   • Valores de opción de búsqueda (cuidado con bases de datos grandes):

     wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%wfop_phone%';"

5. Escanear con un escáner de seguridad (WP‑Firewall, escáneres de malware o scripts personalizados) — buscar ocurrencias de <script o JavaScript: dentro de cualquier contenido o datos de plugins.
6. Auditar usuarios con rol de Contribuyente: buscar registros recientes, nombres de usuario sospechosos o actividad repentina.

---

Mitigaciones inmediatas (qué hacer ahora — priorizado)

Si tu sitio ejecuta una versión vulnerable de FunnelKit o encuentras sospechas wfop_phone ocurrencias, sigue esta lista priorizada. Siempre trabaja en staging antes de hacer cambios en producción si es posible.

1. Actualiza el plugin (mejor solución)
   • Actualiza Funnel Builder a 3.13.1.3 o posterior inmediatamente a través del administrador de WordPress o WP‑CLI:

     wp plugin update funnel-builder

   • Si la actualización automática no está disponible, descarga el plugin parcheado del repositorio oficial de plugins e instálalo.
2. Desactivar temporalmente el complemento
   • Si no puedes actualizar inmediatamente, desactiva temporalmente Funnel Builder (admin → plugins) para evitar que se renderice el shortcode y detener la ejecución del script.
3. Elimina o neutraliza los shortcodes afectados
   • Reemplazar ocurrencias de [wfop_phone ...] uso en publicaciones/páginas con un marcador de posición seguro hasta que se parchee.
   • Ejecuta actualizaciones de base de datos para eliminar atributos sospechosos:

     UPDATE wp_posts;

   • Haz una copia de seguridad de tu DB antes de ejecutar cualquier actualización masiva.
4. Limpiar el contenido almacenado
   • Busca <script y otros controladores de eventos en el contenido de la publicación y los metadatos del complemento y eliminarlos:

     SELECCIONAR ID, post_title DE wp_posts DONDE post_content LIKE '%

5. Limitar privilegios de Colaborador (temporalmente)
   • Cambiar roles de miembros; restringir la capacidad de crear o editar formularios/funnel para Colaboradores hasta que el sitio esté parcheado.
   • Considerar deshabilitar temporalmente el registro en el front-end o requerir aprobación de administrador para nuevos usuarios.
6. Escanee en busca de indicadores de compromiso.
   • Buscar nuevas cuentas de administrador, archivos de complemento/tema modificados, tareas programadas desconocidas (cron) o archivos añadidos a uploads.
   • Revisar los registros del servidor en busca de solicitudes POST inusuales o entradas alrededor del momento en que se pudo haber almacenado una carga útil maliciosa.
7. secretos rotativos
   • Después de confirmar un estado limpio, rotar sales, claves API y cualquier credencial que pudiera haber sido filtrada.
8. Restaurar desde una copia de seguridad si encuentras puertas traseras persistentes.
   • Si la limpieza está incompleta o detectas una compromisión más profunda, restaura desde una copia de seguridad limpia y aplica todos los parches de seguridad.

---

Protecciones de WP‑Firewall — cómo ayudamos

Como un proveedor de firewall y seguridad de WordPress, WP‑Firewall tiene múltiples capas para proteger sitios de esta clase de vulnerabilidad, incluso antes de que se apliquen actualizaciones de complementos:

1. Parcheo virtual (regla WAF)
   • Desplegamos parches virtuales (reglas WAF) que interceptan solicitudes que intentan almacenar patrones de explotación conocidos en wfop_phone o en otras entradas de FunnelKit.
   • Ejemplo de patrón de firma WAF que usamos (conceptual; la regla real utiliza regex endurecido y verificaciones de contexto):
   • Bloquear HTTP POSTs/PUTs que contengan wfop_phone valores de parámetros que incluyan:
     • <script o variantes codificadas (%3Cscript%3E)
     • onerror=, al cargar=, JavaScript:, documento.cookie, o evaluar(
   • Regex conceptual para detectar etiquetas de script o controladores de eventos en valores de parámetros:

     (?i)(<\s*script\b|%3C\s*script|javascript:|on\w+\s*=|document\.cookie|eval\()

   • Ajustamos las reglas para evitar falsos positivos (por ejemplo, números de teléfono que contienen on subcadenas) verificando el contexto y los nombres de los parámetros.
2. Filtrado de respuestas
   • WP‑Firewall puede opcionalmente sanitizar las respuestas HTML salientes para eliminar las etiquetas en línea <script> insertadas a través de shortcodes antes de que lleguen a los clientes. Esta es una segunda línea de defensa y debe usarse con cuidado para evitar romper funcionalidades benignas.
3. Limitación de tasa y controles de registro
   • Bloquee o limite las registraciones automatizadas y los flujos de creación de cuentas de contribuyentes sospechosos para reducir las oportunidades de cuentas de atacantes.
4. Escaneo de archivos e integridad
   • Escaneamos en busca de archivos recién añadidos, archivos de plugins/temas modificados y cambios sospechosos que a menudo acompañan actividades de post-explotación.
5. Monitoreo de actividad y alertas
   • Las alertas para vistas previas de administrador sospechosas, cambios de contenido que contienen cargas útiles similares a scripts y actividad de cuentas de contribuyentes están disponibles para los administradores.
6. Soporte post-incidente
   • Si detecta un compromiso, el soporte de WP‑Firewall puede ayudar a eliminar código malicioso, restaurar estados seguros y recomendar pasos de endurecimiento.

Nota: el parcheo virtual es una mitigación de emergencia temporal y nunca debe ser un sustituto permanente para aplicar parches del proveedor. Siempre actualice a la versión del plugin corregida cuando esté disponible.

---

Reglas WAF recomendadas (técnicas, para equipos de seguridad)

A continuación se presentan reglas de detección sugeridas que puede implementar en un WAF. Estas son ilustrativas: pruebe las reglas en staging y evite patrones demasiado amplios para reducir falsos positivos.

1. Bloquee las solicitudes POST donde un nombre de parámetro contiene wfop_phone y el valor incluye <script o etiqueta de script codificada:
   Condición: El método HTTP es POST/PUT
   Parámetro: cuerpo (datos del formulario) o carga útil JSON
   Patrón:

   (?i)(wfop_phone).*?(%3C\s*script|<\s*script|javascript:|on\w+\s*=|document\.cookie|eval\(|window\.location)

2. Bloquear solicitudes con wfop_phone valor del parámetro que contiene atributos de eventos JS sospechosos:
   Patrón:

   (?i)wfop_phone=.*(onerror|onload|onclick|onsubmit|onfocus)=

3. Sanitizar el contenido renderizado (inspección de respuesta)
   Inspeccionar el HTML de salida para <script incrustado bajo wfop_phonemarcado relacionado; eliminar o escapar antes de responder.
4. Monitorear y alertar
   Si alguna solicitud coincide con la regla, registrar la solicitud completa con marca de tiempo, IP, agente de usuario y valores de parámetros capturados (almacenar registros de forma segura) y enviar una alerta a los administradores.

Importante: Las reglas de WAF son poderosas pero requieren ajustes para su sitio. Pruebe extensivamente ya que los campos de teléfono a veces contienen legítimamente caracteres que podrían activar reglas ingenuas (por ejemplo, signos más, paréntesis o formatos de número localizados).

---

Lista de verificación de respuesta a incidentes (paso a paso)

Si encuentra evidencia de explotación, use esta lista de verificación estructurada:

1. Contener
   • Desactivar el plugin vulnerable o aplicar el parche del proveedor.
   • Activar las reglas de protección de WP‑Firewall y aumentar el registro/alertas.
   • Desactivar temporalmente el registro de usuarios públicos si se abusa.
2. Investigar
   • Identificar cuándo se almacenó el contenido malicioso (marca de tiempo).
   • Identificar la(s) cuenta(s) de Contribuyente que almacenaron la carga útil.
   • Buscar otras instancias de wfop_phone y otros códigos cortos sospechosos.
   • Revisar los registros del servidor y de acceso en busca de IPs de atacantes y patrones de solicitud.
3. Erradicar
   • Eliminar contenido malicioso de la base de datos (publicaciones, postmeta, opciones).
   • Eliminar cualquier archivo malicioso o usuarios administradores no autorizados.
   • Limpiar las tareas programadas (ganchos wp_cron) creadas por el atacante.
4. Recuperar
   • Rotar todas las credenciales que puedan haber sido expuestas.
   • Reaplicar parches de seguridad y confirmar que el plugin está actualizado a 3.13.1.3 o posterior.
   • Restaurar desde una copia de seguridad limpia si no se puede garantizar la integridad.
5. Lecciones aprendidas
   • Revisar por qué existía la cuenta de Contribuidor y si un proceso de incorporación o moderación de contenido más estricto podría reducir el riesgo.
   • Implementar endurecimiento post-incidente: 2FA, privilegio mínimo para roles, revisar flujos de trabajo de publicación automática.
6. Notificar
   • Si se comprometieron datos o cuentas de usuario sensibles, seguir las políticas de notificación de violaciones aplicables e informar a los usuarios afectados.

---

Recomendaciones de endurecimiento preventivo

1. Principio de mínimo privilegio
   • Revisar roles y capacidades. Los Contribuidores solo deben tener lo que necesitan. Limitar el acceso a las páginas de administración del plugin.
2. Requerir moderación y revisión administrativa
   • Asegurarse de que las presentaciones de los contribuyentes sean revisadas por editores/admins antes de ser publicadas. Evitar la renderización automática de borradores de editores a admins sin sanitización.
3. Usar validación de entrada y sanitización
   • Los plugins que aceptan contenido de usuario deben sanitizar las entradas utilizando funciones estándar de WP:
     • Usar wp_kses() para la lista blanca de HTML.
     • Escapar la salida con esc_html(), esc_attr(), o wp_kses_post() según corresponda.
4. Mantenga actualizado el núcleo de WordPress, los temas y los complementos
   • Aplicar parches de seguridad de manera oportuna y mantener un proceso de staging para pruebas.
5. Aplique autenticación fuerte.
   • Usar 2FA para cuentas de admin/editor y habilitar políticas de contraseñas fuertes.
6. Limitar las ediciones directas de archivos y deshabilitar PHP exec donde sea posible
   • Prevenir editores de archivos en el panel para dificultar que los atacantes mantengan puertas traseras del lado del servidor.
7. Monitoreo continuo
   • La monitorización de la integridad de archivos, escaneos programados de malware y protección WAF en tiempo de ejecución reducen el tiempo de permanencia de los atacantes.

---

Consultas y scripts de ejemplo (para administradores del sitio)

• Encontrar publicaciones que contengan el shortcode:

  SELECT ID, post_title, post_status;

• Encuentra postmeta con contenido de script sospechoso:

  SELECT post_id, meta_key
  FROM wp_postmeta
  WHERE meta_value REGEXP '<script|%3Cscript|on[a-z]+\\s*=';

• Búsqueda de cadenas sospechosas con WP‑CLI:

  wp search-replace '<script' '' --all-tables --dry-run

  Usar --simulación primero, luego elimínalo para realizar el reemplazo después de verificar los resultados.

---

Mejores prácticas para editores de plugins y constructores de sitios

Si construyes embudos, formularios o permites contribuciones de usuarios con menos privilegios, sigue estas obligaciones:

• Siempre escapa la salida. Nunca confíes en el rol del usuario para hacer que la salida no escapada sea segura.
• Usa sanitización del lado del servidor, no solo del lado del cliente.
• Valida los números de teléfono estrictamente (solo dígitos, signo más, espacios, guiones).
• Evita inyectar contenido de usuario sin procesar en atributos HTML en línea sin la codificación adecuada.
• Implementa un mecanismo de vista previa seguro que neutralice scripts durante la vista previa del administrador.

---

Un ejemplo práctico: manejo seguro del campo de teléfono en el código

Si eres un desarrollador que actualiza el código del plugin o tema, asegúrate de que los campos de teléfono estén sanitizados/escapados. Ejemplo (PHP conceptual):

// Al guardar la entrada del teléfono:

Nunca imprimas valores sin procesar directamente en atributos o contenido HTML.

---

Regístrate en WP‑Firewall Basic — protege tu sitio hoy

Título: Comienza a proteger tu sitio de WordPress de forma gratuita con WP‑Firewall Basic

Si deseas una forma rápida y sin fricciones de agregar una capa de protección mientras reparas o investigas, el plan Básico (Gratis) de WP‑Firewall ofrece protección esencial para sitios de WordPress. El plan Básico incluye un firewall gestionado, reglas WAF, ancho de banda ilimitado, un escáner de malware y mitigación para los riesgos del OWASP Top 10, ayudando a detener patrones de explotación conocidos como el FunnelKit. wfop_phone XSS antes de que lleguen a los navegadores de los visitantes. Para los propietarios de sitios que necesitan más automatización y una remediación más profunda, nuestros planes de pago añaden eliminación automática de malware, listas negras/blancas de IP, parches virtuales automáticos de vulnerabilidades y servicios de remediación avanzados. Regístrate en el plan gratuito de WP‑Firewall y añade una capa defensiva de emergencia a tu sitio aquí: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Monitoreo y aseguramiento a largo plazo.

Después de parchear y limpiar, sigue monitoreando:

• Escaneos semanales de malware y verificaciones de integridad de archivos.
• Alertas para nuevas instalaciones de plugins o cambios.
• Búsquedas periódicas de shortcodes y patrones sospechosos.
• Revisa regularmente las cuentas de usuario, especialmente las de los colaboradores.

Considera un despliegue por etapas para actualizaciones automáticas de plugins y un proceso para aplicar rápidamente parches de emergencia en todo el sitio.

---

Reflexiones finales del equipo de WP‑Firewall

Las vulnerabilidades XSS almacenadas en plugins ampliamente utilizados presentan un riesgo significativo porque pueden convertir cuentas de bajo privilegio en potentes vectores de ataque. El problema de FunnelKit. wfop_phone es un claro ejemplo: un solo campo no sanitizado puede tener consecuencias desproporcionadas.

La respuesta segura y correcta es en capas:

1. Parchear en la fuente: actualiza FunnelKit a 3.13.1.3 o posterior.
2. Contener y limpiar: desactiva o sanitiza el contenido afectado, revisa las cuentas.
3. Proteger al frente: utiliza una capa WAF/parcheo virtual (como WP‑Firewall) para bloquear intentos de explotación y monitorear actividad sospechosa.
4. Endurecer procesos: limita roles, requiere moderación y mantiene un canal de actualización rápida en su lugar.

Estamos disponibles para ayudar a los administradores de WP a implementar rápidamente reglas WAF de emergencia, escanear contenido sospechoso y restaurar la operación limpia. Si aún no estás utilizando WP‑Firewall, nuestro plan Básico (Gratis) te brinda protección inmediata de firewall y escaneo de malware mientras aplicas parches de proveedores. Comienza aquí: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Mantente alerta: este tipo de vulnerabilidades son bastante comunes, y las defensas en capas más un parcheo rápido reducen drásticamente el riesgo.

— Equipo de seguridad de firewall de WP