WordPress向けサイト構築ツールBricksで、認証なしに情報を読み取られる恐れがある脆弱性2件(CVE-2026-118803/118804)が公表された。影響するのは2.4.4未満のバージョン。ユーザー情報や非公開投稿、クーポン情報が漏えいする可能性があり、開発元はセキュリティ修正を含む2.4.4への更新を推奨している。
30秒でわかる / THE SIGNAL
WordPress向けサイト構築ツールBricksで、認証なしに情報を読み取られる恐れがある脆弱性2件(CVE-2026-118803/118804)が公表された。影響するのは2.4.4未満のバージョン。ユーザー情報や非公開投稿、クーポン情報が漏えいする可能性があり、開発元はセキュリティ修正を含む2.4.4への更新を推奨している。
Bricksに認証不要の情報漏えい脆弱性が2件
WordPress向けのWebサイト構築ツール「Bricks」で、外部からログインせずに本来公開されるべきではない情報へアクセスできる恐れがある2件の脆弱性が、2026年10月28日に公表された。識別番号はCVE-2026-118803とCVE-2026-118804。VulnCheckが公開したCNA(CVE採番機関)の勧告では、どちらもCVSS v3.1で7.5、深刻度はHIGHとされる。
対象はBricks Theme/Bricks Builderの2.4.4未満(2.4.3以前)。2件はBricksの`query_result`機能を経由するが、漏えいに至る仕組みと対象情報は異なる。運営するWordPressサイトでBricksを利用している場合は、まず導入バージョンの確認が必要だ。
CVE-2026-118803:動的データ処理からユーザー情報が漏れる恐れ
CVE-2026-118803は、Bricks Themeの動的データ(Dynamic Data)の扱いに関する問題だ。CNA勧告によると、`query_result`のRESTエンドポイントで受け取った値が動的データタグとして再解釈されることにより、認証されていない外部から投稿者のユーザーレコードやメタデータに由来する情報を取得できる恐れがある。
影響例としてメールアドレスやパスワードのハッシュ値が挙げられている。ハッシュ値の漏えいは直ちに平文パスワードの判明を意味しないが、認証情報の保護上、看過できないリスクだ。具体的な漏えい範囲はサイトの設定や保持する情報に左右されるため、すべてのサイトで同一の情報が露出すると断定することはできない。
CVE-2026-118804:非公開投稿やクーポン情報へのアクセス制御不備
もう一つのCVE-2026-118804は、Bricks Builderの`query_result`エンドポイントにおけるアクセス制御の不備。CNA勧告によれば、外部から渡されるクエリ条件の扱いによって、通常のWordPress REST APIでは制限される下書き・非公開投稿などの内容や、WooCommerceのクーポンに関する情報を、認証なしで参照できる可能性がある。
1件目が動的データタグの処理に起因するのに対し、こちらは本来非公開の投稿種別・公開状態を守る権限確認が焦点だ。扱っている未公開情報や商取引関連データが多いサイトほど、想定外の情報露出が事業上の問題につながり得る。
Bricks 2.4.4で関連するセキュリティ修正、全サイトの更新を推奨
Bricks開発元が2026年10月28日に公表したバージョン2.4.4には、セキュリティ関連の修正が複数含まれる。公式変更履歴にはSVGのサニタイズ、AJAXポップアップ、クエリ結果、動的データを対象とした修正が記載され、開発元はすべてのサイトでの更新を勧めている。
ただし開発元のリリースノートには個々のCVE番号が列挙されていない。今回の2件と修正バージョンの対応は、2.4.4を参照先に挙げるVulnCheckの各CNA勧告によって確認した。対応としては、まず管理対象サイトのBricksのバージョンを点検し、バックアップや動作確認の手順を踏んだうえで2.4.4以降へ更新する。変更後はテーマ・プラグインの機能や公開設定に問題がないかを確認したい。
WORK SIGNALの視点:修正履歴とCVEを突き合わせて更新判断を
今回の2件は、単なる画面表示の不具合ではなく、Webサイトに保存された非公開情報の保護にかかわる。ログイン不要で影響し得る点、CVSS v3.1で7.5と評価されている点、すでに修正版が公開されている点から、Bricksを利用するサイトの管理者には優先度の高い確認事項だ。
一方、公開情報だけから「実際に攻撃が発生した」「すべてのBricksサイトで情報漏えいが起きた」と結論付けることはできない。公式リリースがCVEを明示しない場合は、開発元の更新履歴とCNA勧告の両方を確認し、影響製品・範囲・修正版を照合することが重要になる。脆弱性管理は深刻度の数字だけでなく、自社の利用状況と修正可能性を合わせて判断したい。