Integral Security Reportインテグラル セキュリティ レポート
← 一覧に戻る
2026-moneyforwardIT/クラウド最終確認 2026-10-13 10:00

マネーフォワードへの不正アクセス(GitHub認証情報の漏えいでリポジトリがコピー、従業員2,300名分・顧客識別子60,449名分などの個人データ流出の可能性、銀行口座連携を約5週間停止)

公表日

株式会社マネーフォワード · 上場
最終報不正アクセス認証情報悪用

家計簿・会計サービスのマネーフォワードで、開発に使うGitHubのログイン情報が漏れ、プログラムなどの保管場所が第三者にコピーされました。顧客・従業員など最大約6.3万人分の情報が流出したおそれがあり、銀行口座との連携機能が約5週間止まりました。

対象者は?

流出したおそれがあるのは、顧客124人と取引先28人の氏名またはメールアドレス、従業員(退職者を含む)2,300人の氏名・メールアドレス・電話番号など、顧客60,449人分の管理用の番号(氏名などを含まず、それだけでは個人を特定できないとされる番号)です。これとは別に、マネーフォワード ビジネスカードの保持者370件のカード名義(ローマ字)とカード番号の下4桁も対象です。合計は最大約6.3万人分で(重複があればこれより少なくなります)、流出が確認されたわけではありません。カード番号の全桁、有効期限、セキュリティコードの流出は確認されておらず、銀行などのログイン情報はプログラムに含まれていなかったとされています。

対象の方には、メールなどで個別に案内が行われています。詳しい内容は第四報とよくある質問(FAQ)で確認できます。

いますぐできること

  • マネーフォワードを名乗るメールのリンクは開かず、公式アプリや公式サイトから確認する
  • 銀行によっては口座連携の再設定が必要なため、アプリで連携が止まったままの口座がないか確認する

何が起きたのか

2026年5月1日、マネーフォワードは、ソフトウェアの開発や管理に使う「GitHub」のログイン情報が漏れ、第三者にプログラムなどの保管場所(リポジトリ)をコピーされたと発表しました。コピーされたファイルの中には、本来そこに置くべきではなかった個人情報を含むファイルも、作業の途中で誤って保管されていました。会社は安全を確かめるため、マネーフォワード MEとマネーフォワード クラウドの銀行口座連携を止めました。連携は5月12日から順次再開し、6月5日にすべての銀行で再開しました。6月23日に調査を終え、流出のおそれがある個人データの内訳を発表しました。

なぜ起きたのか・なぜ広がったのか

GitHubのログイン情報が漏れたことが発端です。どんな種類のログイン情報が、どこから、いつ漏れたのかは公表されていません。個人情報を含むファイルが、サービスの更新作業の中で管理の手順から外れ、プログラムと同じ場所に保管されていたため、プログラムと一緒にコピーの対象になりました。銀行口座の連携まで止まったのは、プログラムの中に認証キーやパスワードも含まれており、安全を確かめる必要があったためです。

いまの状況2026-06-23 時点

利用者の情報が保存されている本番のデータベースへの侵入はなかったとされています。銀行口座連携は6月5日にすべて再開し、マネーフォワード ME の有料会員には利用期間を15日間延ばす対応がとられました。会社は、ログイン情報の管理ルールの見直し、業務用パソコンの管理強化、許可していない外部サイトやクラウドサービスへの接続を止める仕組みの導入などを進めるとしています。個人情報保護委員会や金融庁などへの確定報告も提出しました。

企業として考えたいこと

自社の開発者が使うGitHubなどの保管場所に、お客様の情報やパスワードが紛れ込んでいないか、確かめたことはあるでしょうか。

技術的な要約

マネーフォワードは2026年5月1日、ソフトウェア開発・システム管理に使うGitHubの認証情報が漏えいし、第三者の不正アクセスでリポジトリがコピーされたと公表した(第一報)。第一報では、リポジトリ内のファイルに含まれていたマネーフォワード ビジネスカード保持者370件のカード保持者名(アルファベット)とカード番号下4桁が流出した可能性があるとし、銀行法上の電子決済等代行業者としての安全確認のため、マネーフォワード ME・クラウドの銀行口座連携機能を一時停止した。5月3日には個人情報を含むファイルがサービス更新作業の過程で管理手順から外れ誤ってGitHubに保管されていたと説明し、5月11日の第二報で個人情報保護委員会への速報、関東財務局等への報告、警察署への相談、全社的な認証情報の刷新を公表。口座連携は5月12日から順次再開し、6月5日10時50分に全銀行で再開した。6月23日の第四報で精査を完了し、流出の可能性がある個人データを顧客124名・取引先28名・従業員(退職者含む)2,300名の氏名・メール等と、顧客60,449名分の固有識別子(単体で個人を特定できない最大19桁の管理用番号)と公表、個人情報保護委員会と金融庁等へ確定報告を提出した。本番データベースへの侵害はないとされ、認証情報の種類・漏えい経路・不正アクセスの日時は最後まで公表されていない。

侵入
—
被害発生
—
検知
—
第1報公表
2026-05-01
最新続報
2026-06-23
侵入 → 検知
—
侵入日が非公表
検知 → 公表
—
データ(上限)
6.3万人
確定 —
波及先
—

攻撃の分類

侵入口
認証情報窃取・流用公表で確認
公式(5/1第一報、原文確認):『ソフトウェア開発・システム管理に利用する『GitHub』の認証情報が漏えいし、第三者による不正アクセスが発生』し、リポジトリがコピーされた。経路となった認証情報は無効化しアカウントを遮断。認証情報の種類(PAT、OAuthトークン、SSH鍵、パスワード等)、漏えい経路、不正アクセスの日時は第四報(6/23)まで一貫して非公表。第四報は『発端となった認証情報の漏えい』への再発防止策として『業務端末のセキュリティ統制の強化』と『認可されていない外部サイトやクラウドサービスへのアクセスをシステム的に遮断する通信統制基盤の導入』を挙げており、業務端末上で認証情報が窃取された、または未認可の外部サービスを経由して漏えいした可能性がうかがえるが、これは再発防止策からの推測で公表事実ではない。第二報はGitHub認証情報の発行・運用ルールを見直し最小権限へ移行したとしている。
脆弱性
CVE 非公表公表で確認
GitHub認証情報(種類非公表)
ソフトウェアの脆弱性ではなく認証情報の漏えい(公式)。被害を広げた要因として、ソースコードに各種認証キー・パスワードが含まれていたこと(第一報で無効化・再発行を表明)、個人情報を含むファイルがサービス更新作業の過程で本来の管理手順から外れて誤ってGitHub上に保管されていたこと(5/3 Q&A)を公式が説明。金融機関のログイン情報はソースコードに含まれず、本番DBに暗号化して保存しているとする。
攻撃者
特定・主張なし
ATT&CK

影響

業務停止
あり 第一報(5/1)で、銀行法に基づく電子決済等代行業者としての責任と提携金融機関との安全性確認を理由に、マネーフォワード ME・マネーフォワード クラウドの銀行口座連携機能を一時停止。第二報(5/11)時点で再開時期未定。第三報(5/12)で最終確認が完了した金融機関から順次再開し、2026年6月5日10時50分に全銀行の連携が再開した(MEサポートサイト)。金融機関によっては再連携操作が必要とされた。その他のサービス停止は公表されていない。
期間:2026-05-01〜2026-06-05 10:50(5/12から順次再開、約5週間)
データ
おそれ上限 63,271確定 —人
氏名メール電話会員ID取引先情報従業員情報その他(カード番号下4桁)業務データ
第四報(6/23、原文確認)が示す『流出の可能性が判明した個人データ』:①顧客の氏名またはメールアドレス124名分(氏名100件・メール24件)、②取引先28名分(氏名5件・メール23件)、③従業員(退職者含む)2,300名分(システム上の固有識別子373件・氏名490件・メール1,807件・電話番号305件。人数は名寄せ後)、④顧客の固有識別子60,449名分(最大19桁の管理用番号。ユーザーIDとは異なり氏名・メールを含まず、単体で個人を特定できないとされる)。別に第一報(5/1)がマネーフォワード ビジネスカード(発行:マネーフォワードケッサイ)保持者370件のカード保持者名(アルファベット)・カード番号下4桁の流出可能性を公表(カード番号全桁・有効期限・CVVの流出は未確認)。第四報本文は370件に触れておらず、①〜④との重複関係は非公表。records_max は ①〜④(62,901名)に370件を単純加算した上限値 63,271 で、重複があれば実数はこれより少ない。合計値は公式には記載されていない。会員IDは④の固有識別子を指す。ほかにソースコードと各種認証キー・パスワード(業務データ)がコピーされた。本番DBへの不正アクセス・本番環境からの漏えい・二次被害はないとされる。
波及先
—
  • マネーフォワード ME・マネーフォワード クラウド利用者:銀行口座連携が5/1〜最長6/5まで利用不可
  • マネーフォワード ME プレミアムサービス利用者:購読期間を15日間延長(5/20決定、6/19に全員へ適用完了)
  • マネーフォワードケッサイ株式会社(ビジネスカード発行元)の保持者370件
金銭影響
マネーフォワード ME プレミアムサービス利用者の購読期間を15日間延長(5/20決定、6/15から順次適用し6/19完了)。第二報時点で補償等は『検討中』。特別損失・業績影響の金額は本調査で確認した公式発表には記載なし。
サプライチェーン
他組織のデータ漏えいへの波及は公表されていない。電子決済等代行業者として提携金融機関との安全性確認が必要になり、銀行口座連携を全面停止したため、連携先金融機関のデータ取得がME・クラウドの利用者側で約5週間できなかった(サービス影響、提携金融機関側の被害ではない)。ビジネスカード370件はグループ会社マネーフォワードケッサイの発行カードの情報。同時期のCAMPFIREのGitHub起点の事案や npm サプライチェーン攻撃との関連は公表されていない。

時系列

  1. 2026-05-01
    第一報『『GitHub』への不正アクセス発生に関するお知らせとお詫び(第一報)』。GitHub認証情報の漏えいで第三者がリポジトリをコピー、ビジネスカード保持者370件の氏名(アルファベット)・カード番号下4桁が流出した可能性。経路の認証情報の無効化・アカウント遮断は完了、ソースコード内の認証キー・パスワードの無効化・再発行は概ね完了。銀行口座連携機能を一時停止1311
  2. 2026-05-01 16:24
    マネーフォワード MEサポートサイトにお知らせを掲載(ソースコードの閲覧・コピー判明、本番DBからの漏えいは未確認、口座連携の一時停止)8
  3. 2026-05-03 13:00
    MEサポートサイトでQ&A公開・お知らせ追記。個人情報を含むファイルがサービス更新作業の過程で管理手順から外れ誤ってGitHubに保管されていたと説明。金融機関ログイン情報はソースコードに含まれず本番DBに暗号化保存、警察署・個人情報保護委員会等へ報告・相談中28
  4. 2026-05-07
    報道によれば複数の金融機関との口座連携停止が継続(innovaTopiaは5/7 18:30時点と記載。公式側で同時刻の記載は確認できず)34
  5. 2026-05-11
    第二報『調査進捗および銀行口座連携再開に向けた経過のご報告』。本番DBの漏えい・侵害なしを確認、個人情報保護委員会へ速報、関東財務局等の監督官庁へ報告、警察署へ相談開始、外部セキュリティコンサルによる第三者評価、全社的な認証情報の刷新、最小権限化・機密情報の自動検知・開発環境のリアルタイム監視を実施。補償は検討中5812
  6. 2026-05-12
    第三報『銀行口座連携の順次再開に関するお知らせ』。最終確認が完了した金融機関から口座連携を再開68
  7. 2026-05-20 14:00
    ME プレミアムサービス利用者の購読期間を15日間延長することを決定(MEお知らせ追記)8
  8. 2026-06-05 10:50
    すべての銀行の口座連携が再開(6/9追記で公表)28
  9. 2026-06-19 15:30
    プレミアム購読期間延長を全顧客へ適用完了(6/15から順次適用)8
  10. 2026-06-23
    第四報『GitHubへの不正アクセスに関する詳細調査の完了およびセキュリティ対策強化のお知らせ』。流出可能性のある個人データを顧客124名・取引先28名・従業員2,300名・顧客固有識別子60,449名分と公表、個人情報保護委員会と事業所管大臣(金融庁等)へ確定報告を提出。業務端末の統制強化と通信統制基盤の導入を表明78910

技術解説

攻撃の構造:リポジトリが『データ置き場』と『鍵束』を兼ねていた 事実

公式発表によれば、攻撃者は漏えいしたGitHub認証情報でリポジトリにアクセスし、コピーした。被害は二つの性質を持つ。一つは個人情報で、第一報はビジネスカード保持者370件の氏名(アルファベット)とカード番号下4桁、第四報は顧客124名・取引先28名・従業員2,300名の氏名・メール等と顧客60,449名分の固有識別子を挙げた。これらは5/3の説明どおり、サービス更新作業の過程で本来の管理手順から外れてリポジトリに置かれていたファイル等に含まれていた。もう一つはソースコード内の認証キーとパスワードで、同社は第一報で無効化・再発行を『概ね完了』とし、第二報で全社的に認証情報を刷新したとした。金融機関のログイン情報はソースコードに含まれず本番DBに暗号化保存されており、本番DBへの侵害はないと第二報・第四報で確認している。認証情報の種類・漏えい経路・侵入日時は公表されていない。

本番DBが無事でも金融連携が5週間止まった 事実

同社は第一報と同時に、銀行法に基づく電子決済等代行業者としての責任と提携金融機関との安全性確認を理由に、ME・クラウドの銀行口座連携を全面停止した。第二報(5/11)で外部セキュリティコンサルの第三者評価により本番DBへの侵害がないこと等の妥当性を確認したとし、第三報(5/12)で最終確認が取れた金融機関から順次再開、全銀行の再開は6月5日10時50分だった。停止期間は約5週間に及び、MEプレミアム利用者には購読期間15日延長の措置が取られた。本番環境の顧客データが漏れていなくても、開発基盤の侵害だけで、金融機関側の確認手続きを含めた再開までに長期間を要したことが公表資料から読み取れる。

件数は小さいが講義上の重要度は高い理由 解釈

個人データの件数(最大でも約6.3万名分、うち6万件は単体で個人を特定できない識別子)や項目だけを見れば中規模以下の事案だが、起点が開発基盤の認証情報である点で、CAMPFIRE事案と同じ型に属する。リポジトリにアクセスできる認証情報は、ソースコードの閲覧にとどまらず、コード内のシークレットを通じて本番環境・外部連携先への到達経路になりうる。本件では同社が全社的に認証情報を刷新し、利用者向けの主要機能(銀行口座連携)を約5週間止めることになり、シークレット漏えいの後始末が実サービスの可用性に直接響いた。第一報で再発行が『概ね完了』と表現されたことは、ローテーション対象の洗い出しに時間を要した可能性、つまり平時からシークレットの所在と依存関係を把握する仕組みが十分でなかった可能性を示している(解釈)。

公表の評価:4報で何が分かり、何が残ったか 解釈

同社は5/1の第一報から6/23の第四報まで、コーポレートサイトの4報とMEサポートサイトの追記・Q&Aで、停止・再開状況を時刻つきで更新し、当局(個人情報保護委員会の速報・確報、関東財務局・金融庁、警察)への対応、外部の第三者評価、件数の区分別内訳(名寄せ後の人数と項目別件数)まで開示した。利用者の行動(パスワード変更は不要)も明示しており、再開までの情報提供は丁寧である。一方、漏えいした認証情報の種類、漏えい経路、侵入日時、コピーされたリポジトリの範囲は最後まで示されず、第四報の再発防止策(業務端末の統制、未認可の外部サイト・クラウドへの通信遮断)から経路を推し量るしかない。第一報の370件と第四報①〜④の関係も説明がなく、同種の開発基盤を持つ他社が自社の対策の妥当性を検証する材料としては不足が残る(解釈)。

対応

封じ込め
不正アクセスの経路となった認証情報を無効化しアカウントを遮断(第一報で完了)。ソースコード内の認証キー・パスワードを無効化・再発行し(第一報で概ね完了)、第二報で流出の可能性があるアラート通知等の認証情報を含め全社的に刷新、流出の可能性があるソースコードのセキュリティ検査を再実施。予防措置として銀行口座連携を5/1に停止し、外部セキュリティコンサルの第三者評価と提携金融機関の最終確認を経て5/12から順次再開、6/5 10:50に全銀行再開。再発防止策:GitHub認証情報の発行・運用ルール見直しと最小権限化、リポジトリ保存時の機密情報自動検知、本番環境の24時間監視に加え開発環境のリアルタイム監視(第二報)、業務端末のセキュリティ統制強化、未認可の外部サイト・クラウドサービスへのアクセスを遮断する通信統制基盤の導入、開発環境での個人情報取り扱い体制の整備と教育(第四報、外部専門機関の評価を踏まえ実施)。
公表の仕方
コーポレートサイトで5/1第一報、5/11第二報、5/12第三報(口座連携の順次再開)、6/23第四報(詳細調査の完了)。MEサポートサイトでお知らせ(5/1 16:24作成、6/23まで7回追記)とQ&A(5/3公開、6/9最終更新、6/23に更新終了)、第四報のFAQを掲載。対象者にはメール等で個別に案内済み。認証情報の種類・漏えい経路・侵入日時は非公表。
当局対応
  • 個人情報保護委員会:速報(第二報5/11時点で実施)、確定報告(6/23)
  • 監督官庁(関東財務局ほか):事象の発生と調査状況を報告(5/11)、事業所管大臣(金融庁等)へ確定報告(6/23)
  • 警察:管轄警察署へ相談開始(5/11)

教訓と対策

教訓具体的な対策
GitHubの認証情報が漏えいし、リポジトリが丸ごとコピーされたOrganizationで classic PAT を禁止し、fine-grained PAT は承認制・対象リポジトリ限定・短期有効期限に制限する。SAML SSO と IP 許可リストを有効化し、GitHub 監査ログの git.clone / repo.download_zip とトークン認証元IPを SIEM に転送して、通常と異なる大量クローンをアラート化する。
ソースコード内に認証キー・パスワードがあり、全件の再発行が必要になったSecret Scanning と Push Protection を全リポジトリで有効化し、既存履歴は gitleaks 等で棚卸しする。アプリのシークレットは AWS Secrets Manager / GCP Secret Manager / Vault 等に移し、コードには参照名だけを置く。シークレットごとの所有者・利用箇所・ローテーション手順を台帳化し、漏えい時に即日全件ローテーションできることを演習で確認する。
個人情報を含むファイルが、更新作業の過程で手順外にリポジトリへ置かれていた本番データのエクスポート先を専用の暗号化ストレージに限定し、開発環境・リポジトリへの持ち込みを禁止する。pre-commit/CI で CSV・ダンプファイルやカード番号・氏名パターンを検出するチェックを入れ、テストには合成データを使う。
鍵の失効が利用者向け機能(銀行口座連携)の停止に直結した外部連携の認証情報は連携先ごと・環境ごとに分離し、デュアルキー運用(新旧キーの並行有効化)で無停止ローテーションできる設計にする。連携先金融機関との再発行手続きのリードタイムを事前に確認しておく。
第四報の再発防止策は、認証情報の漏えいが業務端末や未認可の外部サービスに起因した可能性を示している開発者端末にEDRと端末管理(MDM)を必須化し、ブラウザ保存資格情報やgit credential helper に平文トークンを残さない運用にする。SWG/CASB で未認可のSaaS・ペーストサイト・AIサービスへの送信を遮断または監査し、GitHub トークンはデバイス紐付け・短期有効の発行に限定する

自組織などでの確認項目

  1. あなたの会社のリポジトリが今日すべてコピーされたと仮定したとき、失効・再発行が必要なシークレットは何件あり、全件を何時間で入れ替えられるか。その間に止めなければならない機能はどれか。
  2. 本番データのダンプやCSVが、作業の都合でリポジトリやチャット、個人端末に置かれていないことを、どの仕組みで保証しているか。
  3. 370件・下4桁という『小さな』漏えいの段階で公表し、主要機能の口座連携を約5週間止めた判断を、あなたの組織ならどう下すか。件数より起点(開発基盤の侵害)を重視すべきなのはなぜか。

未解明点

  • 漏えいしたGitHub認証情報の種類(PAT、OAuthトークン、SSH鍵、パスワード等)と漏えい経路(業務端末か外部サービスか)
  • 不正アクセスの発生日時と検知の経緯
  • コピーされたリポジトリの範囲と、含まれていた認証キー・パスワードの種類(本番環境・金融機関連携に関するものを含むか)
  • 第一報のビジネスカード370件と第四報の①〜④(顧客124名等)との重複関係
  • 補償の最終的な内容と特別損失等の財務影響
  • 同時期のCAMPFIREのGitHub起点の事案や、npm(axios等)サプライチェーン攻撃との関連の有無

出典

  1. 1
    株式会社マネーフォワード2026-05-01公式本文確認済
  2. 2
    株式会社マネーフォワード(マネーフォワード MEサポートサイト)2026-05-03公式本文確認済
  3. 3
  4. 4
  5. 5
  6. 6
    株式会社マネーフォワード2026-05-12公式本文確認済
  7. 7
  8. 8
    株式会社マネーフォワード(マネーフォワード MEサポートサイト)2026-05-01公式本文確認済
  9. 9
    株式会社マネーフォワード(マネーフォワード MEサポートサイト)2026-06-23公式本文確認済
  10. 10
  11. 11
  12. 12