Una falla en Popup Box permite a atacantes remotos ejecutar código a través de encabezados de red sin necesidad de autenticación — siempre que el administrador haya usado un token específico.
El plugin Popup Box para WordPress, instalado en miles de sitios, contiene una vulnerabilidad catalogada como CVE-2026-100159 que permite a atacantes no autenticados ejecutar shortcodes arbitrarios del sistema mediante la manipulación de encabezados HTTP estándar. La falla afecta las versiones 6.4.1 y 6.4.2, y su explotación depende de una condición previa: que el administrador del sitio haya incorporado el token `%%user_ip_address%%` en el contenido de algún popup. Cuando esa condición se cumple, cualquier visitante puede inyectar sintaxis de shortcode a través de headers como `X-Forwarded-For` o `Client-IP`, logrando que el servidor ejecute funciones registradas en WordPress con parámetros controlados por el atacante.
Cómo un mecanismo de detección de IP se convierte en vector de ataque
La vulnerabilidad se origina en la función `ays_popup_get_user_ip()`, diseñada para capturar la dirección IP del visitante leyendo una serie de encabezados HTTP comunes en entornos con proxies o balanceadores de carga: `Client-IP`, `X-Forwarded-For`, `Forwarded`, `X-Forwarded` y `Forwarded-For`. El plugin sanitiza estos valores únicamente con `sanitize_text_field()`, una función de WordPress que elimina saltos de línea y etiquetas HTML pero preserva intactos los caracteres críticos de la sintaxis de shortcode: corchetes, comillas, espacios y el signo igual.
Cuando un administrador inserta el token `%%user_ip_address%%` en el cuerpo de un popup, el plugin sustituye ese marcador por el valor capturado del header mediante `str_replace` sin ningún tipo de escapado adicional en la función `Ays_Pb_Data::replace_message_variables()`. El contenido resultante se pasa luego a `do_shortcode()` en el hook `wp_footer` a través de `Ays_Pb_Public::ays_autoembed()`, momento en el cual WordPress interpreta y ejecuta cualquier shortcode presente en el texto. Un atacante puede enviar un header como `X-Forwarded-For: [shortcode attr=»valor»]` y lograr que el servidor procese ese shortcode con los atributos que el atacante especifique.
Qué puede hacer un atacante con shortcodes arbitrarios en WordPress
La ejecución de shortcodes arbitrarios no equivale a ejecución remota de código en el sentido clásico, pero abre un abanico de acciones maliciosas que dependen de qué shortcodes estén registrados en el sitio objetivo. Muchos plugins de WordPress exponen funcionalidades sensibles a través de shortcodes: lectura de archivos del servidor, consultas a la base de datos, envío de correos, generación de formularios con destinos controlados por parámetros, o incluso ejecución de operaciones administrativas si el shortcode no valida permisos correctamente.
Un atacante podría, por ejemplo, usar un shortcode de un plugin de formularios para exfiltrar datos de usuarios, o aprovechar un shortcode de gestión de archivos para leer configuraciones del servidor. La severidad asignada por el National Vulnerability Database es MEDIUM, reflejando que la explotación requiere una condición previa (el uso del token por parte del administrador) pero no requiere autenticación ni interacción del usuario más allá de visitar el sitio. La ventana de exposición se limita a las versiones 6.4.1 y 6.4.2, lo que sugiere que la funcionalidad del token `%%user_ip_address%%` es relativamente reciente o fue modificada en esas versiones específicas.
Exposición en América Latina por dependencia de plugins populares
WordPress domina el 43% de todos los sitios web a nivel global, y en América Latina esa proporción es similar o superior en segmentos como medios digitales, comercio electrónico de pequeña escala y sitios institucionales. Popup Box, con su capacidad de crear ventanas emergentes para captura de leads o avisos legales, es un tipo de plugin ampliamente adoptado en la región para cumplir con normativas de cookies o impulsar conversiones en tiendas online. La práctica de mostrar la IP del visitante en popups — ya sea por transparencia en geolocalización o como elemento de personalización — no es infrecuente en sitios que operan con restricciones geográficas de contenido o precios diferenciados por país.
Brasil y México, los dos mercados digitales más grandes de la región, concentran decenas de miles de sitios WordPress en sectores como educación en línea, fintech de nicho y medios locales, muchos de ellos gestionados por equipos pequeños que dependen de plugins de terceros para funcionalidades básicas. La combinación de alta adopción de WordPress, uso frecuente de plugins de popup para cumplimiento normativo, y la costumbre de operar detrás de CDNs o proxies inversos (que hacen necesario leer headers como `X-Forwarded-For` para obtener la IP real) crea un escenario donde la superficie de ataque de CVE-2026-100159 es estructuralmente mayor que en otras regiones. No hay reportes públicos de explotación activa en LATAM hasta el momento, pero la ventana entre la publicación del CVE y la aplicación de parches en sitios con mantenimiento irregular suele medirse en semanas o meses.
Por qué la sanitización de entrada sigue siendo el eslabón débil en WordPress
Esta vulnerabilidad ilustra un patrón recurrente en el ecosistema de plugins de WordPress: la confianza excesiva en funciones de sanitización genéricas que no están diseñadas para el contexto específico de uso. `sanitize_text_field()` es adecuada para limpiar campos de texto plano destinados a almacenamiento en base de datos, pero no para valores que luego se interpolarán en contextos donde ciertos caracteres tienen significado sintáctico, como shortcodes, HTML o SQL. El problema se agrava cuando el flujo de datos atraviesa múltiples funciones sin que ninguna asuma la responsabilidad de escapado contextual: `ays_popup_get_user_ip()` confía en que `sanitize_text_field()` es suficiente, `replace_message_variables()` asume que el valor ya está seguro, y `ays_autoembed()` ejecuta `do_shortcode()` sin cuestionar el origen del contenido.
La arquitectura de WordPress, con su sistema de hooks y filtros, permite que el código de un plugin modifique datos en tránsito sin que otros componentes tengan visibilidad de esas transformaciones. Esto hace que las vulnerabilidades de este tipo sean difíciles de detectar en revisiones de código estáticas: cada función individual puede parecer correcta en aislamiento, pero la cadena completa crea una condición explotable. La ausencia de un sistema de tipos fuerte o de anotaciones de seguridad en PHP agrava el problema, dejando la responsabilidad de rastrear el flujo de datos contaminados enteramente en manos del desarrollador.
Nuestro análisis
CVE-2026-100159 pertenece a una clase de vulnerabilidades que está creciendo en frecuencia a medida que los plugins de WordPress incorporan tokens dinámicos y personalización basada en datos del cliente. La tendencia a ofrecer «merge tags» o variables de sustitución en editores de contenido — heredada de plataformas de email marketing — traslada al contexto web un modelo de interpolación de strings que no fue diseñado para entornos donde el input del usuario puede provenir de fuentes no confiables como headers HTTP. El hecho de que la explotación requiera que el administrador haya usado un token específico reduce la superficie de ataque, pero no la elimina: muchos tutoriales y plantillas de popups recomiendan mostrar la IP del visitante como elemento de «prueba social» o transparencia, lo que convierte una funcionalidad opcional en un vector de ataque latente en miles de instalaciones.
Lo que no se sabe todavía es si existen otros tokens en Popup Box o en plugins similares que sigan el mismo patrón de sustitución sin escapado. Si `%%user_ip_address%%` es vulnerable, es razonable sospechar que tokens como `%%user_agent%%`, `%%referer%%` o cualquier otro que lea headers HTTP puedan tener el mismo problema. La falta de un análisis público exhaustivo del código del plugin deja abierta la pregunta de si CVE-2026-100159 es un caso aislado o el primero de una serie de hallazgos en la misma base de código. La asignación de severidad MEDIUM por parte de NVD refleja el balance entre la facilidad de explotación (no requiere autenticación) y la dependencia de una configuración específica del administrador, pero subestima el riesgo en sitios que ya usan el token vulnerable y que operan con plugins adicionales que exponen shortcodes sensibles.
¿Cuántos sitios en producción están ejecutando versiones vulnerables de Popup Box con el token `%%user_ip_address%%` activo, sin saber que cada visitante puede leer datos arbitrarios del servidor simplemente modificando un header HTTP?