FlawOpen

flawopen.com/Incidents/wordpress-stored-xss-admin-session-campaign-october-2026

● WordPress plugin installations (campaign observations attributed to Patchstack) · CVE-2026-93836 · 2026-10-04 · CVSS 7.2 · Alta
Investigación · FlawOpen

Campaña de XSS almacenado en WordPress: dos plugins, una cadena de persistencia

Patchstack observó intentos de usar el mismo implante posterior a la explotación a través de dos fallos de XSS almacenado en WordPress. Actualice ambos plugins e investigue la persistencia: el parche no limpia un sitio ya comprometido.[1], [2], [3], [4], [5]

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina dos buzones públicos de sugerencias cuyos mensajes abre después el administrador del sitio. Si el sitio guarda un mensaje como marcado ejecutable en vez de mostrarlo como texto, puede actuar con los privilegios del navegador del administrador al abrirse. El informe de campaña dice que se usaron dos fallos distintos de plugins como puntos de entrada y que después se intentó mantener el acceso tras una actualización.[1], [8], [9]

Conceptos Clave y Términos

XSS almacenado
Texto controlado por un atacante se guarda y luego se muestra en el navegador como marcado ejecutable. Aquí, el contexto relevante era la administración de WordPress.[2], [3], [8], [9]
Sesión de mismo origen
El navegador envía automáticamente la sesión del sitio en solicitudes del mismo origen. Un script que ya se ejecuta en ese sitio puede actuar mediante la página sin leer una cookie HttpOnly.[1], [17], [18]
Persistencia
Acceso que continúa después de corregir el fallo inicial, por ejemplo, cuentas o archivos no autorizados. Una actualización limpia no elimina esos cambios.[1]
Atribución de CVSS
Los registros CNA de Wordfence asignan CVSS 3.1 7,2 a cada CVE. Patchstack muestra 7,1 en su aviso de WPC Product Bundles; este artículo usa la puntuación del registro CVE y mantiene la atribución de la fuente.[2], [3], [6]
Referencias al código fuente
Las referencias CNA de Wordfence señalan archivos versionados de WPC Product Bundles y Ninja Forms relacionados con validación, almacenamiento y visualización administrativa. Son pistas de código, no un diff de parche verificado. El par PHP anterior es un modelo ilustrativo de codificación de salida, no código reconstruido de los plugins.[8], [9], [10], [11], [12], [13], [14], [15], [16]

Mapeos de marcos

Cronología del Incidente

2026-09-21 / 2026-09-22

Los registros CNA de Wordfence muestran fechas de publicación del 21 de septiembre, mientras que Patchstack afirma que las fallas ya se habían divulgado públicamente el 22 de septiembre. Las fuentes difieren por un día; los registros CVE indican versiones afectadas hasta 8.6.6 y 3.15.3, respectivamente.[2], [3], [8], [9], [1]

2026-10-04 a 2026-10-05

Patchstack informa de intentos con la misma fase posterior a la explotación, primero mediante WPC Product Bundles y luego mediante Ninja Forms. Patchstack publicó su análisis el 6 de octubre.[1]

Flujo de Ataque Paso a Paso

Paso 1

Dos puntos de entrada distintos de XSS almacenado

Patchstack afirma que una campaña usó CVE-2026-93836 en WPC Product Bundles y CVE-2026-94504 en Ninja Forms. Son vulnerabilidades distintas; el informe las vincula por la actividad posterior compartida.[1], [2], [3], [8], [9]

Paso 2

El contenido guardado llega a un administrador

Los datos enviados se guardan y luego se muestran en una vista administrativa de pedido o envío. Si el tratamiento inseguro de salida permite ejecutarlos como marcado, la visita del administrador aporta el contexto del navegador.[1], [8], [9], [10], [11], [12], [13], [14]

Paso 3

El script hereda el contexto del sitio

El código que se ejecuta en el origen de WordPress puede hacer solicitudes del mismo origen con la sesión existente del administrador. HttpOnly protege la confidencialidad de la cookie; no impide que código ya ejecutado en ese origen use la sesión.[1], [17], [18]

Paso 4

El acceso posterior puede sobrevivir al fallo

Patchstack informa de intentos de instalar un plugin y crear persistencia adicional. Son observaciones de la campaña, no un resultado confirmado para cada objetivo; actualizar bloquea la entrada vulnerable, pero no elimina cambios ya realizados.[1], [4], [5]

Código Fuente: Vulnerable vs. Seguro

Este es el cambio de código fuente en Textarea::admin_form_element() de Ninja Forms, no un modelo genérico. La versión 3.15.3 interpolaba directamente el texto almacenado del envío en el cuerpo HTML de un textarea; la 3.15.4 aplica esc_textarea() antes de mostrarlo. Así se evita que ese contenido se interprete como marcado en este contexto. El ejemplo documenta solo la ruta de Ninja Forms para CVE-2026-94504; no es la corrección de WPC Product Bundles para CVE-2026-93836. Use un escape específico para cada contexto en los demás casos.[13], [15], [16]

IMPLEMENTACIÓN VULNERABLE
public function admin_form_element( $id, $value )
{
    return "<textarea class='widefat' name='fields[$id]'>$value</textarea>";
}
PARCHE SEGURO Y ROBUSTO
public function admin_form_element( $id, $value )
{
    return "<textarea class='widefat' name='fields[$id]'>" . esc_textarea( $value ) . "</textarea>";
}

Lista de Verificación de Seguridad para Ingeniería

Fuentes