TYPO3 Extension Security: What We Can Learn from Cloudflare's EmDash

With EmDash, Cloudflare has introduced an ambitious project: an entirely new CMS, written in TypeScript, built on Astro, with a radically different approach to plugin security. The timing — 1st of April — caused justifiable scepticism, but the product is real: the code is on GitHub, the architecture is well thought out, and industry heavyweights like Joost de Valk (founder of Yoast SEO) have seriously engaged with it.

For TYPO3 agencies, EmDash is not a direct competitor. However, the ideas behind it deserve attention — especially the capability manifest concept.

Table of Contents  

EmDash: The new CMS by Cloudflare  

On the 1st of April 2026, Cloudflare released EmDash — an open-source CMS positioning itself as the "spiritual successor to WordPress". The complete source code is available on GitHub; the project runs on Cloudflare's own infrastructure (D1, R2, Workers) or on any Node.js server with SQLite.

The core innovation: every plugin declares in a capability manifest which permissions it requires. Undeclared capabilities are physically impossible — enforced by v8 isolates (Cloudflare Dynamic Workers).

Joost de Valk, founder of Yoast SEO and one of the most influential voices in the WordPress ecosystem, described EmDash as the most interesting thing to happen to content management in years. The tech press reacted with mixed feelings: technically impressed, but sceptical regarding its market chances against WordPress, which holds over a 43% market share and has 60,000 plugins.

// EmDash Plugin — declares exactly two capabilities
export default () =>
  definePlugin({
    id: "notify-on-publish",
    capabilities: ["read:content", "email:send"],
    hooks: {
      "content:afterSave": async (event, ctx) => {
        if (event.content.status !== "published") return;
        await ctx.email.send({
          to: "editorial@example.com",
          subject: `New post: ${event.content.title}`,
        });
      },
    },
  });

This plugin can exclusively read content and send emails. No file access, no database manipulation, no outbound network traffic — technically impossible, not just by convention.

The WordPress Problem (and why TYPO3 is not immune)  

96% of all WordPress security vulnerabilities stem from plugins. The reason is architectural: a WordPress plugin runs in the same PHP process as WordPress itself and has full access to the database, file system, and network. A compromised plugin means a compromised system.

EmDash solves this radically: each plugin runs in its own v8 isolate. It can only use the capabilities it has declared.

The question is not which CMS has the more secure foundational system. The question is: do administrators know what their extensions are actually doing? Which tables does EXT:news read? Does EXT:solr make outbound network connections? Does EXT:gridelements override core classes via XCLASS?

What we are adopting from EmDash  

PHP does not have v8 isolates. We cannot physically isolate extensions from one another — at least not without fundamental architectural changes. But we can achieve a large part of the security benefits through declaration and auditing:

Specifically, we are transferring three EmDash concepts to TYPO3:

1. Capability Manifests — Every extension declares in a Capabilities.yaml which subsystems it uses
2. Static Analysis — An audit tool verifies the declaration against the actual code
3. Site Policies — Administrators define which capabilities are permitted

The Manifest Format: Capabilities.yaml  

Every TYPO3 extension receives a new file under Configuration/Capabilities.yaml:

# EXT:news/Configuration/Capabilities.yaml
capabilities:
  version: "1.0"

  subsystems:
    - database:read
    - database:write
    - database:schema
    - cache:read
    - cache:write
    - file:read
    - content:plugin
    - content:contentElement
    - typoscript:provider
    - cli:command
    - routing:enhancer
    - tca:override

  database:
    own_tables:
      - tx_news_domain_model_news
      - tx_news_domain_model_tag
      - tx_news_domain_model_link
    reads:
      - pages
      - tt_content
      - sys_file_reference
      - sys_category
    writes:
      - tx_news_domain_model_news
      - tx_news_domain_model_tag

  network:
    outbound: []

  risk:
    level: "low"
    justification: "Content extension with no outbound network connections"

Administrators can see immediately: this extension accesses its own tables and a few core tables, makes no outbound network connections, and does not override any XCLASS. Risk: low.

Risk Assessment  

The audit tool calculates a risk score based on the declared (and detected) capabilities:

Risk levels: 0–4 Low, 5–9 Medium, 10–14 High, 15+ Critical.

The CLI Tool  

Our open-source package webconsulting/typo3-capability-manifest provides three commands:

# Generate manifest from existing code
typo3 capability:generate news

# Result:
# ✓ Capabilities.yaml written to:
#   vendor/georgringer/news/Configuration/Capabilities.yaml
# Detected: database:read, database:write, content:plugin, ...
# Risk score: 4 (LOW)

Site Capability Policy  

For enterprise environments, administrators can define which capabilities are allowed:

# config/capability-policy.yaml
policy:
  name: "Enterprise Strict"

  deny:
    - xclass:override
    - network:outbound:any

  review_required:
    - auth:provider
    - site:middleware
    - network:outbound

  max_risk_score: 12
  require_manifest: true

Comparison: EmDash vs TYPO3 Capability Manifests  

What the Static Analysis Detects  

The tool uses nikic/php-parser for AST-based analysis and pattern matching for configuration files:

Example Manifests: Top TER Extensions  

The approach can be applied as an example to popular TER extensions. Here is an overview of exemplary risk assessments:

Potential Roadmap  

Installation and Usage  

# Entry point
# Repository: https://github.com/dirnbauer/typo3-capability-manifest

# Example calls after local setup of the repository
./vendor/bin/capability-audit capability:generate news \
  --extension-path=vendor/georgringer/news

# Perform audit
./vendor/bin/capability-audit capability:audit news \
  --extension-path=vendor/georgringer/news

# Check all extensions against policy
./vendor/bin/capability-audit capability:policy-check \
  --policy=config/capability-policy.yaml \
  --project-root=.

Conclusion  

EmDash demonstrates what CMS plugin security should look like in 2026: declarative, transparent, and auditable. Whether EmDash will replace WordPress remains to be seen — the ecosystem problem is real. However, the architectural ideas behind it can be applied immediately.

For TYPO3, this means: we do not have to wait for runtime isolation. Capability manifests with static analysis and policy enforcement already give us the transparency and governance that enterprise clients require today.

Key takeaways:

• Extension security is not a WordPress-exclusive problem — TYPO3 benefits from the same approach
• Declaration + auditing delivers a large portion of the benefits of runtime isolation
• The verified entry point for the tool is the GitHub repository
• Every TYPO3 agency can apply the capability manifest approach to their extensions today