BtoBマーケティング支援の株式会社イノベーション（東京都渋谷区）、GitHubリポジトリが侵害され62,691名分が流出のおそれ — 認証情報を設定ファイルに直書き
| 項目 | 内容 |
|---|---|
| 発生日 | 公表されていない。2026年8月4日に第一報を公表 |
| 公表日 | 2026年8月4日（第一報）／2026年8月7日（確定報） |
| 対象組織・業界 | 株式会社イノベーション（Innovation Inc.／東京都渋谷区。法人向けIT製品比較メディア「ITトレンド」、マーケティングオートメーション「List Finder」等を提供／情報通信・IT） |
| 影響件数 | 62,691名分。氏名 62,631件、メールアドレス 62,691件、電話番号 506件。GitHub上のリポジトリに含まれていたものに限定される |
| 攻撃手法 | プログラムの設定ファイル内に直接記載されていたGitHubへの認証情報を第三者が取得し、悪用してリポジトリへ不正アクセス |
| 情報源 | 株式会社イノベーション「GitHubへの不正アクセスに関する詳細調査の完了およびセキュリティ対策強化のお知らせ（確定報）」（2026年8月7日）、Security NEXT（2026年8月19日）、ScanNetSecurity（2026年8月20日） |
法人向けIT製品比較メディア「ITトレンド」やマーケティングオートメーション「List Finder」を手がける株式会社イノベーション（Innovation Inc.／東京都渋谷区）は2026年8月4日、ソフトウェア開発およびシステム管理に利用しているソースコード管理サービス「GitHub」上の同社リポジトリが第三者に侵害されたと公表しました。8月7日には詳細調査を完了し、確定報を発表しています。
同社は原因を2つに整理しています。1つは、GitHubへアクセスするための認証情報が、プログラムの設定ファイル内に直接記載された状態で運用されていたこと。この認証情報を第三者が不正に取得し、悪用したことが不正アクセスの直接の原因とされています。もう1つは、社内の分析・開発作業の過程で、一部の個人情報がGitHub上のリポジトリ内にも保存されていたことです。
流出のおそれがあるのは62,691名分の情報で、内訳は氏名 62,631件、メールアドレス 62,691件、電話番号 506件です。同社は対象を「GitHub上のリポジトリに含まれていたものに限定」されると明記し、本番データベースへの不正アクセスや、本番環境からの情報漏えい、個人情報の不正利用等による被害は確認されていないとしています。
対応として、悪用された認証情報の無効化・停止を完了し、権限と発行ワークフローの見直し、レビュールールの強化、GitHubリポジトリへのアクセス監視の強化を実施しました。あわせて、個人情報を含むデータをリポジトリに保存しない運用ルールへの見直しと、リポジトリにアップロードされた場合の検知の仕組みを導入し、混入を未然に遮断する自動チェックの導入を進めています。連絡先を把握している対象者には個別に連絡するとしています。
- 侵入の時期: 公表されていない
- 2026年8月4日: GitHub上の同社リポジトリへの不正アクセスについて第一報を公表
- 2026年8月4日以降: 認証情報の無効化・停止を実施し、詳細調査を進める
- 2026年8月7日: 確定報を公表。原因を2点に整理し、対象を62,691名分と確定。再発防止策を発表
- 2026年8月19日〜20日: 報道により広く伝えられる
判明している事実: 同社は確定報で原因を明示しています。GitHubへの認証情報がプログラムの設定ファイル内に直接記載された状態で運用され、それを第三者が不正に取得して悪用したこと。そして、分析・開発作業の過程で一部の個人情報がリポジトリ内に保存されていたことです。一方で、その認証情報を第三者がどこから取得したのか、侵入がいつ始まったのかは公表されていません。
考えられる原因（推測）
Section titled “考えられる原因（推測）”説明されていないのは、設定ファイルに書かれた認証情報に、第三者がどうやって到達したかです。設定ファイルが公開範囲の広い場所に置かれていたのか、開発者の端末や別のサービスを経由したのか、いずれとも判断できる材料がありません。
一方で、被害の大きさを決めたのは2つ目の原因の側です。本番データベースは無事だったにもかかわらず62,691名分が対象になったのは、本番の防御とは無関係な場所に個人情報が置かれていたためです。同社が「社内の分析・開発作業の過程で」と書いているとおり、分析用に抽出したデータがそのままリポジトリに残っていたと読めます。氏名とメールアドレスがほぼ全件そろい、電話番号だけが506件と極端に少ないのも、業務システムの正規のテーブルではなく、ある目的のために切り出されたデータの形に見えます。
組織が学ぶべきこと
Section titled “組織が学ぶべきこと”1. 個人情報の所在の棚卸しに、リポジトリを含める
Section titled “1. 個人情報の所在の棚卸しに、リポジトリを含める”本番データベースは守れていました。それでも62,691名分が対象になったのは、リポジトリという別の場所に同じデータが存在していたからです。個人情報の保管場所の一覧が「本番のデータベース」で終わっていると、分析用の抽出データ、検証用のダンプ、調査のために貼ったログといった控えが台帳の外に残ります。守るべき場所を数え漏らせば、防御の強さは関係なくなります。
2. 認証情報は、流出した後の被害まで含めて設計する
Section titled “2. 認証情報は、流出した後の被害まで含めて設計する”設定ファイルへの直書きをやめて環境変数やシークレット管理に移すのは出発点です。同社が「権限と発行ワークフローの見直し」を挙げているとおり、そのトークンが何にアクセスできて、いつ失効するかを決めておけば、漏れたときに届く範囲が縮みます。読み取り専用か、リポジトリ単位に限定されているか、有効期限があるか。この3点の違いが、同じ流出から生じる被害の差になります。
3. 混入の防止を、人のレビューに委ねない
Section titled “3. 混入の防止を、人のレビューに委ねない”個人情報や認証情報がコミットに混ざるのは、判断の誤りというより作業の副産物として起きます。急いでいるとき、検証しているとき、一時的なつもりのときに入り込むので、レビューで毎回捕まえるのは現実的ではありません。同社が自動チェックの導入を進めているのは、この工程を人の注意力から切り離すためでしょう。
ヤグラの視点 — 二次攻撃の連鎖を断つ：法人向けサービスの会員名簿が、次の攻撃の材料になる
Section titled “ヤグラの視点 — 二次攻撃の連鎖を断つ：法人向けサービスの会員名簿が、次の攻撃の材料になる”流出したのは氏名、メールアドレス、電話番号だけです。カード情報も認証情報も含まれていません。それでも扱いが軽くならないのは、同社が運営しているのが法人向けのIT製品比較メディアとマーケティング支援サービスだからです。名簿に並んでいるのは、各社でIT製品の導入を検討し、資料請求や問い合わせを行った担当者ということになります。
なりすましのメールは、送り主に心当たりがあるほど通ります。自分で資料を請求した相手からの続報なら、疑う理由がないからです。しかも二次波は流出の翌日には来ません。名簿が別の攻撃者の手に渡り、文面が用意されるまでには時間がかかるため、事案が落ち着いた数週間後、数か月後に届きます。今回の62,691名分は、その大半が他社の従業員です。自社の担当者がこの名簿に載っているかどうかは、自社では確かめようがありません。
そのときに効くのは、送信元の見分け方を配ることではありません。迷った従業員がその場で報告できる窓口を1つに決めておくこと、そして報告された1通と同じメールが社内の誰に届いたのかを、届いた本人に聞かずに割り出せる状態にしておくことです（→ ヤグラ PhishAI）。1人目が報告してから2人目が開くまでの短い時間が、封じ込めに使える時間になります。
本件は原因・影響範囲・再発防止策のいずれも確定報として公表され、追加公表の予定は示されていません。混入を遮断する自動チェックの導入は進行中とされています。
- 参考: 認証情報が第三者に取得された経路と、侵入の時期は公表されていません
| 日時 | 内容 |
|---|---|
| 2026-08-21 | 2026年8月7日の確定報および2026年8月19日〜20日の報道をもとに記事を公開 |