MoneyFowardがやられただと？それもGitHubだと〜少しだけ個人情報も漏れた

2026年5月2日

マネフォのソースが盗まれた

MoneyFowardはME有料契約しています。確定申告などには使っていませんが、資産管理の目的で結構つかっています。MoneyFowardのデータが漏れると私の情報もやばいです。

でもまあ、GitHubがやられたのなら、データは漏れてないか・・・と思ったら

漏れてんのかーい！

当社がソフトウェア開発およびシステム管理に利用している『GitHub』の認証情報が漏えいし、これを用いた第三者による不正なアクセスが発生し、『GitHub』内の「リポジトリ」がコピーされたことが判明しました。

現時点において、ソースコードおよび、リポジトリに含まれていたファイル内に記載されていた個人情報の一部が流出した可能性があることを確認しております。なお、流出したソースコードおよび個人情報の不正利用等による被害や、お客さま情報を格納している本番データベースからの情報漏えいは確認されておりません。

たら、もれたのは370件のカード情報などとなっていました。サンプルデータとして使っていたくらいのデータが漏れたのでしょうか？　本番DBからは漏れていないということなので、多くのユーザは大丈夫ということでしょうか。

ただソースコードの類は一切合切漏洩したでしょうから、今後攻撃する側からしても、ソース情報見ながらできるから、今後の継続的な攻撃は心配になりますね。

以下DeepResearchです。

事件の概要

日本のフィンテック業界を牽引する株式会社マネーフォワードが2026年5月1日に公表した、ソースコード管理プラットフォーム「GitHub」への不正アクセス事案は、現代のソフトウェア開発ライフサイクル（SDLC）に潜む構造的な脆弱性を浮き彫りにした。本件は、単なる一企業のセキュリティ事故にとどまらず、銀行法に基づく電子決済等代行業者としての責任、サプライチェーン・セキュリティの限界、そして開発プロセスにおける機密情報管理の在り方について、業界全体に極めて重要な示唆を与えている。本報告書では、2026年に発生した事案の詳細を中心に、2021年のCodecov事案からの教訓、技術的背景、規制当局への対応、そして今後の再発防止策について、専門的な見地から網羅的に分析する。

2026年GitHub不正アクセス事案の全容とタイムライン

2026年5月1日、マネーフォワードは自社およびグループ会社が利用するGitHubの認証情報が漏洩し、第三者によってリポジトリが不正にコピーされたことを公表した 。この事案の核心は、開発の中枢であるソースコードそのものが外部に流出した可能性が高いという点にある。

事象の発生と検知

公式発表および関連報道を統合すると、事案の端緒はGitHub上の認証情報の悪用による異常なアクセスであった 。GitHubは開発者がプログラムの「設計図」を共有・管理するための基盤であり、ここに不正アクセスが行われることは、システムの全容が攻撃者の手に渡ることを意味する。

日付	段階	対応内容
2026年4月6日以前	発生	何らかの経路でGitHubの認証情報（PAT等）が外部に漏洩 。
2026年4月6日	検知	システム内の異常なアクセスを検知し、即座にアカウント遮断および調査を開始 。
2026年4月8日	法的報告	個人情報保護委員会および所轄警察署への報告を実施 。
2026年5月1日	第一報公開	公式サイトおよびプレスリリースにて、GitHubへの不正アクセスと情報流出の可能性を公表 。
2026年5月1日	緊急措置	銀行口座連携機能の一時停止、およびソースコード内シークレットの刷新を概ね完了 。

このタイムラインから読み取れるのは、検知から公表までに約1ヶ月の調査期間を設けている点である。これは、2022年4月に施行された改正個人情報保護法が求める「速報」と「確報」の義務に基づき、全容解明と二次被害防止のための技術的対策（シークレットの洗い替え等）を優先した結果と考えられる 。

漏洩した情報の精査

流出した可能性のある情報は、大きく分けて「ソースコード一式」「特定の個人情報」「ソースコード内の認証キー」の3点に分類される 。

特に懸念されたのが、子会社であるマネーフォワードケッサイ株式会社が提供する「マネーフォワード ビジネスカード」に関する情報の流出である。具体的な対象件数は370件であり、以下の項目が含まれていた 。

• カード保持者名（アルファベット表記）
• クレジットカード番号の下4桁

同社は、カード番号の全桁、有効期限、セキュリティコード（CVV）、および顧客情報を格納する本番データベースそのものへの侵入については、現時点で確認されていないと明言している 。しかし、名前と下4桁の組み合わせは、フィッシング詐欺やなりすましメールにおいて、受信者を信用させるための強力な武器となり得るため、370件という数字以上に深刻なリスクを孕んでいる 。

技術的分析：認証情報の漏洩経路とソースコード内の課題

GitHubへの不正アクセスが成功した背景には、現代のエンジニアリング環境特有の脆弱性が存在する。2FA（二要素認証）が標準化されている現在においても、なぜ認証情報は突破されたのか。

認証情報の窃取メカニズム

GitHubの認証には、Web画面からのログイン（ID/パスワード/MFA）以外に、プログラムや開発ツールが利用するパーソナルアクセストークン（PAT）やSSH鍵が用いられる。これらの「非対話型」認証情報は、一度発行されると長期間有効である場合が多く、攻撃者にとって格好の標的となる 。

想定される漏洩経路は多岐にわたるが、専門家の分析によれば以下の4つの仮説が有力である 。

1. 開発者PCのマルウェア感染（Infostealer）: 近年、160億件以上のパスワードがダークウェブで流通している背景には、Infostealerと呼ばれるマルウェアの存在がある 。開発者のPCが感染し、ブラウザのセッションCookieや、ローカルに保存されていたPAT、SSH秘密鍵が抜き取られた可能性である 。
2. サードパーティ連携の侵害: CircleCIやCodecovのような、GitHubと密接に連携する外部サービスの認証情報が、それ自体の脆弱性によって漏洩し、連鎖的にGitHubリポジトリへアクセスされたケースである 。
3. フィッシング・プロキシ: 巧妙に偽装されたGitHubのログインページを経由させ、2FAトークンまでリアルタイムで中継してセッションを奪取する攻撃手法（Adversary-in-the-Middle）の可能性も否定できない 。
4. 誤コミットと履歴の残留: 過去のコミットにおいて、誤って認証情報を含む設定ファイルをプッシュし、後に削除したものの、Gitの履歴（History）には残っていた情報を攻撃者がスキャンして発見した可能性である 。

ソースコード内のシークレットとテストデータの問題

本件において、ソースコードの流出と並んで深刻視されたのが、リポジトリ内に「各種認証キー・パスワード」が含まれていたこと、および「370件のカード情報」が存在していたことである 。

本来、AWSのアクセスキーやデータベースのパスワードなどのシークレットは、GitHub SecretsやAWS Secrets Managerなどの専用サービスで管理し、ソースコードには変数名のみを記述するのがベストプラクティスである 。しかし、開発の利便性や「内部リポジトリだから安全である」という過信から、ハードコード（直接記述）が行われてしまう実態がある 。攻撃者がリポジトリをコピーした際、これらのキーも同時に手にすることになるため、ソースコード流出はインフラ全体への侵入の「前置詞」となるリスクを孕んでいる 。

また、370件のカード情報がリポジトリ内に存在していた点については、CI/CD（継続的インテグレーション/デリバリー）におけるテストデータとしての流用が疑われている 。開発過程で、本番環境に近いデータを用いて動作確認を行う際、匿名化（仮名化）が不十分なままテスト用のフィクスチャファイルとしてコードに含めてしまった可能性が高い 。これは、データの最小化原則および開発環境と本番環境の厳格な分離という、金融機関が守るべきデータガバナンスの欠如を示唆している 。

2021年Codecov事案との比較：サプライチェーン攻撃の進化

マネーフォワードの事案を理解する上で、2021年に発生したCodecovのサプライチェーン攻撃との比較は不可欠である。この比較により、攻撃者が狙うポイントが「完成された製品」から「製品を作るための道具」へとシフトしていることが明確になる。

Codecov事案のメカニズムと教訓

2021年1月、コードカバレッジツールを提供するCodecovのインフラが侵害され、顧客がダウンロードする「Bash Uploader」スクリプトに悪意のあるコードが混入された 。このスクリプトは、顧客のCI環境（GitHub Actionsなど）で実行される際、環境変数（Environment Variables）を攻撃者のサーバーへ送信するように書き換えられていた 。

比較項目	2021年 Codecov事案	2026年 マネーフォワード事案
攻撃の種類	サプライチェーン攻撃（ツールの汚染）	認証情報窃取による直接的なリポジトリ侵害
流出の対象	CI環境の環境変数（各種トークン等）	ソースコード一式、一部個人情報、埋め込みシークレット
影響範囲	世界中のCodecov利用者（メルカリ等含む）	マネーフォワードグループおよび一部顧客
侵入の起点	公開Dockerイメージ内の古い認証情報	不明（PATの漏洩またはセッション奪取が濃厚）

2021年の事案では、メルカリなどの日本企業も影響を受け、ソースコードの一部が流出する事態となった 。この時も、流出した環境変数に含まれる認証情報を悪用してリポジトリがクローンされており、2026年の事案と「リポジトリの複製」という結果において共通している 。

Codecov事案からの最大の教訓は、「信頼しているツールであっても、CI環境での権限は最小化すべきである」という点だった 。しかし、2026年の事案は、外部ツールの汚染がなくとも、開発者個人の認証情報が一点突破されるだけで、サプライチェーン全体が崩壊するリスクを改めて突きつけたと言える 。

銀行法と個人情報保護法に基づく法的・社会的責任

マネーフォワードは単なるソフトウェア企業ではなく、銀行法上の「電子決済等代行業者」であり、高度な公共性と安全性が求められる立場にある 。

電子決済等代行業者としての判断

事案発覚後、マネーフォワードが取った最も重い決断の一つが「銀行口座連携機能の一時停止」である 。この措置は、ユーザーの利便性を一時的に大きく損なうものであるが、フィンテック企業としての信頼を守るためには避けて通れないものであった。

1. 整合性の確認: ソースコードが流出したことで、銀行と接続するためのAPI仕様やクライアントシークレットが漏洩した可能性がある。安全性が確認されるまで通信を継続することは、提携銀行側のシステムにまでリスクを波及させる恐れがある 。
2. 規制への準拠: 銀行法に基づき、電子決済等代行業者は委託先管理やセキュリティ管理について厳しい基準が課されている。不正アクセスの経路が不明な段階でのサービス継続は、善管注意義務違反に問われる可能性がある 。
3. 透明性の確保: 第一報において「本番DBの漏洩は確認されていない」としながらも、あえて連携を止めたことは、同社が「安全性確認を万全にする」という姿勢をステークホルダーに示すメッセージとなった 。

改正個人情報保護法と速やかな公表

2022年4月に施行された改正個人情報保護法では、個人データの漏洩が発生し、個人の権利利益を害するおそれが大きい場合に、個人情報保護委員会への報告と本人への通知が法的義務となった 。

特に「不正アクセスによる漏洩」は、件数に関わらず報告義務が発生する 。マネーフォワードは5月1日の発表時点で、対象となる370名のビジネスカード保持者に対して個別の連絡を開始しており、法的な要件を迅速に満たしている 。過去のインシデント事例（CAMPFIRE等）では、初動の過小評価が後に被害規模の拡大を招き、社会的批判を浴びたケースがある 。今回のマネーフォワードの対応は、全容解明前であっても「わかっていること」を公表し、速やかに注意喚起を行うという、現代的なクライシス・マネジメントの型に従っている 。

再発防止策の多角的アプローチ：DevSecOpsの再構築

事案の収束に向けた次のステップは、物理的な対策とプロセス、そして組織文化の三位一体となった再発防止策の構築である。同社が公表した対策案および専門家による提言を軸に、今後の展望を詳述する。

短期的な技術的対策：シークレット管理の自動化

不正アクセスの経路となった認証情報の無効化およびアカウントの遮断は完了しているが、これだけでは不十分である。ソースコードが一度クローンされた以上、そこに記載されていた全てのキーは「汚染された」ものとして扱う必要がある 。

対策項目	具体的な手法	目的
シークレットの刷新	ソースコードに含まれる全認証キー・パスワードの再発行（洗い替え） 。	盗まれたキーを用いた二次的な侵入を防ぐ。
スキャンツールの導入	GitleaksやTruffleHogのCI/CD組み込み 。	将来的なハードコードのプッシュを未然に防ぐ。
GitHub Push Protection	GitHub標準のプッシュプロテクション有効化 。	サーバーサイドでシークレットのコミットを拒否する。
IP制限の強化	GitHubへのアクセスを社内VPNや特定の固定IPに限定 。	認証情報が盗まれても、攻撃者の環境からのアクセスを遮断する。

特に、Gitleaksをpre-commitフックとして活用することは、エンジニアがコミットする瞬間にローカル環境で警告を出し、プッシュを阻止できるため、非常に効果が高い 。また、過去の全履歴をスキャンし、秘密裏に残っている「古い鍵」を見つけ出して無効化することも、今回の事案のようなリポジトリ複製攻撃に対する強力なカウンターとなる 。

長期的な構造改革：Zero Trust Developmentへの移行

今回の事案が突きつけた根本的な問いは、「GitHubに機密情報を置いてよいのか」という点である。これに対する現代的な回答が、OpenID Connect (OIDC) による「シークレットレス」な認証への移行である 。

1. OIDCの活用: GitHub ActionsからAWSやGCPのリソースにアクセスする際、静的なアクセスキーをGitHub Secretsに保存するのではなく、GitHubが発行するIDトークンを用いて、クラウドプロバイダーから一時的な（短時間の）認証情報を取得する仕組みである 。これにより、万が一GitHubの認証情報が漏洩しても、クラウド側の操作に必要な長期シークレットが盗まれるリスクが消滅する 。
2. 最小権限の原則（Least Privilege）: 開発者が利用するPATの有効期限を最短化し、必要なリポジトリにのみアクセスできる「細粒度（fine-grained）」トークンを強制する運用が求められる 。
3. テストデータの非識別化の仕組み化: 開発環境で本番類似データが必要な場合、手動でデータを持ち込むのではなく、Faker等のライブラリを用いた「合成データ生成」を開発フローに組み込む。これにより、万が一コードが流出しても、個人情報の流出を構造的に防ぐことができる 。

組織文化と教育

技術的な対策を施しても、最終的にはそれを利用する人間の意識がボトルネックとなる。フィッシング攻撃やソーシャルエンジニアリングに対する訓練は、もはや管理部門だけでなく、特権権限を持つエンジニアに対してより重点的に行われるべきである 。

特に、マネーフォワードのような金融サービス事業者においては、一人のエンジニアの不注意が数千万人のユーザーの資産に影響を与え得るという「重み」を、開発組織全体が共有する必要がある 。退職時やプロジェクト終了時の権限削除の徹底など、基本的な「アイデンティティ管理」のサイクルを、単なる事務手続きではなく、セキュリティの最優先事項として再定義することが求められる 。

結論とフィンテック業界への示唆

株式会社マネーフォワードのGitHub不正アクセス事案は、エンジニアリングの利便性と金融の安全性の間にある緊張関係を象徴する事件であった。370件という比較的限定された個人情報の流出に留まったことは、同社の初動の速さと、本番データベースの分離という基本的なセキュリティアーキテクチャが機能していたことを示している 。

しかし、ソースコードの流出は、将来的な攻撃に対する「地図」を敵に渡したに等しい。流出したコードに含まれていたロジックやAPI仕様、そして過去の履歴に残された断片的な情報は、長期にわたって潜在的なリスクとして残り続ける。同社が銀行連携を停止し、全認証キーを洗い替えるという「痛み」を伴う決断をしたことは、この不可逆的なリスクを重く受け止めた結果と言える 。

本件から、日本の全てのフィンテック企業が学ぶべき教訓は、以下の3点に集約される。

1. 「内側」は安全ではない: GitHubリポジトリを「安全な内側」と見なす時代は終わった。リポジトリ自体がいつ侵害されても良いように、ハードコードを廃絶し、OIDCへの移行を急ぐべきである 。
2. データガバナンスをコードに適用せよ: 個人情報がDBからではなく、コード（テストデータ等）から流出するリスクを正しく認識し、非識別化のプロセスをエンジニアリングの一部として標準化しなければならない 。
3. サプライチェーン全体での透明性: 外部プラットフォーム（GitHub）や連携先（提携銀行）との相互信頼を維持するためには、異常検知時の迅速な情報共有と、サービス停止を厭わない決断力が必要である 。

マネーフォワードが今後公表する調査の詳細と、より具体的な再発防止策の進捗は、日本のフィンテック・セキュリティにおける新たなスタンダードを形成することになるだろう。本事案を教訓として、開発とセキュリティがより高度に統合された「真のDevSecOps」へと昇華させることが、業界全体の信頼回復に向けた唯一の道である。

そんなところで