El 1 de agosto de 2026 salió el aviso de CVE-2026-18435 en Kadence Blocks, uno de los plugins de bloques más instalados del ecosistema Gutenberg. XSS almacenado, CVSS 6.4, acceso mínimo requerido: rol Contributor. Dos días antes del lanzamiento previsto de WordPress 7.1. Yo no lo veo como una mala coincidencia: lo veo como el patrón que llevamos repitiendo desde mayo, cuando Spectra —antes Ultimate Addons for Gutenberg— apareció en el NVD con un RCE de nivel 8.8 que también bastaba con un Contributor para ejecutar PHP en el servidor.
Si gestionas webs de clientes con bloques personalizados, seguro que tienes al menos uno de estos plugins en algún proyecto. Kadence, Spectra, Essential Blocks, Nexter… son el kit de herramientas estándar para montar landings sin tocar código. Y todos comparten la misma debilidad estructural: confían en que quien puede crear contenido no va a abusar de los atributos de los bloques. Spoiler: en WordPress, eso nunca ha sido una apuesta segura.
Lo de Spectra es más grave de lo que parece en el titular. Según NVD y el análisis de Threat-Modeling.com, un atacante autenticado con rol Contributor puede registrar un bloque falso con prefijo uagb/, inyectar un render_callback malicioso y ejecutarlo en la misma petición de renderizado. No hace falta ser administrador. No hace falta subir un plugin. Basta con poder editar una entrada. En sitios con registro abierto o con cuentas de colaboradores externas —redactores freelance, agencias de contenido, community managers— eso es exactamente lo que tienes.
Kadence, en cambio, es la versión «suave» del mismo problema: XSS almacenado vía el atributo toggleIcon en versiones hasta la 3.7.8. No te tumba el servidor de un golpe, pero sí te permite inyectar JavaScript que se ejecuta cuando un editor o un visitante abre la página. En una tienda WooCommerce con sesión de admin activa, eso puede escalar rápido. Y otra vez: Contributor basta.
¿Por qué siempre Contributor? Porque el modelo de permisos de WordPress separa «puede publicar contenido» de «puede administrar el sitio», y los desarrolladores de plugins de bloques diseñan asumiendo que quien edita bloques es de confianza. Pero en la práctica, el rol Contributor existe precisamente para dar acceso limitado a personas que no deberían tocar nada crítico. Si tu plugin permite ejecutar código o inyectar scripts con ese nivel de permiso, el plugin es la vulnerabilidad.
Lo que me molesta no es tanto el fallo concreto —los bugs pasan— sino la cadencia. Spectra en mayo, Essential Blocks en junio, Kadence el 1 de agosto. Cada aviso con la misma firma: sanitización insuficiente en atributos de bloques, explotación con permisos bajos, parche en la versión siguiente. Actualizas, respiras, y al mes siguiente aparece otro plugin del top 50 con el mismo patrón. No es mala suerte: es deuda técnica acumulada en una arquitectura donde cualquier atributo JSON del bloque puede acabar renderizado en HTML sin pasar por las mismas validaciones que el resto del contenido.
Y mientras tanto, WordPress 7.1 apunta a otra dirección. Responsive styling nativo, editor en iframe forzado, Abilities API para agentes de IA. Cosas que mejoran la experiencia de edición y abren WordPress al futuro. Pero si tu stack de bloques sigue siendo un colador de XSS y RCE, da igual que el editor sea responsive: el agujero está en lo que renderizas, no en cómo lo maquetas.
En mi experiencia con clientes, casi nadie audita qué plugins de bloques tienen instalados ni qué roles tienen activos los usuarios que no son admin. El panel de WordPress muestra «todo actualizado» si el núcleo y los plugins principales están al día, pero no te avisa de que tienes tres Contributors de una agencia de contenido de 2022 que ya no trabaja contigo. Ni de que el plugin de bloques que instalaste para una landing de 2024 sigue activo en producción con 200.000 instalaciones en el repositorio y un historial de CVEs trimestral.
Las recomendaciones oficiales son las de siempre: actualiza Kadence a la 3.7.9 o superior, Spectra a la 2.19.26, revisa logs, restringe registros abiertos. Correcto. Pero insuficiente si no cambias el modelo mental. Un Contributor no debería poder hacer nada más allá de escribir texto y subir imágenes. Si tu plugin de bloques le da más poder que eso —aunque sea «solo» inyectar un icono SVG sin sanitizar— estás externalizando la seguridad de tu servidor a la buena fe de quien tiene acceso al editor.
Tampoco ayuda que muchos de estos plugins se venden como «page builders ligeros» alternativos a Elementor, con la promesa de rendimiento y simplicidad. Instalas Kadence Blocks porque quieres tabs y acordeones sin cargar medio megabyte de JavaScript. Pero ligero en peso no significa ligero en superficie de ataque. Cada bloque con atributos configurables es un vector potencial, y Gutenberg no obliga a los desarrolladores a pasar por un sandbox antes de renderizar.
Lo que haría yo esta semana, antes de que WordPress 7.1 llegue el 19 de agosto y todo el mundo esté distraido con estilos responsive: inventario de plugins de bloques activos en cada instalación, grep de usuarios con rol Contributor o superior que no hayan entrado en los últimos 90 días, y verificación de versión en Kadence y Spectra aunque el panel diga que no hay actualizaciones pendientes —a veces el caché del hosting miente. Si tienes registro abierto en algún sitio, ciérralo o limita el rol por defecto a Subscriber hasta que tengas claro quién entra.
No voy a decirte que dejes de usar plugins de bloques. Los uso y ahorran horas. Pero sí que dejes de tratarlos como «solo maquetación» y empieces a tratarlos como código con privilegios de ejecución. Porque eso es lo que son cuando un XSS almacenado se convierte en robo de sesión de admin, o cuando un RCE en Spectra te deja un webshell en wp-content/uploads.
El ecosistema Gutenberg lleva años prometiendo que los bloques son el futuro del contenido en WordPress. Y lo son. Pero el futuro también incluye que un redactor externo con permisos mínimos no debería poder tumbar tu servidor con dos bloques en un borrador. Hasta que eso no sea verdad de serie —no parche a parche— seguirás pagando el mantenimiento en CVEs, no en funcionalidades.
Si mañana te entra un correo de un freelance pidiendo acceso Contributor para «publicar un par de entradas del blog», y tienes Kadence Blocks sin actualizar desde antes del 1 de agosto, ¿le das acceso o primero revisas qué plugins de bloques tiene activos ese sitio?