TYPO3 Extension Security: Was wir von Cloudflares EmDash lernen

Cloudflare hat mit EmDash ein ambitioniertes Projekt vorgestellt: Ein komplett neues CMS, geschrieben in TypeScript, gebaut auf Astro, mit einem radikal anderen Ansatz für Plugin-Sicherheit. Das Timing — 1. April — sorgte für berechtigte Skepsis, aber das Produkt ist real: Der Code liegt auf GitHub, die Architektur ist durchdacht, und Branchengrößen wie Joost de Valk (Gründer von Yoast SEO) haben sich ernsthaft damit auseinandergesetzt.

Für TYPO3-Agenturen ist EmDash kein direkter Konkurrent. Aber die Ideen dahinter verdienen Aufmerksamkeit — insbesondere das Capability-Manifest-Konzept.

Inhaltsverzeichnis  

EmDash: Das neue CMS von Cloudflare  

Am 1. April 2026 hat Cloudflare EmDash veröffentlicht — ein Open-Source-CMS, das sich als "spiritueller Nachfolger von WordPress" positioniert. Der vollständige Quellcode liegt auf GitHub, das Projekt läuft auf Cloudflares eigener Infrastruktur (D1, R2, Workers) oder auf jedem Node.js-Server mit SQLite.

Die Kern-Innovation: Jedes Plugin deklariert in einem Capability Manifest, welche Berechtigungen es benötigt. Nicht deklarierte Fähigkeiten sind physisch unmöglich — durchgesetzt durch v8-Isolates (Cloudflare Dynamic Workers).

Joost de Valk, Gründer von Yoast SEO und eine der einflussreichsten Stimmen im WordPress-Ökosystem, bezeichnete EmDash als das Interessanteste, was dem Content-Management seit Jahren passiert ist. Die Tech-Presse reagierte gemischt: Technisch beeindruckt, aber skeptisch gegenüber den Marktchancen gegen WordPress mit über 43 % Marktanteil und 60.000 Plugins.

// EmDash Plugin — deklariert exakt zwei 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: "redaktion@example.com",
          subject: `Neuer Beitrag: ${event.content.title}`,
        });
      },
    },
  });

Dieses Plugin kann ausschließlich Inhalte lesen und E-Mails senden. Kein Dateizugriff, keine Datenbankmanipulation, kein ausgehender Netzwerkverkehr — technisch unmöglich, nicht nur per Konvention.

Das WordPress-Problem (und warum TYPO3 nicht immun ist)  

96 % aller WordPress-Sicherheitslücken stammen aus Plugins. Der Grund ist architektonisch: Ein WordPress-Plugin läuft im selben PHP-Prozess wie WordPress selbst und hat vollen Zugriff auf Datenbank, Dateisystem und Netzwerk. Ein kompromittiertes Plugin bedeutet ein kompromittiertes System.

EmDash löst das radikal: Jedes Plugin läuft in einem eigenen v8-Isolate. Es kann nur die Capabilities nutzen, die es deklariert hat.

Die Frage ist nicht, welches CMS das sicherere Grundsystem hat. Die Frage ist: Wissen Administrator:innen, was ihre Extensions tatsächlich tun? Welche Tabellen liest EXT:news? Macht EXT:solr ausgehende Netzwerkverbindungen? Überschreibt EXT:gridelements Core-Klassen via XCLASS?

Was wir von EmDash übernehmen  

PHP hat keine v8-Isolates. Wir können Extensions nicht physisch voneinander isolieren — zumindest nicht ohne fundamentale Architektur-Änderungen. Aber wir können einen Großteil des Sicherheitsgewinns durch Deklaration und Audit erreichen:

Konkret übertragen wir drei EmDash-Konzepte auf TYPO3:

1. Capability Manifests — Jede Extension deklariert in einer Capabilities.yaml, welche Subsysteme sie nutzt
2. Static Analysis — Ein Audit-Tool verifiziert die Deklaration gegen den tatsächlichen Code
3. Site Policies — Administrator:innen definieren, welche Capabilities erlaubt sind

Das Manifest-Format: Capabilities.yaml  

Jede TYPO3-Extension erhält eine neue Datei unter 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 ohne ausgehende Netzwerkverbindungen"

Administrator:innen sehen sofort: Diese Extension greift auf eigene Tabellen und einige Core-Tabellen zu, macht keine ausgehenden Netzwerkverbindungen und überschreibt kein XCLASS. Risiko: niedrig.

Risikobewertung  

Das Audit-Tool berechnet einen Risk Score basierend auf den deklarierten (und erkannten) Capabilities:

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

Das CLI-Tool  

Unser Open-Source-Paket webconsulting/typo3-capability-manifest bietet drei Befehle:

# Manifest aus bestehendem Code generieren
typo3 capability:generate news

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

Site Capability Policy  

Für Enterprise-Umgebungen können Administrator:innen definieren, welche Capabilities erlaubt sind:

# 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

Vergleich: EmDash vs. TYPO3 Capability Manifests  

Was die Static Analysis erkennt  

Das Tool nutzt nikic/php-parser für AST-basierte Analyse und Pattern-Matching für Konfigurationsdateien:

Beispiel-Manifests: Top TER-Extensions  

Das Repository enthält Stub-Manifests für die meistgenutzten TER-Extensions. Hier ein Überblick der Risikobewertungen:

Mögliche Roadmap  

Installation und Nutzung  

# Installation
composer require webconsulting/typo3-capability-manifest

# Manifest für eine Extension generieren
./vendor/bin/capability-audit capability:generate news \
  --extension-path=vendor/georgringer/news

# Audit durchführen
./vendor/bin/capability-audit capability:audit news \
  --extension-path=vendor/georgringer/news

# Alle Extensions gegen Policy prüfen
./vendor/bin/capability-audit capability:policy-check \
  --policy=config/capability-policy.yaml \
  --project-root=.

Fazit  

EmDash zeigt, wie CMS-Plugin-Sicherheit im Jahr 2026 aussehen sollte: deklarativ, transparent, auditierbar. Ob EmDash WordPress ablösen wird, bleibt abzuwarten — das Ecosystem-Problem ist real. Aber die Architektur-Ideen dahinter sind sofort anwendbar.

Für TYPO3 bedeutet das: Wir müssen nicht auf Runtime-Isolierung warten. Capability Manifests mit Static Analysis und Policy Enforcement geben uns heute schon die Transparenz und Governance, die Enterprise-Kund:innen brauchen.

Die wichtigsten Erkenntnisse:

• Extension-Sicherheit ist kein WordPress-exklusives Problem — TYPO3 profitiert vom gleichen Ansatz
• Deklaration + Audit liefert einen Großteil des Nutzens von Runtime-Isolierung
• Das Tool ist ab sofort nutzbar — composer require webconsulting/typo3-capability-manifest
• Jede TYPO3-Agentur kann ihre Extensions heute auditieren