Matthew Kosarek, desarrollador principal de Miracle (un compositor Wayland para Linux), publicó un sistema de plugins basado en WebAssembly que permite extender el manejo de ventanas con código aislado en sandbox. La propuesta de creating a WebAssembly plugin system para window management plantea un modelo de seguridad por capacidades que, si lo comparás con cómo funcionan los plugins de WordPress, te deja pensando en todo lo que el ecosistema WP todavía no resolvió.
En 30 segundos
- Miracle-WM implementa plugins con WebAssembly (WASM) que corren en sandbox aislado, sin acceso directo al sistema
- El modelo usa capacidades explícitas: cada plugin declara qué permisos necesita antes de ejecutarse
- A diferencia de los plugins WordPress (que tienen acceso total al servidor), WASM limita el daño posible de un plugin malicioso
- El Component Model de WebAssembly define interfaces tipadas que previenen la inyección de datos arbitrarios entre componentes
- WordPress no tiene nada parecido a este nivel de aislamiento, y eso explica por qué un plugin vulnerable compromete todo el sitio
Qué es Miracle-WM y por qué importa su modelo de plugins
Miracle es un compositor de ventanas para Wayland, el protocolo que reemplaza a X11 en Linux. Desde que Wayland se impuso, los gestores de ventanas perdieron la capacidad de ser extensibles con plugins externos. Cada escritorio armó su propio sistema cerrado.
Según el post de Kosarek, el objetivo era crear un sistema donde los usuarios pudieran personalizar el comportamiento de las ventanas sin comprometer la estabilidad ni la seguridad del compositor. La solución: WebAssembly como runtime de plugins.
WASM es un formato binario que corre en un sandbox determinístico. No tiene acceso al filesystem, a la red, ni a la memoria del proceso host salvo que se le otorguen permisos explícitos. Eso lo hace ideal para ejecutar código de terceros sin confiar ciegamente en él (algo que WordPress podría aprender). Si te interesa, podés leer más sobre estrategias de segmentación y firewalls perimetrales.
Creating a WebAssembly plugin system: el enfoque de seguridad por capacidades
Ponele que instalás un plugin en tu compositor que reorganiza las ventanas en un layout tipo tiling. En el modelo tradicional, ese plugin tendría acceso a todo: podría leer archivos, abrir conexiones de red, modificar otros procesos. En el modelo WASM de Miracle, el plugin solo puede hacer lo que el host le permite a través de interfaces definidas.
Kosarek exploró varias alternativas antes de llegar a WASM. GNOME usa extensiones en JavaScript que se cargan dinámicamente. River tiene un protocolo IPC para control externo. Cada enfoque tiene sus trade-offs, pero la mayoría comparte un problema: el código del plugin corre con los mismos privilegios que el proceso principal.
El modelo de Miracle tiene tres propiedades clave que lo diferencian:
- Rendimiento: los plugins WASM corren a velocidad casi nativa sin frenar el compositor
- Aislamiento: cada plugin opera en su propio sandbox, sin acceso a recursos que no se le otorgaron
- Portabilidad: un plugin compilado a WASM funciona en cualquier arquitectura sin recompilar
Ojo: esto no es teoría. El Component Model de WebAssembly (que alcanzó estabilidad en 2025) define interfaces tipadas con WIT (WebAssembly Interface Types) que especifican exactamente qué funciones expone el host y qué puede invocar el plugin. Si te interesa, podés leer más sobre los feature plugins gratuitos de WordPress.
El contraste brutal con los plugins de WordPress
Acá viene lo interesante. Si trabajás con WordPress, sabés que cualquier plugin tiene acceso completo al servidor. Un plugin de formularios de contacto puede leer wp-config.php, ejecutar queries SQL arbitrarias, escribir archivos en cualquier directorio, y hasta instalar backdoors. No existe sandbox. No existe aislamiento. No existen capacidades declaradas.
Te llega un aviso de Wordfence, entrás al admin, ves que hay un archivo PHP que no creaste en wp-content/uploads, revisás los logs del servidor, descubrís que un plugin de galería tenía un file upload sin validar y alguien subió un webshell que lleva tres días activo mientras vos ni te enteraste.
Esa es la realidad. Y no es un caso extremo.
En 2025, Patchstack reportó que el 97% de las vulnerabilidades de WordPress venían de plugins, no del core. El problema no es que los desarrolladores sean malos programadores. El problema es que la arquitectura de WordPress le da a cada plugin la llave maestra del edificio entero.
Lo que WASM resuelve y WordPress no
En el modelo WASM, si un plugin de window management tiene una vulnerabilidad, lo peor que puede pasar es que las ventanas se comporten raro. El plugin no puede escalar a leer archivos del usuario ni modificar el sistema operativo. El sandbox lo contiene. Si te interesa, podés leer más sobre parches críticos de Windows en la nube.
En WordPress, si un plugin de SEO tiene un SQL injection, el atacante accede a toda la base de datos: usuarios, passwords hasheados, tokens, emails, contenido. No hay contención posible porque PHP no ofrece ese nivel de aislamiento entre componentes.
WASI y el futuro de los plugins seguros
WASI (WebAssembly System Interface) es la capa que define cómo un módulo WASM interactúa con el sistema operativo de forma controlada. Pensalo como un set de permisos granulares: este plugin puede leer este directorio, pero no puede escribir. Puede hacer requests HTTP, pero solo a estos dominios.
Miracle usa esto para que cada plugin declare sus necesidades al instalarse. Si un plugin de tiling pide acceso a la red, eso ya es sospechoso (para qué necesitaría red un plugin que solo mueve ventanas?). Si te interesa, podés leer más sobre el ataque a Trivy en GitHub Actions.
WordPress no tiene nada equivalente. Un plugin declara que necesita PHP 7.4 y WordPress 6.0, y eso es todo. No dice «necesito acceso a la base de datos», «necesito escribir en el filesystem», o «voy a hacer requests HTTP externos». Se asume que puede hacer todo, siempre.
Hay propuestas para implementar algo similar en WordPress (el concepto de «plugin capabilities» se discutió en varios WordCamps), pero la retrocompatibilidad lo hace casi imposible. Miles de plugins dependen de poder hacer lo que quieran con el servidor.
Qué significa para sitios WordPress en Latinoamérica
Si administrás sitios WordPress en un hosting como donweb.com, la realidad es que dependés de que cada plugin que instalás esté bien programado. No tenés un sandbox que te proteja si el desarrollador del plugin cometió un error. La «protección» que ofrecen la mayoría de los hostings compartidos es un WAF genérico que bloquea patrones conocidos, pero no impide que un plugin vulnerable ejecute código arbitrario dentro de tu cuenta.
El modelo WASM no va a llegar a WordPress mañana. Pero entender cómo funciona te ayuda a dimensionar el riesgo real de instalar plugins sin auditar. Si te interesa, podés leer más sobre comparativas de plugins de seguridad WordPress.
Errores comunes
Creer que «plugin popular» significa «plugin seguro»
Un plugin con 5 millones de instalaciones activas tuvo exactamente las mismas vulnerabilidades críticas que uno con 500. La popularidad no implica auditoría de código. Revisá el historial de CVEs antes de instalar cualquier cosa.
Confiar en que WordPress core te protege de plugins maliciosos
WordPress core no tiene mecanismo de aislamiento entre plugins. Si un plugin es vulnerable, tiene el mismo nivel de acceso que wp-admin. El core asume buena fe de todos los plugins instalados, y eso es un problema de diseño que lleva dos décadas sin resolverse.
Pensar que desactivar un plugin lo neutraliza
Un plugin desactivado sigue teniendo sus archivos PHP en el servidor. Si alguno de esos archivos tiene un endpoint accesible directamente (sin pasar por el loader de WordPress), un atacante puede ejecutarlo aunque el plugin esté «desactivado». Desactivar no es desinstalar.
Preguntas Frecuentes
WebAssembly puede usarse para proteger plugins de WordPress?
No de forma directa. WordPress corre sobre PHP, que no tiene soporte nativo para sandboxing WASM de plugins. Existen proyectos experimentales como php-wasm, pero ninguno está listo para producción. Por ahora, la protección pasa por auditoría manual, WAFs, y limitar los plugins al mínimo indispensable.
Qué diferencia hay entre el sandbox de WASM y un contenedor Docker?
Docker aísla a nivel de sistema operativo (filesystem, red, procesos). WASM aísla a nivel de runtime, dentro del mismo proceso. WASM es más granular y liviano: podés tener 50 plugins WASM corriendo en el mismo proceso sin overhead significativo, algo impensable con 50 contenedores.
Miracle-WM se puede usar en un servidor que corre WordPress?
No tienen relación directa. Miracle-WM es un compositor de ventanas para escritorio Linux. Lo relevante para WordPress es el modelo de seguridad que implementa: capacidades declaradas y sandbox por plugin. Ese patrón de diseño es lo que la comunidad WP debería estudiar, no la herramienta en sí.
Cómo puedo reducir el riesgo de plugins vulnerables hoy?
Instalá solo plugins que necesités (no los que «podrían servir algún día»). Mantené todo actualizado con wp-cli: wp plugin update --all. Usá un WAF como Wordfence o Patchstack que bloquee exploits conocidos. Y revisá periódicamente los reportes de vulnerabilidades en sitios como donweb.news para enterarte antes de que te afecte.
Conclusión
Lo que hizo Kosarek con Miracle-WM demuestra que es posible tener un sistema de plugins extensible sin sacrificar la seguridad. WebAssembly, con su sandbox determinístico y su modelo de capacidades, ofrece lo que WordPress nunca tuvo: la posibilidad de ejecutar código de terceros sin darle acceso irrestricto al sistema.
WordPress no va a adoptar WASM para plugins en el corto plazo. Pero el contraste es útil para entender por qué cada semana aparecen CVEs críticos en plugins: no es solo negligencia de los desarrolladores, es un problema arquitectónico. Mientras tanto, la defensa es la de siempre: menos plugins, más actualizaciones, y no confiar en que alguien más auditó el código por vos.