見出し画像

Cloudflare WAFでは塞げない穴と、EmDashという選択肢(代替WordPress)

zephel01

2026年4月、EssentialPlugin が配布していた30以上のWordPressプラグインにバックドアが仕込まれていたと分かった。影響は40万件超のインストールに及ぶとされる（TechCrunch の2026年4月14日報道）。Patchstack によれば、プラグイン群は2025年8〜9月ごろ Flippa 経由で取得され、直後にバックドアが埋め込まれた。活性化が4月5日、発覚は4月7日。半年以上、正規のプラグインとして更新が配信され続けたことになる。

2026年6月には ShapedPlugin の件が報じられている。攻撃者がベンダーのビルド・配布パイプラインに侵入し、正規のライセンス更新チャネルから配られる有償プラグインに悪意コードを混ぜた、というものだ。対象は Product Slider Pro for WooCommerce（3.5.4以前）など3製品、CVE-2026-49777 には CVSS 10.0 が付いている。

どちらも、WAF が壊れていたわけではない。管理画面で「更新」を押す、あの経路から入ってきている。

Cloudflare WAF が守ってくれる範囲

WAF を軽く見ないように先に書いておく。Cloudflare の Free Managed Ruleset は Free を含む全プランに自動適用され、Log4j や Shellshock と並んで「非常に一般的な WordPress の既知エクスプロイト」への対応ルールが入っている。各ルールには技術スタック別のタグが付き、`wordpress` タグのルールを有効にする運用も案内されている。

Cloudflare の公式サポートドキュメントが示す WordPress の守り方は3段階だ。Managed Rulesets と OWASP ruleset で XSS/SQLi を止める。`/wp-admin/` にスキップルールを置いて IP・ASN・Cookie などで絞る。その先が Zero Trust Access による管理画面のアクセス制限、mTLS、Rate Limiting でのログインブルートフォース対策。

ここまでやれば外から飛んでくる既知の攻撃はかなり削れる。最初にやることとして十分に妥当だ。

構文は見えるが、意味は見えない

WAF が検査するのはリクエストの構文で、アプリがそれを内部で何として扱うかは分からない。認証後の脆弱性や権限昇格、ビジネスロジックの不備が苦手なのはそのためだ。IDOR のようにリクエストが構文的に正当でペイロードも無い攻撃は素通りするし、シグネチャの無いゼロデイも止まらない。

冒頭の2件は、そこからもう一段外側にある。WAF が見るのはサイトに入ってくるリクエストだ。プラグインの更新は、サイトが自分から取りに行って自分の中で実行する。検査線を、そもそも横切らない。動き出した時点で、それは攻撃ではなくサイト自身の正規の動作だ。

WordPress のプラグインが強いのはここだ。サイトのデータベースとファイルシステムに直接触れる。Cloudflare の言い方だと "There is no isolation"。入れた瞬間に、ほぼ全部を渡している。

割合は下がり、件数は増えた

Patchstack「State of WordPress Security in 2026」（2026年2月25日発行・2025年のデータ）によると、2025年の新規脆弱性は11,334件で2024年比42%増、うち91%がプラグイン起因だ。前年版（2025年3月・2024年のデータ）は7,966件でプラグイン起因96%。EmDash の公式ブログが引く「96%」はこちらの数字になる。

割合は下がったが、件数は1.4倍になった。もっと刺さるのは時間軸で、脆弱性の公開から大規模な悪用が始まるまでの中央値は5時間。高リスクの約50%が24時間以内に悪用される。「気づいたら更新する」という運用と、5時間は噛み合っていない。

EmDash が変えたのは、権限の持ち方

Cloudflare が EmDash を発表したのは2026年4月1日。日付が日付なのでネタを疑うが、開発は続いていて2026年7月1日に v0.26.0 が出ている。TypeScript 製、Astro 6.0 ベース、Cloudflare Workers 上で動く MIT ライセンスの CMS で、位置づけは "the spiritual successor to WordPress"。自分はまだ触っていないから、以下は公式ドキュメントを読んだ範囲の話だ。

肝はプラグインの動かし方だ。EmDash のプラグインは Dynamic Worker Loader を使った Worker サンドボックス、つまり V8 isolate の中で動き、それぞれが capability マニフェストを宣言する。宣言先は `emdash-plugin.jsonc`（2026年7月時点の表記）。

{
  "slug": "plugin-hello",
  "capabilities": ["content:read", "network:request"],
  "allowedHosts": ["api.example.com"]
}

面白いのは、権限チェックで弾く設計になっていない点。docs はこう書く。"Calling a method on an undeclared capability isn't possible — there's no object there."。宣言した capability に対応する `ctx.content` や `ctx.http` だけが注入され、宣言していないものは呼ぶ先そのものが存在しない。

サンドボックス版は環境変数もファイルシステムも見えず、`fetch()` の直接呼び出しはランナーがブロックする。テーマも "can never perform database operations" とされる。配布は marketplace.emdashcms.com 経由だけで任意 zip は非対応。インストール前に権限の同意ダイアログが挟まり、認証は Passkey がデフォルトだ。

冒頭の手口をここに置き直すと、`wp-config.php` に相当するものを書き換えようにもファイルシステムが見えない。C2 に出ようにも `network:request` を宣言していなければ `ctx.http` が無い。

正直な但し書き

とはいえ「EmDash ならプラグインは安全」とは書けない。公式自身が限界を認めている（以下すべて2026年7月時点）。

いちばん大きいのは金の話だ。README は、サンドボックスプラグインの実行が Dynamic Workers に依存し、それは有料アカウントでしか使えないと書いている。示された選択肢は、$5/月から始まる Workers Paid にアップグレードするか、`wrangler.jsonc` の `worker_loaders` ブロックをコメントアウトしてプラグイン機能を切るか、の二択。「WordPress のプラグイン問題を解決した」という物語の、実運用上いちばん大きな注釈がこれだ。

プラグイン形式が2つあるのも効く。ネイティブプラグインは Astro サイトと同じプロセスで動き、docs の表現では "full access to the runtime"。React 製の管理画面が要るものはこちらで、サンドボックスされない。Node.js 上で動かす場合も "no V8 isolate, no resource limits" だ。

capability の粒度も粗い。docs は "Capabilities are coarse." と認めていて、`content:write` を持つプラグインは自分のもの以外のコンテンツも編集できる。ホスト制限を外す `network:request:unrestricted` も正式にある。docs 自身 "Only install plugins from authors you trust." と書いていて、結局そこは変わらない。違うのは、信頼が裏切られたときの被害範囲が設計で狭めてあるかどうかだ。README には "EmDash is in beta preview." とあり、1.0 はまだ出ていない。

移行はこう進む、という程度の話

まず監査から。投稿数、カスタム投稿タイプと ACF フィールド、必須プラグイン、パーマリンク構造、Search Console で上位に出ている URL。WooCommerce や会員機能が中核にあるなら、今の EmDash では現実的に厳しい。環境は `npm create emdash@latest` で作れて、管理画面は `/_emdash/admin`、初回は Passkey で管理者を作る。

コンテンツは WXR が確実で、docs も "The most complete import method" としている。ツール → エクスポート のファイルを Import に渡すと、Connect → Analyze → Prepare Schema → Execute Import → Media Import（任意）の5ステージを通る（docs の content-import ページの表記）。

本丸はテーマだ。PHP のテンプレート階層から Astro コンポーネントへは移植ではなく再構築になる。コンテンツ取得は `getEmDashCollection("posts")` で戻り値は配列ではなく `{ entries, error }`、本文は `"emdash/ui"` から import した `PortableText` で描画する。docs の "In themes, never use `getStaticPaths()` or `export const prerender = true`" は、Astro に慣れているほど踏みそうだ。

本文側では、Gutenberg から Portable Text への変換で未知のブロックが `htmlBlock` として生 HTML のまま残る。独自ブロックが多いサイトほど手動レビューが増える。あとは対応表を作って Cloudflare の Redirect Rules で301、サイトマップを送り直し、1〜2週間は並行稼働させる。

で、どっちを選ぶのか

WAF + WordPress を固めて使い続けるのが妥当なケースははっきりある。WooCommerce や会員機能が売上の中核にある、ACF で作り込んだカスタム投稿が大量にある。この条件なら、Managed Rules を `wordpress` タグで絞り、`/wp-admin/` に Zero Trust Access を被せ、Rate Limiting でログインを守るほうが現実的だ。

EmDash を試す価値があるのは逆側だ。コンテンツが主で、プラグイン依存が数個に収まり、Astro や Workers を触るのが苦にならない。ただし条件が付く。Cloudflare の有料アカウント（Workers Paid $5/月〜）を前提にできること、beta preview を承知で使うこと、プラグインをマーケットプレイスにあるもので済ませられること。この3つが揃わないなら、今すぐ移る理由は薄いと思う。

どちらも守り方として妥当だと思う。違うのは残る攻撃面だ。WordPress に残るのは、プラグインがサイトの全部に触れるという構造そのもの。EmDash に残るのは、ネイティブプラグインと粗い capability、そして beta であること。WAF はどちらを選んでも入れる。差が出るのは、その内側でコードがどこまで触れるかだ。

自分のプラグイン一覧を開いてみる

いま WordPress を運用しているなら、プラグイン一覧を開いて数えてみるといい。そのうち、開発元が去年から変わっていないと確認できるものは、いくつあるだろうか。EssentialPlugin の件は、開発元が変わったこと自体が引き金だった。

自分も近いうちに検証環境を立てて、WXR を投げるところまでは試すつもりだ。EmDash をすでに触っている人がいたら、Workers Paid を払っているのか、プラグインを切って無料枠で回しているのか、コメントで教えてほしい。

参考

EmDash 側（すべて2026年7月時点）

Cloudflare 側

統計・事例

関連記事
https://note.com/zephel01/n/n0e9dcf4a88ed 

https://note.com/zephel01/n/nb795eb8420a2 


#WordPress #Cloudflare #WAF #EmDash #Webセキュリティ #サプライチェーン攻撃 #Astro #CloudflareWorkers #CMS #サイト移行

いいなと思ったら応援しよう！

zephel01 サーバー代とコーヒー代になります☕ 役に立ったら応援よろしくお願いします！