EmDash 1.0とは？Cloudflare発「WordPressの精神的後継」をセキュリティの視点で読み解く

2026年9月28日（米国時間）、Cloudflareはオープンソースのコンテンツ管理システムEmDashの正式版「EmDash 1.0」をリリースしました。4月1日に「WordPressの精神的後継」という刺激的なキャッチコピーとともにプレビュー版が公開され、日付が日付だけに「エイプリルフールでは？」と疑われたプロジェクトです。それからおよそ半年、ベータを卒業して本番利用を前提とした安定版になりました。

EmDashが真っ先に掲げているのは「プラグインのセキュリティ問題を設計で解決する」という主張です。ちょうど2026年はWordPress界隈で、プラグインの買収を悪用したバックドア事件や、コア本体の重大な脆弱性「wp2shell」など、セキュリティの話題が相次いだ年でもあります。今回はEmDashの中身を、昨今のWordPressのセキュリティ事情と突き合わせながら整理してみます。

EmDashとは何か

EmDashは、Webフレームワーク「Astro」の上に構築された、TypeScript製のフルスタックCMSです。WordPressのコードは一切使わずにゼロから作り直されており、その分ライセンスもGPLではなく、より制約の少ないMITライセンスで公開されています。名前の由来は英文で使われる記号の「—（エムダッシュ）」です。

項目	内容
開発元	Cloudflare（オープンソースプロジェクトとして公開）
ライセンス	MIT
言語・基盤	TypeScript／Astro 6系
動作環境	Cloudflare Workers（D1・R2・KV）または任意のNode.jsサーバー
データベース	D1、SQLite、Turso/libSQL、PostgreSQL
ストレージ	R2、AWS S3、S3互換サービス、ローカルファイル
認証	パスキー（WebAuthn）が標準。OAuth・マジックリンク、SSO連携にも対応
権限管理	管理者・編集者・投稿者・寄稿者のロールベース
コンテンツ形式	HTMLではなく構造化JSON（Portable Text）で保存
AI連携	Agent Skills、CLI、組み込みのリモートMCPサーバー
その他	WordPressからのインポート、x402による記事単位の課金
最新版（執筆時点）	emdash 1.3.1（2026年10月18日）

管理画面はWordPressに近い見た目で、投稿・固定ページ・カスタムコンテンツタイプ、メディアライブラリ、メニュー、タクソノミーなど、CMSとして期待される機能はひと通りそろっています。WordPressからはWXRエクスポートやREST API経由で投稿・メディア・タクソノミーを取り込めます。

プレビュー版から1.0までの流れ

4月1日：v0.1.0プレビュー公開　CloudflareのMatt “TK” Taylor氏とMatt Kane氏が発表。AIコーディングエージェントを使って約2か月で作り上げたと説明されました。
4月2日：WordPress側からの反論　WordPress共同創設者のMatt Mullenweg氏が自身のブログで「精神的後継とは言えない」「プラグインのセキュリティは解決していない」と批判（詳しくは後述）。
8月：Cloudflare Blogを移行　自社ブログをEmDashへ移行し、週数百万PV・毎秒5,000リクエスト級のアクセスに耐える運用を自ら検証。
9月28日：EmDash 1.0リリース　安定版となり、以降の破壊的変更はメジャーバージョンでのみ行う方針に。あわせて分散型のプラグインレジストリと、AIサイトビルダー「EmDash Build」（アルファ版）も公開。

1.0の時点で、コントリビューターは175人超、コミットは1,800件超、翻訳は25言語に達しています。半年でここまで来たスピード感は、AIエージェントを開発に組み込んだプロジェクトらしいところです。

なぜ今「プラグインのセキュリティ」なのか

EmDashの主張を理解するには、まずWordPressで何が起きているのかを押さえておく必要があります。2026年は、まさにその問題が立て続けに表面化した年でした。

数字で見るWordPressの脆弱性

WordPressのセキュリティ企業Patchstackが2026年2月に公開した年次レポート「State of WordPress Security in 2026」によると、2025年にWordPressエコシステムで新たに見つかった脆弱性は11,334件。前年の7,966件から約42%増えています。そのうち91%がプラグイン、9%がテーマに由来し、WordPress本体（コア）の脆弱性はごくわずかでした。つまり、リスクの大半は「本体」ではなく「後から入れる拡張機能」にあるということです。

事例1：買収されたプラグインに仕込まれたバックドア

2026年4月に発覚した「Essential Plugin」事件は、プラグインのサプライチェーン攻撃の典型例です。30本以上の無料プラグインを公開していた開発元が、事業売買サイトのFlippaでポートフォリオを売却。新しいオーナーは最初のコミットで、「WordPress 6.8.2との互換性確認」を装った更新にバックドアを仕込みました。

バックドアは約8か月間眠ったまま潜伏し、2026年4月5〜6日に起動
外部サーバーから送られた悪意あるデータをPHPのデシリアライズ処理で実行させ、ファイル書き込みやコマンド実行を可能にする仕組み
サイト管理者からは見えない形で、スパムリンクへのリダイレクトなどが行われた
4月7日、WordPress.orgのプラグインチームが該当する31本を一斉に永久閉鎖。公称インストール数は合計約40万件とされる

この事件が厄介なのは、プラグイン自体はもともと信頼されていたもので、利用者には所有者が変わったことが知らされなかった点です。「評判のよいプラグインを選ぶ」という従来の自衛策が通用しない攻撃でした。

事例2：コア本体の重大脆弱性「wp2shell」

7月17日には、WordPressコアそのものに見つかった脆弱性の連鎖「wp2shell」が公表されました。REST APIのバッチ処理におけるルート混同（CVE-2026-63030、CVSS 9.8）と、WP_QueryのSQLインジェクション（CVE-2026-60137）を組み合わせることで、プラグインを一切入れていない標準構成のサイトでも、認証なしでリモートからコードを実行できるというものです。

WordPressは即日7.0.2・6.9.5・6.8.6を緊急リリースして自動更新を実施しましたが、直後に攻撃コードが出回り、実際に悪用されてWebシェルを設置される被害も確認されています。セキュリティ企業Wizによれば、この脆弱性は発見者がAIモデルを活用して見つけたものだそうです。AIによって脆弱性の発見も悪用も加速している、という最近の流れを象徴する出来事でした。

なお、wp2shellはプラグインではなくコアの問題なので、EmDashのプラグイン隔離とは直接関係しません。ただ「20年以上の歴史を持つ巨大なPHPコードベースを安全に保ち続けることの難しさ」を改めて示した事例として、EmDashをめぐる議論の背景にはなっています。

EmDashのセキュリティ設計

では、EmDashはこうした問題にどう向き合っているのでしょうか。柱は大きく3つあります。

1. プラグインをサンドボックスに閉じ込める

WordPressのプラグインは、本体と同じPHPプロセスの中で動きます。データベースにもファイルにもネットワークにも直接アクセスできるため、たとえば問い合わせフォーム用のプラグインでも、技術的には未公開記事を読んだり、データを外部に送ったりできてしまいます。

EmDashのサンドボックス型プラグインは、それぞれが独立した実行環境（Cloudflare上ではDynamic Worker、Node.js上ではworkerdの別プロセス）で動きます。初期状態で触れるのは自分専用のストレージだけで、サイトのコンテンツ、メディア、ユーザー、シークレット、ファイルシステム、ネットワークには一切アクセスできません。追加の能力は、プラグインがマニフェストで宣言し、サイト管理者が承認したものだけが与えられます。

公式リポジトリで紹介されている、記事の公開時に編集者へメールを送るプラグインの例を見てみましょう。

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

このプラグインが要求しているのは「コンテンツの読み取り」と「メール送信」の2つだけです。記事を書き換えることも、任意の外部サーバーと通信することもできません。外部通信が必要な場合は、接続先のホスト名を個別に指定する必要があります。インストール前に「このプラグインに何を許すのか」が一覧で示される体験は、スマートフォンアプリの権限確認に近いものです。

2. 署名で検証する分散型プラグインレジストリ

1.0で新たに加わったのが、プラグインレジストリです。WordPress.orgのような中央集権型マーケットプレイスではなく、Blueskyでも使われている分散型プロトコル「AT Protocol」の上に構築されています。

プラグイン作者は、ポータブルなID「Atmosphereアカウント」で公開し、パッケージやリリースの記録に自分で署名して自分のアカウントに保存する
EmDashはインストール前に、ダウンロードしたファイルが署名済みリリース記録と一致するか、チェックサム・パッケージ名・バージョン・要求している権限・ビルドの来歴（プロビナンス）を検証する
公式カタログはWorkers AIを使ったラベラーで名前や説明文をモデレーションするが、リリースそのものを書き換えたり、プラグインを取り上げたりはできない
集約サービスやラベラーもオープンソース化されており、第三者が独自のカタログを運営することも可能

現時点で扱えるのは無料プラグインのみで、有料プラグインへの対応は今後の目標とされています。

3. パスワードに頼らない認証

ログインはパスキーが標準です。パスワードそのものが存在しないため、漏えいやブルートフォース攻撃（総当たり）の心配がそもそもありません。WordPressで定番の「wp-login.phpへの総当たり攻撃対策」が不要になるのは、運用面でも地味にありがたいポイントです。

WordPressとの比較

観点	WordPress	EmDash（サンドボックス型プラグイン）
プラグインの実行場所	本体と同じPHPプロセス	プラグインごとに隔離された実行環境
プラグインの権限	DB・ファイル・ネットワークに事実上フルアクセス	宣言し、管理者が承認した能力のみ
権限の可視性	インストール前に把握する手段がほぼない	インストール前に要求権限を表示
配布と検証	WordPress.orgの人手による審査が中心	作者の署名＋インストール時の自動検証
テーマの権限	functions.phpで何でもできる	データベース操作は不可
標準の認証	パスワード（2FAはプラグインなどで追加）	パスキー
エコシステムの規模	6万本超のプラグイン	立ち上がったばかり

「万能の盾」ではない：注意しておきたい点

設計思想は筋がよいものの、EmDashを入れれば安全になる、と考えるのは早計です。導入を検討するなら、次の点は押さえておきたいところです。

サンドボックスの外で動く「ネイティブプラグイン」がある

EmDashのプラグインには、サンドボックスで動く標準形式とは別に、「ネイティブ」形式があります。管理画面用のReactコンポーネントやAstroコンポーネント、データベースへの直接アクセスが必要な場合のための“逃げ道”で、npmからインストールして本体と同じプロセスで動きます。つまり、ネイティブプラグインの信頼モデルは実質的にWordPressと同じです。また、標準形式のプラグインでも、サンドボックス側ではなく信頼済み（trusted）の設定に登録すれば本体と同じプロセスで動きます。

開発者コミュニティでも「多くの利用者はこの違いを理解しないまま使うのでは」という懸念が出ています。EmDashを評価するときは「サンドボックスで動いているプラグインはどれか」を必ず確認する必要があります。

承認するのは結局「人」

権限の可視化は、管理者が中身を読んで判断してはじめて意味を持ちます。スマホアプリで権限ダイアログを流し読みして「許可」を押してしまうのと同じことが、CMSでも起こりえます。CMSWireも、この仕組みが機能するかは管理者がどれだけ注意深く権限要求を確認するか次第だと指摘しています。

Essential Plugin事件のような「所有者が変わって悪意ある更新が配られる」ケースについても、署名が保証するのは「誰が出したか」であって「善意かどうか」ではありません。ただ、更新で新しい権限（たとえば外部ホストへの通信）が追加されれば承認時に気づける余地があり、権限が変わらないかぎり被害の範囲も宣言された能力の内側に限られます。ここが従来モデルとの大きな違いと言えるでしょう（これは筆者の見立てです）。

Cloudflareへの依存度

4月の発表直後、Mullenweg氏は「プラグインのセキュリティはCloudflare上でしか機能しない」「Cloudflareのサービスを売るためのものでは」と批判しました。その後、Node.js環境でもworkerdを別プロセスとして起動してプラグインを隔離する仕組みが整い、1.0では両環境で同じマニフェストと権限制御が使えるようになっています。

とはいえ、最も快適に動くのがCloudflareであることは変わりません。Cloudflare上でサンドボックスを使うにはWorker Loaderのバインディングが必要で、新規プロジェクトでは無料プランでデプロイできるよう、この有料プラン向けの設定が既定で無効になっています。ホスティング先とコストの見積もりは事前に確認しておきましょう。

EmDash自体の「若さ」というリスク

EmDashの公開から約半年。GitHubのセキュリティアドバイザリー欄には、執筆時点で公開済みの脆弱性情報は見当たりません。ただし、これは「脆弱性がない」ことを意味するわけではなく、まだ攻撃者や研究者の目に十分さらされていない段階とも言えます。プロジェクトのセキュリティポリシーでも、認証の回避やサンドボックスからの脱出、SQLインジェクションなどを重点的に報告してほしい対象として挙げています。

加えて、プラグインやテーマのエコシステムはまだ小さく、WordPressで当たり前に使えていた機能がプラグインとして存在しないことも珍しくありません。Mullenweg氏が指摘したとおり、「プラグインがサイトのあらゆる部分を変えられること」はWordPressの強みでもあり、隔離モデルではできないこともあります。

導入を検討するときのチェックポイント

まずは小さなサイトから　キャンペーンサイトや技術ブログなど、要件がシンプルなサイトで試すのが現実的です。管理画面だけならEmDash Playgroundでも触れます。
必要な機能がプラグインで揃うか確認　フォーム、SEO、EC、多言語など、現行サイトで使っている機能を棚卸ししてから判断しましょう。
ネイティブプラグインは最小限に　どうしても必要な場合は、WordPressのプラグインと同じ慎重さでコードと提供元を確認します。
権限承認のルールを決めておく　「外部通信を求めるプラグインは複数人で確認する」など、承認を担当者の感覚任せにしない運用が大切です。
アップデートを追う体制を　1.0以降も更新は頻繁です。リリースノートとセキュリティアドバイザリーを定期的に確認しましょう。
WordPressを使い続けるなら基本の徹底を　使っていないプラグインの削除、コア・プラグインの即時更新、WAFや脆弱性監視の導入など、従来の対策の重要性は変わりません。

まとめ

EmDashは、「プラグインを最初から信用しない」という前提でCMSを組み立て直した、意欲的なプロジェクトです。サンドボックスによる隔離、宣言と承認による権限管理、署名で検証できる分散型レジストリ、パスキー標準の認証と、2026年に表面化したWordPressの課題に対して、設計レベルで答えを出そうとしている点は高く評価できます。

一方で、ネイティブプラグインという例外の存在、管理者の判断に委ねられる承認プロセス、Cloudflareとの結びつきの強さ、そして公開から半年という若さは、冷静に見ておく必要があります。WordPressの代わりにすぐ全面移行する、というよりは、新規の小規模サイトから試しつつ、「プラグインにどこまで権限を渡すか」という考え方そのものを自社のサイト運用に取り入れるのが、現時点での賢い付き合い方と言えそうです。

本記事は、Cloudflareの公式発表、EmDashのGitHubリポジトリ、各種報道・セキュリティ企業の公開情報（2026年10月20日時点の情報）をもとに整理したものです。EmDashのセキュリティ上の効果に関する記述の多くは開発元自身の説明に基づいており、筆者が独自にセキュリティ評価を行ったものではありません。仕様・提供範囲・脆弱性情報は今後変わる可能性があるため、導入を検討する際は必ず公式情報をご確認ください。