法人向けIT事業の会社で、GitHubの認証情報が漏れ、リポジトリ内のファイルに書かれた顧客情報62,691名分が漏洩

何が起きたか

この事故で流出した、または流出したおそれがある情報は、ソースコードと、リポジトリ内のファイルに書かれていた氏名・メールアドレス、一部の人の電話番号。62,691名分です。その後の対応と影響は、経路となった認証情報を無効にし、アカウントを遮断した。ソースコード内の認証キーとパスワードを無効にして再発行した。対象者にメールなどで個別に連絡したです。

原因になったのは「開発に使うGitHubの認証情報が漏えいし、リポジトリに不正アクセスされた」です。公表された内容では、生成AIは事故に関わっていません。

なぜ起きたか

公表されている直接の原因は、GitHubの認証情報が漏えいし、第三者がその認証情報で不正にアクセスした。認証情報が漏れた経緯は公表されていないです。それがどのように起きたかの詳しい経緯は、まだ公表されていません。新しい発表があれば、この記事に追記します。

原因の種類は「認証情報の漏れ」です。IDやパスワードが漏れ、なりすましで入られた事故を指します。このサイトに掲載している事故のうち、同じ種類の原因で起きた事故は28件あります。

事故が起きてから公表されるまで

1. GitHubの認証情報が漏えいし、第三者が不正にアクセス
2. 2026年8月4日速報を公表（最大約60,000件）
3. 8月7日調査結果を公表
4. その後確定報で62,691名分と公表

どうすれば防げたか

上の流れでは、最初から公表まで、途中で異常に気づいて止める仕組みが働いていません。

止められた可能性がある所（当社の見立て）

リポジトリに顧客の個人情報を置かず、GitHubの認証にトークンの期限や多要素認証を設定していれば、認証情報が漏れても被害を小さくできた可能性がある。

この見立ては、公表された原因から当社が考えたものです。当事者の調査の結果とは異なる場合があります。

自社で確認する3つの手順

上から順に、短い時間で確認できるものを並べています。

1. GitHubなどのリポジトリに顧客の個人情報を含むファイルが無いか検索する
2. 開発用アカウントとアクセストークンの一覧と期限を確認する
3. ソースコードに書かれたパスワードやAPIキーを検出するツールを入れる

自社に同じ原因があるか

当てはまるものを選んでください。1つでも当てはまれば、この事故と同じ原因が自社にもある可能性があります。

出典と更新の履歴

• 『GitHub』への不正アクセス発生に関するお知らせとお詫び（速報）2026.08.04
• イノベーションが利用する GitHub への不正アクセス、62,691名分の顧客情報が漏えい（ScanNetSecurity）2026.08.20