TL;DR — A stored Cross‑Site Scripting (XSS) vulnerability (CVE-2026-3604) affects the “WP SEO Structured Data Schema” plugin in versions up to and including 2.8.1. An authenticated user with Contributor privileges can store a malicious script that executes when a higher‑privileged user or another visitor views an affected page. The issue carries a CVSS-equivalent severity of 6.5 and requires user interaction for successful exploitation. No official patch was available at disclosure — apply mitigations immediately if you run this plugin.

Por qué esto es importante (breve)

El XSS almacenado es particularmente peligroso porque la carga maliciosa persiste (base de datos, opciones, postmeta) y se ejecuta en el navegador de cualquiera que vea el contenido infectado. Los contribuyentes pueden crear contenido, pero no se les confía insertar HTML sin procesar. Si esos usuarios pueden almacenar scripts que luego se renderizan para administradores o editores, el sitio puede ser escalado de un compromiso de bajo privilegio a una toma de control total del sitio: secuestro de sesión, creación de administradores no autorizados, modificación de configuraciones, instalación de puertas traseras, spam SEO o distribución de contenido malicioso.

Resumen de vulnerabilidad

• Vulnerabilidad: Cross‑Site Scripting (XSS) almacenado autenticado (Contribuyente+)
• Software afectado: Plugin de esquema de datos estructurados de WP SEO
• Versiones afectadas: ≤ 2.8.1
• CVE: CVE-2026-3604
• Publicado: 11 de mayo de 2026
• Privilegio requerido: Contribuyente (o superior)
• Gravedad similar a CVSS: 6.5 (moderado/medio)
• Explotación: Requiere la presencia de una cuenta de Contribuyente e interacción de usuario privilegiado (por ejemplo, ver o interactuar con la carga almacenada en el administrador o en el frontend)
• Estado del parche en el momento de la divulgación: No hay parche oficial disponible (los propietarios del sitio deben aplicar mitigaciones)

Cómo funciona el XSS almacenado en este contexto

Stored XSS occurs when user-supplied input is saved and later output without proper sanitization or escaping. In this plugin, certain fields Contributors can populate (structured data snippets, meta fields, or custom schema entries) are not sufficiently filtered. An attacker with a Contributor account can insert HTML/JavaScript payloads that are saved to the database. When an admin/editor or a visitor loads the page or the plugin’s admin view that outputs that content, the malicious script runs in the context of the user’s browser.

Because the script runs with the victim’s browser privileges, consequences include:

• Robar cookies de autenticación o tokens de sesión (lo que lleva a la toma de control de la cuenta)
• Realizar acciones administrativas falsificando solicitudes
• Instalar puertas traseras persistentes, crear cuentas de administrador no autorizadas o modificar plugins/temas
• Alterar contenido SEO o insertar enlaces de spam para dañar la reputación
• Servir JavaScript malicioso que redirige o carga malware de forma automática para los visitantes

Aunque el atacante puede tener inicialmente solo una cuenta de Contribuyente, XSS almacenado puede escalar a una completa compromisión una vez que usuarios con mayores privilegios interactúan con la carga útil.

¿Quién está en riesgo?

• Sitios con el plugin WP SEO Structured Data Schema instalado y habilitado, ejecutando la versión 2.8.1 o anterior
• Sitios que permiten a usuarios externos registrarse u obtener de otra manera un rol de Contribuyente (o superior)
• Blogs de múltiples autores donde los Contribuyentes proporcionan datos estructurados o llenan campos gestionados por el plugin que luego se renderizan en pantallas de administración o plantillas del front-end
• Sitios donde administradores o editores revisan frecuentemente contenido directamente en la interfaz de administración sin sanitización adicional

If you don’t use the plugin or it’s not active, you are not impacted. If you host the plugin but haven’t updated or removed it, treat this as a high-priority assessment.

Escenarios de explotación en el mundo real

1. Contribuyente → Ingeniería Social → Administrador

   An attacker with a Contributor account saves a crafted schema snippet or meta field containing a hidden script. An editor/admin opens the plugin’s settings page or views the post in the admin preview; the script executes and uses the admin’s authenticated cookies to call admin-only AJAX endpoints (create admin accounts, install plugins, change site email, etc.).

2. Contribuyente → Ejecución en el Front-end → Visitantes

   If the plugin outputs structured data or schema markup into the front-end without escaping, a visitor’s browser can execute the payload. The script can load third-party malicious code or leverage browser flaws to harm visitors and the site’s reputation.

3. Carga útil almacenada + tareas programadas

   La carga útil puede desencadenar acciones cuando las páginas cron o de mantenimiento son visitadas por usuarios privilegiados, automatizando la persistencia y dificultando la limpieza.

Pasos inmediatos a seguir (dentro de 24 horas)

1. Inventariar y evaluar
   • Verifica si el plugin WP SEO Structured Data Schema está instalado y determina su versión.
   • WP-CLI: wp plugin get wp-seo-structured-data-schema --field=version
   • Administrador de WordPress: Plugins → Plugins Instalados → verificar versión
   • Si el plugin está activo y la versión ≤ 2.8.1, toma acción mitigadora de inmediato.
2. Si no puedes aplicar un parche (no hay parche oficial disponible)
   • Desactive el plugin inmediatamente si es posible. La desactivación es la mitigación inmediata más segura.
   • WP-CLI: wp plugin desactivar wp-seo-structured-data-schema
   • Si la desactivación no es posible por razones comerciales, limite la exposición:
     • Restringa el acceso a las páginas de administración del plugin por IP (utilice controles de hosting o configuración del servidor).
     • Desactive temporalmente la capacidad de los Colaboradores para crear o editar los campos gestionados por el plugin.
     • Requiera revisión manual por parte de los Editores antes de que el contenido se publique.
3. Restringir los privilegios de usuario.
   • Elimine o degrade cualquier cuenta de Colaborador no confiable.
   • Aplique contraseñas fuertes y rote las credenciales para administradores y editores.
   • Desactive el registro de nuevos usuarios si no es necesario.
4. Inspeccionar y limpiar
   • Busque scripts sospechosos y etiquetas inyectadas en el contenido y almacenamiento relacionado con el plugin (vea la sección de Detección).
   • Elimine los scripts maliciosos descubiertos, usuarios no autorizados o cuentas de administrador inyectadas.
   • Si la integridad del archivo se ve afectada, restaure desde una copia de seguridad limpia.
5. Monitorear registros y tráfico
   • Revise los registros del servidor y de la aplicación en busca de solicitudes POST sospechosas, vistas inusuales de páginas de administración o picos en la actividad.
   • Monitoree el tráfico saliente en busca de conexiones a hosts desconocidos que podrían indicar un beaconing por malware.
6. Aplique WAF/parcheo virtual (si está disponible)

   Despliegue reglas de Firewall de Aplicaciones Web para bloquear cargas útiles típicas de XSS en los puntos finales del plugin afectados. Bloquee etiquetas de script obvias y atributos sospechosos en las presentaciones a los puntos finales relacionados con el esquema y monitoree/bloquee POSTs maliciosos desde los puntos finales de colaboradores.

7. Planifique la remediación

   Observe los canales oficiales del plugin para un lanzamiento de seguridad. Cuando se publique un parche, aplíquelo rápidamente en staging, pruébelo y luego empújelo a producción.

Detección: cómo encontrar posibles artefactos de explotación

Suponga que el atacante almacena scripts en el contenido de las publicaciones, meta de publicaciones, opciones o tablas personalizadas. Utilice estos enfoques para localizar artefactos sospechosos.

Busque etiquetas de script o atributos on-event en el contenido

Ejemplos de WP-CLI:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"
wp db query "SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

Direct SQL (replace table prefixes if different):

SELECT ID, post_title FROM wp_posts WHERE post_content REGEXP '<[[:space:]]*script';
SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value REGEXP '<[[:space:]]*script';

Look for suspicious HTML attributes commonly used in XSS payloads: onerror=, onload=, onclick=, javascript:, document.cookie, window.location, eval(.

Search site options and plugin-related fields

SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Search files and uploads

• Scan the files directory for recently added PHP files or suspicious JS files.
• Use grep to find injected strings:

  grep -R --exclude-dir=uploads 'document.cookie' .
  grep -R --exclude-dir=wp-content/uploads '<script' wp-content/plugins/

Verifique las cuentas de usuario

List accounts with Contributor+ privileges and their last login times:

wp user list --role=contributor --fields=ID,user_login,user_email,user_registered,last_login

Nota: last_login may require a plugin that records logins; otherwise check authentication logs on the server.

If you find injected content, take screenshots, export the records, and store them for forensic analysis before cleaning.

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

1. Aislar
   • Deactivate the vulnerable plugin immediately or restrict access to its admin pages.
   • If you suspect active compromise, consider taking the site into maintenance mode and blocking public access temporarily.
2. Preserva
   • Make a full backup (database + files) and preserve a copy offline for forensic purposes.
3. Identifica
   • Run the detection queries above.
   • Look for new admin users, unauthorized plugins, modified core files, or unexpected scheduled tasks (wp_cron).
4. Eliminar
   • Delete injected scripts from posts/postmeta/options.
   • Remove rogue users and reset passwords for editors and admins.
   • Remove any unauthorized plugins or themes and revert modified files from a trusted backup.
5. Recuperar
   • Restore core files and plugin files from known-good sources.
   • Apply any available security update for the plugin when released. If no official patch yet, continue virtual patching and other mitigations.
6. Revise y refuerce
   • Audit user roles and permissions.
   • Ensure two-factor authentication (2FA) for all admins and editors.
   • Review logging and monitoring practices to catch future abuse earlier.
   • Implement a content-review workflow: contributors should not publish content that bypasses editor review.
7. Notificar
   • Inform affected stakeholders (site owners, administrators).
   • If customer data was exposed or site integrity was affected, follow applicable regulatory obligations.
8. Post-mortem
   • Document root cause, steps taken, and improvements to prevent recurrence.

Mitigation strategies — technical guidance for developers and site admins

Practical defensive steps to mitigate the vulnerability and reduce future risk.

1. Principio de menor privilegio
   • Limit user capabilities. Contributors should not be able to inject raw HTML or scripts.
   • Consider a custom role with stricter capabilities where appropriate.
2. Sanea las entradas y escapa las salidas
   • Sanitize on input and escape on output using WordPress APIs:
   • Sanitizar en la entrada: wp_kses_post(), sanitize_text_field(), wp_strip_all_tags()
   • Escapa en la salida: esc_html(), esc_attr(), wp_kses_post()
3. Política de Seguridad de Contenidos (CSP)

   Apply CSP headers to limit the risk of script execution from unauthorized sources. Example (start restrictive, then adjust):

   Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'nonce-<random>'; object-src 'none';

   CSP reduces XSS impact but must be implemented carefully to avoid breaking functionality.

4. Disable unfiltered HTML for untrusted roles

   Asegúrese de que los Colaboradores no tengan el unfiltered_html capability. Use capability management code or plugins to remove it. Example (add to an mu-plugin or functions.php with caution):

   <?php
   // mu-plugin/remove-unfiltered-html.php
   function hk_remove_unfiltered_html_from_contributors() {
     $role = get_role('contributor');
     if ( $role && $role->has_cap('unfiltered_html') ) {
       $role->remove_cap('unfiltered_html');
     }
   }
   add_action('init', 'hk_remove_unfiltered_html_from_contributors');

5. Harden REST API and AJAX endpoints

   Ensure endpoints that accept structured data check capabilities and nonces. Limit who can POST to endpoints that manage schema or plugin settings.

6. Parches virtuales con un WAF

   If you operate or can configure a Web Application Firewall, add rules that inspect POST data for XSS payloads on plugin-specific endpoints. Example generic patterns to block:

   • Bloquear solicitudes con <script in parameters destined to schema endpoints.
   • Bloquear onerror=, onload=, javascript: appearing in form fields.
7. Input validation layers

   When structured data is expected (e.g., JSON-LD), validate that incoming strings match expected JSON formats and allowed keys. Reject or sanitize unexpected HTML and attributes.

8. Review plugin updates and vendor communications

   Subscribe to vendor security announcements and update promptly when a fix is released.

Practical mitigation examples (do‑it‑yourself)

Concrete actions administrators can apply immediately.

1. Deactivate plugin

   wp plugin desactivar wp-seo-structured-data-schema (if deactivation is acceptable)

2. Temporarily prevent Contributors from submitting posts

   Use a role-management approach to change Contributor capabilities or require content moderation.

3. Add a simple server-side filter (example mu-plugin)

   This example strips <script> tags from contenido_post on save. Use as a short-term defensive measure and test thoroughly:

   <?php
   // mu-plugin/strip-scripts-on-save.php
   add_filter('content_save_pre', 'hk_strip_scripts_on_save', 10, 1);
   function hk_strip_scripts_on_save($content) {
       if ( current_user_can('contributor') || current_user_can('author') ) {
           // Remove script tags
           $content = preg_replace('#<script(.*?)>(.*?)</script>#is', '', $content);
       }
       return $content;
   }

   Nota: Este es un remedio defensivo. La sanitización adecuada en el código del plugin es la solución correcta.

4. Bloquear envíos a nivel de servidor web

   Agregar reglas de inspección del cuerpo de la solicitud que nieguen solicitudes con <script in form data to plugin endpoints. Consult your hosting provider or server administrator for implementation details.

Long-term hardening — lessons learned

• Treat any content re-rendered in admin screens with the same caution as front-end content — admins are high-value targets.
• Limit users who can create content without review. Enforce editor review for content with structured data or raw markup.
• Use layered defenses: secure code, WAF protections, monitoring, and recovery planning.
• Maintain up-to-date backups with regular verification and offsite copies.
• Deploy 2FA and enforce strong passwords for all privileged accounts.

Detection queries and forensics cheat sheet

• Listar versión del plugin:

  wp plugin get wp-seo-structured-data-schema --field=version

• Find posts containing <script:

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

• Encontrar postmeta con scripts:

  wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

• Buscar opciones:

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

• List contributor accounts:

  wp user list --role=contributor --fields=ID,user_login,user_email,user_registered

• Check current active plugins:

  wp plugin list --status=active

Always make a copy of affected rows before cleaning to preserve evidence.

What if you already see signs of compromise?

If you detect unexpected admin accounts, changed content, unknown scheduled events, or file system changes:

1. Immediately change all administrative credentials and rotate application secrets (API keys, OAuth tokens, etc.).
2. Put the site in maintenance/offline mode to prevent further harm.
3. Restore from a clean backup prior to the compromise, after ensuring the backup is not infected.
4. Engage a security professional if you’re unable to determine root cause or if the attacker maintains persistence.

Recomendaciones finales — acciones priorizadas

1. Inventario: Determine whether the vulnerable plugin is installed and active — do this now.
2. Deactivate or restrict: If installed and vulnerable, deactivate the plugin or restrict access to its pages and endpoints.
3. Lockdown accounts: Remove untrusted Contributor accounts and force password resets for privileged users.
4. Escanea y limpia: Inspect posts/postmeta/options and remove any injected scripts.
5. WAF/virtual patch: If available, deploy WAF rules to block known XSS patterns for plugin endpoints.
6. Monitor and recover: Keep heightened monitoring and restore clean backups where necessary.
7. Aplica parches cuando estén disponibles: Apply the official plugin update immediately when released and test before reactivating.

Recursos y referencias

• Referencia CVE
• Researcher credit: Muhammad Yudha – DJ (disclosure credited to the researcher in the public advisory)