Here is a question most site owners have never been asked, because the answer has always been the same. When you install a contact form plugin, what is it actually allowed to do?
On WordPress the answer is everything. Plugins run inside the same PHP process as the rest of the site, with direct access to the database, the filesystem and the network. A contact form plugin can read your unpublished drafts, alter another plugin’s files, and send whatever it likes wherever it likes. Not because it is malicious, but because nothing stops it. You are trusting that it will not, and trusting that no future update changes its mind.
Everyone in this industry knows that and most of us have stopped noticing it. A new content management system released by Cloudflare at the end of September 2026 is built around not doing it that way, and the comparison is instructive whether or not you would ever switch.
Every article we have written this month about a compromised WordPress site comes back to the same structural fact. A flawed upload handler could write a program file anywhere on the site because the plugin containing it had permission to write anywhere. A page builder could switch off an authentication check for the entire site, including other plugins’ endpoints, because nothing scoped it to its own. A single malicious file could read the database credentials, rewrite the active plugin list and copy itself to other sites on the server, because a plugin runs with the full authority of the site.
In none of those cases did the attacker need to defeat a boundary. There was no boundary. The flaw got them inside the process, and inside the process everything is reachable.
Your phone solved this fifteen years ago. An app declares what it needs, you approve it, and the operating system enforces it. A torch app that asks for your contacts is a question you get to answer, and if you say no it does not get them. Nothing equivalent exists in WordPress, and the practical consequence is that the only real control a site owner has is how many plugins they install and how well they know each one.
The CMS in question is called EmDash. It reached version 1.0 on 28 September 2026, it is free and open source under the MIT licence, and it is built on Astro rather than PHP. Cloudflare first introduced it on 1 April, which led a lot of people to assume it was a joke. It was not.
The part worth attention is the plugin model. Each plugin runs in its own isolated runtime with its own private storage, and by default it cannot reach the site’s content, media, users, secrets, environment, filesystem or network. Anything beyond that has to be declared by the plugin and approved by the site administrator, and the capabilities are independent of one another: permission to work with media does not carry permission to read users, and permission to contact one external service does not open the rest of the network.
Their own illustration is a good one. A search indexing plugin can be allowed to read your content and contact the search service, while still being unable to edit an article or contact any other host. An image optimisation plugin can read and manage media without being able to read a word of your user data. Those limits are enforced by the runtime, not by the plugin author’s intentions.
This is not Cloudflare-only, which matters for the idea’s prospects. On Cloudflare each plugin runs as an isolated worker, and on an ordinary Node.js server EmDash starts the same open source runtime as a separate process and isolates plugins inside that. Same declarations, same enforcement.
The other half of the announcement is a plugin registry built on the protocol behind Bluesky. Plugin authors publish under a portable identity, and the package and release records are signed by the publisher and stored in the publisher’s own account rather than in a central catalogue. EmDash verifies a plugin against the signed record, checking the checksum, package name, version, requested access and build provenance before trusting the download.
The argument is about who holds the keys. In a conventional registry one organisation controls the publisher’s identity, the authoritative record of what was released, and the shop window. If your account is suspended or the rules change, you cannot take your identity and history elsewhere. Here they are yours, and other catalogues can index the same publications under their own policies.
Be clear about what that verification proves, because this will be widely misreported. It proves the package you downloaded is exactly what that publisher signed. It is not a security review. There is no human vetting, no audit and no approval gate, and the project says so plainly: authors can publish without asking permission. Moderation applies only to the names, descriptions, links and images shown in the catalogue, not to the code. Cryptographic provenance answers “is this really from them and unaltered”, which is a genuinely useful question and a completely different one from “is this safe”.
The sandbox is what limits the damage a bad plugin can do. The registry is what tells you who wrote it. Neither is a review, and the combination is still a large improvement on trusting a zip file.
For most of the sites we host, not as something to move to. Being straight about it:
Where it is worth a serious look is a marketing site or brochure site that a developer already maintains, particularly one where the WordPress plugin count has become a maintenance burden rather than a feature. That is the case the project makes for itself, and it is a fair one.
You will probably not move your site. The idea is still the most interesting thing to happen to this problem in a decade, and it changes how a reasonable person should think about the risk they are carrying.
Every plugin on your site today has full access to everything on your site. That is not a criticism of any particular plugin and it is not a reason for alarm. It is a reason for a specific habit: treat the number of installed plugins as a security figure rather than a convenience figure. Ten plugins is ten pieces of code with complete authority over your content, your customer data and your credentials, maintained by ten different people to ten different standards, any of which can be sold, abandoned or compromised.
Until WordPress has something like a permission model, and there is no sign of one coming, the only lever you have is that number. Remove what you do not use, including the deactivated ones, since a deactivated plugin is still a folder of code on the server. Know who maintains each of the rest. Prefer one plugin doing three jobs over three doing one each. Our article on the security measures that actually matter covers the ground, and everything in it becomes easier the shorter your plugin list is.
We will keep an eye on EmDash and will say so here if it becomes something we would recommend building on. If you would like us to go through your plugin list with you and identify what can go, open a ticket. It is a short job and it is the closest thing to a sandbox that WordPress currently offers.