El mito del consentimiento: por qué tu plugin de cookies es una brecha de seguridad

Vulnerabilidades reales en Complianz, CookieYes y otros gestores de consentimiento: el catálogo CVE que demuestra por qué instalar un plugin de cookies añade una superficie de ataque, no una protección.

Sunt mala quae libas, ipse venena bibas.

La Acusación

Para cumplir con el RGPD y la LSSI, instalaste un plugin de gestión de cookies. Es el primer paso de cualquier checklist de cumplimiento, la recomendación que repite cualquier consultor: instala un gestor de consentimiento. Lo que esa recomendación no incluye es una advertencia elemental: el componente que vas a instalar para cerrar tu exposición legal es, por definición, código ejecutable de terceros con acceso a tu base de datos y a cada página de tu web. Y el código ejecutable de terceros tiene historial.

Antes de preguntarte si tu banner cumple el RGPD, hay una pregunta anterior que casi nadie formula: ¿qué ocurre cuando, en lugar de gestionar un consentimiento, alguien usa ese mismo plugin para algo distinto?

El Cuerpo del Delito

El catálogo que nadie revisa antes de instalar

Complianz, uno de los gestores de consentimiento más utilizados en WordPress —con cientos de miles de instalaciones activas en el registro público de WPScan— acumula múltiples vulnerabilidades documentadas. La mayoría son XSS persistente por sanitización insuficiente de entradas (CWE-79): CVE-2022-0193 permitía robar credenciales de sesión a través de cookies de autenticación; CVE-2023-6498 afectaba directamente a los ajustes del panel de administración. La más reciente en su histórico, CVE-2025-11185, vive en el shortcode cmplz-accept-link: el propio enlace de aceptación de cookies, el elemento que el usuario pulsa para dar su consentimiento, era el punto de inyección. Y en la misma serie se documentó una falsificación de petición (CSRF) que permitía borrar las solicitudes de acceso o supresión de datos que el propio plugin gestiona en nombre del responsable del tratamiento: una herramienta de cumplimiento del RGPD, vulnerable de tal forma que un atacante podía interferir con el ejercicio de los derechos que esa misma herramienta dice proteger.

CookieYes —antes conocido como GDPR Cookie Consent— registra en su historial XSS persistente combinado con omisión de control de autorización: no solo inyección de código, sino la posibilidad de saltarse los permisos que deberían impedirla. Y no es un caso aislado dentro de su propia categoría: el dominio que aloja el servicio sufrió en su histórico la explotación de campos de texto sin sanitizar que permitían robar, vía document.cookie, las cookies de sesión de cualquier usuario autenticado del sitio. La herramienta diseñada para pedir permiso antes de instalar una cookie fue la vía de entrada para robar las cookies que ya existían.

Cuando el cerrojo es la llave: el caso que lo prueba sin metáfora

El expediente más claro en el registro de vulnerabilidades críticas pertenece al plugin Beautiful Cookie Consent Banner. En enero de 2023, investigadores de seguridad detectaron una campaña de explotación activa bajo el registro CVE-2023-0157: una vulnerabilidad de XSS persistente que, a diferencia de las anteriores, no requería ninguna cuenta previa ni privilegios en el sitio; cualquier visitante anónimo podía inyectar el payload malicioso. El resultado documentado no fue una ventana emergente molesta. Fue la creación de cuentas de administrador no autorizadas en las bases de datos de los sitios afectados, usando como puerta de entrada el mismo componente instalado para mostrar el aviso de cumplimiento legal. El cerrojo de cookies fue, en este expediente, la llave de la cuenta de raíz del servidor.

La misma paradoja sin instalar nada: cuando el cerrojo vive en otro servidor

Sustituir el plugin autoalojado por una plataforma externa que se conecta mediante un script —el modelo de muchos gestores de consentimiento como servicio (SaaS)— no elimina el riesgo. Lo traslada a una cadena de suministro que el titular del dominio no controla en absoluto. En el histórico de ataques globales, el caso del dominio que alojaba la popular librería polyfill.io demostró la fragilidad de este modelo: un cambio de operador modificó el script remoto para inyectar código que redirigía a usuarios hacia sitios de estafas. Más de cien mil webs que cargaban ese recurso externo distribuyeron código malicioso a sus visitantes sin haber modificado una sola línea de su propio código local. El mecanismo es idéntico al que asumes al delegar tu consentimiento en un script externo de cookies: el día que cambie la configuración interna de ese tercero, tu servidor ejecutará lo que el tercero decida, no lo que tú aprobaste.

El cerrojo y la llave no son metáforas opuestas. Son la misma pieza de código, en el mismo expediente CVE, con la misma fecha de publicación. Quien instala un gestor de consentimiento dinámico para reducir su exposición legal acaba de ampliar, en la misma operación, su superficie de ataque técnico.

La Sentencia

Cada una de estas vulnerabilidades, si se explota, no se queda en un problema de seguridad informática. Si un atacante usa el plugin de cookies para acceder a datos de tus usuarios o tomar el control de tu sitio, lo que tienes delante es una posible brecha de seguridad en el sentido del artículo 33 del RGPD: notificación obligatoria a la AEPD en 72 horas, comunicación a los afectados si el riesgo es alto, y una exposición que nace exactamente de la herramienta instalada para evitar una sanción distinta. Instalaste un plugin para eludir un expediente de cookies y terminaste expuesto a una sanción por fuga de datos de carácter personal.

A esto se suma la carga administrativa que ya viste documentada en otros folios: cada consentimiento exige un registro inmutable, cada retirada exige un mecanismo idéntico al de aceptación, cada cambio en tus scripts exige una auditoría interna. No es un detalle de implementación; es una obligación regulatoria en sí misma cuyo incumplimiento ya ha acarreado sanciones directas por parte de la agencia, como demuestra la jurisprudencia reciente contra grandes plataformas del sector automotriz y editorial.

Sustituir un plugin vulnerable por otro de la misma categoría no resuelve el problema estructural. Solo cambia qué nombre aparecerá en el próximo reporte de seguridad. La única arquitectura que elimina simultáneamente las dos cargas —la superficie de ataque y la obligación administrativa— es aquella en la que no existe ningún gestor de consentimiento que vulnerar porque se ha extirpado cualquier software de rastreo: código estático, sin scripts de terceros que mantener actualizados, sin almacenamiento de ID de usuarios en la sombra. No es una versión más segura del mismo sistema; es la neutralización del riesgo por supresión de la infraestructura.

El Cuervo es el archivo de diagnóstico de PRIBECY_