Por qué los plugins de WordPress son una pesadilla para la seguridad y cómo EmDash lo soluciona

WordPress alimenta más de 40 sitios %. Pero su arquitectura de plugins es responsable de miles de vulnerabilidades al año. Cloudflare ofrece otra manera.

Un problema que WordPress no puede resolver desde dentro

Cuando instalas un plugin en WordPress, le das acceso completo a la base de datos y al sistema de archivos de todo el sitio. No hay aislamiento. El plugin de formulario de contacto técnicamente tiene los mismos permisos que el plugin de gestión de comercio electrónico - ambos ven todo: datos de usuario, contenido, configuración, detalles de pago.

Esto no es culpa de un plugin específico. Es un principio arquitectónico de WordPress desde 2003. Un plugin es un script PHP que se conecta directamente al núcleo del sistema. WordPress confía absolutamente en él.

Y aquí es donde empieza el problema.

Cifras que deberían preocupar a todo webmaster

La empresa de seguridad Patchstack realiza un seguimiento sistemático de las vulnerabilidades en el ecosistema de WordPress. Sus datos de los últimos años muestran una tendencia clara:

Año 2024 trajo consigo 7 966 nuevas vulnerabilidades, lo que supone un aumento de 34 % con respecto al año anterior. Esto significa una media de 22 nuevos agujeros de seguridad cada día. De ellos, 96 % procedían de plugins y 4 % de plantillas. Sólo se encontraron 7 vulnerabilidades en el propio núcleo de WordPress.

Primer semestre de 2025 añadió 6.700 vulnerabilidades. Sin embargo, más importante que el número en sí es otra cifra: 41,5 % de ellas eran realmente explotables en la práctica, frente a 30,4 % en el mismo periodo del año pasado. El atacante no necesitaba credenciales de acceso.

Los tipos de vulnerabilidades más comunes siguen siendo los mismos desde hace años: Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Broken Access Control y Local File Inclusion.

El mito del plugin popular

La suposición generalizada es que los plugins conocidos con millones de instalaciones son seguros porque están controlados por una gran comunidad. Los datos dicen lo contrario.

En 2024, se encontraron más de 1.000 vulnerabilidades en plugins con más de 100.000 instalaciones activas. Se encontraron vulnerabilidades críticas en herramientas tan extendidas como LiteSpeed Cache, Really Simple SSL y The Events Calendar. Patchstack pagó su recompensa más alta en 2024 -16.400 dólares- por una vulnerabilidad crítica en LiteSpeed Cache, un plugin con millones de usuarios.

La popularidad no significa seguridad. Significa un objetivo mayor.

Por qué WordPress no puede arreglarlo

La arquitectura de plugins está tan integrada en el funcionamiento de WordPress que no puede modificarse sin romper la compatibilidad con decenas de miles de plugins existentes. Todos los plugins presuponen un acceso total a la base de datos. Eliminar este acceso significaría que la mayoría de los plugins dejarían de funcionar.

Por lo tanto, WordPress aborda la seguridad de otras maneras: actualizaciones periódicas, plugins de seguridad (como Patchstack), reglas de cortafuegos, principios de permisos mínimos a nivel de rol de usuario. Todo esto ayuda, pero no aborda la causa raíz: la arquitectura confía implícitamente en cada plugin.

A esto se añade el problema de los plugins abandonados. En 2024, 1.614 plugins y plantillas vulnerables fueron retirados de WordPress.org gracias a los investigadores de seguridad. Pero muchos de ellos siguen instalados en sitios activos.

EmDash: un enfoque diferente de la seguridad de los plugins

En abril de 2026, Cloudflare presentó EmDash, un CMS (sistema de gestión de contenidos) de código abierto que denomina „el sucesor espiritual de WordPress“. Se encuentra en la versión 0.1.0 - early developer beta diseñado principalmente para pruebas y desarrollo. Pero su arquitectura de seguridad merece atención incluso en esta fase.

Sandbox en lugar de acceso total

EmDash resuelve el principal problema de la arquitectura de WordPress: los plugins se ejecutan en un entorno aislado (sandbox) y tienen que declarar de antemano a qué necesitan acceder. El plugin de envío de correo electrónico obtiene permisos „email:send“ y „read:content“, nada más. No puede leer la base de datos de usuarios, acceder a los datos de pago o modificar el contenido de otros plugins.

En Cloudflare Workers, cada plugin se ejecuta en su propio entorno aislado V8. Incluso si un plugin se ve comprometido, su alcance se limita a las operaciones permitidas explícitamente. Un formulario de contacto comprometido no puede escalar el acceso a todo el sitio.

El modelo de seguridad total de EmDash está estrechamente ligado a la arquitectura de Cloudflare Workers y a su modelo de aislamiento. Para implementaciones que no sean de Cloudflare, es aconsejable verificar qué garantías de seguridad se mantienen en la práctica.

Autenticación sin contraseñas

Por defecto, WordPress utiliza un inicio de sesión clásico con nombre de usuario y contraseña. Los ataques de fuerza bruta en la página de inicio de sesión son uno de los vectores de ataque más comunes.

EmDash no admite contraseñas en absoluto. La autenticación por defecto utiliza passkeys (claves criptográficas vinculadas al dispositivo) y está diseñada para ser conectable - se pueden conectar proveedores de identidad externos. No hay contraseñas que puedan ser adivinadas, robadas de la base de datos o mal utilizadas tras una filtración desde otro servicio.

Licencias y aislamiento del código

EmDash está escrito completamente en TypeScript y utiliza la licencia MIT. Por razones de seguridad, es importante que los plugins no compartan código con EmDash, ya que se ejecutan de forma independiente. Esto significa que Vulnerabilidad en el plugin no puede utilizar la API interna del núcleo de la forma que permite la arquitectura de WordPress.

Lo que EmDash aún no es

Es importante dejar claro lo que EmDash no representa en su forma actual:

• No es un producto acabado. Cloudflare lo lista como v0.1.0 preview / early developer beta - es una versión temprana principalmente para pruebas y desarrollo.
• No tiene Ecosistema. WordPress tiene decenas de miles de plugins y plantillas. EmDash cuenta con varias demos oficiales.
• Sandbox depende de la plataforma. El aislamiento completo de plugins se incluye con Cloudflare Workers. Para otros entornos, el alcance de las garantías de seguridad no está claramente documentado.
• La instalación es más complicada. Requiere trabajar con el repositorio de GitHub y configurar la base de datos, algo muy distinto a la „instalación en cinco minutos“ de WordPress.

Lo que hay que aprender

EmDash no es una razón para abandonar WordPress. Pero sí hay motivos para pensar en lo fundamentalmente diferentes que son los modelos de seguridad:

Hay una lección práctica para los webmasters de WordPress: si te quedas en WordPress (y la mayoría de la gente tiene buenas razones para quedarse), presta atención a la higiene de la seguridad de los plugins:

• Minimizar el número de plugins. Cada plugin es un vector de ataque potencial.
• Elimine los plugins no utilizados y no actualizados. Los plugins abandonados son una amenaza silenciosa.
• Actualización continua. La mayoría de los ataques se dirigen a vulnerabilidades conocidas y ya parcheadas.
• Considere la posibilidad de supervisar la seguridad. Herramientas como Patchstack pueden desplegar reglas de protección antes del parche oficial.
• Utilice la autenticación de dos factores. WordPress no lo ofrece por defecto, pero hay plugins fiables que lo añaden.

EmDash muestra cómo puede ser un CMS diseñado con la seguridad como principio arquitectónico básico, no como una capa adicional. Que se convierta en una alternativa viable dependerá de que se desarrolle una comunidad y un ecosistema a su alrededor. Hoy por hoy, es un concepto interesante. Pero un concepto que nombra correctamente un problema que todos los que tienen un sitio WordPress deberían conocer.

Patchstack - State of WordPress Security 2025, Patchstack Mid-Year Report 2025, Cloudflare Blog, The Register, Search Engine Journal, The Repository