# サイバーセキュリティクラウド、GitHubの認証情報流出で情報漏えいか

- 分類: 漏洩情報
- 公開日: 2026年11月12日
- 発行: サイバーセキュリティ情報センター 編集部（株式会社Rabbitly）
- URL: https://security-info.org/articles/2026-11-12-cscloud-github-credential-leak/
- タグ: 不正アクセス、外部サービス

> サイバーセキュリティクラウドは11月12日、従業員のGitHub認証情報1件が流出し、開発用の領域に不審なアクセスがあったと公表しました。一部の顧客の企業名、氏名、メールアドレスなどが漏えいしたおそれがあり、対象は調査中です。

## この事故の概要

| 項目 | 内容 |
| --- | --- |
| 組織 | 株式会社サイバーセキュリティクラウド（IT） |
| 公表日 | 2026年11月12日 |
| 流出の恐れがある件数 | 調査中 |
| 原因 | 従業員が業務で使っていたGitHubの認証情報1件の流出 |
| 漏れた情報 | 一部の顧客の企業名、氏名、メールアドレスなど、サービス利用に伴う通信関連情報 |
| 発覚 | 2026年11月5日 |

Webサイトを守るサービスなどを提供するサイバーセキュリティクラウドは2026年11月12日、ソフトウェア開発に使っている「GitHub」の自社の管理領域に不審なアクセスがあり、そこに保存していた個人情報が漏えいしたおそれがあると公表しました。第一報で、対象の範囲は調査中です。同社のサービスは通常どおり提供されていて、サービスへの不正アクセスや不正な操作は確認されていません。

## 何が起きたのか

きっかけは外部機関からの情報提供でした。同社の従業員が業務で使っていたGitHubの認証情報1件が、外部に流出していることが分かりました。GitHubはプログラムや開発に関する情報を保管し、複数人で管理するためのサービスです。

同社がGitHubのアクセスログを調べたところ、この認証情報を使った第三者によるものと考えられる不審なアクセスが過去に行われていたことを、11月5日に確認しました。不審なアクセスがあった時期は「過去」とあるだけで、日付は書かれていません。

確認できるアクセスログは対象の期間と記録の内容に制約があり、認証情報が有効だった期間の全体については、アクセスの状況を確認できていないとしています。

流出した認証情報がパスワードなのか、プログラムから使うトークンなのかは書かれていません。認証情報がどこからどのように流出したかも調査中です。

## 漏えいのおそれがある情報

同社のGitHubに保存されていた次の情報は、第三者に閲覧、取得された可能性を否定できないとしています。

- 一部の顧客に関する情報（企業名、氏名、メールアドレスなど）
- サービスの利用に伴う通信関連情報

件数と対象者は調査中で、対象と確認できた顧客には順次案内するとしています。同社が顧客から取り扱いを委託されている個人情報については、委託元の顧客と連携して、本人への通知などを進めます。

「通信関連情報」が具体的に何を指すかは、お知らせには書かれていません。

## サービスへの影響と会社の対応

11月12日の時点で、この件に起因するサービスへの不正アクセスや不正な操作、二次被害は確認されていません。サービスの提供とセキュリティ機能への影響も確認されておらず、各サービスは通常どおり動いています。

被害を広げないために済ませた対応として、同社は次の4つを挙げています。

- 流出したGitHubの認証情報を無効にした
- GitHubに保存されていた、ほかのサービスの各種認証情報を確認し、変更した
- 関連する認証情報とアクセス権限を見直し、変更した
- 関係する開発用の端末を隔離し、アカウントの利用を止めた

原因と影響範囲については、GitHubと関連システムのアクセスログの調査と、同社のセキュリティエンジニアと外部の専門機関によるフォレンジック調査を進めています。フォレンジック調査は端末やサーバーに残った記録から、何が行われたかを復元する調査です。

個人情報保護委員会などの関係機関には報告済みです。個人情報の取り扱いを同社に委託している顧客は、委託元として自らも個人情報保護委員会へ報告する立場になります。この報告について同社は連名での報告を含めた方法を相談中で、決まり次第案内するとしています。

問い合わせの窓口は顧客とパートナー向け、株主と投資家向けの2つのメールアドレスです。

## 中小企業が学べること

今回のお知らせからは、GitHubの中に顧客の情報と、ほかのサービスの認証情報が保存されていたことが読み取れます。GitHubのような開発用の保管場所はプログラムを置くための場所ですが、動作確認に使った顧客データの写しや、設定ファイルに書いたパスワードがそのまま入ってしまうことがあります。そうなると、開発者1人の認証情報が漏れただけで、プログラムと一緒に顧客の情報やほかのサービスの鍵まで見られます。同じ形の事故は[アイル「CROSS POINT」、漏れたAPIキーで会員情報を取得](/articles/2026-11-10-ill-cross-point-api-key/)でも起きています。

開発を外の会社に任せている場合も、リポジトリの中身は発注した側の持ち物です。制作会社や開発の担当者に、リポジトリに顧客データやパスワードが入っていないかを確かめてもらい、入っていれば取り除いたうえで、そのパスワードやキーを作り直します。履歴に残ったものは、ファイルを消しただけでは取り出せるためです。

記録の残る期間も、事故のあとの調査を左右します。同社はログの期間と内容に制約があるために、認証情報が有効だった期間の全体を調べきれていません。GitHubに限らず、クラウドサービスのアクセスの記録は、契約のプランによって見られる期間が決まっています。記録を何日分さかのぼれるかを事故が起きる前に調べておくと、漏えいの範囲を言い切れるかどうかが変わります。

## 自社で確かめること

1. **GitHubに置いているもの**：開発の担当者や委託先に、リポジトリの中にお客様の名簿、問い合わせの記録、ほかのサービスのパスワードやキーが入っていないかを聞きます。
2. **退職者と委託先のアカウント**：GitHubの組織のメンバー一覧を開き、退職した人、契約が終わった会社の人が残っていれば外します。2要素認証を全員に必須にしているかも見ます。
3. **アクセスの記録が残る期間**：契約しているプランで、誰がいつ何を取り出したかの記録を何日前まで見られるかを調べます。短ければ、記録を別の場所に写して残す設定を開発の担当者に頼みます。

## 出典

- [株式会社サイバーセキュリティクラウド「当社開発環境における情報漏えいのおそれに関するお知らせとお詫び（第一報）」（2026年11月12日）](https://www.cscloud.co.jp/news/info/20261112-2/)