DrupalのBlock AJAXに重大な脆弱性｜3.0.2の修正と表示変更を一緒に確認

Drupal Security Teamは2026年10月7日、Block AJAXモジュールのPHPオブジェクトインジェクションをSA-CONTRIB-2026-192として公表しました。識別子はCVE-2026-107249、対象は3.0.2未満です。公式は最悪の場合にリモートコード実行へ至る可能性を説明し、3.0.2への更新を案内しています。

本稿の確認日は10月18日です。当日の新たな被害の速報ではありません。Drupal独自のリスク評価はHighly criticalの20/25で、CVSSの20点という意味ではありません。本記事のCVSS欄には独自尺度を転記せず、実際の悪用についても確認した資料で分からないことを断定しません。

出典：Drupal Security Team：SA-CONTRIB-2026-192。

Drupal本体ではなく非同期表示を担う拡張の問題

Block AJAXはブロックをAjaxで非同期に読み込むモジュールです。公式説明では、ブロックの構築に使う利用者入力を十分に検証していないことが問題とされています。ページの一部を後から読み込む処理でも、サーバー側で入力を解釈して構築する境界が存在します。

告知は、Layout Builderが有効なサイト、または渡されたデータを危険な方法で処理する別のブロックプラグインがある場合という条件を挙げています。Drupal本体を使うすべてのサイトが同じ状態だと読み替えないでください。拡張の導入、版、組み合わせを調べる必要があります。

一般にPHPオブジェクトインジェクションでは、外部から与えられたデータが、プログラム内のオブジェクトとして扱われる過程で想定外の処理につながる場合があります。ただし、今回の全構成で同じ実行経路があるとは限りません。本稿は攻撃用のデータや再現要求を提示せず、修正と運用の確認を扱います。

関連する一次資料：Drupal.org：Block AJAX 3.0.2リリースノート。

有効モジュールと実際の呼び出し元を結び付ける

最初の作業として、拡張の管理情報でblock_ajaxの有無と導入版を確認します。名前が一覧にあるだけでなく、どのページやテーマ、独自モジュールから使われているかも調べます。使っていないと思っていた機能が、テーマの一部で読み込まれている場合があります。

本サイトでは、ブロック名、表示条件、呼び出し元、利用するプラグイン、管理担当を対応付けることを提案します。Layout Builderを利用している場合は、その編集画面と公開側を分けます。編集者に見えるページだけでなく、未ログイン利用者がアクセスする経路も調査対象です。

設定の画面表示と実際のリリース成果物が違う環境では、依存関係のロック情報や配信済みファイルも照合します。ローカルのcomposer.jsonを見ただけで、本番がその内容へ更新されているとは判断しません。使用している構成管理の流れに沿って実体を確かめます。

3.0.2には意図された動作変更がある

公式リリースノートは、セキュリティ修正のためTwig Tweakのサポートの一部を戻したと説明しています。カスタム設定を伴うTwig TweakからのAJAXブロック描画は、設計上サポートされなくなりました。更新後の表示不具合をすべて想定外のバグと考えないことが大切です。

修正後のルートで読み込めるのは、ブロック設定エンティティとして保存された、Block layoutから配置するブロックです。プラグインIDと設定から生成する呼び出しは、従来と同じ方法では利用できません。公式は配置済みブロックを使う方法をREADMEで案内しています。

したがって、版の変更だけを試験するのではなく、該当するカスタム呼び出しを探して移行方針を決める必要があります。本サイトでは、その修正をセキュリティ更新と同じ作業票に載せ、互換性のために危険な旧処理へ戻してしまわない管理を勧めます。

置き換えでは表示条件も引き継ぐ

説明用の仮想例として、テーマのTwigから、顧客のログイン状態に応じた案内ブロックをカスタム設定付きで表示しているサイトを考えます。配置済みブロックへ移す場合、見た目を再現するだけでなく、誰へ表示するか、どのページへ出すかも確認が必要です。

管理画面でブロックを配置できたことは、旧実装と同じ公開範囲になった証明ではありません。対象ロール、言語、パス、表示しない条件を一覧にし、移行後の設定と照合する方法を提案します。過去の独自条件がテーマ側にしかなかった場合は、その条件をどこで維持するか明確にします。

試験には機密データを含まない識別用テキストを使い、匿名利用者、一般の認証済み利用者、編集者で結果を比べます。新しいブロックが表示されることだけでなく、表示されるべきでない相手に出ないことを対で確認してください。

依存関係の更新を本番へ届ける手順を決める

公式の3.0.2リリースページは対応するDrupalの条件とComposerを使う導入案内を掲載しています。実際の更新は、プロジェクトの依存関係と配信方式に沿って行います。導入例のコマンドを、依存関係や保守手順を確認せず本番で直接実行することは勧めません。

本サイトの実施案は、検証環境で依存関係を解決し、ロック情報と変更差分を確認してから、承認された成果物を本番へ配信する方法です。手元でバージョンが上がっても、本番のドキュメントルートが別のままなら修正は届きません。配信先の拡張版を読み戻します。

必要な設定反映やキャッシュ処理は、採用しているDrupalの運用方法に従って実施します。表示が古い場合に、修正ファイルをさらに手作業で上書きして原因を増やすのではなく、実行中の成果物、設定、キャッシュのどこで差が生じているかを分けて確認します。

非同期の失敗をページ全体の成功で隠さない

Ajaxで読み込むブロックは、ページ本体が表示されても後続の要求だけ失敗することがあります。検証ではブラウザーの画面だけでなく、許可された環境で後続要求の成功・失敗、応答の内容、エラー時の表示を確認します。利用者が空白を見ているのに監視は正常という状態を避けます。

通信が遅い場合、期限切れの認証、権限がない場合も、代表的な業務条件として試します。ただしこれは脆弱性の攻撃再現とは別の互換性試験です。失敗するときに内部のファイルパスや秘密情報を画面へ出すよう、デバッグ設定を本番で広げないでください。

JavaScriptを使う経路だけでなく、必要な代替表示も確認します。すべてのサイトで同じフォールバックが求められるわけではありませんが、料金、操作の注意、問い合わせ導線など重要な情報が後続要求の失敗で消える設計なら、業務側と改善を検討する理由になります。

表示速度の改善と安全な構築を両立する試験計画

非同期化はページの体感速度を改善するために採用されることがあります。そのため、修正後にブロックの読み込みが変わると、以前と同じ表示へ急いで戻したくなるかもしれません。本サイトでは、旧実装をそのまま復活させる前に、何を達成するために非同期化したかを確認する方法を勧めます。

説明用の試験では、重要な情報が表示される時刻、後続要求の失敗、ページ操作が可能になるまでを分けて観測します。全体の読み込み時間一つでは、必要なブロックが空白のままでも速く見える場合があります。ページ本体、非同期の内容、操作に必要な情報をそれぞれ完了条件にします。

Twig Tweakからのカスタム設定を配置済みブロックへ移す際も、表示結果だけでなく設定を誰が変更できるかを確認します。テーマのコードレビューで管理していた条件が、管理画面の権限へ移るなら、運用責任が変わります。変更を承認する人と、公開後に確認する人を決めておきます。

検証で特定のページだけ問題が出た場合には、そのページのブロック、呼び出し方法、表示条件を照合します。修正を無効化する大きな変更より、配置や設定の差を一つずつ調べます。利用者への影響が大きければ、一時的に静的な案内へ替えるなど、危険な旧処理を再開せずに必要な情報を届ける代替手段を検討します。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	完了の判断
拡張の版	block_ajaxと依存関係の実体	配信先で3.0.2以降の修正版を確認
構築の条件	Layout Builderなどの組み合わせ	Drupal本体だけで対象を判断しない
呼び出し	Twig Tweakとカスタム設定の利用	旧い生成方法を配置済みブロックへ整理
表示範囲	ロール・言語・パスごとの条件	必要な相手だけに表示されることを確認
非同期要求	後続通信の成功・失敗・代替表示	ページ本体の成功だけで完了にしない

キャッシュの境界とロールの境界を一緒に確認する

表示条件を変えた移行では、利用者ごとの結果がキャッシュを通じて混ざらないことも確認するよう提案します。これは本CVEで必ず起きると報告された事象ではなく、アクセス条件を移す際の独立した検証観点です。ログイン済みの表示を、直後に匿名で再利用しないかを確かめます。

複数言語や複数サイトを同居させる環境では、その境界も対象にします。代表ケースを選び、期待する表示と実際の表示を記録します。不一致が出た場合は、ブロック設定、テーマの条件、キャッシュ設定を分けて調べ、闇雲にすべてのキャッシュを無効にして完了にしないでください。

今回の修正対応では、危険な入力経路を閉じることと、必要なブロックを正しい相手へ表示することの両方が必要です。3.0.2の変更を理解し、利用している呼び出し方を更新と合わせて直すことで、旧挙動へ戻さずに業務を維持しやすくなります。