Introducing EmDash — the spiritual successor to WordPress that solves plugin security (opens in new tab)
EmDash is presented as a modern, TypeScript-based successor to WordPress, designed for today’s serverless hosting environment. Its central innovation is isolating plugins in sandboxed Dynamic Workers and granting them only explicitly declared capabilities. The project aims to preserve WordPress’s open-source publishing model while addressing plugin security, marketplace dependence, and licensing concerns.
Modernizing WordPress for Today’s Web
- WordPress powers more than 40% of the Internet but was designed when hosting commonly meant managing virtual private servers.
- EmDash is:
- Written entirely in TypeScript
- Built on Astro
- Serverless, while still deployable on personal hardware or Node.js servers
- Fully open source and MIT licensed
- Intended to remain compatible with WordPress-style functionality without using WordPress code
- Version 0.1.0 is available as an early developer beta for Cloudflare or Node.js deployment, along with an online playground.
Building on WordPress’s Publishing Legacy
- WordPress democratized publishing and created a large ecosystem of core contributors, plugin developers, and theme developers.
- The authors argue that WordPress will continue to have a role, but newer developers increasingly use Astro and TypeScript frameworks.
- EmDash seeks to provide a similarly accessible, inexpensive, and open publishing platform suited to modern development practices.
Sandboxed Plugins and Explicit Permissions
- WordPress plugins are PHP scripts with direct access to the site’s database and filesystem.
- This lack of isolation is identified as the source of most WordPress security problems:
- 96% of WordPress site security issues reportedly originate in plugins.
- High-severity vulnerabilities increased substantially in 2025.
- EmDash runs each plugin inside an isolated Dynamic Worker.
- Plugins access platform functionality through capability-based bindings rather than direct access to underlying resources.
- A plugin must declare its required permissions in its manifest, allowing administrators to evaluate permissions before installation.
- The example notification plugin:
- Reacts to content-save events
- Checks whether a post has been published
- Sends an email to editors
- Logs the notification
- Plugins have no general external network access. If network access is necessary, the plugin can request permission for specific hostnames.
- Administrators or platforms could enforce installation policies based on requested permissions instead of relying solely on approved-plugin allowlists.
Security, Marketplaces, and Licensing
- WordPress.org manually reviews plugins because the platform cannot otherwise guarantee their safety.
- The review queue reportedly exceeds 800 plugins and can take at least two weeks.
- Marketplace reputation, ratings, and reviews therefore become essential substitutes for technical trust.
- Because WordPress plugins run inside WordPress and are tightly coupled to its code, developers may also face GPL licensing constraints.
- The article argues that plugin security creates marketplace lock-in:
- Customers rely on marketplaces to assess plugin trustworthiness.
- Developers may need to distribute code under restrictive licensing terms to participate.
- Hosting platforms inherit the risk of running third-party plugins.
- EmDash’s sandboxing and permission model is positioned as a way to reduce reliance on centralized marketplace approval, though the provided article excerpt ends before explaining the promised “two important properties” in full.
EmDash’s practical recommendation is to use capability-limited, isolated plugins as the foundation for a more secure and flexible WordPress-like ecosystem. Its early beta is intended for developers who want to evaluate that model on Cloudflare or Node.js.