EmDash – der geistige Nachfolger von WordPress, der Plugin-Sicherheitsprobleme löst

• EmDash, entwickelt von Cloudflare, ist ein neu konzipiertes Open-Source-CMS, das mit TypeScript und serverloser Architektur entworfen wurde, um die strukturellen Grenzen von WordPress zu überwinden
• Jedes Plugin läuft in einer isolierten Sandbox-Umgebung, wodurch Plugin-Schwachstellen, die 96 % der Sicherheitsprobleme von WordPress-Seiten ausmachen, grundlegend abgeblockt werden
• Mit integriertem x402-Zahlungsstandard unterstützt es On-Demand-Zahlungen (pay-per-use) pro Inhaltseinheit und bietet ein Monetarisierungsmodell für das Zeitalter des KI-basierten Web-Traffics
• Dank einer serverlosen Architektur auf Basis von Cloudflare Workers wird bei Anfragen automatisch hoch- und herunterskaliert, wodurch Kostensenkung und hohe Performance gleichzeitig erreicht werden
• Durch die Integration moderner Funktionen wie Verwaltung von KI-Agenten, Passkey-Authentifizierung und Astro-Theme-Struktur ist es ein CMS, das den Geist von WordPress übernimmt und zugleich vollständig neu aufgebaut wurde

---

Überblick über EmDash

• EmDash ist ein neu entwickeltes Open-Source-CMS, das die strukturellen Grenzen von WordPress lösen soll, und setzt vollständig auf TypeScript sowie eine serverlose Architektur
  • Mit den Kernfunktionen von WordPress kompatibel, verwendet aber keinen bestehenden Code und kann daher unter der MIT-Lizenz vertrieben werden
  • Nutzt die Dynamic Worker von Cloudflare Workers, um jedes Plugin in einer unabhängigen isolierten Umgebung (isolate) auszuführen
  • Bietet auf Basis des Astro-Frameworks eine für inhaltszentrierte Websites optimierte Performance
• EmDash ist auf GitHub öffentlich verfügbar und kann direkt in einem Cloudflare-Konto oder auf einem Node.js-Server bereitgestellt werden
• Verbessert Probleme, die WordPress nicht lösen konnte, grundlegend, darunter Plugin-Sicherheit, Abbau von Marktbindung, KI-basierte Verwaltung und Unterstützung für x402-Zahlungen

Erfolge und Grenzen von WordPress

• WordPress betreibt mehr als 40 % des Internets und ist ein herausragendes Open-Source-Erfolgsbeispiel, das die Demokratisierung des Publizierens vorangetrieben hat
• Doch nach 24 Jahren haben sich Hosting-Umgebungen und Entwicklungsparadigmen stark verändert
  • Früher war das Mieten eines VPS nötig, heute ist Bereitstellung möglich, indem man einfach ein JavaScript-Bundle in ein weltweit verteiltes Netzwerk hochlädt
• EmDash übernimmt den Geist von WordPress, ist aber für moderne Web-Infrastrukturen und Sicherheitsanforderungen neu konzipiert

Lösung der WordPress-Plugin-Sicherheitsprobleme

• 96 % der Sicherheitsprobleme von WordPress-Seiten entstehen durch Plugins
  • Plugins sind PHP-Skripte mit direktem Zugriff auf Datenbank und Dateisystem
  • Bei der Installation erhalten sie nahezu alle Rechte; Isolierung oder Einschränkung von Berechtigungen gibt es nicht
• EmDash führt jedes Plugin in einer Sandbox-Umgebung auf Basis von Dynamic Worker aus
  • Plugins fordern über eine explizite Deklaration (manifest) nur die benötigten capabilities an
  • Beispiel: nur erforderliche Rechte wie read:content, email:send
  • Auch der Netzwerkzugriff ist auf deklarierte Hosts beschränkt
• Vor der Installation lässt sich klar prüfen, welche Rechte ein Plugin anfordert, was eine transparente Berechtigungsstruktur ähnlich OAuth bietet
• Administratoren können Installationsrichtlinien automatisieren auf Basis angeforderter Rechte

Plugin-Sicherheit und Abbau von Marketplace-Bindung

• WordPress.org betreibt wegen Sicherheitsproblemen bei Plugins ein manuelles Prüfverfahren; die Warteschlange umfasst mehr als 800 Einträge
  • Durch GPL-Lizenzauflagen sind Wiederverwendung von Code und Kommerzialisierung eingeschränkt
• EmDash beseitigt Lock-in am Markt durch zwei strukturelle Verbesserungen
  1. Freie Wahl der Plugin-Lizenz: Da EmDash keinen Code teilt, können Entwickler die gewünschte Lizenz wählen
  2. Ausführung in einer Sicherheits-Sandbox: Eine Website kann Plugin-Code vertrauen, ohne ihn direkt einsehen zu müssen
• Da Plugins nur deklarierte capabilities ausführen, lässt sich das Sicherheitsrisiko fein granular bewerten
• Diese Struktur führt zu geringerer Abhängigkeit von zentralisierten Marketplaces
  • Wenn ein verlässliches Sicherheitsmodell vorhanden ist, können Entwickler und Nutzer das Ökosystem frei erweitern

Integrierter x402-Zahlungsstandard — kostenpflichtiger Zugriff auf Inhalte

• EmDash unterstützt den x402-Standard standardmäßig und ermöglicht On-Demand-Zahlungen über die Antwort HTTP 402 Payment Required
  • Nutzer können ohne Abonnement pro Inhaltseinheit zahlen (pay-per-use)
  • Website-Betreiber können Inhalte allein mit Wallet-Adresse und Preisangabe monetarisieren
• Das bietet ein neues Geschäftsmodell für das Zeitalter des KI-Agenten-basierten Web-Traffics
• Jede EmDash-Website besitzt damit eine eingebaute Monetarisierungsstruktur für das KI-Zeitalter

Serverlose Skalierbarkeit und Kostensenkung

• WordPress erfordert Server-Provisionierung, wodurch Kosten für ungenutzte Ressourcen entstehen
• EmDash nutzt eine v8-isolate-Architektur auf Basis von Cloudflare workerd
  • Instanzen werden bei Anfragen sofort erzeugt und bei ausbleibenden Anfragen automatisch auf null skaliert
  • Abgerechnet wird nur die CPU-Nutzungszeit
• Über Cloudflare for Platforms ist automatische Skalierung auf Millionen von Instanzen möglich
• Die kostengünstige und leistungsstarke Struktur eignet sich für großes Traffic-Aufkommen und kostenlose Tiers

Moderne Theme-Struktur auf Basis von Astro

• EmDash-Themes sind als Astro-Projekte aufgebaut und enthalten folgende Elemente
  • Pages: Routen zur Inhaltsdarstellung
  • Layouts: gemeinsame HTML-Struktur
  • Components: wiederverwendbare UI-Elemente
  • Styles: CSS- oder Tailwind-Konfiguration
  • Seed-Dateien: Definitionen der vom CMS zu erzeugenden Inhaltstypen
• Astro ist ein beliebtes Framework, das in Trainingsdaten von LLMs enthalten ist, und dadurch entwicklerfreundlich
• Anders als bei der auf functions.php basierenden Struktur von WordPress-Themes haben EmDash-Themes keinen Zugriff auf die Datenbank, was die Sicherheit erhöht

KI-natives CMS — MCP, CLI, Agent Skills

• EmDash ist als CMS konzipiert, das direkt von KI-Agenten verwaltet werden kann
  • Automatisiert wiederkehrende Aufgaben wie Content-Migration oder Feldtransformationen

• Agent Skills

  • EmDash-Instanzen verfügen über integrierte Agent Skills, die KI Informationen zu Plugin-Struktur, Hooks und Theme-Portierung bereitstellen
  • KI kann die EmDash-Codebasis verstehen und automatisch Anpassungen vornehmen

• EmDash CLI

  • Über die CLI lassen sich Verwaltungsfunktionen wie Inhaltssuche, Medien-Upload und Schema-Erstellung ausführen
  • Sowohl lokale als auch entfernte Instanzen können gesteuert werden

• Integrierter MCP-Server

  • Jede Instanz stellt ihren eigenen Model Context Protocol-Server bereit
  • Alle Aktionen, die in der Admin-UI möglich sind, können auch remote ausgeführt werden

Passkey-basierte Authentifizierung und Rollenverwaltung

• EmDash verwendet standardmäßig Passkey-Authentifizierung
  • Schutz vor Passwortlecks und Brute-Force-Angriffen
• Unterstützt standardmäßig rollenbasierte Zugriffskontrolle (RBAC)
  • Rechte werden nach Rollen wie Administrator, Editor, Autor und Mitwirkender getrennt
• Authentifizierung ist per Plugin erweiterbar und unterstützt die Integration von SSO sowie IdP-Metadaten

Migration von WordPress-Websites

• Bestehende WordPress-Websites können per WXR-Dateiexport oder mit dem EmDash Exporter-Plugin migriert werden
  • Das Exporter-Plugin erstellt einen dedizierten Endpoint, der durch ein WordPress Application Password geschützt ist
  • Inhalte und Medien werden automatisch in die EmDash-Bibliothek übertragen
• EmDash unterstützt eine schema-basierte Inhaltsstruktur
  • Custom Post Types aus WordPress werden in eigenständige Collections von EmDash umgewandelt
• Mit dem Block Kit Agent Skill lassen sich benutzerdefinierte Blöcke per KI erstellen

Ausprobieren und Mitmachen

• EmDash ist derzeit als v0.1.0-Vorschauversion verfügbar und kann aus dem GitHub-Repository heruntergeladen werden
• Über den EmDash Playground lässt sich die Admin-UI direkt ausprobieren
• Lokaler Installationsbefehl: npm create emdash@latest
• Bereitstellung ist auch über das Cloudflare-Dashboard möglich
• Feedback und Beiträge aus der WordPress-Community, von Hosting-Plattformen sowie Plugin- und Theme-Entwicklern sind willkommen

[xguru]

Ich habe auf meinem persönlichen Blog WordPress verwendet, ihn aber wegen genau dieses Sicherheitsproblems aufgegeben und auf eine statische Seite umgestellt.
Ich hatte den Blog eine Zeit lang einfach unbeaufsichtigt gelassen, und dann sind wirklich merkwürdige Spam-Sachen eingedrungen und haben den Blog in ein einziges Spam-Feld verwandelt. Sie haben eine seltsame Methode benutzt, bei der sie über Tags Seiten bei Google registriert haben, die es lokal bei mir gar nicht gibt. Ich kämpfe immer noch damit, das alles zu bereinigen ;_;

[lunamoth]

Ich erinnere mich, dass ich auch einmal seltsame URLs in den Webmaster-Tools entdeckt habe und mich gewundert habe.

„Eine merkwürdige Methode, mit Tags Seiten bei Google zu registrieren, die es lokal gar nicht gibt“ – wie funktioniert das genau??

Kann man das irgendwie blockieren?

[nemorize]

Es gibt auch Spam, bei dem Suchergebnis-URLs für nach Spam klingende Formulierungen als Backlinks in Beiträge anderer Blogs eingetragen werden;
letztlich muss man so etwas ohnehin alles manuell löschen...

[xguru]

Normalerweise dringt man ein, indem man Plugins/Themes usw. mit Schwachstellen beim Datei-Upload ausnutzt.
Wenn sie erst einmal drin sind, platzieren sie Inhalte in Tags/Kategorien usw., ohne dass der eigentliche Blogbesitzer es merkt.
Tatsächlich ist auf der Blog-Seite selbst überhaupt nichts sichtbar, sodass man es nicht bemerkt, und stattdessen wird es so gerendert, dass diese URL nur für den Google-Bot sichtbar ist. (So etwas wie BabaYaga macht genau das.)

Sobald die Seite einmal kompromittiert wurde, gibt es in der Praxis offenbar keine andere Möglichkeit, als alles, was über diese Adressen hereinkommt, auf 410 Gone zu setzen. Auf dem Server sollte man alle unnötigen Adressen auf 410 setzen und dann in der Search Console sechs Monate lang manuell beantragen, bestimmte Muster beim Crawling zu entfernen. Zum Beispiel muss man dann alles löschen lassen, was mit /tag beginnt.

Ich stelle den Löschantrag jetzt seit einem Monat, aber noch immer ist nicht alles entfernt. Die Google-Indexierung müsste eigentlich korrekt funktionieren, aber es dauert lange.

[lunamoth]

Ach so. Danke für den Hinweis. Da muss man wohl in vielerlei Hinsicht darauf achten.

[GN⁺]

Hacker-News-Kommentare

• Ich arbeite seit über 10 Jahren mit WordPress und finde, dass dieses Projekt die zwei Punkte TypeScript und Worker-Plugins genau richtig angeht.
  Ich habe in letzter Zeit viel über die Sicherheitsprobleme von WP nachgedacht: Bösartige Plugins können auf die DB oder Umgebungsvariablen zugreifen oder XSS auslösen. Mit einem gut entworfenen Plugin-System ließe sich das aber abmildern.
  Ich entwickle persönlich gerade HotsauceCMS. Es nutzt optional NodeJS- oder Deno-Worker-Plugins, sodass First-Party-Plugins schnell im Prozess laufen können, während Third-Party-Plugins isoliert in Workern ausgeführt werden.
  Es hat nur vier Abhängigkeiten und null transitive Abhängigkeiten, weil ich von Dependabot-Warnungen und npm-Supply-Chain-Angriffen genug habe.
  Mit einer schema-first-Struktur auf Basis von Drizzle hat man die DB-Struktur vollständig unter Kontrolle und definiert Dinge wie Datei-Uploads über Schema-Hinweise.
  Es ist DB-unabhängig und läuft auf Postgres, MySQL, SQLite und allen anderen von Drizzle unterstützten Datenbanken.
  Das Frontend ist frei wählbar; persönlich bevorzuge ich JSX ohne React.
  Feedback ist willkommen. Mich würde interessieren, ob ich etwas übersehe und ob die Richtung stimmt. Ich bin auch gespannt, wie sich EmDash weiterentwickelt.

  • Mich würde interessieren, warum du TypeScript für so wichtig hältst.
  • Ich habe früher viel WordPress benutzt, und damals war der Reiz die einfache Installierbarkeit: per FTP hochladen und direkt loslegen. Man brauchte weder CLI noch Build-Tools. Sicherheit war aber immer ein Problem, und Hacks hörten nie auf.
  • Hier ist ein Link zu einer früheren Diskussion.

• Es heißt, EmDash sei der geistige Nachfolger von WordPress, aber ich finde, CMS sollten sich eher in die entgegengesetzte Richtung entwickeln.
  Stattdessen sollte man vereinfachen und zu Websites auf Basis statischer Dateien zurückkehren. Das lässt sich leicht cachen, ist schnell und einfach zu verwalten.
  Natürlich wirkt es aus Cloudflares Sicht so, als hätten sie diese Struktur gewählt, um ihre eigenen Workers-Produkte zu verkaufen. Ob damit die grundlegenden Sicherheitsprobleme wirklich gelöst werden, ist für mich noch fraglich.

  • Ich mag statische Websites auch, aber Kunden wollen oft dynamische Inhalte. Erst wünschen sie sich eine einfache Website, später dann Formulare, Bestand, Buchungen und ähnliche Funktionen. Deshalb ist eine pluginzentrierte Struktur nachvollziehbar.
  • Nichttechnische Kunden mögen es, Dinge selbst über eine UI bearbeiten zu können. WordPress hat aber eine zu komplexe und aufgeblähte UI, sodass am Ende doch meist wieder Entwickler ranmüssen. Ideal wäre eine minimale UI, in der nur das Nötigste bearbeitet werden kann.
  • Wenn man Astro verwendet, ist es im Kern ein Generator für statische Websites. Bei Bedarf kann man React-Komponenten hinzufügen und Plugins optional nutzen.
  • Wenn du statische Dateien dort hosten willst, wo sie sich leicht cachen lassen, bietet Cloudflare dafür bereits Dienste an.
  • Astro gibt statisches HTML aus, daher scheint das in dieser Hinsicht kein Problem zu sein.

• Ich glaube, Cloudflare geht das aus der falschen Richtung an.
  WordPress war wegen einfacher Installation und Netzwerkeffekten erfolgreich. Mehr noch als Sicherheit zählt, dass es bereits viele Entwickler gibt, die mit WP vertraut sind.
  Damit EmDash erfolgreich wird, müsste es einfacher, schneller und flexibler sein als Wix oder Squarespace. Sonst wird es schwer, Netzwerkeffekte aufzubauen.

  • Für WordPress gibt es bereits viele erfahrene Fachkräfte, EmDash steht dagegen ganz am Anfang. Wenn es aber wächst, drücke ich die Daumen.

• Als WordPress-Entwickler war mein größter Schmerzpunkt die Plugin-Architektur.
  Bei WP landen Plugins in einem wp-content-Ordner zusammen mit Bildern, was CI/CD zum Albtraum macht. Bei EmDash sind Plugins TS-Module, was deutlich sauberer ist.

  • In WP gibt es kein Staging-Konzept, daher muss man Änderungen beim Übergang in die Produktion manuell erneut durchführen.

• Das Konzept von Cloudflares x402-Zahlungsstandard finde ich interessant.
  Agenten schicken dabei automatisch Kleinstzahlungen, um Zugriff auf Inhalte zu erhalten; das ist etwas unheimlich, aber futuristisch.
  Im Scherz gesagt: Wenn man einen HTTP-402-Honeypot baut, der bei jedem Besuch 10 Cent verlangt, wäre das vielleicht die Wiedergeburt der alten Idee „1 Pixel für 1 Dollar“.

  • Wenn man Agenten so täuscht, dass sie immer weiter bezahlen, könnte man mit Endlosschleifen bei Redirects oder mit wertlosem Inhalt Geld verdienen.
  • Siehe die HTTP-402-Dokumentation.
  • Es fühlt sich an wie eine legalisierte Version des Kleinstbetrags-Unterschlagungshacks aus dem Film Office Space.

• Der Wert von WordPress liegt nicht im Code, sondern im Ökosystem und den Support-Strukturen.
  Die Codequalität ist eher mäßig, aber jeder SaaS-Anbieter liefert einen WP-Connector.
  Damit EmDash erfolgreich wird, müsste auch ein Nichtentwickler auf Fiverr leicht jemanden finden können, der Anpassungen übernimmt. Das ist kein technisches, sondern ein Arbeitsmarktproblem.

  • Cloudflare macht keine Aprilscherze. 1.1.1.1 wurde auch am 1. April gestartet und ist heute ein wichtiger DNS-Dienst.
  • Es wurde bestätigt, dass es ein echtes Projekt ist.
  • Auch die .com-vs-.org-Kontroverse rund um „Open Source“ bei WordPress ist in diesem Zusammenhang interessant.
  • Als ältere Alternative gibt es auch Textpattern.

• Dass es sich um einen von Cloudflare gebauten WordPress-Nachfolger handelt, ist attraktiv, aber die Plugin-Isolierung auf Basis von Dynamic Workers funktioniert nur in der Cloudflare-Laufzeitumgebung.
  Auf anderen Hosts ist es nur ein gewöhnliches TS-CMS, daher ist diese Architekturabhängigkeit problematisch.

  • Letztlich ist es schwer zu übernehmen, wenn OSS in der Praxis an Cloudflare-Infrastruktur gebunden ist.
  • Allerdings ist Workerd Open Source, daher wäre auch Self-Hosting möglich.
  • Andere Laufzeitumgebungen könnten diese Funktion ebenfalls nachbauen.
  • Cloudflare scheint die Strategie zu verfolgen, beliebte OSS als nur auf der eigenen Infrastruktur laufende Ersatzprodukte neu zu bauen.

• Ich frage mich, warum AI-Projekte immer noch mit JavaScript gebaut werden.
  Inzwischen kann man auch mit kompilierten Sprachen wie Go schnell Apps bauen. Sie sind kleiner, schneller und einfacher zu deployen.
  JS ist interpretiert und daher langsam und komplex. Früher war die sofortige Ausführung ein Vorteil, heute geht Kompilierung aber ebenfalls schnell.

  • Zu sagen, „JS ist keine echte Sprache“, ist übertrieben. Es gibt nach wie vor viele gute Gründe für interpretierte Sprachen.
  • JS ist die einzige Sprache, die Web-Frontend, Backend, Mobile und Desktop zugleich abdecken kann. Mit Tools wie tRPC lässt sich außerdem End-to-End-Typsicherheit erreichen.
  • Die meisten Entwickler kennen JS/TS, und die Community ist die größte. Das Ökosystem ist riesig, daher gibt es wenig Anlass zu wechseln.
  • Go ist bei JSON-Verarbeitung und Template-Arbeit umständlich. Das Typsystem ist weniger flexibel, was die Frontend-Entwicklung stärker einschränkt.
  • LLMs kommen gut mit TS zurecht, und TS hat viele Schwächen von JS verbessert. Durch schnelle Laufzeitumgebungen und einfaches Deployment ist es weiterhin attraktiv.

• Interessant ist auch, dass EmDash ohne WordPress-Code auskommt und daher unter der MIT-Lizenz veröffentlicht wird.
  Das erinnert mich aber an das kürzlich aufgetauchte Malus, einen Cleanroom as a Service. Das Timing ist auffällig.

  • Malus ist in Wirklichkeit ein Satireprojekt.