Concrete CMS 9.5.1がCVSS 9.4のパストラバーサルRCEを含む5件の脆弱性を修正(CVE-2026-8134)など|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年06月03日更新日時: 2026年06月03日

PHPで構築されたオープンソースのCMS「Concrete CMS（コンクリートCMS）」の開発チームは、最新バージョン9.5.1において、CVSS v4.0スコア9.4（Critical）のパストラバーサルによるリモートコード実行（CVE-2026-8134）を筆頭とする計5件のセキュリティ脆弱性を修正したリリースを公開しました（Concrete CMS 公式9.5.1リリースノート）。

今回の修正でとりわけ注目すべきなのは、「パストラバーサルによるファイル読み込み」と「拡張子のみを確認するファイルアップローダー（.png等の画像拡張子で保存されたPHPコードを通過させる）」という2つの弱点を組み合わせることで、認証済みの不正管理者がリモートコード実行を達成できるという複合的な攻撃経路です。

なお今回の修正はバージョン9系のみに適用されており、v8系へのセキュリティ修正のバックポートはこれ以上行われません。Concrete CMSの開発チームはv8系ユーザーに対して速やかなv9系への移行を強く推奨しています。

1 この記事のサマリー
2 Concrete CMSとは—国産CMS市場にも根づくオープンソースCMS
3 CVE-2026-8134—CVSS 9.4のパストラバーサルRCE（最重要）
- 3.1 脆弱性の場所と技術的な仕組み
- 3.2 「画像拡張子のPHPコード」との組み合わせで完全なRCEへ
4 CVE-2026-8135——デシリアライズRCE（CVSS 7.5）
5 CVE-2026-8426——CSRFから始まるRCE（CVSS 7.5）
6 CVE-2026-8428——コアアップデートのCSRF（CVSS 7.5）
7 CVE-2026-7882——「逆転したCSRFトークン検証」によるファイル削除（CVSS 2.3）
8 Concrete CMSを使用する組織のサイト運営者が確認すべき事項
9 日本の組織が特に注意すべき点
10 FAQ
11 参考情報（1次ソース）

この記事のサマリー

CVE	種別	CVSS v4.0	報告者	概要
CVE-2026-8134	パストラバーサル + RCE	9.4（Critical）	Yonatan Drori（Tenzai）氏	`ptComposerFormLayoutSetControlCustomTemplate`フィールドでパストラバーサル→任意ファイル読み込み→画像拡張子のPHPコードと組み合わせてRCE
CVE-2026-8135	デシリアライズRCE	7.5（High）	maru1009氏	ExpressEntryListブロックコントローラーの安全でないデシリアライズ
CVE-2026-8426	CSRF経由のRCE	7.5（High）	—	パッケージアップデートエンドポイントのCSRFトークン未検証→リモートパッケージを制御してRCE
CVE-2026-8428	コアアップデートのCSRF	7.5（High）	—	コアアップデートコントローラーがCSRFトークンを生成するが検証しない
CVE-2026-7882	倒置CSRFによる不正ファイル削除	2.3（Low）	—	DeleteFileコントローラーのCSRFトークン検証ロジックが逆転

修正済みバージョン：9.5.1
v8系への対応：なし（修正バックポートなし）
v8系からの移行推奨：Concrete CMS開発チームが明示的に推奨

Concrete CMSとは—国産CMS市場にも根づくオープンソースCMS

脆弱性の影響範囲を理解するために、まずConcrete CMSについて簡単に整理します。

Concrete CMS（旧名：concrete5）は、PHPとMySQLで構築されたオープンソースのコンテンツ管理システム（CMS）です。2003年にPortland Labs社によって開発が始まり、2023年に「concrete5」から「Concrete CMS」へ改称されました。WordPressほどの市場シェアは持ちませんが、企業・行政機関・大学のウェブサイト構築に多く採用されており、日本国内でも公官庁・大学・製造業等の公式サイトで採用実績があります。

特筆すべき特徴として「インライン編集（ページ上で直接コンテンツを編集できる）」とページ構成の柔軟性があります。この柔軟性を実現するための「ブロック」機構・「コンポーザーフォーム」機能が、今回の脆弱性の舞台となっています。

Concrete CMSのセキュリティ報告はHackerOneのバグバウンティプログラムを通じて受け付けられており、発見者への謝辞が公式リリースノートに明記されます。今回のCVE-2026-8134も、Yonatan Drori（Tenzai）氏がHackerOneのレポートH1-3705064として報告したものです。

CVE-2026-8134—CVSS 9.4のパストラバーサルRCE（最重要）

脆弱性の場所と技術的な仕組み

公式リリースノートによれば、本脆弱性はページタイプのコンポーザーフォームレイアウトを保存する際に処理されるptComposerFormLayoutSetControlCustomTemplateフィールドにあります。このフィールドはページタイプのコンポーザーフォームのカスタムテンプレートを指定するためのものです。

修正前のConcrete CMSは、このフィールドに対してパストラバーサルシーケンス（../等）のサニタイズを行っておらず、コンポーザーフォームの編集権限を持つ認証済みの不正管理者がサーバー上の任意の読み取り可能なファイルを読み込める状態でした。

「画像拡張子のPHPコード」との組み合わせで完全なRCEへ

本脆弱性が単なるファイル読み込みを超えてRCEに到達できる理由は、Concrete CMSのファイルアップローダーが拡張子のみの検証しか行っていなかったためです。具体的には、.png・.jpg等の画像拡張子を持つファイルであれば、その中身がPHPコードであってもアップロードが許可されていました。

攻撃の流れとして、攻撃者はまずPHPコードを含む.pngファイルをConcrete CMSにアップロードします。その後、CVE-2026-8134のパストラバーサルを利用してこのPHPファイルをコンポーザーフォームのカスタムテンプレートとして読み込ませることで、ウェブサーバーの権限で任意のコードを実行できます。

この攻撃にはコンポーザーフォームの編集権限を持つ管理者権限（PR:H）が必要ですが、CVSS v4.0スコア9.4という高さは「攻撃複雑度が低く・ユーザー操作が不要で・機密性・完全性・可用性すべてへの影響が高く・後続システムへの影響も高い」という評価を反映しています。

CVE-2026-8135——デシリアライズRCE（CVSS 7.5）

公式リリースノートとTHREATINTの分析によれば、ExpressEntryListブロックコントローラーに安全でないデシリアライズの問題が存在しました。これはPHPのunserialize()関数が攻撃者制御のデータをクラス制限なしに処理することで、PHPオブジェクトインジェクションを通じたRCEが可能となる古典的な攻撃パターンです。CVSSv4.0ベクターはAV:N/AC:H/AT:P/PR:N/UI:Aとされており、攻撃の複雑度は高いものの認証が不要な（PR:N）点が特徴的です。

CVE-2026-8426——CSRFから始まるRCE（CVSS 7.5）

BitNinjaの分析によれば、Concrete CMSのマーケットプレイスパッケージをアップデートする際に呼び出されるエンドポイント（/dashboard/extend/update/prepare_remote_upgrade/<remoteMPID>）が、リクエストを処理する前にCSRFトークンの検証を行っていませんでした。

このため、既知のマーケットプレイスアイテムIDに対して返されるリモートパッケージを制御できる攻撃者は、被害者の管理者が特定のURLにアクセスするだけの単一のブラウザナビゲーションで、以下の一連の攻撃を完結させることができました。まず悪意あるリモートパッケージ（攻撃者が管理するサーバーから返される）のPHPファイルをディスク上に書き込み、そのパッケージのupgrade()メソッドをウェブサーバーユーザー権限で実行させることが可能でした。

CVE-2026-8428——コアアップデートのCSRF（CVSS 7.5）

BitNinjaの技術分析によれば、Concrete CMSのコアアップデートコントローラーは、CSRFトークンを生成するものの検証しないという実装上の欠陥を抱えていました。本来CSRFトークンの目的は「このリクエストが正規の管理画面から発行されたものであること」を確認することですが、生成するだけで検証しない実装ではその目的を果たしません。CVSSスコアは7.5（High）と評価されており、認証済みの攻撃者が管理者のブラウザを誘導することでCMSコアを不正にアップデート（またはダウングレード）させることができます。

CVE-2026-7882——「逆転したCSRFトークン検証」によるファイル削除（CVSS 2.3）

今回の5件の中で深刻度が最も低い（CVSS 2.3）ながら、概念的にユニークな欠陥です。BitNinjaの分析が示す通り、DeleteFileコントローラーのCSRFトークン検証ロジックが完全に逆転していました。CSRFトークンが有効な場合にエラーをスローし、無効または存在しない場合にファイル削除を許可するという、本来の意図とは真逆の動作をしていました。

メッセージ編集権限を持つユーザーがこの欠陥を悪用できます。深刻度が低い理由は、削除できるファイルの種類や範囲に制限があること、また攻撃にはCSRFトークンの不存在という条件が必要なためです。

Concrete CMSを使用する組織のサイト運営者が確認すべき事項

現在のバージョン確認と更新

# Composerでのアップデート
composer require concrete5/concrete5:^9.5.1

# または管理パネル → ダッシュボード → システム → アップデートとマーケットプレイス
# からGUI経由でアップデートを実施

v8系からの移行の必要性

Concrete CMS開発チームはリリースノートで「バージョン8に対するセキュリティ修正のバックポートはこれ以上行わない」と明示しています。v8系を使い続けることは今後発見される脆弱性に対して無防備な状態に置かれることを意味します。移行の主なハードルとして、v9系ではUI・APIに変更があるため、カスタムブロック・アドオン・テーマの互換性確認が必要です。移行を計画している場合は早急に開発者または保守担当者に相談することを推奨します。

管理者権限の最小化

CVE-2026-8134・CVE-2026-8135はいずれも認証済み管理者権限が必要です。Concrete CMSのユーザー権限グループを見直し、コンポーザーフォームの編集権限・ブロック追加権限が本当に必要なユーザーのみに付与されているかを確認してください。

日本の組織が特に注意すべき点

国内での採用が見られる行政機関・大学・製造業の公式ウェブサイトで、CVE-2026-8426やCVE-2026-8428のようなCSRF経由の攻撃が組み合わさった場合、管理者が偽装されたリンクを踏むだけでサイト改ざんにつながる可能性があります。WAF（Webアプリケーションファイアウォール）でCSRF攻撃をブロックする設定を確認しつつ、早急なv9.5.1へのアップデートを実施してください。

FAQ

Q. 今回の脆弱性はConcrete CMSのクラウドホスティング版（concretecms.com）も影響を受けますか？ A. 今回の脆弱性はConcrete CMSのオープンソースコア（concretecms/concretecms）に対するものです。concretecms.comのクラウドホスティングサービスを利用している場合はサービス提供側が対応していますが、セルフホスト環境は管理者が自ら対応する必要があります。

Q. バージョン9.5.0から9.5.1へのアップデートで既存サイトのコンテンツやカスタマイズは失われますか？ A. マイナーバージョンのアップデートでコンテンツが失われることは通常ありません。ただし事前のバックアップは必ず取得してください。またカスタムブロック・テーマ・アドオンについては事前に開発者のアップデート情報を確認してください。

Q. Concrete CMSのバージョンはどこで確認できますか？ A. 管理パネル（/index.php/dashboard）にログイン後、右下または「システムと設定」→「バージョン情報」でバージョンが確認できます。またcomposer show concrete5/concrete5コマンドでも確認可能です。