# Essential Blocks abre tus CPT privados a cualquiera sin login: el agujero que el marketing del plugin no menciona
**Categoría:** CMS
**Estilo:** crítico
**Fecha:** 2026-09-02
—
Si tienes Essential Blocks instalado y además usas custom post types no públicos — membresías, catálogos internos, fichas de clientes, lo que sea — puede que hayas montado la privacidad en el registro del CPT y te hayas olvidado de mirar qué hace un plugin de bloques por su cuenta. La CVE-2026-13154 demuestra que no hace falta ni usuario ni contraseña para leer contenido que marcaste como no visible.
Lo vi en el informe de Armis y me quedé con la misma sensación de cuando Spectra y Kadence empezaron a acumular fallos graves en bloques de Gutenberg: el problema no es solo el código roto, es que miles de sitios instalan estos plugins porque «van bien con el editor» sin revisar qué endpoints REST dejan abiertos. Essential Blocks, en versiones anteriores a la 6.4.0, expone un endpoint público que acepta nombres de post type enviados por el atacante y devuelve entradas publicadas de tipos que tú registraste como no públicos. CVSS 7.5, vector de red, sin autenticación, sin interacción del usuario. En castellano: cualquiera con un navegador puede probar.
Y aquí viene lo que me parece peor que la vulnerabilidad en sí. No es un fallo de configuración tuyo. No es que hayas olvidado un checkbox en Ajustes → Privacidad. Es que el plugin asume que si algo está «publicado», da igual si el post type es público o no. En WordPress, registrar un CPT con publicly_queryable => false o show_in_rest => false es un patrón habitual en tiendas con productos ocultos, áreas de socios o contenido premium empaquetado con otro plugin de acceso. Tú hiciste las cosas bien en el core. El plugin las deshace por la puerta de atrás.
En mi experiencia auditando webs de clientes, casi nadie revisa la superficie REST después de instalar un page builder. Miras si el diseño cuadra, si el bloque de testimonios carga rápido y si el soporte responde en el foro. Los endpoints quedan en segundo plano hasta que WPScan o un informe de CVE te avisan. Essential Blocks lleva millones de instalaciones activas — es de los plugins estrella del ecosistema Gutenberg — y la corrección llegó en la 6.4.0, pero el aviso no aparece en el changelog con el mismo dramatismo que una feature nueva de animaciones. Actualiza y listo, dicen. Como si actualizar en producción un martes a las once de la mañana fuera gratis.
Lo irónico es el timing. WordPress acaba de anunciar su Core Security Initiative para gestionar el aluvión de informes que generan las herramientas de IA, y al mismo tiempo los plugins más instalados del editor siguen regalando filtraciones sin autenticar. El core aprieta el grifo a los investigadores pidiendo impacto alto y issues sin auth; los constructores de bloques siguen publicando REST routes que no respetan la visibilidad del post type. No me cuadra el mensaje de «ecosistema más seguro» cuando la cadena de suministro de Gutenberg depende de decenas de plugins con ciclos de parche distintos y changelog pensados para marketing, no para operaciones.
¿Qué puedes hacer hoy si gestionas sitios con Essential Blocks? Tres cosas, en este orden. Primero: comprueba la versión. Si estás por debajo de 6.4.0, actualiza o desactiva el plugin hasta poder hacerlo en staging. Segundo: si tienes CPT no públicos con contenido sensible, asume que pudo haberse filtrado si el plugin estuvo activo meses — no hay confirmación de explotación masiva en producción, pero el vector es trivial. Tercero: audita qué otros plugins de bloques tienes instalados; la CVE-2026-13154 no es la única en la familia Essential Blocks, y el patrón de XSS almacenado en versiones anteriores a 6.1.4 (CVE-2026-10833) demuestra que la superficie de ataque no se limita a esta filtración.
Desde el lado del desarrollador de plugins, la lección es aburrida y necesaria: un endpoint REST público no puede confiar en que el cliente envíe solo post types «seguros». Hay que comprobar visibilidad, capacidades y contexto antes de devolver datos. WordPress ya tiene APIs para eso; ignorarlas no es innovación, es deuda técnica con intereses de seguridad. Y desde el lado del usuario — tú, que mantienes webs de clientes — deberías tratar cada plugin de bloques como una extensión del servidor: si lo activas, amplías la API de tu sitio aunque no lo veas en el menú.
No voy a decirte que dejes Gutenberg ni que proscribas Essential Blocks para siempre. Lo uso en proyectos y funciona bien para maquetar sin escribir CSS a mano. Pero sí te digo que la promesa de «bloques bonitos sin código» esconde una responsabilidad de infraestructura que muchas agencias siguen externalizando al «lo actualizamos cuando salga la notificación del dashboard». Esa notificación llegó en agosto. Estamos en septiembre. Si tu cliente tiene un área de socios montada con CPT privados y Essential Blocks viejo, la pregunta no es si el plugin es bonito. Es si alguien ya habrá probado el endpoint.
Si mañana un auditor te confirmara que tu catálogo de precios internos estuvo expuesto tres meses por un plugin de bloques que no habías auditado, ¿le explicarías al cliente que «era culpa del ecosistema WordPress» o reconocerías que no revisaste la REST API cuando instalaste el page builder?