iPLAss Ver.2の脆弱性：対象確認と外部到達の遮断、4系への更新判断

電通総研は2026年11月4日、ローコード開発基盤iPLAssのVer.2で、認証を経ずに管理機能へ到達できる場合があると公表しました。実際に不正アクセスと情報のダウンロードも確認されています。CVE番号も管理機能の名称も出ていないため、パッチの番号を追う通常の手順は使えません。この記事では2026年11月9日時点の一次情報をもとに、稼働版の確認、社外からの到達検証、ログの保全、nginxとTomcatでの暫定遮断、更新先の選び方を、運用担当者と開発者向けに整理します。

まとめ：iPLAss Ver.2は外部到達を今日絞り、4系への更新を計画

Ver.2が動いているなら、当日中に行うのはアプリケーションサーバーへの経路を絞ることです。発表が脆弱性の条件として挙げたのはアクセス制御の設定不備であり、ここは利用者側で手を打てます。管理機能の名称が公表されていないので、拒否するパスを列挙する方式は成り立ちません。公開するパスだけを通す許可リストに切り替えます。

次に、ログを消える前に保全します。11月2日は検知された日であり、攻撃が始まった日ではありません。更新先は、公式のサポート対象である4.1系か4.0系です。3.2系は2026年6月にサポートを終えているので、Ver.3に同様の問題がないという発表を理由に3系へ留めるのは勧めません。

どのパスが外から届くのか自社で判断しきれない場合は、脆弱性診断・セキュリティ診断で公開範囲の棚卸しから始めると抜けを減らせます。

iPLAss Ver.2の脆弱性で公表された内容と未公表のままの項目

判断の土台になる事実は多くありません。確定している範囲と、まだ分からない範囲を分けておきます。

電通総研の2026年11月4日の発表で確定している発生条件と被害

電通総研のお知らせによると、2026年11月2日に監視のアラートを検知して調査した結果、iPLAss Ver.2の利用環境で第三者による不正アクセスと情報のダウンロードが判明しました。アプリケーションサーバーなどのアクセス制御が適切でない場合に、外部からのアクセスを想定していない管理機能へ、認証なしで到達できることがあります。

製品の機能や挙動と、利用環境の設定との組み合わせで起きるとされ、詳細は調査中です。Ver.3以降では同様の脆弱性が生じないことを確認済みで、利用者には版の確認と最新版への更新の検討が求められています。設定だけの問題とも、製品だけの問題とも読めない点に注意が要ります。

CVE番号も管理機能の名称も出ていない2026年11月9日時点の限界

お知らせにはCVE番号、CVSSの値、管理機能の名称、攻撃に使われたパスの記載がありません。スキャナの検出項目やWAFのシグネチャに頼る対応は、この時点では組めないということです。

iPLAssにはAdminConsoleという管理ツールがありますが、今回の管理機能がこれを指すのかは公表されていません。同じくAdminConsoleを使える利用者を絞る設定（Userエンティティのadminプロパティ）や2段階認証は、認証を経ずに届く経路に対する防御としては当てになりません。

所沢シティマラソン178名の漏えいとVer.2の関係を断定しない理由

所沢市の2026年11月6日の発表は、ローソンエンタテインメントのLAWSON DO! SPORTSが使うiPLAssへの不正アクセスにより、第37回所沢シティマラソンの申込89件、計178名分の情報が漏えいしたと伝えています。対象は氏名、性別、住所、生年月日、電話番号、メールアドレス、緊急連絡先です。カード情報やパスワードはシステムに保持していませんでした。

発表にVer.2の語はなく、電通総研の件と同じ原因かどうかは読み取れません。ただ、この事例は別の教訓を示しています。自治体から見ると、iPLAssは委託先のサービスの内側にある部品でした。自社で導入した覚えがなくても、無関係とは言い切れません。

自社のiPLAssが対象か確かめる版の確認と外部到達の検証手順

確かめることは2つです。動いている版と、社外から届くパスです。以下のコマンドは公式の記載をもとに書いたもので、検証環境での実行結果ではありません。

WARの中のjar名から稼働中のiPLAssの版を特定する確認コマンド

配布物の版番号は、WARに同梱されたjarのファイル名で見分けます。Maven Centralのiplass-coreはこの形式の成果物で、登録されている版は3.0.1から4.1.4までです。Ver.2は載っていません。GitHubのタグも3.0.0が最古なので、公開リポジトリの差分からVer.2の問題箇所を追うこともできません。

# 配備したWARの同梱jarを一覧する（app.warは実際のファイル名に置き換える）
unzip -l app.war | grep -E 'WEB-INF/lib/iplass-'

# 展開済みの配備先を見る場合
ls /opt/tomcat/webapps/app/WEB-INF/lib | grep '^iplass-'

jar名に2.で始まる版が出たら対象です。ファイル名に版番号が含まれない独自ビルドは、構築を担当した会社に確認します。あわせて動いているTomcat自体の版も控えてください。Tomcatのバージョン確認方法で手順を確認できます。

社外回線のcurlでAPサーバーと運用系パスの到達範囲を実測する手順

社内からの確認では、社内IPを許可する設定に隠れて見落とします。テザリングなど社外の回線から実行してください。自社が管理するホストだけを対象にします。

現行のソースにあるweb-fragment.xmlには、/cmcs、/checkStatus、/warmupStatusというサーブレットの定義があります。いずれも運用のための経路で、一般の利用者に開ける理由はありません。今回の管理機能と同じものとは確認されていませんし、Ver.2の定義は自社のWARで見る必要があります。公開範囲の点検の起点として使います。

# 社外の回線から実行する。HOSTとCTXは自社の値に置き換える
HOST=app.example.jp
CTX=app
for p in cmcs checkStatus warmupStatus; do
  curl -s -o /dev/null -w "%{http_code} ${p}\n" "https://${HOST}/${CTX}/${p}"
done

# APサーバーのポートが直接開いていないかも確かめる
curl -s -o /dev/null -m 5 -w "%{http_code}\n" "http://${HOST}:8080/"

403、404、接続失敗のいずれかなら入口で止まっています。200が返った経路は、次の章の暫定策の対象です。8080番に限らず、構成に合わせて実際の待ち受けポートを指定します。

情報持ち出しの痕跡を探すアクセスログの集計方法と保全の順序、報告判断

到達できる状態だったのなら、すでに持ち出されている前提で調べます。設定を変える前に、ログの確保を先に済ませます。

検知日の11月2日より前まで遡るログの保全と応答サイズ集計の手順

お知らせには攻撃の開始時期が書かれていません。保持しているログは期間を区切らず、すべて別の場所へ複製します。ローテーションで消える環境では、これが最優先の作業です。

集計では、ふだん使われないパスと、応答サイズの大きな取得を探します。情報のダウンロードが確認された事案なので、件数よりもバイト数で並べるほうが手掛かりになります。

# combined形式のログで、200応答のパスをバイト数の合計順に並べる
awk '$9 == 200 { split($7, a, "?"); sum[a[1]] += $10; n[a[1]]++ }
  END { for (p in sum) print sum[p], n[p], p }' access.log | sort -rn | head -50

# 上で見つけたパスの送信元と時刻を確認する
grep -F ' /app/調べるパス' access.log | awk '{print $1, $4, $9, $10}' | head -100

リバースプロキシとTomcatのログは両方見ます。プロキシを通らない直接の接続は、Tomcat側にしか残らないからです。ログインした記録のない送信元が、大きな応答を受け取っていれば要調査です。

不審な取得を見つけた場合の個人情報保護委員会への報告と連絡先

個人データの漏えいのおそれがあると判断した時点で、報告の期限が動き出します。件数が確定していなくても速報は出せます。個人情報保護委員会への報告義務で、対象の4類型と速報3〜5日、確報30日の扱いを確認してください。

製品については、電通総研のお知らせに記載されたエンタープライズソリューション営業3部の問い合わせ先へ連絡します。管理者のパスワードやAPIのトークンは、何が読まれたのかが分からない以上、取り替えておくのが無難です。ただし、痕跡を調べ終える前にサーバーを作り直すのは避けます。

バージョンアップまでの暫定策としてnginxとTomcatで外部到達を絞る設定

更新には時間がかかります。発表が条件に挙げたアクセス制御の側を、それまでの間に塞ぎます。

名称不明の管理機能には拒否リストでなく許可リストで絞るnginx設定

閉じるべきパスの名前が分からない以上、「このパスを拒否する」形では漏れます。社内だけで使うシステムなら、全体をIPアドレスで絞るのが確実です。nginxのaccessモジュールは規則を上から順に評価し、最初に一致したもので止まります。

# 社内利用のシステム：サイト全体を拠点のIPに限定する
server {
    listen 443 ssl;
    server_name app.example.jp;

    allow 203.0.113.0/24;
    deny  all;

    location / {
        proxy_pass http://ap_backend;
    }
}

# 一般公開のシステム：使っているパスだけを通し、残りは404にする
server {
    listen 443 ssl;
    server_name www.example.jp;

    # パスパラメータを使った解釈のずれを防ぐ
    if ($request_uri ~ ";") { return 400; }

    location ^~ /iplassApp/sampleTenant/gem/ {
        proxy_pass http://ap_backend;
    }
    location / {
        return 404;
    }
}

/iplassApp/sampleTenant/gem/は公式チュートリアルのURL例をなぞったものです。実環境では、前章のログ集計を元に静的ファイルやWebAPIのパスを足します。この配下に管理機能が含まれないことは確認されていないので、IP制限を掛けられる経路には併用してください。

nginxのallowとdenyは、そのレベルに規則を書くと親レベルの規則を引き継ぎません。locationに1行足しただけで、serverに書いた制限が外れることがあります。セミコロンの拒否は、JavaのサーブレットコンテナがパスパラメータとしてURLを解釈し、プロキシと見え方がずれるのを防ぐためです。;jsessionidをURLに載せる構成では先にログで使用の有無を確かめます。

TomcatのRemoteCIDRValveでプロキシ以外からの接続を拒否する設定

nginxを迂回された場合に備えて、Tomcat側でも接続元を絞る設定が必要です。Tomcatのセキュリティ指針も、管理系アプリを接続元で保護するよう勧めています。Tomcat 9.0.123の設定リファレンスにあるRemoteCIDRValveをアプリのContextに置きます。

<Context>
  <Valve className="org.apache.catalina.valves.RemoteCIDRValve"
         usePeerAddress="true"
         allow="10.0.1.10, 127.0.0.1, ::1" />
</Context>

10.0.1.10はnginxのアドレスの例です。ロードバランサーのヘルスチェックを受けている場合は、その送信元も加えます。

落とし穴はusePeerAddressにあります。iPLAssの環境構築の注意事項は、プロキシの背後ではRemoteIpValveでクライアント情報を渡すよう案内しています。この場合、Valveが判定するのは書き換え後のクライアントIPなので、プロキシのアドレスを許可しても一致しません。usePeerAddress="true"はTCP接続の相手で判定させる指定です。古いTomcatにこの属性がなければ、APサーバーの待ち受けを内部ネットワークに限定し、セキュリティグループなどで塞ぎます。

社内利用か一般公開かで分かれる暫定策の強度と公開停止判断の基準

同じVer.2でも、取れる暫定策の強さは利用者の範囲で変わります。

WAFだけの対策で公開を続ける判断は取りません。シグネチャを書くための攻撃パスが公表されていないからです。

更新先は4.1系か4.0系か：サポート期限から見たVer.2の移行判断

到達を絞っても、Ver.2に残る問題そのものは消えません。更新先の選び方を、公式のサポート表から決めます。

3.2系は2026年6月でEOL、延長はEnterprise Editionのみの制約

公式のサポートポリシーでは、サポート対象は最新の4.1系とその一つ前の4.0系です。

3.2系はEnterprise Editionのみ、2027年6月まで延長されます。結論は4.1系です。これから更新の工数をかけるなら、サポートの残りが長い系列を選ぶ方針です。3.2系へ移す案は、Enterprise Editionの延長契約を持っていて、4系への移行が2027年6月までに確実に終わる場合に限り、つなぎとして成り立ちます。それ以外では、同じ移行作業を2回行うことになります。

Java 21とTomcat 10.1への移行で工数が膨らむ改修箇所の見積もり

4.1系の動作環境はJava 21以上、Servlet 6.0を実装するTomcat 10.1です。4.0系の動作環境も同じ条件なので、4.0系を選んでも実行環境の更新は避けられません。

工数が読みにくいのは、製品の設定ではなく独自に書いたコードです。Servlet 6.0ではjavax.servletのパッケージがjakarta.servletに変わるため、カスタムのサーブレットやフィルタ、それらに依存するライブラリの差し替えが発生します。見積もりの前に、次の順で対象を数えてください。

1. 独自コードとGroovyスクリプトに含まれるjavax.のインポート数
2. WARに同梱した第三者ライブラリのうち、Jakarta対応版が存在しないもの
3. Oracle、MySQLなどDBの版が動作環境の下限を満たすか

1は機械的に置換できる範囲が広く、2は代替品の選定に時間を取られます。全体の進め方はパッチ管理の手順も参考にしてください。

4.1.4と4.0.25のリリースノートから今回の修正を読み取れない理由

お知らせの翌日にあたる2026年11月5日に、4.1.4と4.0.25が公開されました。どちらのリリースノートにも脆弱性の修正やCVEの項目はありません。掲載された変更は機能追加や不具合の修正、依存ライブラリの更新です。

公表どおりVer.3以降に同様の問題がないのであれば、この2版に今回の修正が入っている必要もありません。更新先は日付で選ばず、その時点の最新版を選びます。

委託先のサービスにiPLAssが入っているか確認するときの質問項目

所沢市の例のように、発注側が製品名を知らないまま使っていることがあります。個人情報を預けている委託先には、次の順で確認します。

1. 当社の案件で使うシステムにiPLAssが含まれるか、含まれるなら版は何か
2. Ver.2の場合、社外から届くパスと接続元の制限はどうなっているか
3. 2026年11月2日以前を含むアクセスログの保全と調査は済んでいるか
4. 更新の完了予定日はいつか

iPLAssに限らず、ローコード基盤の権限設計と発注時の確認項目は委託の契約時点で押さえておくと、次の事案で回答を待つ時間が短くなります。

iPLAssの脆弱性についてよくある質問と対象バージョン・暫定対策の判断

2026年11月9日時点の一次情報で答えられる範囲をまとめました。

今回のiPLAss Ver.2の脆弱性にCVE番号はありますか？

電通総研のお知らせにはCVE番号とCVSSの値が記載されていません。詳細は調査中とされているので、今後採番される可能性はあります。番号が出るまで待つ必要はありません。発表の時点で実際の不正アクセスが確認されているため、Ver.2を外部に公開しているなら番号の有無とは関係なく、接続元の制限とログの保全を先に進めてください。

Ver.3を使っている場合も対応は必要ですか？

発表では、Ver.3以降に同様の脆弱性は生じないことを確認済みとされています。今回の件に限れば緊急の対応は不要です。ただし3.2系は2026年6月にサポートを終えていて、延長の対象はEnterprise Editionのみです。今後見つかる別の問題には修正が届かない可能性があるため、4系への更新計画は別途必要になります。

4.1.4と4.0.25は今回の脆弱性の修正版ですか？

リリースノートに脆弱性の修正は書かれていないため、修正版とは言えません。公表の内容ではVer.3以降に同様の問題はないとされており、更新の目的はVer.2から離れることにあります。更新先には、作業の時点で公開されている4.1系の最新版を選ぶのが素直です。4.1.4という番号に固定して計画する必要はありません。

同じ日に電通総研が公表したFACEREの件と関係はありますか？

同じ2026年11月4日に公表されたFACEREのお知らせは、特定企業の環境におけるアクセス権限の設定不備が原因で、不正アクセスは9月10日、判明は10月29日とされています。文中にiPLAssへの言及はなく、両者の関係は2つの発表からは読み取れません。別の事案として扱うのが妥当です。

WAFやIP制限を入れれば更新しなくても大丈夫ですか？

IP制限は有効な暫定策ですが、更新の代わりにはなりません。発表では詳細が調査中で、製品の挙動も条件に含まれているからです。WAFは攻撃のパスが公表されていないため、効果を確かめられません。社内利用に閉じたシステムでも更新の期限は決めてください。ロールによる権限の設計の見直しは、更新の工程に合わせて行うと手戻りが減ります。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：WebAPIを公開している場合の認可の実装です。
• FaveConnect不正アクセス：11万7,392件の対象確認と管理画面の不正ログイン対策：管理画面が狙われた別の事案の対応手順です。
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順：更新を止めない運用の組み方です。
• ローコード開発のセキュリティリスクと対策｜権限設計・野良アプリ・発注時の確認項目：ローコード基盤を委託するときの確認点です。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：外から届く範囲の棚卸しを外部に頼むときの判断材料です。