2026年5月に公表されたマネーフォワードのGitHub不正アクセスを、公式発表をもとに整理。認証情報漏えい、リポジトリコピー、鍵ローテーション、銀行口座連携停止から、開発組織が確認すべき実務対応を解説する。
何が起きたのか：GitHub認証情報の漏えいとリポジトリコピー
2026年5月1日、マネーフォワードは、同社グループがソフトウェア開発およびシステム管理に利用している GitHubの認証情報が漏えいし、第三者による不正アクセスが発生した と公表した。公式発表では、GitHub内のリポジトリがコピーされたこと、ソースコードおよびリポジトリ内ファイルに含まれていた一部個人情報が流出した可能性があることが示されている。
公表時点で、本番データベースからの情報漏えいは確認されていない。一方で、マネーフォワードケッサイ株式会社が提供する「マネーフォワード ビジネスカード」に関わる370件のカード保持者名（アルファベット）およびカード番号下4桁について、流出可能性があると説明されている。カード番号全桁、有効期限、CVVの流出は確認されていない、という整理だ。
また、マネーフォワード ME のサポートサイトでは、金融情報を含むデータベースからの漏えいは現時点で確認されていないこと、各提携金融機関との安全性確認のため銀行口座連携機能を一時停止していることが案内されている。
この記事は2026年5月2日時点で確認できる公式発表と公開情報をもとにしている。調査中の事案であり、今後追加情報が出る可能性がある。利用者としての最新確認は、マネーフォワード公式のお知らせと各サービスのサポートページを優先してほしい。
「ソースコードがコピーされた」だけでは済まない理由
GitHubリポジトリの侵害でまず見るべきなのは、コードそのものよりも「コードの周辺に置かれがちな運用情報」だ。リポジトリには、アプリケーションのソースコードだけでなく、CI/CD設定、IaC、デプロイスクリプト、サンプル設定、テストデータ、運用メモ、古いREADME、GitHub Actions Secretsの参照名などが残る。
攻撃者がリポジトリをコピーした場合、次のような情報を組み合わせて次の侵害経路を探せる。
| 見られやすい情報 | 悪用され得ること |
|---|---|
| APIキーやパスワードの残骸 | クラウド、SaaS、DB、外部APIへの不正アクセス |
| CI/CDワークフロー | デプロイ権限、署名、成果物配布経路の把握 |
| IaCや環境変数名 | 本番構成、ネットワーク、秘密情報の所在推測 |
| テストデータやログ | 個人情報・社内情報・取引先情報の混入 |
| 内部ツールのコード | 管理画面、運用API、監査ログの構造理解 |
| 古いブランチや履歴 | 現行コードから消したはずの秘密情報の復元 |
これは サプライチェーン攻撃 の入口にもなる。コード管理基盤は、開発者の作業場所であると同時に、ビルド、検証、配布、運用へつながる中枢だ。GitHubの侵害は「開発部門だけの問題」ではなく、サービス継続、顧客説明、委託先管理、金融機関との接続確認まで波及する。
第一報から読み取れる初動対応
今回の公式発表では、事象発覚後の追加被害防止策として、不正アクセス経路となった認証情報の無効化、アカウント遮断、ソースコードに含まれる各種認証キー・パスワードの無効化と再発行が進められていると説明されている。
この流れは、GitHub侵害時の初動として筋が通っている。重要なのは「コピーされたリポジトリを消せば終わり」ではない点だ。一度漏えいした可能性のある秘密情報は、攻撃者の手元に残っている前提で扱う必要がある。
GitHub Docs でも、リポジトリに含まれた秘密情報はGit履歴に残り、最新コミットから削除するだけでは不十分だと説明されている。漏えいした可能性がある秘密情報は、原則として失効・再発行・利用範囲確認まで進めるべきだ。
秘密情報がリポジトリに含まれていた可能性がある場合、まず使えない状態にする。削除コミットや履歴整理はその後の作業だ。攻撃者がすでにコピーしている前提では、ファイルを消しても鍵そのものは無効にならない。
利用者がまず確認すべきこと
マネーフォワード利用者の視点では、まず公式からの個別連絡とサポートページを確認するのがよい。今回の第一報では、該当する顧客にはメール等で個別連絡すると説明されている。
注意したいのは、インシデント直後に便乗フィッシングが増えやすいことだ。「本人確認」「返金」「口座連携の再設定」「カード停止」などを装うメールやSMSが届いても、リンクからログインしない。ブックマークや公式アプリから確認する方が安全だ。
| 利用者が確認すること | 実務上の見方 |
|---|---|
| 公式発表とサポートページ | 最新の影響範囲、復旧状況、個別連絡の有無を見る |
| 口座連携の状態 | 一時停止や再開予定は公式案内を確認する |
| 不審メール・SMS | リンクからログインせず、公式アプリや公式サイトから確認する |
| カード関連の通知 | 該当者への個別連絡を確認し、必要ならカード会社側の明細も見る |
ここで「すべての利用者がすぐパスワードを変えるべき」と断定するのは早い。現時点の公式説明では、本番データベースからの漏えいは確認されていない。利用者は過度に慌てるより、公式情報の更新を確認し、便乗詐欺に引っかからないことを優先したい。
開発組織が見るべきGitHub棚卸しチェックリスト
今回のような事案は、GitHubを使う日本企業にとって他人事ではない。特にSaaS、金融、医療、自治体、BtoBクラウドのように、コードと運用情報が事業継続へ直結する組織では、リポジトリを「置き場」ではなく「高価値資産」として扱う必要がある。
まず確認したいのは、次の6領域だ。
| 領域 | 確認ポイント |
|---|---|
| 人の認証 | SSO強制、MFA/パスキー必須化、退職者・委託先アカウントの削除 |
| トークン | Personal Access Token、fine-grained PAT、Deploy Key、GitHub App権限の棚卸し |
| Secrets | Actions Secrets、環境別Secrets、古い.env、サンプル設定内の実値混入 |
| CI/CD | ワークフロー権限、OIDC短命トークン、承認なしデプロイの有無 |
| 監査ログ | 不審なclone、repo visibility変更、secret参照、Actions実行履歴 |
| リポジトリ管理 | Private設定、ブランチ保護、CODEOWNERS、不要なfork/旧リポジトリ |
GitHub Docs は、漏えいしたシークレット対応として、特定、リスク評価、失効、影響サービスの更新、不正アクセス確認、再発防止を順に進める考え方を示している。これは インシデントレスポンス の実務そのものだ。
個人のMFAだけに寄せると、対策は片手落ちになる。GitHub侵害では、個人アカウント、組織設定、リポジトリ権限、CI/CD、クラウド認証情報がつながっている。パスキー導入やSSOは入口の強化として有効だが、その先にある権限最小化と監査がなければ、1つの認証情報漏えいが広く効いてしまう。
インシデント発生時の72時間でやること
GitHub不正アクセスが疑われたら、最初の72時間は「原因の特定」と「被害範囲の確定」を同時に進める。完璧な分析を待ってから鍵を変えるのでは遅い。
| 時間軸 | やること | 目的 |
|---|---|---|
| 0〜6時間 | 該当アカウント遮断、トークン失効、SSO/MFA確認 | 追加アクセスを止める |
| 6〜24時間 | clone履歴、IP、repoアクセス、Actions実行、権限変更を確認 | 攻撃経路と対象範囲を絞る |
| 24〜48時間 | Secrets、環境変数、クラウドキー、Webhook、Deploy Keyをローテーション | 二次侵害を防ぐ |
| 48〜72時間 | 顧客影響、個人情報、提携先影響、公開説明の準備 | 信頼回復と法務・広報対応に備える |
このとき、SBOMやリリースごとの依存関係一覧があると、影響調査は短くなる。たとえば、漏えいしたリポジトリに含まれるライブラリ、内部パッケージ、CI/CDテンプレートがどのサービスへ展開されているかを説明しやすい。詳しくは SBOMとOSV-Scannerで依存関係リスクを棚卸しする実習 で扱っている。
平時にやるべき設計：長期鍵を減らし、検知できる状態にする
GitHub侵害への備えは、事件が起きてから始めると遅い。平時の設計としては、長期的に有効な鍵を減らし、漏れてもすぐ失効でき、誰が何へアクセスしたかを追える状態を作る。
特にCI/CDでは、クラウドの長期アクセスキーをGitHub Actions Secretsへ置きっぱなしにする設計を避けたい。可能であれば、GitHub Actions OIDCを使ってクラウド側で短命トークンを発行し、リポジトリ・ブランチ・環境ごとに条件を絞る。これにより、Secretsそのものを減らし、漏えい時の影響範囲を小さくできる。
また、GitHub Secret Scanning と Push Protection は、秘密情報の混入を早期に止めるための基本線になる。公開リポジトリでは自動的に保護される範囲もあるが、組織のprivate/internalリポジトリでは契約や設定によって利用範囲が変わる。自社のGitHubプランと対象リポジトリを確認しておきたい。
委託先・副業・業務委託メンバーのGitHubアカウント棚卸しは後回しになりがちだ。SSO未連携の個人アカウント、長期間使われていない外部コラボレーター、退職者のforkやDeploy Keyは、定期的に確認する。
まとめ：GitHubは「開発ツール」ではなく事業インフラ
マネーフォワードの第一報が示したのは、GitHubの不正アクセスがソースコード流出だけで終わらないという現実だ。認証情報、鍵、リポジトリ、CI/CD、金融機関との連携確認、顧客説明まで、開発基盤の侵害は事業運営へ直結する。
利用者は、公式発表を確認し、便乗フィッシングに注意する。企業側は、GitHubの認証、権限、Secrets、監査ログ、CI/CD、委託先アカウントを棚卸しする。特に、漏えいした可能性のある秘密情報は削除ではなく失効・再発行を優先する。
次に読むなら、攻撃面の理解として サプライチェーン攻撃、認証設計として パスキー導入の落とし穴、侵害後の動きとして インフォスティーラーとAI時代の認証情報危機 を合わせて読むと、今回の事案を自社のGitHub運用に引き寄せて考えやすい。
