Ghost CMS の脆弱性 CVE-2026-26980 と 700 サイト改ざん事例の対処

はじめに

2026 年 5 月、Ghost CMS の重大な脆弱性「CVE-2026-26980」が悪用され、世界中で 700 以上のサイトが大規模に改ざんされる キャンペーンが発生したと報告されました。改ざんされたサイトには記事末尾に悪意のある JavaScript ローダーが埋め込まれ、訪問者を ClickFix 攻撃へ誘導する偽 CAPTCHA ページが表示されています。

被害を受けたサイトには、大学・ブロックチェーン・AI 関連企業・SaaS 事業者・セキュリティ研究機関・メディア・FinTech などが含まれており、正規の信頼されているサイトが ClickFix 攻撃の配布基盤として悪用される という構図が成立しています。Ghost CMS の脆弱性自体は 2026 年 2 月に修正版（v6.19.1）が公開済みですが、影響範囲は v3.24.0〜v6.19.0 と非常に広く、未更新のインスタンスが依然として攻撃対象となっています。

本記事では、CVE-2026-26980 の技術的な内容、改ざんキャンペーンの全体像、影響範囲の確認方法、WAF による暫定緩和策、修正版への移行手順、改ざん被害が疑われた場合の対応を整理します。

CVE-2026-26980 の概要

CVE-2026-26980 は、Ghost CMS の Content API における SQL インジェクション脆弱性 です。CVSS スコアは 9.4（Critical）で、認証不要・ユーザー操作不要で攻撃が成立する深刻な脆弱性として位置づけられています。

脆弱性の基本情報

参考: SQL injection in Content API（Ghost CMS 公式アドバイザリー）
“A SQL injection vulnerability existed in Ghost’s Content API that allowed unauthenticated attackers to read arbitrary data from the database.”
（Ghost の Content API に SQL インジェクションの脆弱性が存在し、認証されていない攻撃者がデータベースから任意のデータを読み取ることが可能でした。）
https://github.com/TryGhost/Ghost/security/advisories/GHSA-w52v-v783-gw97

Content API における SQL インジェクションの原理

Ghost CMS には、公開コンテンツを取得するための Content API と、サイト管理用の Admin API の 2 つの API が用意されています。Content API は仕様上「公開コンテンツの読み取り専用」として設計されており、Content API キーは公開されることを前提とした設計となっています。

しかし CVE-2026-26980 では、Content API のクエリ処理に存在する SQL インジェクションを通じて、本来取得できないはずのデータベース内データ（管理者ユーザーや Admin API キーなどを含む） にアクセス可能でした。Ghost 公式のアドバイザリーが「Content API キーは公開設計であるため、キーアクセスを制限してもこの脆弱性は緩和されない」と明示している点が、本脆弱性の重要なポイントです。

攻撃者が Admin API キーを入手すると、本来は管理者しか実行できない以下の操作が可能となります。

• 既存記事の改ざん（任意の HTML/JavaScript の埋め込み）
• 新規記事の投稿
• スタッフユーザーの一覧取得・操作
• サイト設定の変更

つまり、本脆弱性は単なる情報漏えいではなく、SQL インジェクションを起点としたサイト全体の乗っ取りに発展する 構造を持っています。

影響を受けるバージョンと修正版

公式アドバイザリーによると、本脆弱性は Ghost v3.24.0〜v6.19.0 の長期間にわたるバージョン に存在しています。v3.24.0 のリリースは数年前まで遡るため、長期間にわたって未更新のセルフホスト型インスタンスは、ほぼ確実に影響を受ける可能性があります。

• 影響を受けるバージョン: <= 6.19.0（v3.24.0 以降のすべて）
• 修正版: v6.19.1（2026 年 2 月リリース）

Ghost(Pro) などのマネージドホスティングを利用している場合、運営側で順次パッチが適用されている可能性がありますが、自己ホスト型インスタンスは利用者自身の責任でアップデートが必要 です。

参考: Ghost CMS 公式アドバイザリー（影響範囲と推奨事項）
“as this vulnerability lets an attacker gain access to a site’s API keys, we recommend reviewing staff users and rotating keys. We generally recommend always updating Ghost to its most current version.”
（この脆弱性は攻撃者にサイトの API キーへのアクセスを許すため、スタッフユーザーの確認と API キーのローテーションを推奨します。Ghost は常に最新バージョンへ更新することを推奨します。）
https://github.com/TryGhost/Ghost/security/advisories/GHSA-w52v-v783-gw97

Anthropic Claude による発見という新しい潮流

本脆弱性のもう一つの注目点は、発見の経緯 です。公式アドバイザリーには、Anthropic 社のセキュリティ研究者 Nicholas Carlini 氏が、同社の AI モデル Claude を活用して脆弱性を発見・報告したと明記されています。

近年、AI を活用したコードレビューや脆弱性発見の取り組みが、各社で本格化しています。本件は、広く利用される OSS の重大な脆弱性が AI 支援による発見・修正につながった事例 として、セキュリティ業界全体にとって示唆的な出来事と言えます。今後、同様の手法で多数の OSS において既存の脆弱性が発見されていく可能性も考えられます。

700 サイト改ざんキャンペーンの全体像

CVE-2026-26980 を悪用した実攻撃は、2026 年 5 月 7 日に中国のセキュリティベンダー QiAnXin XLab によって初めて観測されました。被害は単発の事案ではなく、少なくとも 2 つの異なる攻撃クラスター による「大規模ポイズニング」キャンペーンとして整理されており、わずか 1 日のうちに複数の Ghost CMS サイトへ悪意のあるコードが埋め込まれる事例も確認されています。

攻撃の検知時期と被害規模

報告時点で、700 を超える正規サイトが改ざんされた ことが確認されています。改ざん対象は特定の業界に偏らず、幅広いセクターのサイトが含まれている点が特徴です。

特筆すべき点は、正規サイトが改ざんされて配布基盤となる構造 です。利用者は普段から信頼しているサイトを訪問しているため、Web ブラウザ上で表示される偽 CAPTCHA や偽エラー画面に対する警戒心が低下し、ClickFix 攻撃の成功率が押し上げられます。ClickFix 攻撃そのものの仕組みや、利用者・端末側で取り得る対策については関連記事『ClickFix 攻撃の仕組みと多層防御｜FileFix・ConsentFix への備え』を参照してください。

攻撃チェーン: API キー窃取から ClickFix 誘導まで

XLab の報告に基づき、攻撃チェーンを段階ごとに整理すると以下の通りです。

参考: Ghost CMS CVE-2026-26980 Exploited to Hijack 700+ Sites for ClickFix Attacks（The Hacker News）
“obtain the target site’s Admin API Key without authorization, and then used the Ghost Admin API to tamper with articles in bulk, injecting malicious JavaScript loaders at the bottom of the pages to assist fake CAPTCHA attacks”
（対象サイトの Admin API キーを認証なしで取得し、Ghost Admin API を悪用して記事を一括改ざんし、偽 CAPTCHA 攻撃を支援する悪意のある JavaScript ローダーをページ末尾に注入した。）
https://thehackernews.com/2026/05/ghost-cms-cve-2026-26980-exploited-to.html

配布インフラの構造（Adspect クローキング）

攻撃チェーンの中でも特に注意すべきは、配布インフラに Adspect という商用クローキングサービスが使われている 点です。Adspect は本来、広告配信業界向けに提供されているトラフィック分配サービスですが、攻撃者がこれを悪用することで以下のような振る舞いを実現しています。

• 訪問者のブラウザフィンガープリント（OS、言語、IP 地理情報、ブラウザバージョン等）を収集
• セキュリティスキャナ・自動クローラー・サンドボックスと判定された訪問者には 無害な Web ページ を返却
• 実在の被害者と判定された訪問者にのみ 偽 CAPTCHA ページ を表示
• 19 種類の制御コマンドにより、攻撃者が訪問者のブラウザを遠隔操作することも可能

このようなクローキング構造により、自動セキュリティスキャナによる調査時には改ざんが検知されにくく、対象組織のセキュリティチームが侵害に気づくまでの時間を引き延ばす効果があります。さらに、最終ペイロードもローダーを切り替えずに差し替え可能な構造となっており、攻撃者は配布物を容易にローテーションできます。

最終的に投下される実行ファイルには、有効なコード署名証明書を持つ PuTTY クライアントを偽装したバイナリ や、Grape オープンソース・デスクトップクライアントの改変版が確認されており、30 秒間隔で web-telegram[.]ug をポーリング して攻撃者の指示を受け取る常駐型マルウェアとして動作します。

影響範囲と暫定的な緩和策

修正版 v6.19.1 への移行が最優先の対応となりますが、すぐにアップグレードできない環境では暫定緩和策の検討が必要です。本章では、自身の Ghost インスタンスが影響を受けるかの確認方法と、WAF / リバースプロキシによる暫定緩和の選択肢を整理します。

影響を受ける Ghost CMS のバージョン範囲

公式アドバイザリーで明示されている影響範囲は以下の通りです。

v3.24.0 のリリースは数年前まで遡るため、長期間アップデートを停止しているセルフホスト型インスタンスは、ほぼすべて本脆弱性の影響を受ける と考えられます。Ghost(Pro) などのマネージドホスティングを利用している場合は運営側でパッチが順次適用されていますが、自己ホスト型では利用者自身による対応が必要です。

Ghost インスタンスのバージョン確認方法

自身の Ghost インスタンスのバージョンを確認する最も簡単な方法は、サーバー上で Ghost-CLI の ghost version コマンド を実行することです。

# Ghost のインストールディレクトリへ移動
cd /var/www/ghost

# バージョン確認
ghost version

実行結果の例

Ghost-CLI version: 1.26.0
Ghost version: 6.18.0 (at /var/www/ghost)

加えて、新しいバージョンが利用可能かを確認するためには、公式の ghost check-update コマンドも有用です。

ghost check-update

参考: How To Update Ghost（Ghost 公式ドキュメント）
“you can find out whether new updates are available any time by running ghost check-update.”
（ghost check-update を実行することで、いつでも新しいアップデートが利用可能かを確認できます。）
https://ghost.org/docs/update/

Ghost(Pro) を利用している場合、または admin ダッシュボードからアクセス可能な場合は、https://<your-domain>/ghost/#/whatsnew からも現行バージョンを確認できます。

WAF / リバースプロキシによる暫定的な緩和

修正版へのアップグレードがすぐに実施できない場合、公式アドバイザリーで唯一推奨されている暫定緩和策は WAF またはリバースプロキシで特定パターンを含むリクエストをブロックする 方法です。

公式アドバイザリーには、以下のクエリ文字列フィルタパターンを含む Content API リクエストをブロックするよう明記されています。

Nginx での設定例

# 注意: 本パターンは正規の slug フィルタ機能を阻害する可能性があります。
# 適用前に必ず動作検証を実施することを推奨します。
location /ghost/api/content/ {
    if ($args ~* "slug(:|%3A)\[") {
        return 403;
    }
    proxy_pass http://localhost:2368;
}

重要な注意点: 公式アドバイザリーは、この暫定緩和策について 「正規の slug フィルタ機能を阻害する可能性がある」 と明記しています。Ghost CMS の正規機能として slug:[id1,id2,...] 形式での記事フィルタリングを利用している場合、この WAF ルールにより業務影響が発生する可能性があります。

参考: SQL injection in Content API – Workarounds（Ghost CMS 公式アドバイザリー）
“As a temporary mitigation, a reverse proxy or WAF rule can be used to block Content API requests containing slug%3A%5B or slug:[ in the query string filter parameter. Note that this may break legitimate slug filter functionality.”
（暫定緩和策として、リバースプロキシまたは WAF ルールにより、クエリ文字列フィルタパラメータに slug%3A%5B または slug:[ を含む Content API リクエストをブロックできます。ただし、これは正規の slug フィルタ機能を阻害する可能性があることに留意してください。）
https://github.com/TryGhost/Ghost/security/advisories/GHSA-w52v-v783-gw97

アプリケーションレベルの回避策が存在しない理由

公式アドバイザリーは、「アプリケーションレベルでの回避策は存在しない」 と明言しています。これは、CVE-2026-26980 の構造的な特性に起因します。

• Content API キーは設計上「公開を前提とした公開鍵的な扱い」となっており、アクセス元 IP 制限やキーの秘匿による緩和ができない
• API キーの定期ローテーションは漏えい後の影響軽減には有効だが、脆弱性そのものの悪用は防げない
• Content API のエンドポイントは、サイトの公開コンテンツを取得するために通常運用で常に開放されている

このため、修正版 v6.19.1 への移行が事実上の唯一の根本対応 であり、WAF による暫定緩和はあくまで「移行までの時間稼ぎ」と位置づけて運用することが重要です。

修正版 v6.19.1 への移行手順

CVE-2026-26980 への根本的な対応は、修正版 Ghost v6.19.1 以降への移行 です。Ghost-CLI を使ったセルフホスト型インスタンスのアップグレード手順を、事前準備から確認までの順に整理します。

なお、現在 v3.x や v4.x など古いメジャーバージョンを使用している場合は、メジャーバージョンを段階的に上げていく必要があります（例: v3.x → 最新 v4.x → 最新 v5.x → v6.19.1 以降）。本章では 直前のメジャーバージョン（v5.x または v6.x の古いマイナー版）から v6.19.1 以降への移行 を主に扱います。

システム要件の確認

Ghost v6 系の主なシステム要件は以下の通りです。

参考: Supported Node Versions（Ghost 公式ドキュメント）
“Ghost’s current required Node version is Node v22 LTS.”
（Ghost の現行で必須となる Node バージョンは Node v22 LTS です。）
https://docs.ghost.org/faq/node-versions

特に注意すべき点として、Ghost v5 から v6 への移行では Node.js のバージョンアップが必要 となります。v5 系は Node 18 系を前提としていましたが、v6 系は Node 22 LTS が要件です。Node.js のバージョン管理は nvm（Node Version Manager）の利用が推奨されます。

事前準備: バックアップ取得

アップグレード前に、必ず 完全バックアップ を取得します。Ghost-CLI には専用の ghost backup コマンドが用意されています。

# Ghost インストールディレクトリへ移動
cd /var/www/ghost

# バックアップを取得（zip 形式でサイト全体の状態を保存）
ghost backup

ghost backup はサイトデータの ZIP アーカイブを生成します。加えて、念のため以下のファイル・ディレクトリも個別にコピーしておくことを推奨します。

# 個別バックアップディレクトリの作成
mkdir -p ~/ghost-backup-$(date +%Y%m%d)

# 設定ファイル
cp /var/www/ghost/config.production.json ~/ghost-backup-$(date +%Y%m%d)/

# コンテンツファイル（画像・テーマ・データ）
cp -r /var/www/ghost/content ~/ghost-backup-$(date +%Y%m%d)/

# データベースのダンプ（DB 名・ユーザー名は環境に合わせて変更）
mysqldump -u ghost_user -p ghost_production > ~/ghost-backup-$(date +%Y%m%d)/db-backup.sql

参考: Ghost-CLI Documentation（Ghost 公式ドキュメント）
“Run ghost backup to generate a zip file backup of your site data. When performing manual updates it’s recommended to make frequent backups, so if anything goes wrong, you’ll still have all your data.”
（ghost backup を実行することでサイトデータの zip ファイルバックアップが生成されます。手動アップデートを実施する際は、何か問題が発生した場合に備えて、頻繁にバックアップを取得することを推奨します。）
https://docs.ghost.org/ghost-cli

加えて、SSH セッションが切断されてもアップグレード処理が中断されないよう、tmux または screen 内での実行 を推奨します。

# tmux のインストール（未インストールの場合）
sudo apt install tmux

# tmux セッションの開始
tmux

環境チェック: ghost doctor の実行

Ghost-CLI には、アップグレード前に環境の問題を事前検出する ghost doctor コマンドが用意されています。

cd /var/www/ghost
ghost doctor

このコマンドは以下のような項目を自動チェックします。

• システムの Node.js バージョン
• 現在のフォルダ・ファイル権限
• メモリ・空き容量
• MySQL の状態
• Ghost ユーザーでのログイン確認

検出されたエラーや警告は、アップグレード処理を進める前にすべて解消することを推奨します。

Ghost-CLI のアップデート

Ghost 本体のアップグレード前に、Ghost-CLI 自体を最新版へアップデートします。

# Ghost-CLI を最新版へ更新
sudo npm install -g ghost-cli@latest

# バージョン確認
ghost --version

Node.js のバージョンアップ（v5 → v6 移行時に必要）

Ghost v5 系から v6 系へ移行する場合、Node.js を v22 LTS へバージョンアップする必要があります。nvm を利用する場合の手順は以下の通りです。

# nvm がインストール済みの前提
# Node v22 LTS のインストール
nvm install 22 --lts

# 既定の Node バージョンとして設定
nvm alias default 22
nvm use 22

# バージョン確認
node -v

参考: Tips or procedure for upgrading Node version（Ghost Forum）
“Ghost v6.0.1 is not compatible with the current Node version. Your node version is 18.20.8, but Ghost v6.0.1 requires ^22.13.1”
（Ghost v6.0.1 は現在の Node バージョンと互換性がありません。お使いの Node バージョンは 18.20.8 ですが、Ghost v6.0.1 は ^22.13.1 を要求します。）
https://forum.ghost.org/t/tips-or-procedure-for-upgrading-node-version/59475

ghost update コマンドの実行

事前準備が完了したら、ghost update でアップグレードを実施します。

cd /var/www/ghost

# 念のため Ghost プロセスを停止
ghost stop

# アップデート実行（最新版へ）
ghost update

# 特定のバージョンを指定する場合
ghost update 6.19.1

メジャーバージョンをまたぐアップグレード（v5.x → v6.x 等）を実施する場合は、現行メジャーバージョンの最新マイナー版まで上げてから次のメジャーへ移行する 二段階アップグレードが推奨されます。

# v5.x の最新版へまずアップグレード
ghost update v5

# その後 v6.19.1 以降へアップグレード
ghost update

アップグレード後の動作確認

アップグレードが完了したら、以下の項目を確認します。

# バージョン確認
ghost version

# Ghost プロセスの稼働状態を確認
ghost status

# 環境チェックを再実行
ghost doctor

ブラウザから admin ダッシュボード（https://<your-domain>/ghost/）にログインし、以下が正常に動作するかを確認することも推奨します。

• 既存記事の表示・編集
• メディアファイル（画像・動画）の表示
• テーマの正常表示（v6 系で互換性警告が出る可能性あり）
• メンバー機能・サブスクリプション機能（利用している場合）

改ざん被害が疑われる場合の対応

すでに改ざんを受けている可能性がある場合、修正版へのアップグレードだけでは不十分です。API キーのローテーション、不正コードの除去、アクセスログの監査、訪問者への通知 までを含めた、包括的な対応が必要となります。

参考: Ghost CMS CVE-2026-26980 Exploited to Hijack 700+ Sites for ClickFix Attacks（The Hacker News）
“Ghost CMS users are advised to upgrade their instances to the latest version, rotate all credentials, clean up the sites, audit access logs for signs of suspicious activity, and notify users who may have visited the sites during the contamination period for potential compromise.”
（Ghost CMS の利用者は、インスタンスを最新バージョンへアップグレードし、すべての認証情報をローテーションし、サイトをクリーンアップし、アクセスログで不審なアクティビティの兆候を監査し、汚染期間中にサイトを訪問した可能性のあるユーザーに侵害の可能性を通知することを推奨されます。）
https://thehackernews.com/2026/05/ghost-cms-cve-2026-26980-exploited-to.html

API キーのローテーション

CVE-2026-26980 の悪用により、攻撃者が Admin API キーと Content API キーの両方を窃取済み である可能性があります。修正版へアップグレードした後、すべての API キーを必ずローテーションすることが重要です。

Ghost の admin ダッシュボードでの操作手順は以下の通りです。

1. admin ダッシュボード（https://<your-domain>/ghost/）にログイン
2. 左メニューから「Settings」→「Integrations」を選択
3. 各カスタムインテグレーションの「Regenerate」ボタンで Admin API キー / Content API キーを再生成
4. ビルトインインテグレーション（Zapier、Slack 等）も同様に再生成
5. API キーを利用している外部システム側の設定も新しいキーへ更新

加えて、スタッフユーザーの状況確認 も推奨されます。攻撃者が Admin API 経由で不正な管理者ユーザーを追加している可能性があるため、「Settings」→「Staff」から登録ユーザー一覧を確認し、心当たりのないユーザーがあれば削除します。

記事末尾の不正 JavaScript 検出

XLab のレポートによると、改ざんされた記事には 末尾に悪意のある JavaScript ローダー が挿入される手口が確認されています。侵害指標（IoC）として、外部ドメイン clo4shara[.]xyz/11z77u3.php への通信や、web-telegram[.]ug への定期的なポーリングが挙げられています。

データベースから直接、不正な JavaScript の有無を検索する一例として、以下のような SQL クエリが考えられます（環境やテーブル構造によって調整が必要です）。

-- 不審な外部ドメインを記事本文から検索
SELECT id, title, updated_at
FROM posts
WHERE html LIKE '%clo4shara%'
   OR html LIKE '%web-telegram.ug%'
   OR html LIKE '%<script%src="http%';

-- 最近大量に更新された記事を確認（一括改ざんの兆候）
SELECT id, title, updated_at, updated_by
FROM posts
ORDER BY updated_at DESC
LIMIT 100;

ただし、攻撃者は配布インフラを切り替える可能性がある ため、上記の特定ドメインに合致しない場合でも改ざんが完全に否定できるわけではありません。記事末尾の <script> タグや外部ドメイン読み込みの有無を、テーマ・コンテンツ全体に対して網羅的に確認することを推奨します。

アクセスログの監査ポイント

Web サーバー（Nginx 等）のアクセスログから、本脆弱性の悪用痕跡を確認するために以下の観点を参照します。

Nginx のアクセスログから slug:[ パターンを抽出する例は以下の通りです。

# Nginx アクセスログから不審なリクエストを抽出
grep -E "slug(%3A|:)%5B|slug(%3A|:)\[" /var/log/nginx/access.log

# 直近 7 日間に絞って検索
find /var/log/nginx/ -name "access.log*" -mtime -7 \
  -exec grep -lE "slug(%3A|:)%5B|slug(%3A|:)\[" {} \;

訪問者への通知の検討

公式アドバイザリーが推奨する通り、汚染期間中にサイトを訪問した可能性のあるユーザーへの通知 も検討事項となります。改ざん期間中にサイトを訪問した利用者は、以下のような被害を受けている可能性があります。

• 偽 CAPTCHA に従って PowerShell コマンドを実行してしまった場合は、インフォスティーラー（Lumma Stealer 等）感染の可能性
• ブラウザ保存の認証情報、Cookie、暗号資産ウォレットの情報が窃取された可能性
• 遠隔操作型マルウェアによる持続的アクセスの確立

通知の文面では、訪問者側で取り得る対応（端末のフルスキャン、保存パスワードの変更、認証情報のローテーション等）にも触れることを推奨します。訪問者側で取り得る具体的な多層防御の設計（Windows GPO、EDR・SIEM での検知観点、FortiGate UTM の機能配置）については、関連記事「ClickFix 攻撃の仕組みと多層防御｜FileFix・ConsentFix への備え」で詳しく整理していますので、通知文書の参考としてご活用いただけます。

同種の改ざん攻撃を防ぐための運用設計

CVE-2026-26980 は Ghost CMS に固有の脆弱性ですが、「正規サイトを改ざんして ClickFix 等の攻撃配布基盤として悪用する」攻撃モデル自体は CMS 全般に共通 しています。WordPress、Drupal、Joomla をはじめとする主要 CMS でも同種の攻撃事例は継続的に発生しており、サイト運営者は CMS 種別を問わず構造的な備えが求められます。本章では、CMS 運用全般に共通する防御の考え方を整理します。

CMS 全般に共通する脆弱性管理のポイント

CMS のセキュリティ運用で軽視されがちなのは、「インストール直後は最新だが、その後の運用フェーズで更新が滞る」 というパターンです。CVE-2026-26980 の影響範囲が v3.24.0〜v6.19.0 と数年にわたる長期間に及んでいる事実は、未更新のセルフホスト型インスタンスが大量に放置されている実態 を示唆しています。

最低限押さえておきたい運用ポイントは以下の通りです。

特に 「使われていない API キーが残り続けている」状態は侵害時の影響範囲を広げる要因 となります。Ghost CMS の場合、admin ダッシュボードの「Integrations」画面で利用状況を定期的に棚卸しすることを推奨します。

WAF・SSL インスペクション・EDR の組み合わせ

サイト運営者と訪問者の双方を守るには、配布側（サイト改ざんの抑止）と感染側（訪問者端末の防御）の両方 に防御層を配置する必要があります。FortiGate のような UTM 機器を境界に配置することで、両方向の防御を集約的に実装できます。

FortiGate を活用した境界防御の全体像については、関連記事「FortiGate UTM 機能の仕組みと IPS 誤検知のリスクと対処」もあわせて参照してください。

また、本件のように 「正規サイトを経由した攻撃」では、URL レピュテーションだけでは検知が困難 です。アクセス先のドメインそのものは信頼できるサイトであり、レピュテーション系の防御は機能しません。このため、サイト内に埋め込まれた JavaScript の振る舞いを検査できる SSL/TLS インスペクション や、訪問者端末側の EDR による振る舞い検知 が、防御の重要な役割を担うことになります。

訪問者側で取り得る防御策

サイト運営者側の対策と並行して、訪問者側（利用者・社内エンドユーザー）が取り得る防御策 を組織内で周知することも重要です。CMS の脆弱性は運営者側でしかパッチ適用できないため、エンドユーザーは「信頼しているサイトでも改ざんされる可能性がある」前提で行動する必要があります。

• 普段利用しているサイトであっても、突然の CAPTCHA 表示やエラー画面に対して安易に従わない
• 「Windows キー + R」や PowerShell へコマンドを貼り付けて実行するよう求める正規サービスは存在しない、という社内ルールの周知
• 訪問者端末への EDR 導入、GPO による Win+R 無効化、AppLocker / WDAC の組み合わせ
• フィッシングシミュレーション訓練に ClickFix 型シナリオを組み込む

訪問者側で取り得る具体的な多層防御の設計（Windows GPO、EDR・SIEM での検知観点、FortiGate UTM の機能配置）については、関連記事「ClickFix 攻撃の仕組みと多層防御｜FileFix・ConsentFix への備え」で詳しく整理していますので、社内教育の参考としてご活用いただけます。

まとめ

本記事では、Ghost CMS の SQL インジェクション脆弱性 CVE-2026-26980 と、700 以上のサイトが改ざんされた大規模ポイズニングキャンペーンへの対処について整理しました。要点は以下の通りです。

• CVE-2026-26980 は Ghost CMS の Content API における SQL インジェクション（CVSS 9.4、認証不要）
• 影響を受けるのは v3.24.0〜v6.19.0 の長期間にわたるバージョンで、修正版は v6.19.1（2026 年 2 月公開）
• 2026 年 5 月時点で 700 以上の正規サイトが改ざんされ、ClickFix 攻撃の配布基盤として悪用されている
• アプリケーションレベルの回避策は存在せず、WAF による slug:[ パターンブロックが唯一の暫定緩和策となる
• 修正版への移行には ghost backup ghost doctor ghost update を順に実行し、Node.js v22 LTS と MySQL 8 が前提となる
• 改ざんが疑われる場合は、API キーローテーション・スタッフユーザー確認・記事末尾の不正 JavaScript 検出・アクセスログ監査・訪問者通知までを包括的に実施する
• 同種の改ざん攻撃は CMS 全般に共通するため、WAF・SSL インスペクション・EDR を組み合わせた多層防御の運用設計が重要となる

以上、最後までお読みいただきありがとうございました。