Security2 publishers2 min readPublished Updated
Cloudflare's EmDash 1.0 blocks sandboxed plugins from site data until an admin approves
Cloudflare's EmDash 1.0 CMS starts each sandboxed plugin with only its own storage and blocks seven kinds of site resource until an admin approves. It answers the WordPress model, where every plugin shares the site's PHP process with direct access to its database, files and network.
The Watch · Security desk
What happened
- EmDash shows the access a plugin wants before it runs, and the runtime holds the plugin to that list, with each ability granted separately.
- In the published example, a search plugin can read published articles and reach its search service but cannot edit articles or contact other hosts.
- The plugin registry runs on AT Protocol, the network behind Bluesky, and publishers sign their releases and store them in their own Atmosphere accounts.
- EmDash checks each release against a signed commit, then confirms the checksum, package name, version, requested access and any required build provenance.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint An attacker who takes over a sandboxed plugin through a bad update gets only the grants it already had, so a compromised plugin no longer hands over the whole site by default.
- exposure The administrator's approval is now the main control point, since a request approved without reading is enforced exactly like one that was reviewed.
- exposure Publisher Atmosphere accounts become the target for supply-chain attackers, because a takeover yields releases that pass EmDash's signature checks.
- constraint Responders facing a signed malicious release have no registry-wide recall to call on, so removal has to happen site by site.
Cloudflare pitches EmDash as the "spiritual successor to WordPress" [4]. The plugin runtime is where the two part ways for anyone cleaning up after a compromise. Help Net Security's WordPress example is a contact form plugin that can technically read unpublished posts or send data anywhere, with the owner trusting it through every future update [5][6]. On EmDash the same form would start in an isolated runtime with its own private storage [2]. Content, media, users, secrets, environment, filesystem and network, seven classes in all, stay closed until it declares a need and an administrator approves [3][1]. An image optimizer gets the media library and no user content [17].
In Cloudflare's own comparison, installing a plugin is like installing a phone app [15]. Help Net Security names the weak spot that comes with that model: the runtime enforces whatever the administrator approved, including approvals granted without a glance [8]. A hostile plugin that asks for content and network access gets both with one careless approval. From then on the sandbox enforces the grant as written [3][8]. Help Net Security describes the model for sandboxed plugins and does not say whether EmDash lets any plugin run outside the sandbox [2].
Signing ties each release to the publisher account that committed it and to the access that release declares [9][10]. A release altered after signing, in its code or in its permission list, should fail the checksum and requested-access checks [10]. A signature proves who published a release. Help Net Security notes that a hijacked publisher account would produce valid signatures too [11].
Cloudflare built the registry with no central controller that can take over or remove plugins [12]. Moderation on EmDash's own catalog can hide a listing's name, description, links and images, and the release itself stays published [13].
What to watch
- Whether an EmDash plugin update that requests more access than its previous release forces a fresh administrator approval.
- The first reported takeover of an EmDash publisher's Atmosphere account, and how sites that approved the resulting release learn of it.
- Independent testing of EmDash's isolated plugin runtime for sandbox escapes.