お問い合わせフォームの脆弱性は情報漏洩に直結！どのようにフォームを見直すべきかを具体的に紹介

こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、最新の Web セキュリティに関する内容を紹介し、企業のサイトを守るための考え方と実践方法をご紹介します。

Web サイト運用で、いちばん「個人情報が集まる場所」はどこでしょう?

多くの場合、それはお問い合わせフォームです。

2025 年 12 月、WordPress プラグイン「Ninja Forms」に、フォーム定義や送信データが参照され得る脆弱性(CVE-2025-11924)が公表されました。

Ninja Forms を使っており、3.13.3 以降へのアップデートがまだの場合は最優先です。
ただ、プラグインのアップデートだけで「フォーム運用は安全」とは言えません。フォームは仕組み上、攻撃者にとって狙いやすいターゲットなので、運用の設計もセットで見直しましょう。

今回の脆弱性の概要(何が起きるのか)

CVE-2025-11924 は、Ninja Forms の REST API(ninja-forms-views)まわりに起因する、Insecure Direct Object Reference(IDOR)の脆弱性として整理されています。

大まかに言うと、「参照してはいけないデータを、参照できてしまう経路がある」というタイプです。

公表されている情報(CVE-2025-11924 Detail – NVD)では、以下がポイントです。

このことは、プライム・ストラテジーの『Security Advisory for WordPress』でも言及されています。(WordPress テーマ・プラグイン 脆弱性情報のまとめ(2025/12/11-2025/12/17))

またここでは、「3.13.1 で修正を出したが、別の REST API によりパッチが効かない状態になっていた」という注意点も書かれています。

こういう「直したつもりが直ってない」系のものは、運用者側が巻き込まれやすく、気づきにくいです。

フォームが危ないのはプラグインだけの話ではない

フォームの事故は、脆弱性だけが原因ではありません。これらのような問題もよく起こります。

以前のコラムでも、フォーム / DL 資産は「積み重ねの管理」が重要だと整理しました。フォームは便利なぶん、放置すると負債化します。
参考: オウンドメディア構築・運用の「フォーム / DL 資産」の総点検をする | Web ガバナンス

いますぐやる対応

1) Ninja Forms を使っているか確認する

まず現状を把握します。WordPress は複数サイト・複数環境に分散しがちなので、把握しているつもりが一番危ないです。

本番サイトだけでなくステージング / プレビュー / 過去のキャンペーンサイトも対象です。(マルチサイトの場合は、サイトごとに有効化状況が違うケースもあります)

2) 3.13.3 以降へアップデートする

管理画面からの更新で問題ない場合は、それで OK です。もし更新できない事情がある場合は、「なぜ更新できないのか」をまず解消すると良いです。

(PHP バージョンが古い、テスト環境がない、制作会社に依存しているなど、運用課題が根本原因であることが多いです)

3) 「Submissions Table ブロック」を公開ページに置いていないか確認する

「Submissions Table ブロック」とは、WordPress のブロックエディタ(Gutenberg)で使える Ninja Forms 専用のブロックで、フォームの送信一覧を表示するためのものです。Classic Editor を使っている場合は該当しませんが、ブロックエディタを使っているサイトは確認が必要です。

今回の件は、条件次第で送信データにアクセスされ得る点が怖いところです。少なくとも、

• 公開ページに管理寄りのブロックを置かない
• 置くなら IP 制限 / Basic 認証などで閲覧者を絞る

という発想は持っておくと良いと考えています。

4) フォームのデータ側も棚卸しする

脆弱性対応で忘れがちですが、フォームは「データを持つ」時点でリスクがあります。

• どのフォームが、何の目的で、どんな項目を収集しているか
• 送信データの保存期間はどうしているか
• 保存場所(DB / メール / 外部 SaaS)と、そのアクセス権は適切か
• 不要フォームの停止・削除フローはあるか

この棚卸しができている会社ほど、脆弱性が出た時に判断が速いです。

【発展】さらに堅牢にするなら: 個人情報の外部 DB 化

ここからは、今回の脆弱性対応とは別に、フォーム運用をより堅牢にするための設計についてです。すぐに対応が必要なものではありませんが、中長期的な改善の参考にしてください。

WordPress 運用で「個人情報は外部 DB 化しておくと良い」とよく言われます。私も基本的には賛成です。

理由はシンプルで、攻撃対象(攻撃面)を減らせるからです。WordPress はプラグインも含めると構成が複雑になりがちで、もし侵害された場合に DB からまとめてデータを抜かれるリスクが現実にあります。

また、プライバシー観点でも「必要最小限の個人情報だけを持つ(データ最小化)」という考え方が推奨されています。

外部 DB 化のよくあるパターン

• WordPress は入力 UI(フォーム)だけにして、送信データは CRM / チケット管理 / MA ツールなどの「本来保管すべき場所」に直接送る
  • WordPress 側には「問い合わせ ID」など最小限だけ残す(あるいは何も保存しない)
• トークン化する
  • WordPress 側に個人情報を持たず、外部 DB にだけ保存し、WordPress は参照用トークンだけ扱う

注意点: 外部 DB 化すると「別の運用責任」が生まれる

外部 DB 化はセキュリティ上のメリットがある一方で、次の点は要注意です。

• 連携 API の防御が必要(認証, HTTPS, レート制限, IP 制限, ログ監視など)
• 個人データのエクスポート / 削除対応が複雑になる

「外部 DB 化すれば安心」ではなく、「どこに個人情報が存在するか」を台帳化し、削除期限(保存期間)と権限設計まで含めて運用するのがポイントです。

「更新する体制」が最大のセキュリティ対策

今回のようなプラグイン脆弱性は、今後も繰り返し出ます。個別の CVE を追うのも大事ですが、もっと大事なのは更新できる運用を作ることです。

プライム・ストラテジーでは、WordPress のセキュリティ運用を支援するサービスが複数提供されています。

• まず情報収集から始めたい方:
  Security Advisory for WordPress (テーマ・プラグイン脆弱性情報のダイジェストを無料で配信)
• 継続的な多層防御・自動アップデートを重視したい方:
  KUSANAGI Security Edition
• 「社内に詳しい人がいない」「運用を丸ごと任せたい」方:
  KUSANAGI マネージドサービス
• まず現状把握をしたい方:
  簡易脆弱性診断

フォームは入り口ですが、事故が起きると影響は会社全体に広がります。
この機会に、フォームを「機能」ではなく「情報資産」として管理する体制を整えてみてはいかがでしょうか。