マネーフォワードGitHub不正アクセス事件｜銀行連携停止と侵入経路推測・対策まとめ

2026年5月1日、株式会社マネーフォワードは「『GitHub』への不正アクセス発生に関するお知らせとお詫び（第一報）」を公表した。同社が開発・システム管理に使用しているGitHubアカウントの認証情報が漏えいし、第三者がリポジトリをコピーした事象が確認されている。マネーフォワード ビジネスカード保持者370件分のカード保持者名（アルファベット）とカード番号下4桁、およびソースコード内の個人情報の一部が流出したと発表されている。本記事では第一報で確認された事実と、第一報では未公表の「侵入経路」を明確に区別したうえで、Mercari/CodecovやSpotBugs等の過去のGitHub認証情報漏えい事例から推測される経路、および開発組織が即時に取れる対策を解説する。2026年5月4日時点の続報状況として、マネーフォワードME利用者向けには「重要】GitHubへの不正アクセス発生および銀行口座連携機能の一時停止に関するお知らせ」がサポートサイトに掲示されており、銀行口座連携機能は依然として一時停止状態が続いている点を最新情報として追記している。

この記事ではマネーフォワードのGitHub不正アクセス事件を解説します。OSSサプライチェーン全体のリスク像についてはサプライチェーンセキュリティ完全ガイド：OSSの依存関係をどう守るかをご覧ください。

【最新】2026年5月4日時点の状況

第一報（5/1）からの推移を時系列で整理する。本記事は続報が出るたびに更新する。

検証メモ: 本セクションは2026年5月4日09:00（JST）時点でcorp.moneyforward.com/news/info/の一覧を確認した結果に基づく。最新の状況はマネーフォワード公式お知らせとマネーフォワードMEサポートサイトの双方を必ず確認してほしい。

利用者の体感として大きいのは、マネーフォワードMEで銀行口座連携が「自動取得しない」状態が続いていること。家計簿の自動同期に依存していた利用者は、再開までの間は手動入力かCSVインポートで凌ぐ運用が必要になる。マネーフォワードはこの間も支払い・カード機能等の主要サービスは稼働させており、影響範囲は「銀行連携」と「ビジネスカードの一部利用者向け通知」に絞られている。

【確認済み事実】公式発表の概要

第一報でマネーフォワードが明示している事実を整理する。

公式の表現は「不正アクセスの経路となった認証情報の無効化」となっており、漏えいした認証情報を悪用してGitHubに侵入されたこと自体は明確に認めている。

【未公表】侵入経路の核心部分

第一報の段階でマネーフォワードが開示していない情報は次のとおり。

• 認証情報（GitHubアカウントのパスワード／PAT／SSHキーなど何が漏えいしたか）がどのように外部に流出したか
• 攻撃者の身元、動機（経済目的か情報窃取目的か）
• 不正アクセスを検知したきっかけ（GitHubからの通知、内部監視、外部からの指摘等）
• 影響を受けたリポジトリの数とその性質（パブリック／プライベート、対象範囲）
• 攻撃者がリポジトリをコピーした後、追加の悪用を行ったかの検証結果

「経路となった認証情報の無効化」という表現に留めることで、経路の技術的詳細は伏せられている。続報での開示を待つ必要がある。

【推測・分析】過去類似事例から見る4つの想定経路

ここからは「マネーフォワードのケースに該当する」と特定された情報ではなく、過去のGitHub認証情報漏えい事例から想定される一般的な経路を整理する。読者が自社の開発体制を点検するためのチェックリストとして活用してほしい。

① CI/CDサプライチェーン経由（Mercari/Codecov型）

2021年4月にMercariが受けた被害がこの典型例だ。CI/CDツール「Codecov」のBash Uploaderがサプライチェーン攻撃で改ざんされ、CI/CD環境変数として保持されていたGitHub認証情報・APIキー・トークン類が外部に流出した。Mercariはこの認証情報を使ってGitHubリポジトリにアクセスされ、過去のソースコードと顧客情報の一部（17,085件の支払い情報など）が流出した。

マネーフォワードに当てはまる可能性：金融サービス事業者は多数のCI/CDツール（CircleCI、GitHub Actions、Codecov、Snyk等）を統合運用しており、そのいずれかが侵害された場合に同様の経路が成立しうる。ただし現時点で公式の言及はない。

② 開発者PCのマルウェア感染（SpotBugs型）

2025年に判明したSpotBugs関連のサプライチェーン攻撃では、開発者の個人PCがマルウェアに感染し、ブラウザ保存パスワード・クリップボード・SSHエージェント等からGitHub PATが盗み出された。攻撃者はそのPATでSpotBugsリポジトリのメンバー権限を獲得し、その後Coinbaseやtj-actions/changed-filesへの連鎖攻撃の起点となった。

マネーフォワードに当てはまる可能性：BYODやリモートワーク環境では、業務用GitHub認証情報を含む端末がマルウェアに感染するリスクは常に存在する。InfoStealer系マルウェア（RedLine、Vidar、Lumma等）は特にこの種の認証情報を狙う。

③ PAT・シークレットの誤コミット（Mercedes-Benz型）

2024年にMercedes-Benzで、従業員がプライベートGitHub PATをパブリックリポジトリにコミットしてしまい、長期間放置されていた事案が公開された。攻撃者がGitHub上を継続的に探索する自動化ツール（GHTorrent、TruffleHogベース）でPATを発見し、内部リポジトリにアクセスされた。

マネーフォワードに当てはまる可能性：大規模な開発組織では、git履歴の深い場所に過去のPATが残存している可能性がある。GitHubのPush protectionが有効でなかった時代のリポジトリは特にリスクが高い。

④ フィッシング／標的型攻撃（GitHub認証奪取）

GitHubの2FA／SSO認証画面を模した精巧なフィッシングサイトで開発者の認証情報を奪取する攻撃も増加している。OctoberCMSやSawfishキャンペーンが代表例で、ターゲットを絞った標的型としてエンタープライズ向けに行われる。

マネーフォワードに当てはまる可能性：Adversary-in-the-Middle（AitM）型は2FA有効でも突破される。ハードウェアキー（YubiKey）やパスキーへの移行が進んでいない組織では一定のリスクが残る。

流出する「ソースコード内の個人情報」の意味

公式発表で気になるのが「ソースコード内の個人情報の一部」という表現だ。これは技術者から見ると複数の可能性を含む。

ソースコードリポジトリは「コードだけが入っているもの」ではない。10年以上歴史のあるサービスでは、git履歴の深層にこうした残存物が眠っていることがある。今回の事案はこの構造的リスクを改めて示すものとなった。

開発組織が今すぐ取れる対策

過去事例の経路パターンを踏まえ、自社環境を点検する具体的なアクションを優先度順に整理する。これは類似OSSセキュリティ事例としてRenovate・Dependabot防御｜サプライチェーン攻撃の最新対策とも通底する内容だ。

1. PATを段階的に廃止し、GitHub Apps＋短命トークンへ移行

• 永続PATは漏えい時の影響が長期化する。GitHub Apps＋OIDCの短命トークンに切り替える
• どうしてもPATが必要な場合はFine-grained personal access tokenを使い、リポジトリ・権限を最小化
• 期限は最長でも90日

2. Push protectionとSecret scanningを全リポジトリで有効化

# .github/settings.yml の例（Probot Settings利用時）
repository:
  has_issues: true
  has_wiki: false
  delete_branch_on_merge: true
security_and_analysis:
  secret_scanning:
    status: enabled
  secret_scanning_push_protection:
    status: enabled

GitHubの組織設定からも一括有効化が可能。コミット時点でシークレットを検知して拒否することで、誤コミット由来の漏えいを根本から防ぐ。

3. ローカルでの事前スキャン（gitleaks／TruffleHog）

# pre-commit hook 例（gitleaks）
gitleaks protect --staged --redact

# または GitHub Actions で全PRをスキャン
# .github/workflows/gitleaks.yml
name: gitleaks
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2

PR提出前にローカルで止め、GitHubに到達する前に検知する二重防御を組む。

4. 開発者端末のEDR導入とInfoStealer対策

• ブラウザのパスワード保存機能を無効化、1Password等のパスワードマネージャに統一
• SSH秘密鍵はハードウェア鍵（YubiKey、Secretive）で物理保護
• EDR（Endpoint Detection and Response）の組織展開でInfoStealerを早期検知
• 私物端末でのリポジトリclone禁止、業務端末のみで開発

5. CI/CDサードパーティツールの権限最小化

# CI環境変数を「ジョブごとに必要なものだけ」に絞る
# GitHub Actions 例：
jobs:
  build:
    permissions:
      contents: read
      id-token: write  # OIDC認証用
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/ci-deploy
          # ↑長期credentialではなくIAM Role+OIDCで都度発行

Codecov事件のようなサードパーティ侵害が最小権限で食い止められる設計に切り替える。

6. ソースコードの定期棚卸し（過去シークレットの掘り起こし）

過去のgit履歴に残るシークレットは、現在のコードに見えなくても侵害時の被害拡大要因になる。git filter-repoやBFG Repo-Cleanerでの履歴書き換えと、すべての該当キーのローテーションをセットで実施する。

利用者側で取れる対策

マネーフォワード ビジネスカード利用者および同社サービス利用者として、第三者の口座不正利用フェーズへの拡大に備えて取れる対策を整理する。

なお同社は過去にも第三者によるアカウント不正利用および大量メール送付（2024年8月）、マネーフォワードIDの管理に関する注意（2025年）など複数のセキュリティ関連告知を行っており、ID管理の徹底は継続的に意識する必要がある。

メルカリ2021年Codecov事件の組織対応プレイブック（事後分析）

マネーフォワード本件で開発組織が参考にすべき先行事例は、メルカリが2021年4月のCodecov事件で受けた被害と、その後の対応をまとめたEngineering at Mercariの記事「Removing sensitive data from GitHub」（2021-12-07公開）に集約されている。同社は事件後8ヶ月をかけて公開ナレッジ化しており、国内fintech企業がGitHub認証情報漏えいから組織再構築するプレイブックとして現状で最良の参考資料だ。

メルカリが直面した状況

メルカリが直面したのは「Codecov bash uploaderの侵害」を起点とする連鎖事件だった。

1. Codecovの公式bash uploaderスクリプトが攻撃者により改ざん
2. 多くの組織のCI/CD環境変数が攻撃者サーバへ送信
3. メルカリでも環境変数経由でGitHub認証情報が漏えい
4. 攻撃者がGitHubリポジトリにアクセスし、ソースコード閲覧・コピーを実施
5. ソースコード内に残存していた過去の機微情報（顧客情報・支払い情報）が二次漏えい
6. 結果として、最終的に17,085件の支払い情報・217件のカスタマーサービス情報・ソースコードが流出

「1次原因は外部CI/CDの侵害」「2次被害は自社コード履歴に残った機微情報」という二段階構造が今回のマネーフォワード事案と非常に似ている。

メルカリの組織対応で取り入れるべき要素

メルカリの公開記事から読み取れる実装レベルの対応を、開発組織が今からチェックリスト化できる形で整理する。

最後の「公開ポストモーテム」は重要なアクションだ。Mercariは8ヶ月かけて社外向けに記事化し、コミュニティに学びを還元したことで再発防止文化を組織内外に強化した。マネーフォワードが同様に技術的詳細を公開するかは、今後の続報で示される注目ポイントだ。

「ヒストリ書き換え」の現実：BFGとgit filter-repo

Mercariが用いた履歴書き換えは通常のgitコミット削除とは異なる。コミット履歴から機微情報を完全に消すには、以下のいずれかが必要。

# BFG Repo-Cleaner（Java実装、最も一般的）
java -jar bfg.jar --replace-text passwords.txt repo.git
java -jar bfg.jar --delete-files secrets.json repo.git
git -C repo.git reflog expire --expire=now --all
git -C repo.git gc --prune=now --aggressive

# git filter-repo（Python実装、推奨される後継）
git filter-repo --path secrets.json --invert-paths
git filter-repo --replace-text passwords.txt

BFG Repo-Cleanerは大規模リポジトリで実績があり、git filter-repoはGit公式が推奨する後継ツール。いずれも履歴書き換え後は全ブランチ・全タグを強制プッシュする必要があるため、外部開発者を含むOSSリポジトリでは実施タイミングを慎重に決める必要がある。社内リポジトリであっても、CI/CDのコミットhash参照が壊れる可能性に注意。

Push protection＋Secret scanningのGitHub組織レベル設定

メルカリ事例でも強調されたのは、「コミットされる前に止める」ことの重要性だ。GitHub Advanced SecurityのPush protectionは、シークレットらしき文字列を含むpushを物理的に拒否する。組織レベルで設定すれば、新規リポジトリ含めて全社的に有効化できる。

# gh CLIで全リポジトリのSecret scanning状態を確認
gh api /orgs/YOUR_ORG/secret-scanning/alerts | jq '.[] | {repo:.repository.name, secret_type:.secret_type, state:.state}'

# 特定リポジトリでPush protectionを有効化
gh api -X PATCH /repos/YOUR_ORG/YOUR_REPO \
  -f security_and_analysis[secret_scanning_push_protection][status]=enabled

組織のセキュリティ管理者は、「全リポジトリでPush protection有効、Secret scanning有効、Dependabot有効」を強制する組織ポリシーを設定するのが2026年時点の標準だ。

マネーフォワードに対する第三者評価の視点

OSSや企業のセキュリティ姿勢は主観で語ると揺らぐので、第三者評価サイトのスコアや公開情報で補強したい。マネーフォワードに関連する範囲で押さえておきたい評価ソースを整理する。

マネーフォワードは2025年にもマネーフォワードIDの管理に関する注意喚起を出しており、ID周りでの過去の対応履歴は公開されている。第三者評価軸で見るときは「1度のインシデントだけ」でなく「5年間の対応の積み上げ」を見るのがフェアだ。本件の続報での透明性確保が、第三者評価の改善に直結する。

過去の代表的GitHub認証情報漏えい事件のタイムライン比較

GitHub認証情報の漏えい事件は2020年以降世界で連続している。今回のマネーフォワードの事案を文脈に置くため、主要事件を時系列で並べる。

5年で世界中の名だたる組織が同種の被害を受けており、「うちは大丈夫」と思える組織は存在しないことがこの一覧から読み取れる。マネーフォワードの今後の続報により、上記表の「未公表」枠が確定情報に置き換わる予定だ。とりわけ国内fintech業界での同種事案は珍しく、続報での技術的詳細の公開は他社の予防策にも直結する公益性を持つ。

業界規制との関連：割賦販売法・PCI DSSの観点

クレジットカード関連事業者には改正割賦販売法（2018年施行）およびPCI DSS（カード業界国際基準）に基づく情報管理義務がある。本事案で関連する論点を整理する。

第一報で公表された範囲では、PAN（カード番号全桁）・有効期限・CVVは流出していないため、PCI DSS違反に直結する事象は確認されていない。「カード番号下4桁＋名義」のみであれば、それ単独でカードが不正利用される可能性は低い。ただしフィッシングと組み合わされた場合の二次被害リスクは残るため、利用者側の警戒は引き続き重要だ。

続報で注目すべきポイント

公式の続報が出る際、本事案を理解するうえで重要となる確認ポイントを整理する。

• 認証情報の漏えい経路（具体的にどの経路だったか）
• 認証情報がいつ漏えいし、攻撃者がいつアクセスしたかのタイムライン
• 影響を受けたリポジトリの数と種類
• 流出した「ソースコード内の個人情報」の具体的な内容と件数
• 攻撃者の身元・動機についての言及
• 再発防止策の具体内容（GitHub Apps移行、Push protection適用等）

これらが第二報・第三報で開示されれば、より具体的な分析が可能になる。本記事もその時点で更新予定だ。

マネーフォワードME利用者向け：銀行連携機能停止中の運用Tips

銀行連携が一時停止されている期間の家計簿運用は、以下の3パターンが現実的。

A. CSV手動インポート（精度最優先）

各銀行のWebバンキングからCSVをエクスポートし、マネーフォワードMEへ手動インポートする方式。マネーフォワードMEはほとんどの主要金融機関のCSV形式に対応している。

1. 銀行Web画面 → 入出金明細CSVダウンロード
2. マネーフォワードMEアプリ → 「データ追加」→「CSV取込」
3. 文字コード（Shift_JIS / UTF-8）に注意

CSVは月締めのタイミングでまとめてインポートするのが効率的。連携機能再開後に重複が発生したら、手動で重複削除する。

B. 手入力での補完（最低限の見える化）

家計簿として「入出金が分からない」状態を避けるために、主要な大型支出（家賃・光熱費・カード支払い等）だけ手入力する方式。粒度は粗くても、再開後の差し替え前提で運用する。

C. 電子マネー・カード連携で補完

Suica・PASMO・楽天Edyや、各種クレジットカードの連携は今回の停止対象外なので、カード支出は通常どおり自動取得される。普段カード払い中心の利用者であれば、銀行連携停止の影響は限定的だ。

「現金引き出し→現金支出」の経路だけは捕捉が落ちるため、停止期間中は現金支出を意識的に手入力で記録する習慣を付けたい。

まとめ：「経路の見えないインシデント」をどう読むか

本事案で改めて浮き彫りになったのは、初動の公式発表は経路の核心部分を伏せる傾向にあるという構造だ。法的・捜査的な配慮、追加被害の防止、調査未完了といった理由から、第一報では「事実」のみが共有され、「経路」は時間をかけて開示される。これはマネーフォワードに限らず、国内外fintechの大半が同じパターンを取る。

そのため読者・運用者がいま取れる最善は、過去の類似事例から想定経路を網羅的に学び、自社の体制を多面的に点検することだ。マネーフォワードの今後の続報を冷静に追うとともに、自組織のGitHub認証情報管理が「Mercari/Codecov型」「SpotBugs型」「Mercedes-Benz型」「フィッシング型」のいずれにも備えられているかを今日のうちに確認したい。

参照ソース

• 『GitHub』への不正アクセス発生に関するお知らせとお詫び（第一報）｜株式会社マネーフォワード - 公式第一報（一次ソース）
• 『GitHub』への不正アクセス発生および銀行口座連携機能の一時停止に関するお知らせ｜マネーフォワード MEサポート - サポートサイトでの利用者向け案内
• Removing sensitive data from GitHub｜Engineering at Mercari（2021-12-07） - メルカリのCodecov事件後の組織対応プレイブック
• Mercari’s Response to the Codecov Vulnerability and Related Notification on Personal Information Exposure - Mercari/Codecov事件の公式発表
• GitHub Action での連鎖的攻撃：SpotBugs の PAT 漏洩 (IoT OT Security News) - SpotBugs事件の詳細
• How to Avoid Source Code Breaches: Lessons From the Mercedes-Benz GitHub Token Leak (VicOne) - Mercedes-Benz誤コミット事件
• Best practices for preventing data leaks in your organization (GitHub Docs) - GitHub公式の対策ガイド
• GitHub のセキュリティ改善 (Zenn) - 国内エンジニアによる対策実装解説
• BFG Repo-Cleaner - 履歴書き換えツール公式
• git filter-repo - Git公式推奨の履歴書き換え後継ツール
• 個人情報保護委員会 - 漏えい時報告先
• JPCERT/CC - 国内セキュリティインシデントの報告・連携機関