あれ？Drupal の管理画面で記事を書こうとしたところ、画面の上に赤いエラーメッセージが出ていました。
「利用中のモジュールやテーマのセキュリティーアップデートが入手可能です」という知らせです。
原因は、フォームを機械による送信から守る CAPTCHA モジュールに見つかった脆弱性（セキュリティ上の欠陥）でした。
2026年10月28日（日本時間では29日）に、Drupal のセキュリティチームが修正版の 2.0.11 とセキュリティ情報を公開しています。
この記事では、単なるアップデートの方法ではなく、なぜこの脆弱性が起きたのか、なぜセキュリティ更新が必要なのか、そして更新しないままにしておくリスクを、このブログで実際に行ったアップデートの前と後の画面を交えて、できるだけ分かりやすく解説します。
Drupal の管理画面の「レポート」→「利用可能なアップデート」を開くと、インストールしているモジュールが最新かどうかを確かめられます。
CAPTCHA 2.0.10 の欄が赤くなり、セキュリティーアップデートとして 2.0.11 が案内されていました。「Requires Drupal core: 11.4.11」とあるとおり、今の Drupal 本体のままで入れられる版です。
2.0.11 に更新したあと、「手動で確認」を押すと、CAPTCHA の欄が緑の「最新」に変わりました。
記事の作成画面の赤いエラーメッセージも消えています。
CAPTCHA（キャプチャ）は、フォームを送ろうとしているのが人なのか、機械（ボット）なのかを確かめる仕組みです。
「私はロボットではありません」のチェックや、ゆがんだ文字を読み取る問題などが、よく知られています。
Drupal の CAPTCHA モジュールは、会員登録・コメント・ログイン・お問い合わせなどのフォームに、この確認を付けるためのモジュールです。このブログでは、CAPTCHA モジュールと Cloudflare Turnstile を組み合わせて、ログインのフォームなどを機械による送信から守っています。
CAPTCHA モジュールは、何段階かに分かれたフォームで、2段階目以降に同じ確認をくり返さなくて済むように、「この人はもう CAPTCHA を解いた」という記録を覚えておきます。
ところが 2.0.10 までは、この記録が、使い終わったあとも完全には消されていませんでした。そのため、一度送信したフォームを、新しい CAPTCHA を解かないまま、もう一度送信できてしまいます。これが「セッションリプレイ（記録の使い回し）」です。
図を押すと、その場で動画が再生されます。
今回の脆弱性は、もともと使う人の手間を減らすための便利な仕組みから生まれています。何段階かに分かれたフォームで、毎回 CAPTCHA を解かなくて済むように「もう解いた」という記録を覚えておく仕組みです。
たとえるなら、イベント会場の入口で渡す「入場済みの印」のようなものです。会場の中を行き来するときには便利ですが、帰るときに回収し忘れると、その印を使って何度でも入れてしまいます。今回は、フォームの送信が終わったあとも、この印が完全には回収されていなかったことが原因でした。
このように、セキュリティ上の問題は「便利さ」と「安全さ」の境目で起きやすく、作った人も気づきにくいものです。だからこそ、見つかった時点で修正版が公開され、使う側がそれを入れることで、はじめて守りが完成します。
実は、この種の脆弱性は今回が初めてではありません。2026年の初めにも、記録の使い回しに関する修正（SA-CONTRIB-2026-015）が出ています。そのときは使い回しの経路の1つが閉じられましたが、別の経路が残っていて、今回の 2.0.11 でそれが閉じられました。
Drupal のセキュリティ情報では、今回の脆弱性の重要度は「中程度（Moderately critical）・13／25」とされています。数字だけを見ると、それほど急がなくてもよさそうに見えるかもしれません。ただ、重要度の中身を見ると、早めに更新したい理由が分かります。
この脆弱性には、世界共通の脆弱性の番号として「CVE-2026-118582」が付けられています。これは CAPTCHA モジュールの脆弱性に付けられた番号で、PHP 本体の脆弱性ではありません。そのため、サーバーの PHP の版を上げても直らず、CAPTCHA モジュールを 2.0.11 に更新する必要があります。
| セキュリティ情報の項目 | 今回の内容 | 意味 |
|---|---|---|
| 攻撃に必要な条件 | なし（A:None） | ログインしていない人でも狙える |
| 攻撃の方法 | すでに存在（E:Exploit） | 攻撃のやり方が、すでに知られている |
| 対象になる設定 | すべて（TD:All） | どんな設定で使っていても対象になる |
| 攻撃の難しさ | 基本的（AC:Basic） | 特別な条件がなくても試せる |
| 情報の漏えい・改ざん | なし（CI:None・II:None） | この脆弱性だけで、データが盗まれたり書き換えられたりはしない |
つまり、データを直接盗まれる脆弱性ではないものの、「誰でも」「すでに知られた方法で」「どの設定でも」狙えるという点が重要です。CAPTCHA はサイトの入口を守る部品なので、ここが弱くなると、その奥にあるフォームへの攻撃がしやすくなります。
CAPTCHA が回避されると、機械による大量の送信を止められなくなります。
Drupal のセキュリティ情報でも、次のような攻撃への守りが弱くなると説明されています。
会員登録を受け付けているサイトでは、偽のアカウントが機械で大量に作られるおそれがあります。不要なアカウントの削除に手間がかかるだけでなく、そのアカウントが迷惑な投稿の入口になることもあります。
コメント欄があるサイトでは、宣伝や悪質なリンクが繰り返し書き込まれるおそれがあります。訪問者が危ないページへ誘導されたり、サイトの信用が下がったりする原因になります。
ログインのフォームで、パスワードを機械で次々に試す攻撃（総当たり攻撃）を止めにくくなります。弱いパスワードを使っていると、アカウントを乗っ取られる危険が高まります。
見落とされがちなのが、このリスクです。セキュリティ情報や修正版が公開されると、どこに脆弱性があったのかは、誰でも調べられるようになります。攻撃する側は、古い版のまま残っているサイトを機械で探して狙います。公開から時間がたつほど、更新していないサイトは狙われやすくなります。
セキュリティ更新は急ぎたい一方で、更新でサイトが表示されなくなっては困ります。そこで、次の手順で「すぐに・安全に」更新しました。
| 手順 | 内容 |
|---|---|
| 1. 今の版を確認 | CAPTCHA が 2.0.10 であることを確かめる |
| 2. 退避する | データベースと、Composer の設定ファイル（composer.json・composer.lock）を保存する。退避できなければ、更新しない |
| 3. CAPTCHA だけ更新 | 関係のない部品まで一緒に上げないよう、CAPTCHA だけを指定して更新する |
| 4. 仕上げ | データベースの更新と、Drupal のキャッシュの消去 |
| 5. 表示を確認 | 記事・ログインの画面・一覧が、すべて正常（200）に表示されるかを確かめる。だめなら退避から自動で戻す |
Composer で管理している Drupal の場合、手順3と4は、次のようなコマンドで行います。
composer update drupal/captcha
drush updb -y
drush cr今回は、CAPTCHA が 2.0.10 から 2.0.11 に上がり、ほかの部品は変わりませんでした。データベースの更新も「No pending updates.」（必要な変更なし）で、記事・ログインの画面・一覧はすべて正常に表示されました。
なお、2.0.11 には、今回の脆弱性の修正のほかに、PHP 8.5 に向けた互換性の修正なども含まれています。
同じ画面に、Drupal 本体の「11.5.0-beta1」「12.0.0-beta2」や、二段階認証（TFA）の「2.0.0-alpha5」も表示されていました。beta や alpha は試験版なので、ふだん使っているサイトには入れなくて大丈夫です。「最新」の緑の表示が出ていれば、安定版としては最新です。
このブログでは、ログインに二段階認証（TFA）も使っています。仮に CAPTCHA が回避されても、パスワードだけではログインできないようにしておくと、被害を防ぎやすくなります。入口の守りは、いくつかを重ねておくのが基本です。
「利用可能なアップデート」の「設定」タブでは、更新があったときにメールで知らせてもらう設定ができます。知らせる範囲を「セキュリティー更新のみ」にしておくと、急ぎの更新だけを見落とさずに済みます。
Drupal の管理画面の「レポート」→「利用可能なアップデート」で、CAPTCHA が 2.0.10 以前になっていれば対象です。古い系統の 8.x-1.x を使っている場合は、8.x-1.18 が修正版です。
関係ありません。CAPTCHA モジュールは PHP で書かれていますが、今回の問題はモジュールの処理（解いた記録を消し忘れる部分）にあり、PHP 本体の問題ではありません。直すには、CAPTCHA モジュールを 2.0.11（8.x-1.x の場合は 8.x-1.18）に更新します。なお、2.0.11 のリリースノートにある「PHP 8.5 との互換性の修正」は、今後の PHP でも動くようにするための別の修正です。
おすすめしません。今回は攻撃の方法がすでに知られていて、ログインしていない人でも狙えます。Drupal のセキュリティ情報でも、最新版を入れるよう案内されています。
更新の前にデータベースと Composer の設定を退避しておけば、元の版に戻せます。退避と、更新後の表示の確認は、必ずセットで行いましょう。
金風株式会社では、Drupal や WordPress で作られたサイトの、セキュリティ更新や保守のご相談を承っています。「管理画面に赤い表示が出ているけれど、どうすればいいか分からない」という段階からでも、お気軽にお問い合わせください。