2026年5月1日、株式会社マネーフォワードは「『GitHub』への不正アクセス発生に関するお知らせとお詫び（第一報）」を公表した。同社が開発・システム管理に使用しているGitHubアカウントの認証情報が漏えいし、第三者がリポジトリをコピーした事象が確認されている。マネーフォワード ビジネスカード保持者370件分のカード保持者名（アルファベット）とカード番号下4桁、およびソースコード内の個人情報の一部が流出したと発表されている。本記事では第一報で確認された事実と、第一報では未公表の「侵入経路」を明確に区別したうえで、Mercari/CodecovやSpotBugs等の過去のGitHub認証情報漏えい事例から推測される経路、および開発組織が即時に取れる対策を解説する。
この記事ではマネーフォワードのGitHub不正アクセス事件を解説します。OSSサプライチェーン全体のリスク像についてはサプライチェーンセキュリティ完全ガイド：OSSの依存関係をどう守るかをご覧ください。
事実関係の取り扱いについて（重要）
本記事は3層に分けて記述する。
- 【確認済み事実】：マネーフォワード公式発表（第一報）の記述
- 【未公表】：第一報で開示されていない情報
- 【推測・分析】：過去の類似事例から想定される経路。マネーフォワードが該当する経路と特定したものではない
侵入経路の核心部分は本記事執筆時点で公式に公表されていない。続報で訂正される可能性がある点をご承知のうえお読みください。
この記事のポイント
- マネーフォワード ビジネスカード保持者370件分の情報とソースコード内の個人情報が流出（公式確認）
- カード番号全桁・有効期限・CVVの流出は確認されていない（公式確認）
- 侵入経路の技術的詳細は第一報では未公表。「認証情報の無効化」とのみ言及
- 過去類似事例から想定される経路は4類型（CI/CDサプライチェーン、開発者PCマルウェア、PAT誤コミット、フィッシング）
【確認済み事実】公式発表の概要
第一報でマネーフォワードが明示している事実を整理する。
| 項目 | 公式発表内容 |
|---|---|
| 公表日 | 2026年5月1日（第一報） |
| 事象 | 開発・システム管理用GitHubアカウントの認証情報漏えい→第三者によるリポジトリのコピー |
| 流出可能性のある個人情報 | マネーフォワード ビジネスカード保持者370件分のカード保持者名（アルファベット）・カード番号下4桁／ソースコード内の個人情報の一部 |
| 流出が確認されていない情報 | クレジットカード番号の全桁、有効期限、CVV |
| 対応状況 | 認証情報の無効化・アカウント遮断完了／ソースコード内の認証キー・パスワード無効化と再発行は概ね完了 |
| 影響を受けるサービス | マネーフォワード クラウド、ビジネスカード関連／銀行口座連携機能を一時停止 |
| 本番DB情報の漏えい | 確認されていない |
公式の表現は「不正アクセスの経路となった認証情報の無効化」となっており、漏えいした認証情報を悪用してGitHubに侵入されたこと自体は明確に認めている。
【未公表】侵入経路の核心部分
第一報の段階でマネーフォワードが開示していない情報は次のとおり。
- 認証情報（GitHubアカウントのパスワード／PAT／SSHキーなど何が漏えいしたか）がどのように外部に流出したか
- 攻撃者の身元、動機（経済目的か情報窃取目的か）
- 不正アクセスを検知したきっかけ（GitHubからの通知、内部監視、外部からの指摘等）
- 影響を受けたリポジトリの数とその性質（パブリック／プライベート、対象範囲）
- 攻撃者がリポジトリをコピーした後、追加の悪用を行ったかの検証結果
「経路となった認証情報の無効化」という表現に留めることで、経路の技術的詳細は伏せられている。続報での開示を待つ必要がある。
【推測・分析】過去類似事例から見る4つの想定経路
ここからは「マネーフォワードのケースに該当する」と特定された情報ではなく、過去のGitHub認証情報漏えい事例から想定される一般的な経路を整理する。読者が自社の開発体制を点検するためのチェックリストとして活用してほしい。
(Codecov/Mercari型)"] B --> D["②開発者PCマルウェア
(SpotBugs型)"] B --> E["③PAT/シークレット誤コミット
(Mercedes-Benz型)"] B --> F["④フィッシング/標的型
(GitHub認証奪取)"] C --> G["GitHub アカウント乗っ取り"] D --> G E --> G F --> G G --> H["プライベートリポジトリのコピー"] H --> I["ソースコード／含有シークレット流出"]
① CI/CDサプライチェーン経由（Mercari/Codecov型）
2021年4月にMercariが受けた被害がこの典型例だ。CI/CDツール「Codecov」のBash Uploaderがサプライチェーン攻撃で改ざんされ、CI/CD環境変数として保持されていたGitHub認証情報・APIキー・トークン類が外部に流出した。Mercariはこの認証情報を使ってGitHubリポジトリにアクセスされ、過去のソースコードと顧客情報の一部（17,085件の支払い情報など）が流出した。
| Mercari/Codecov事件の経路 |
|---|
| Codecov Bash Uploaderにバックドア混入（2ヶ月間気づかれず） |
| Mercari CI環境変数からGitHub PAT等を抽出 |
| 攻撃者がPATでGitHub APIにアクセス |
| プライベートリポジトリのソースコードを取得 |
マネーフォワードに当てはまる可能性：金融サービス事業者は多数のCI/CDツール（CircleCI、GitHub Actions、Codecov、Snyk等）を統合運用しており、そのいずれかが侵害された場合に同様の経路が成立しうる。ただし現時点で公式の言及はない。
② 開発者PCのマルウェア感染（SpotBugs型）
2025年に判明したSpotBugs関連のサプライチェーン攻撃では、開発者の個人PCがマルウェアに感染し、ブラウザ保存パスワード・クリップボード・SSHエージェント等からGitHub PATが盗み出された。攻撃者はそのPATでSpotBugsリポジトリのメンバー権限を獲得し、その後Coinbaseやtj-actions/changed-filesへの連鎖攻撃の起点となった。
| SpotBugs型の経路 |
|---|
| 開発者がフィッシング／不正サイトでマルウェア感染 |
| InfoStealerがブラウザ保存・クリップボード・SSH agentを掃き出し |
| GitHub PATがC2サーバーに送信 |
| 攻撃者がPATでアカウント操作（招待・権限変更・リポジトリ操作） |
マネーフォワードに当てはまる可能性：BYODやリモートワーク環境では、業務用GitHub認証情報を含む端末がマルウェアに感染するリスクは常に存在する。InfoStealer系マルウェア（RedLine、Vidar、Lumma等）は特にこの種の認証情報を狙う。
③ PAT・シークレットの誤コミット（Mercedes-Benz型）
2024年にMercedes-Benzで、従業員がプライベートGitHub PATをパブリックリポジトリにコミットしてしまい、長期間放置されていた事案が公開された。攻撃者がGitHub上を継続的に探索する自動化ツール（GHTorrent、TruffleHogベース）でPATを発見し、内部リポジトリにアクセスされた。
| Mercedes-Benz型の経路 |
|---|
開発者が.env／設定ファイルをそのままcommit |
| パブリックリポジトリ／フォーク経由でPATが世界に露出 |
| Botがシークレットを24時間以内に発見 |
| 該当PATで内部リポジトリへ侵入 |
マネーフォワードに当てはまる可能性：大規模な開発組織では、git履歴の深い場所に過去のPATが残存している可能性がある。GitHubのPush protectionが有効でなかった時代のリポジトリは特にリスクが高い。
④ フィッシング／標的型攻撃（GitHub認証奪取）
GitHubの2FA／SSO認証画面を模した精巧なフィッシングサイトで開発者の認証情報を奪取する攻撃も増加している。OctoberCMSやSawfishキャンペーンが代表例で、ターゲットを絞った標的型としてエンタープライズ向けに行われる。
| フィッシング経路 |
|---|
| 開発者宛にGitHub通知を装ったメール送信 |
| クリック先がGitHubそっくりのフィッシングサイト |
| ID/パスワード＋2FAトークンをリアルタイム中継（AitM） |
| 攻撃者がセッションCookieを取得し、即座にGitHubに侵入 |
マネーフォワードに当てはまる可能性：Adversary-in-the-Middle（AitM）型は2FA有効でも突破される。ハードウェアキー（YubiKey）やパスキーへの移行が進んでいない組織では一定のリスクが残る。
流出する「ソースコード内の個人情報」の意味
公式発表で気になるのが「ソースコード内の個人情報の一部」という表現だ。これは技術者から見ると複数の可能性を含む。
| 想定パターン | 内容 |
|---|---|
| テストデータの実データ混入 | 本番データを匿名化せずテストファイルに含めてコミット |
| マイグレーションスクリプトの初期値 | DBマイグレーションで実顧客データを参照 |
| ログファイルのコミット | デバッグ用ログに個人情報が含まれリポジトリ内に残存 |
| ドキュメント／READMEの例示 | 設計書に実顧客名・メールアドレスを記載 |
| 認証キー類 | 環境変数・設定ファイルとしてリポジトリに残存 |
ソースコードリポジトリは「コードだけが入っているもの」ではない。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での履歴書き換えと、すべての該当キーのローテーションをセットで実施する。
利用者側で取れる対策
マネーフォワード ビジネスカード利用者および同社サービス利用者として、第三者の口座不正利用フェーズへの拡大に備えて取れる対策を整理する。
| 対策 | 説明 |
|---|---|
| カード明細の異常監視 | 直近の利用明細を週次で確認、心当たりのない請求は即座にカード会社へ |
| 認証情報の使い回し見直し | マネーフォワードIDと他サービスでパスワードを使い回している場合は変更 |
| マネーフォワードIDの2FA有効化 | TOTP（Google Authenticator等）またはSMSで2要素認証を必ず有効化 |
| 公式情報のフォロー | マネーフォワード公式お知らせで続報を確認 |
なお同社は過去にも第三者によるアカウント不正利用および大量メール送付（2024年8月）、マネーフォワードIDの管理に関する注意（2025年）など複数のセキュリティ関連告知を行っており、ID管理の徹底は継続的に意識する必要がある。
過去の代表的GitHub認証情報漏えい事件のタイムライン比較
GitHub認証情報の漏えい事件は2020年以降世界で連続している。今回のマネーフォワードの事案を文脈に置くため、主要事件を時系列で並べる。
| 年 | 事件 | 経路 | 影響 |
|---|---|---|---|
| 2021/04 | Mercari／Codecov | サードパーティCI/CDツール侵害 | 17,085件の支払い情報、217件のCS情報、ソースコード |
| 2021/04 | HashiCorp／Codecov | 同上（同時被害） | 内部証明書 |
| 2024/01 | Mercedes-Benz | 従業員のPAT誤コミット | 内部リポジトリ・Azure SAS等 |
| 2024/12 | Internet Archive | コミット履歴のシークレット | ユーザーDB相当 |
| 2025/03 | Coinbase（SpotBugs起点） | 開発者端末マルウェア→PAT奪取 | tj-actions改ざんへ連鎖 |
| 2026/05 | マネーフォワード（本件） | 未公表 | カード情報370件、ソースコード内個人情報 |
5年で世界中の名だたる組織が同種の被害を受けており、「うちは大丈夫」と思える組織は存在しないことがこの一覧から読み取れる。マネーフォワードの今後の続報により、上記表の「未公表」枠が確定情報に置き換わる予定だ。
業界規制との関連：割賦販売法・PCI DSSの観点
クレジットカード関連事業者には改正割賦販売法（2018年施行）およびPCI DSS（カード業界国際基準）に基づく情報管理義務がある。本事案で関連する論点を整理する。
| 規制 | 関連する論点 |
|---|---|
| 割賦販売法（経産省） | クレジットカード番号の非保持化義務／漏えい時の報告義務 |
| PCI DSS | ソースコード管理（要件6）、認証情報の保護（要件8） |
| 個人情報保護法 | 漏えい時の本人通知・個人情報保護委員会への報告 |
| 銀行法・資金決済法 | 銀行口座連携機能の安全性確認義務 |
第一報で公表された範囲では、PAN（カード番号全桁）・有効期限・CVVは流出していないため、PCI DSS違反に直結する事象は確認されていない。「カード番号下4桁＋名義」のみであれば、それ単独でカードが不正利用される可能性は低い。ただしフィッシングと組み合わされた場合の二次被害リスクは残るため、利用者側の警戒は引き続き重要だ。
続報で注目すべきポイント
公式の続報が出る際、本事案を理解するうえで重要となる確認ポイントを整理する。
- 認証情報の漏えい経路（具体的にどの経路だったか）
- 認証情報がいつ漏えいし、攻撃者がいつアクセスしたかのタイムライン
- 影響を受けたリポジトリの数と種類
- 流出した「ソースコード内の個人情報」の具体的な内容と件数
- 攻撃者の身元・動機についての言及
- 再発防止策の具体内容（GitHub Apps移行、Push protection適用等）
これらが第二報・第三報で開示されれば、より具体的な分析が可能になる。本記事もその時点で更新予定だ。
まとめ：「経路の見えないインシデント」をどう読むか
本事案で改めて浮き彫りになったのは、初動の公式発表は経路の核心部分を伏せる傾向にあるという構造だ。法的・捜査的な配慮、追加被害の防止、調査未完了といった理由から、第一報では「事実」のみが共有され、「経路」は時間をかけて開示される。
そのため読者・運用者がいま取れる最善は、過去の類似事例から想定経路を網羅的に学び、自社の体制を多面的に点検することだ。マネーフォワードの今後の続報を冷静に追うとともに、自組織のGitHub認証情報管理が「Mercari/Codecov型」「SpotBugs型」「Mercedes-Benz型」「フィッシング型」のいずれにも備えられているかを今日のうちに確認したい。
FAQ
Q. 自分のマネーフォワード ビジネスカードが対象かどうか確認する方法は？
A. 公式発表によれば、対象者には個別に通知が行われる方針です。心配な場合はマネーフォワードケッサイ株式会社のサポート窓口に問い合わせてください。本記事執筆時点で個別通知の状況詳細は公表されていません。
Q. 銀行口座連携機能はいつ復旧しますか？
A. 第一報では「各提携金融機関との安全性の確認を万全なものとするため」一時停止と記載されています。具体的な再開時期は記載されておらず、続報を待つ必要があります。
Q. パスワード変更は必要ですか？
A. マネーフォワード公式は本番DBへの不正アクセスは確認されていないと表明していますが、念のためマネーフォワードIDのパスワード変更と2FA有効化を推奨します。他サービスとパスワードを使い回している場合は特に変更が望ましいです。
Q. ソースコードの一部が流出することのリスクは？
A. ソースコード自体に加え、コード内に残存していた認証情報・APIキー・テストデータ等が悪用される二次リスクがあります。マネーフォワードはコード内の認証キー・パスワード再発行を概ね完了したと発表しています。
Q. なぜGitHubアカウントの認証情報が攻撃者に渡ったかが公表されないのですか？
A. 一般論として、初動公表では(1)調査未完了、(2)同一手口による追加被害防止、(3)捜査機関との調整、(4)公表による模倣犯発生防止などの理由で経路詳細を保留することが多くあります。続報で開示される可能性があります。
Q. 自社で同様のインシデントを防ぐにはどこから手を付けるべきですか？
A. 優先順位は (1)GitHub Push protection＆Secret scanningの全リポジトリ有効化、(2)永続PATの棚卸しと短命トークン移行、(3)CI/CDツールの権限最小化、(4)開発者端末のEDR導入です。本記事「開発組織が今すぐ取れる対策」セクションを参照してください。
参照ソース
- 『GitHub』への不正アクセス発生に関するお知らせとお詫び（第一報）｜株式会社マネーフォワード - 公式第一報（一次ソース）
- 『GitHub』への不正アクセス発生および銀行口座連携機能の一時停止に関するお知らせ｜マネーフォワード MEサポート - サポートサイトでの利用者向け案内
- 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) - 国内エンジニアによる対策実装解説
