--- title: "野村IRの機関Navi不正アクセス：漏えいの範囲と、PHP脆弱性対応後の再開前に確かめる改ざんとログ" url: "https://www.issoh.co.jp/tech/details/19323/" published: 2026-11-04 updated: 2026-11-04 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 野村IRの機関Navi不正アクセス：漏えいの範囲と、PHP脆弱性対応後の再開前に確かめる改ざんとログ 野村インベスター・リレーションズ株式会社は2026年11月4日、機関投資家・アナリスト向けのIR情報提供サービス「機関Navi」で11月2日に第三者による不正アクセスを確認し、その後に情報の外部漏えいを確認したと公表しました。漏えいした情報には氏名やメールアドレス等が含まれる可能性があり、件数と内容は調査中です。前半では登録者とMIR＠I会員、説明会を主催する企業のIR担当が知りたい対象・窓口・不審な連絡への備えを公式文書の文言で整理し、後半では重大な脆弱性の修正後にサービスを再開する前の改ざん確認とログ点検を、実行できるPythonで示します。 ## まとめ：野村IR「機関Navi」の不正アクセスで確定した事実と先にやること [野村IRの11月4日の公表文](https://www.nomura-ir.co.jp/ja/news/news/news20261104/main/00/link/20261104.pdf)で確定しているのは、機関Naviのシステムへの不正アクセスと、そこからの情報の外部漏えいの2点です。漏えいした情報の内容は「氏名やメールアドレス等が含まれる可能性」とされ、件数は書かれていません。過去に登録した人の情報も調査の対象です。 | 区分 | 公表文の記載 | | ---------- | ------------------------- | | 機関Navi | 不正アクセスを確認、情報の外部漏えいを確認、停止中 | | 漏えいの内容 | 氏名やメールアドレス等を含む可能性、調査中 | | MIR＠I | 同居のため予防停止、不正アクセスの有無は調査中 | | 公表されていないこと | 件数、原因、攻撃の手法、再開の時期 | 登録者がすぐやることは、野村グループを名乗るメール・電話・SMSのリンクや添付を開かず、公表文の窓口で確かめることです。説明会を主催する企業のIR担当は、機関Naviに渡していた出席者の項目を洗い出します。PHPで動くサービスを運用する側は、10月の重大な脆弱性の修正を入れて再開した後に、改ざんと不審なアクセスの確認まで済ませたかを見直します。 ## 機関Naviの登録者とMIR＠I会員向け：漏えいの可能性と不審な連絡への備え ### 機関Naviの登録者が対象で、過去に登録した人の情報も調査範囲に入る 機関Naviは、企業の決算説明会などに関わる情報を機関投資家・アナリストへ提供し、説明会への出席管理を支援するサービスです。登録者は機関投資家とアナリストなので、公表文が挙げる氏名やメールアドレスは、仕事で使う連絡先であることが多いはずです。公表文は「過去にご登録いただいた方の情報も含まれます」と書いており、いまは使っていない人も対象から外れません。 同社は、情報漏えいの対象であることが確認された人には同社から案内するとしています。2026年11月4日の時点で、利用者が自分で対象かどうかを確かめる手段は示されていません。 ### 野村グループを名乗るメール・電話・SMSの確かめ方と不正アクセス対応窓口 機関投資家やアナリストの勤務先メールアドレスは、標的型メールの宛先として価値が高い情報です。説明会の案内を装い、資料のダウンロードや出席登録のやり直しを求めるメールは、受け取る側から見て不自然さがありません。公表文は、同社や野村グループ、関係者を装う不審なメール・電話・SMSに注意するよう求め、リンクへのアクセス、添付ファイルの開封、パスワードや暗証番号の入力・回答をしないよう呼びかけています。 不審な連絡を受けたときの連絡先は、野村インベスター・リレーションズの不正アクセス対応窓口（電話03-3276-3603、受付は土日祝日を除く9時〜17時）と[同社の問い合わせフォーム](https://www.nomura-ir.co.jp/ja/contact3.html)です。電話番号はメールに書かれたものではなく、公表文に載っているものを使います。偽メールの見分け方の技術的な背景は[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で扱っています。 ### MIR＠Iは予防的な停止で、説明会の参加方法は別途メールで案内される 個人投資家向けの「MIR＠I（ミライ）」は、機関Naviと同じサーバー上で稼働していたため、予防的措置として止められました。MIR＠Iへの不正アクセスの有無は調査中で、漏えいが確認されたとは書かれていません。 同社は11月2日に[MIR＠I会員向け会社説明会の参加方法の変更](https://www.nomura-ir.co.jp/ja/news/news/news20261102.html)を告知し、具体的な参加方法は別途メールで案内するとしています。正規の案内もメールで届くため、偽物と区別しにくい時期です。案内メールのリンクから個人情報を入力する前に、[野村IRの公式サイトのニュース一覧](https://www.nomura-ir.co.jp/ja/news/news.html)に同じ内容の告知があるかを確かめます。 ## 公式発表で追う経緯：10月21日のPHP脆弱性対応の停止から11月4日の公表まで ### 修正プログラムの適用で一度止めて再開し、その5日後に不正アクセスを確認 野村IRのニュース一覧には、11月4日の公表の前に4件の告知が並んでいます。[10月21日の告知](https://www.nomura-ir.co.jp/ja/news/news/news20261021.html)は、PHPの重大な脆弱性の発表を受け、修正プログラムの適用と安全性の緊急点検のため、MIR＠Iと機関投資家・アナリスト向けIR情報配信サービスを同日22時から止めると案内しました。 | 日付 | 野村IRの告知・公表 | | ----------------------- | ------------------------- | | 2026/10/21 | PHPの重大な脆弱性対応のため、22時から緊急停止 | | 2026/10/23 | MIR＠I会員向け会社説明会の開催を再開 | | 2026/10/28 | 修正プログラム適用・緊急点検完了、サービス再開 | | 2026/11/2 | 機関Naviで第三者による不正アクセスを確認 | | 緊急保守開始、MIR＠Iの説明会参加方法を変更 | | | 2026/11/4 | 不正アクセスと情報漏えいを公表 | [10月28日の再開の告知](https://www.nomura-ir.co.jp/ja/news/news/news20261028.html)は、修正プログラムの適用と緊急点検が終わったとしています。不正アクセスの確認はその5日後です。同じ10月21日に[PHPの公式アドバイザリ](https://www.php.net/archive/2026.php#2026-10-21-5)が、認証なしでリモートコード実行につながる脆弱性2件と、修正版の8.5.12・8.4.27・8.3.36・8.2.35を公表しています。脆弱性の中身と版の確認方法は[PHP2Shell（CVE-2026-109618・109619）の影響範囲と修正版](https://www.issoh.co.jp/tech/details/18738/)にまとめました。 ### 公表文に書かれていないこと：件数・原因・PHPの脆弱性との関係 10月21日の告知にはCVE番号が無く、11月4日の公表文にも原因や侵入の経路は書かれていません。時期は近いものの、PHPの脆弱性が今回の不正アクセスにつながったかどうかは公表されていないため、本記事では両者を結び付けて書きません。 公表文に無いものは、ほかに漏えいの件数、項目の確定、個人情報保護委員会への報告の有無、再開の見通しです。同社は外部専門家と関係各社と連携して経緯と影響範囲を調べており、判明した事項は公式ウェブサイト等で知らせるとしています。同じ10月には野村證券の「i-Port」で、メール配信の委託先であるユミルリンクへの不正アクセスに関わる公表もありましたが、こちらは別の事案です。経緯は[ユミルリンクの不正アクセスと利用企業の確認点](https://www.issoh.co.jp/tech/details/18689/)で追っています。 ## 説明会を主催する上場企業のIR担当が確かめる、預けた出席者情報と委託の形 ### 機関Naviに渡していた出席者の項目と期間を、自社の記録から洗い出す 機関Naviで決算説明会の案内や出席管理をしていた企業は、出席者の氏名・所属・メールアドレスを同社のシステムに預けていた形になります。最初にやるのは、どの説明会から使い始め、どの項目を登録させていたかを自社の記録で確かめることです。自由記述の質問欄や、出席者の電話番号まで集めていた場合は、氏名とメールアドレスより影響が広がります。 次に、出席者への案内をどうするかを決めます。野村IRは対象者に同社から案内するとしているので、主催企業が独自に連絡すると二重の案内になり、かえって偽メールと見分けにくくなります。出席者からの問い合わせに答える文面を用意し、問い合わせ先は野村IRの窓口へ揃えるのが混乱の少ない形です。 ### 出席者情報の取り扱いを委託していた場合の監督と報告義務の確認 主催企業が自社の出席者情報の管理を機関Naviに任せていた形なら、個人情報保護法の上では委託にあたり、委託元として委託先を監督する義務が残ります。[個人情報保護法ガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)では、不正アクセスによる漏えいは「おそれ」の段階から件数にかかわらず個人情報保護委員会への報告の対象です。委託先は委託元へ通知すれば自らの報告が不要になり、報告は委託元が行う整理で、連名での報告も認められています。自社が委託元にあたるかどうかと、誰が報告するかを野村IRと詰めておきます。 委託先に求める契約条項と点検の項目は[委託先管理の監督義務とチェックリスト](https://www.issoh.co.jp/column/details/18778/)に、報告の期限と書式は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)にまとめています。 ## 重大な脆弱性の修正後にサービスを再開する前の侵害確認：改ざんとログの点検 ### JPCERT/CCとCISAが挙げる痕跡と、修正版を入れるだけでは足りない理由 ここからは本件の手口の再現ではなく、PHPで動くサービスを運用する側が、重大な脆弱性の修正後に再開する前に何を確かめるかの一般論です。修正版は穴を塞ぎますが、塞ぐ前に入られていた場合の置き土産は消しません。Webシェルや追加された管理者アカウントは、修正版を入れた後も動き続けます。 [JPCERT/CCの注意喚起（JPCERT-AT-2026-0033）](https://www.jpcert.or.jp/at/2026/at260033.html)は、確認する痕跡として、異常に長い値や不自然な形式のPHPSESSID、不審なmultipart/form-dataの要求とその前後のメモリ上限エラーやHTTP 500、ワーカーの異常終了や頻繁な再起動を挙げています。あわせて、不審なプロセスの実行、外部通信、不審なファイルの作成も確かめるよう求めています。痕跡が見つからなくても攻撃を受けていないとは断定できない、という点も注意喚起に明記された内容です。[CISAのアラート](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching)も、PHPのワーカーがシェルを起動したりツールをダウンロードしたりする挙動の監視を求めています。 ### 停止直後に取った基準とファイルの追加・変更をPythonで突き合わせる サービスを止めた直後、修正版を入れる前に、公開ディレクトリの全ファイルのハッシュを記録しておきます。再開の前にもう一度記録を取り、追加・変更・削除を比べます。比べる元になる基準は、本来はリリース時の成果物から作るのが確実です。ハッシュは[Pythonのhashlib](https://docs.python.org/ja/3/library/hashlib.html)のSHA-256で、ディレクトリの走査は[osモジュールのos.walk](https://docs.python.org/ja/3/library/os.html)で行います。 ``` # 再開前の改ざん確認：パッチ適用前に取った基準マニフェストと現在の公開ディレクトリを突き合わせる（Python 3.9以上・標準ライブラリのみ） import hashlib import json import os import tempfile def manifest(root): """公開ディレクトリ配下の全ファイルの SHA-256 を相対パスごとに記録する""" out = {} for d, _, files in os.walk(root): for f in files: p = os.path.join(d, f) with open(p, "rb") as fh: out[os.path.relpath(p, root).replace(os.sep, "/")] = hashlib.sha256(fh.read()).hexdigest() return out def diff(base, now): added = sorted(set(now) - set(base)) removed = sorted(set(base) - set(now)) changed = sorted(k for k in set(base) & set(now) if base[k] != now[k]) return added, removed, changed root = tempfile.mkdtemp() def put(rel, body): p = os.path.join(root, *rel.split("/")) os.makedirs(os.path.dirname(p), exist_ok=True) with open(p, "w", encoding="utf-8") as fh: fh.write(body) # 1. 停止直後（パッチ適用前）に基準を取る put("index.php", " BIG: print("大きな応答", t.isoformat(), ip, path, int(size) // 1024 // 1024, "MB") for ip, ts in errors.items(): ts.sort() for i in range(len(ts) - 2): if (ts[i + 2] - ts[i]).total_seconds() <= 60: print("500の連発", ts[i].isoformat(), ip, "60秒以内に3回以上") break ``` 同じ環境での実行結果です。ログは説明用に作ったもので、野村IRの記録ではありません。 ``` 追加PHPへのアクセス 2026-10-21T23:42:02+09:00 203.0.113.9 /uploads/cache_7f.php 大きな応答 2026-11-01T02:05:44+09:00 192.0.2.30 /admin/export.php?all=1 18 MB 500の連発 2026-10-21T23:41:10+09:00 203.0.113.9 60秒以内に3回以上 ``` 同じ送信元から60秒以内に500が3回続き、その1分後に追加されたPHPファイルへアクセスがあった、という並びが見えます。エクスポート機能の18MBの応答は、件数を絞らない一括取得の形です。エクスポートは件数の上限と送信元ごとの回数制限を入れておくと、持ち出しの量を抑えられます。考え方は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)のレート制限の章と同じです。ログに応答サイズや要求の種類が残っていなければ、この点検自体ができません。 ## 同じサーバーに同居するサービスの扱い：MIR＠Iの予防停止から考える分離 ### 同居サービスを予防的に止める判断と、止めずに済む分離構成の条件 野村IRは、不正アクセスが確認されていないMIR＠Iも、同じサーバー上で稼働していることを理由に止めました。同じOSの上で動くサービスは、片方で任意のコードを実行されれば、もう片方のファイルや設定、データベースの接続情報にも届く可能性があります。調査が終わるまで止めるのは、同居している限り妥当な判断です。 止めずに済ませるには、サービスごとにサーバー（またはコンテナと実行ユーザー）、データベースのアカウント、秘密情報の保管先が分かれている必要があります。どれか1つでも共有していれば、同居とみなして一緒に停止する判断が必要です。利用者層が違うサービス、たとえば機関投資家向けと個人投資家向けを同じサーバーに載せる構成は、障害時に巻き込む範囲を広げます。 ### 再開を見送る条件と、外部の脆弱性診断・フォレンジック調査に回す範囲 再開を見送るのは、基準のハッシュが無くて改ざんを判定できない、アクセスログが停止前の期間を覆っていない、追加ファイルの出どころを説明できない、のどれかに当たる場合です。この状態で再開すると、残っている侵入口をそのまま公開に戻すことになります。基準が無いなら、リリース時の成果物から作り直したサーバーへ載せ替えてから再開します。 痕跡が見つかった場合は、ログとディスクを保全したうえで[フォレンジック調査](https://www.issoh.co.jp/column/details/2812/)に回します。痕跡が見つからなかった場合も、再開の前に、修正版の適用漏れや管理画面の公開範囲を第三者に確かめてもらうことは、再開判断のためにも有用です。PHPで動く自社サービスの再開前の点検を外部に任せたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 野村IRの機関Naviの不正アクセスについて、登録者・説明会の主催企業・サービスを運用する側から出やすい質問をまとめました。 ### 機関Naviの不正アクセスで、自分が対象かどうか確かめる方法はありますか？ 2026年11月4日の公表文の時点では、利用者が自分で対象かどうかを確かめる手段は示されていません。調査の対象には過去に登録した人の情報も含まれ、同社は漏えいの対象であることが確認された人に案内するとしています。気になる場合は、公表文に載っている不正アクセス対応窓口（03-3276-3603、土日祝日を除く9時〜17時）か問い合わせフォームで問い合わせます。 ### 機関Naviから漏れた情報には何が含まれますか？ 公表文は、漏えいした情報の内容について「氏名やメールアドレス等が含まれる可能性があり、現在調査中」としています。件数と項目の確定は公表されていません。機関Naviは決算説明会の情報提供と出席管理のサービスなので、説明会への申込や出席の記録も同社が持つ情報です。それらが漏えいの範囲に入るかどうかは、11月4日の時点では公表されていません。 ### MIR＠Iの会員情報も漏えいしたのですか？ MIR＠Iは、機関Naviと同じサーバー上で稼働していたため予防的措置として停止されました。MIR＠Iへの不正アクセスの有無は調査中で、漏えいが確認されたとは公表されていません。会社説明会の参加方法は別途メールで案内されるため、届いたメールの内容を公式サイトのニュース一覧の告知と照らしてから手続きします。 ### 野村IRの不正アクセスの原因はPHPの脆弱性ですか？ 原因と侵入の経路は公表されていません。野村IRは10月21日にPHPの重大な脆弱性への対応としてサービスを止め、10月28日に修正プログラムの適用と緊急点検を終えて再開しました。その後の11月2日に不正アクセスを確認していますが、両者の関係は公表文に書かれていないため、現時点で結び付けることはできません。 ### PHPの修正版を入れたら、すぐにサービスを再開してよいですか？ 修正版は脆弱性を塞ぎますが、適用前に設置されたWebシェルや追加されたアカウントは消しません。JPCERT/CCの注意喚起も、異常なPHPSESSID、不審な要求の前後の500、ワーカーの異常終了などの痕跡確認を求め、痕跡が無くても攻撃を受けていないとは断定できないとしています。停止直後に取ったファイルのハッシュとの突き合わせと、停止前後のログの点検を済ませてから再開します。 ## 関連記事 - [NTTデータ委託先の情報漏洩：デジタル特典付き社債の対象確認と委託先に渡す項目の棚卸し](https://www.issoh.co.jp/tech/details/19229/)：同じ時期に証券・投資家の情報が委託先経由で漏れた事案 - [ユミルリンク不正アクセス第二報で延べ5,162万件：DCM・さとふる等の利用企業と受信者の確認点](https://www.issoh.co.jp/tech/details/18689/)：野村證券のi-Portも利用していたメール配信基盤の事案 - [PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版、悪用の実態と更新できない場合の設定【2026年10月】](https://www.issoh.co.jp/tech/details/18738/)：10月21日に公表されたPHPの脆弱性の版と設定の確認 - [Webシェルとは？仕組み・代表例と検知・除去の手順をTomcat・PHP・IISのコマンド例で解説](https://www.issoh.co.jp/tech/details/18314/)：改ざん確認で見つかったファイルの調べ方 - [フォレンジック調査とは？種類・流れ・費用の実額と調査会社の選び方](https://www.issoh.co.jp/column/details/2812/)：痕跡が見つかった後の調査の依頼先 --- 出典: [野村IRの機関Navi不正アクセス：漏えいの範囲と、PHP脆弱性対応後の再開前に確かめる改ざんとログ]()（株式会社一創）