EmDashのサイトは今回のPHP脆弱性の対象外。それでも残る4つの更新と責任
2026年10月のPHP緊急脆弱性（CVE-2026-109618・109619）は、PHPを使わないEmDashのサイトには届きません。自サイトで確かめた4つの手順と、PHPの代わりに残るnpm依存・EmDash本体・プラグイン・ログインの更新、移行を考えるべき条件をまとめました。
「うちのサイトはEmDashで作ってもらったけど、今回のPHPの件は大丈夫？」。2026年10月21日にPHPの緊急アップデートが出てから、こう聞かれる場面が増えています。結論から言うと、EmDashで動くサイトは今回の脆弱性CVE-2026-109618とCVE-2026-109619の対象外です。PHPそのものが動いていないからです。ただし同じドメインやサーバーに、PHPで動く旧サイトやメールフォームが残っている場合は、その部分が対象になります。また「PHPが無いから何もしなくていい」わけではありません。この記事では、綴の自サイト tsudzuri.com で実際に確かめた手順と、PHPの代わりに残る更新の仕事を整理します。
EmDashのサイトに今回のPHP脆弱性は届かない
EmDashのサイトは、リクエストを受け取る場所にPHPがいません。だから今回の2件の脆弱性は届きません。ポイントは2つです。
- 今回の脆弱性は「PHPの処理系」の中にある
- EmDashはPHPを使わず、TypeScriptで書かれたAstroのアプリとして動く
何が起きたかの全体像はPHPに緊急の脆弱性2件（2026年10月）WordPressサイトで今日やることにまとめています。ここでは「EmDashならどうか」だけを扱います。
今回の脆弱性はPHPの処理系の中にある
PHP開発チームのセキュリティアドバイザリによると、修正版は8.5.12・8.4.27・8.3.36・8.2.35です。対象はWebリクエストを処理するすべてのPHPで、例としてPHP-FPM・Apacheのmod_php・php-cgi・FrankenPHP・LiteSpeedが挙がっています。どれも「WebリクエストをPHPに渡して処理させる仕組み」です。8.1以前には通常の修正版が出ないため、8.2以上への切り替えが必要です。
つまり問題はWordPressやプラグインのコードではなく、その下で動くPHP本体にあります。PHPの処理系を通らないサイトには、今回の2件が入り込む入口がありません。
EmDashはPHPを使わないCMS
EmDashの公式ドキュメント「Why EmDash」には、EmDashはPHPもWordPressのテーマやプラグインも動かさない、と明記されています。管理画面もサイトも、Astroというフレームワークの中で動くTypeScriptのアプリです。
Cloudflare Workersに置いた場合、リクエストを受けるのはCloudflareの実行環境（V8というJavaScriptエンジンを使った workerd）です。PHP-FPMやmod_phpに当たるものは、構成のどこにも出てきません。
自サイトで確かめた4つのこと
tsudzuri.com はEmDashで動いています（2026年10月22日に0.32.0から1.3.1へ更新）。「PHPが無い」を言葉だけで終わらせないよう、同じ日に次の4点を自分で確かめました。手順は自分のサイトにもそのまま使えます。
package.jsonとデプロイ設定を見る
package.jsonの依存に並ぶのは、emdash・astro・@astrojs/cloudflare・react などnpmのパッケージだけです。PHPの処理系は1つも入っていません。
デプロイ設定の wrangler.jsonc には、Workersの入口になる src/worker.ts と、データベースのD1、画像置き場のR2、キャッシュ用のKVが書かれています。サーバーを1台借りてPHPを入れる、という手順はどこにもありません。
本番の応答ヘッダーと.phpファイルを見る
本番のトップページにcurlでアクセスし、応答ヘッダーを確かめました。返ってきたのは server: cloudflare で、PHPの存在を示す X-Powered-By は出ていません。WordPressのログイン画面にあたる wp-login.php は404でした。
リポジトリ全体を node_modules まで含めて数えても、拡張子が.phpのファイルは0件でした。
ヘッダーだけで判断しなかったのには理由があります。X-Powered-ByはPHPの設定で隠せるので、出ていないことだけではPHPが無い証拠になりません。依存とデプロイ設定、ファイルの中身まで見て、初めて言い切れます。
PHPが無くても残る更新は4つある
PHPの更新が要らない代わりに、別の更新が残ります。「PHPが無い」は今回の2件に無関係という意味で、更新ゼロという意味ではありません。残るのは次の4つです。
- npmの依存パッケージ
- EmDash本体
- プラグイン
- 管理画面のログイン
npmの依存パッケージ
EmDashのサイトは数百のnpmパッケージの上に乗っています。WordPressでいえば本体やプラグイン、それらに同梱されたライブラリの更新に当たるのが、ここの更新です。
この記事を書くにあたり、2026年10月22日に自サイトで npm audit を実行しました。指摘は29件（脆弱なパッケージの数）で、critical 2件とhigh 20件を含んでいました。件数は実行した時点のもので、脆弱性のデータベースが更新されると同じ状態でも変わります。その日のうちに依存を更新してastroを7.2.0から7.4.2へ上げ、critical 2件を含む28件が消えました。
残った1件は、devalueというパッケージのhighでした。@astrojs/react の6系が古いdevalueを指定していたためで、同じ日に @astrojs/react を7系へ上げるメジャー更新をして解消しました。今は npm audit の指摘は0件です。指摘の読み方はnpm audit の公式ドキュメントが基準です。
処理系の更新はCloudflareに移ります。ライブラリの更新はここに残るわけです。
EmDash本体
自サイトのEmDashは、2026年10月22日に0.32.0から1.3.1（npmの最新）へ上げました。
公式のUpdate EmDashによると、更新ツール upgrade-emdash は0.35.0以降が前提です。0.32だった自サイトは、まず手で0.35.0に上げてから、残りを更新ツールに任せました。emdash と @emdash-cms/cloudflare は同じ番号で一緒に上げる決まりです。
プラグイン
EmDashのプラグインには、隔離された別の実行環境で動くサンドボックス型と、サイトと同じプロセスで動くネイティブ型があります。サンドボックス型は、隔離の仕組み（CloudflareのWorker Loaderなど）が使えない環境では読み込まれません。ネイティブ型はサイトと同じ権限を持ちます。だから入れるなら中身を読んで信頼できるものに限ります。
自サイトで動いているのは field-kit の1件だけで、ネイティブ型として組み込んでいます。2種類の違いはEmDashのプラグインは2種類——サンドボックス型とネイティブ型で任せ方が違うに書きました。公式のChoosing a plugin formatも判断の基準になります。
管理画面のログイン
EmDashの管理画面は、既定でパスキー（指紋や顔認証、端末のPINでサインインする仕組み）を使います。パスワードが存在しないので、使い回しや総当たりの心配は小さくなるわけです。ただしメールのログインリンクや、GitHubやGoogleのアカウント連携を有効にした場合は、そのメールやアカウントの守りもログインの入口になります。詳しくは公式のAuthenticationにあります。
それでも、誰にどの権限を渡すか、退職者のアカウントを消すかは運用の仕事で、CMSが変わってもここは人が決めるしかありません。
構成で変わるのは更新の量より「誰が受け持つか」
構成を変えると、更新の総量よりも「誰が受け持つか」が変わります。WordPressを一般的なレンタルサーバーで動かす場合と、自サイトのEmDash構成を並べると次のとおりです。
項目 | WordPress（レンタルサーバー） | EmDash（綴の構成） |
|---|---|---|
OS・Webサーバー | サーバー会社 | Cloudflare |
言語の処理系 | PHP（サーバー会社か管理者。契約による） | Workersの実行環境（Cloudflare） |
CMS本体 | WordPress（サイトの管理者） | EmDash（制作側がnpmで更新） |
拡張機能 | プラグイン・テーマ（サイトの管理者） | プラグイン（制作側） |
ライブラリ | プラグインに同梱（プラグイン作者が更新） | npmの依存（制作側） |
ログイン | パスワード。2段階認証やパスキーはプラグインで追加（運用側） | パスキーが既定（運用側） |
拡張機能の数・情報量 | 非常に多い | まだ少ない |
対応できる人の数 | 多い | 少ない |
違いが大きいのは上の2行です。Workersの実行環境はCloudflareが更新します。CloudflareのSecurity modelによると、V8に修正が出てから本番に届くまで24時間未満という運用です。今回のPHPのように「処理系の修正を待って、反映を確かめる」作業が、制作側から外れます。
サーバー保守がどこまで消えるかはサーバー保守を抱えたくない制作会社へ。Cloudflare前提の構成で消える作業・残る作業で詳しく書いています。
移行を考えるべき条件、まだ考えなくてよい条件
今回の件だけを理由に、急いでWordPressから移る必要はありません。まずPHPを更新するのが先です。そのうえで、移行を考えるかどうかは次の条件で分けられます。
移行を考えるべき条件
- PHPやWordPressの更新を、誰がいつやるか決まっていない
- サーバーの契約が古く、PHPのバージョンを自分で上げられない
- 使っているプラグインの多くが、すでに更新されていない
- サイトの中身が記事やお知らせ中心で、会員機能や決済が無い
まだ考えなくてよい条件
- 保守契約があり、今回もすぐにPHPが更新された
- 会員管理やネットショップなど、WordPressのプラグインに深く頼る機能がある
- 社内に更新を回せる担当者がいて、手順が回っている
構成の考え方はWordPressを続けるか移るかの判断、実際の引っ越し手順はWordPressからEmDashへの移行にまとめています。
よくある質問
EmDashならセキュリティ対策は何もしなくていいですか
いいえ。今回のPHPの脆弱性には無関係ですが、npmの依存パッケージやEmDash本体の更新、プラグインの見極め、アカウントの管理は残ります。更新の担当者と頻度を決めておく必要がある点は、WordPressと変わりません。
WordPressのサイトでも、Cloudflareを前に置けば今回の件は防げますか
防げるとは言えません。php.netの発表では、完全な解決策はPHPの更新だけです。Cloudflareを前に置いても、後ろのサーバーでPHPが動いている限り、PHPの更新は必要です。
自分のサイトがPHPで動いているか、どう確かめればいいですか
この記事の4手順が使えます。WordPress本体はPHPで動くので、公開側を静的に書き出す構成でも、管理画面のあるサーバーではPHPが動いています。迷ったら、サーバーの管理画面でPHPのバージョン表示があるかを見るのが早い確かめ方です。
まとめ
綴では、WordPressからEmDashへの引っ越しと、EmDash以外も含めたPHPに依存しないCMSへの移行をお手伝いしています。今回の件で「次の更新を誰がやるのか」が気になった方は、WordPress移行のご相談についてをご覧ください。今の構成と更新の担当を一緒に整理するところから始められるので、まずはお問い合わせからご連絡ください。
本記事は2026年10月時点の情報です。