Por qué esto es importante (breve)

El XSS almacenado es de alto riesgo porque la entrada maliciosa se guarda del lado del servidor y se ejecuta más tarde en el navegador de otro usuario, a menudo un administrador. En este caso, un usuario autenticado de bajo privilegio (Suscriptor) puede persistir cargas útiles que se activan cuando un usuario privilegiado ve las páginas afectadas. Eso permite el robo de sesión, la toma de control de cuentas, acciones administrativas no autorizadas y la compromisión persistente del sitio.

Lo que se informó

• Vulnerabilidad: Cross-Site Scripting (XSS) Almacenado
• Software afectado: WP Docs (plugin de WordPress)
• Versiones afectadas: ≤ 2.2.9
• Versión corregida: 2.3.0
• CVE: CVE-2026-3878
• Investigación / crédito: acreditado al investigador de la divulgación pública
• Fecha de publicación: 16 abr 2026
• Puntuación de riesgo: Media (CVSS ~6.5) — pero el impacto práctico puede escalar en implementaciones reales

Cómo funciona la vulnerabilidad — visión técnica (resumen experto)

1. El plugin expone una entrada de configuración identificada como wpdocs_options[icon_size] que acepta datos proporcionados por el usuario.
2. La entrada se almacena de forma persistente en la tabla de opciones de WordPress.
3. Más tarde, el valor almacenado se muestra en un contexto HTML sin suficiente escape o sanitización.
4. Debido a que el valor es persistente, existe una condición de XSS almacenado. Un Suscriptor autenticado puede insertar JavaScript malicioso.
5. La explotación requiere que un usuario privilegiado vea o interactúe con el contenido renderizado (por ejemplo, un administrador visitando la página de configuración).

Importante: este es un vector de inyección autenticado: un atacante necesita al menos una cuenta de Suscriptor. Muchos sitios permiten el registro de usuarios o tienen comentaristas, por lo que este vector es realista en muchas instalaciones.

Posibles objetivos de los atacantes y escenarios de impacto

• Robo de sesión administrativa: exfiltrar cookies o tokens para apoderarse de cuentas de administrador.
• Acciones administrativas remotas: emitir solicitudes AJAX como el administrador para crear puertas traseras, agregar usuarios privilegiados o modificar código.
• Desfiguración e inyección de contenido visible para los visitantes.
• Compromiso estilo cadena de suministro: plantar código malicioso que persiste y se propaga.
• Movimiento lateral a otros sistemas si los navegadores de administrador tienen credenciales o tokens de servicios externos.

Aunque el CVSS lo marca como “Medio”, el impacto en el mundo real en sitios de WordPress ocupados puede ser severo.

Pasos inmediatos si gestionas sitios de WordPress utilizando WP Docs

1. Actualiza inmediatamente: Actualiza WP Docs a la versión 2.3.0 o posterior. Esta es la solución definitiva.
2. Si no puedes actualizar en este momento:
   • Desactiva el plugin hasta que puedas probar y actualizar de forma segura.
   • Aplica un parche virtual (regla WAF) que bloquee solicitudes que intenten establecer wpdocs_options[icon_size] contenido sospechoso.
3. Cambiar credenciales: Rota las contraseñas de administrador e invalida sesiones si hay alguna sospecha de compromiso.
4. Escanee en busca de contenido inyectado: Buscar en la base de datos por wpdocs opciones e inspecciona valores para ), (on\w+\s*=), (javascript:|data:text/html)
5. Bloquear o sanear POSTs que establezcan wpdocs_options[icon_size] valores no numéricos si el campo debe ser numérico.
6. Bloquear solicitudes que contengan cargas útiles codificadas como %3C combinadas con palabras clave sospechosas.

Ejemplo de pseudo-regla (adapte a la sintaxis de su WAF):

IF request contains parameter name: wpdocs_options[icon_size]
AND parameter value matches (?i)(<\s*script\b|on\w+\s*=|javascript:|data:text/html|%3Cscript%3E)
THEN block or sanitize request

Ajuste las reglas cuidadosamente para evitar interrumpir acciones administrativas legítimas. Los parches virtuales son temporales; aplique la actualización del complemento lo antes posible.

Para desarrolladores: cómo se podría haber prevenido

• Hacer cumplir la validación del lado del servidor para las entradas de opción: nunca confiar en controles del lado del cliente.
• Utilizar valores de opción tipados y validados. Si tamaño_icono debe ser un entero, coercionar y validar (por ejemplo, intval() y verificación de límites).
• Escapar la salida al renderizar en contextos HTML (esc_attr(), esc_html()).
• Para arreglos editables por el usuario, sanea cada campo apropiadamente antes de guardar.
• Usa verificaciones de capacidad y nonces para que solo los usuarios autorizados puedan modificar configuraciones.

Ejemplo de correcciones para desarrolladores (conceptual)

Al guardar opciones:

$size = isset($_POST['wpdocs_options']['icon_size']) ? intval($_POST['wpdocs_options']['icon_size']) : 0;

Al renderizar:

echo esc_attr( $options['icon_size'] );

Si se requiere HTML, restringe las etiquetas permitidas con wp_kses().

Lista de verificación de detección y remediación (concisa)

• Actualiza WP Docs a 2.3.0 o posterior.
• Si no puedes actualizar de inmediato: desactiva el plugin o habilita el parcheo virtual en el borde (WAF).
• Inspecciona la base de datos por wpdocs opciones y elimina cargas inyectadas.
• Rota las contraseñas de administrador y fuerza cierres de sesión.
• Escanea el sistema de archivos en busca de archivos modificados y puertas traseras.
• Revisa las cuentas de usuario y elimina usuarios sospechosos.
• Monitorea los registros y configura alertas para actividades administrativas sospechosas.
• Implementa un endurecimiento a largo plazo: 2FA, menor privilegio, CSP, escaneos programados.

Ejemplo de comandos SQL y WP-CLI para ayudar a detectar entradas sospechosas

-- SQL (buscar contenido sospechoso) SELECT option_id, option_name, option_value FROM wp_options WHERE option_name LIKE 'wpdocs_%' OR option_value REGEXP '