XSS crítico en “Máximo de Productos por Usuario para WooCommerce” (≤ 4.3.6) — Lo que los propietarios de sitios de WordPress deben hacer ahora mismo

Fecha: 22 abr, 2026

CVE: CVE-2025-47504

Versiones afectadas: ≤ 4.3.6

Corregido en: 4.3.7

CVSS: 6.5 (Medio)

Privilegio requerido: Contribuyente (autenticado)

Complejidad de explotación: Se requiere interacción del usuario (un usuario privilegiado debe abrir un enlace / página / formulario elaborado)

Resumen

Se ha divulgado una vulnerabilidad de scripting entre sitios (XSS) en el plugin de WordPress “Máximo de Productos por Usuario para WooCommerce” que afecta a las versiones hasta e incluyendo 4.3.6.
Un usuario autenticado con el rol de Contribuyente puede proporcionar una entrada elaborada que, cuando es procesada o vista por un usuario privilegiado (administrador/gerente de tienda), puede ejecutar JavaScript proporcionado por el atacante en el navegador del usuario privilegiado.
El autor del plugin lanzó la versión 4.3.7 para abordar el problema. Si su sitio utiliza este plugin, debe priorizar la remediación y contención de inmediato.

Por qué esto es importante (versión corta)

• XSS en componentes visibles para administradores permite la ejecución de JavaScript en el contexto de un usuario privilegiado. Ese script puede robar cookies de sesión, realizar acciones administrativas o instalar puertas traseras persistentes.
• Aunque la explotación requiere interacción, las interfaces de administración son visitadas frecuentemente por el personal, lo que hace que la explotación sea realista en muchos flujos de trabajo.
• Los sitios que ejecutan WooCommerce y utilizan este plugin son los más directamente afectados; las tiendas con múltiples contribuyentes tienen un mayor riesgo.

¿Qué tipo de XSS es este y cómo podría un atacante explotarlo?

Este es un XSS autenticado donde un Contribuyente puede proporcionar contenido que se vuelve peligroso si un usuario privilegiado activa la representación de ese contenido. Los escenarios comunes de explotación incluyen:

• Un contribuyente agrega o edita una descripción de producto, metadatos de producto, nota o configuración gestionada por el plugin con una carga útil elaborada. Cuando un administrador visita la configuración del plugin, la página de edición de producto o la pantalla de revisión que representa ese contenido sin escapar, se ejecuta el JavaScript malicioso.
• Un contribuyente envía un formulario o enlace que contiene una carga útil que, cuando es previsualizada o clicada por un usuario privilegiado, se ejecuta.
• Ingeniería social para atraer a un gerente de tienda o administrador a ver “pedidos”, “límites de productos” o informes internos que activan la carga útil.

Ejemplos de impacto

• Robar cookies de autenticación o tokens de sesión y usarlos para iniciar sesión como administrador.
• Crear nuevos usuarios administradores o elevar privilegios.
• Exfiltrar datos sensibles (pedidos, metadatos de clientes).
• Inyectar puertas traseras persistentes (archivos de plugin/tema maliciosos o PHP inyectado).
• Provocar cambios de configuración en los ajustes de pago o envío.

Incluso si se etiqueta públicamente como “bajo”, el XSS que afecta a los administradores debe ser tratado seriamente — un exploit exitoso puede llevar a un compromiso total del sitio.

Lista de verificación rápida: acciones inmediatas (ordenadas)

1. Actualiza el plugin a la versión 4.3.7 (o posterior) inmediatamente si puedes.
2. Si no puede actualizar de inmediato:
   • Desactiva el plugin hasta que puedas actualizar, o
   • Aplica parches virtuales con tu Firewall de Aplicaciones Web (WAF): consulta las reglas de mitigación a continuación.
3. Audita las cuentas de los contribuyentes y elimina o degrada temporalmente cualquier cuenta en la que no confíes absolutamente.
4. Requiere que los usuarios privilegiados (administradores/gerentes de tienda) se reautenticen para pantallas administrativas sensibles cuando sea posible.
5. Habilita la autenticación de dos factores (2FA) para todas las cuentas administrativas y usuarios con roles elevados.
6. Inspecciona tu sitio en busca de indicadores de compromiso (consulta la sección de detección a continuación).
7. Asegúrate de tener una copia de seguridad reciente fuera del sitio antes de realizar cambios.

Si gestionas múltiples sitios de clientes, prioriza las tiendas con alto volumen de transacciones y sitios que permiten muchos contribuyentes.

Detección: cómo saber si ya estás afectado

• Buscar en las tablas de la base de datos (postmeta, options, usermeta) instancias de
• Check product descriptions, product meta, and plugin-specific settings pages where untrusted content may be rendered.
• Review recent admin activity logs for unexpected logins, creation of new admin accounts, or plugin/theme changes.
• Inspect wp-content for newly modified files, unknown PHP files, or PHP files in uploads directories.
• Examine web server access logs for suspicious POST/GET requests targeting the plugin’s admin endpoints or containing encoded script payloads.
• Monitor outbound connections from your server for unusual destinations (possible data exfiltration or C2 activity).

If you find suspicious artifacts:

1. Take an immediate backup (filesystem + DB) for forensic purposes.
2. Isolate the site (display a maintenance page) while you investigate.
3. Change passwords for all privileged users, and rotate API keys and tokens used by the site.

Mitigation details — updates, hardening, and WAF rules

Primary remediation

Update the plugin to 4.3.7 or later. This is the only guaranteed fix released by the plugin author.

Secondary mitigations (when immediate updating isn’t possible)

1. Disable or deactivate the plugin
   If you can afford to turn it off temporarily, deactivate it until a tested, patched version is installed.
2. Protect admin routes with IP restrictions
   Limit access to /wp-admin and the plugin’s admin pages to trusted IP addresses via server-level controls (NGINX/Apache) or by allowlisting at the network edge.
3. Reduce Contributor privileges
   Remove the ability for contributors to add HTML or unfiltered content. Ensure contributors cannot upload files or create items that display HTML to admins without review.
4. Apply a virtual patch (WAF)
   A WAF with virtual patching capability can provide immediate protection by blocking suspicious payload patterns targeted at admin routes. Example rule concepts:
   • Block requests containing
     Revisa Mi Pedido

     0

     Subtotal

     Impuestos y envío calculados en la caja

     Pagar