適用對象:曾在CAMPFIRE發起專案、支持專案、收到退款或登錄為合作夥伴的人,以及在工作中使用GitHub與雲端服務的開發者與營運者。本文以CAMPFIRE官方公告為基礎,不涉及攻擊手法。
使用者現在應該做什麼
確認自己是否受影響——通知郵件的主旨是固定的
自2026年4月24日起,該公司已逐一以電子郵件通知受影響者,郵件日文主旨為「【重要:CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告」(關於客戶資訊可能外洩的致歉與報告)。受影響族群如下:
- 2026年4月9日前使用服務的部分專案與社群主
- 以PayPal付款的支持者(2021年1月1日至2026年4月19日),或使用「今度払い(Kondo-barai)」延後付款的支持者(2022年1月3日至2023年4月24日)
- 以銀行轉帳收到退款的支持者(2022年1月6日至2026年3月5日)
- 2025年3月5日前完成登錄的合作夥伴
- 2020年在帳戶頁面編輯過銀行資料的人
若您符合上述任一條件但找不到郵件,仍請依照以下步驟進行。
不要開啟與退款或撥款帳戶有關的訊息中的連結
可能面臨風險的資料包括姓名、地址、電話號碼、電子郵件地址與銀行帳戶資料。若您收到「為退款重新登錄帳戶」或「請確認撥款要匯到何處」之類的訊息,請不要點開連結;如有需要,請從書籤或自行輸入的網址登入CAMPFIRE。該公司表示,從不會透過電話或電子郵件索取PIN碼(基礎知識:什麼是網路釣魚)。
檢查銀行對帳單
該公司表示,可能外洩的銀行資料本身無法用來提領現金或進行轉帳。若您看到不熟悉的交易,請立即聯絡銀行或該公司。若您使用網路銀行,開啟交易通知會更方便察覺異常。
拒收不是您訂購的貨到付款包裹
由於資料包含地址,該公司提醒需留意寄送您未訂購之貨到付款包裹的詐騙。收貨前請先確認寄件人與內容。
更改在其他服務上重複使用的密碼
該公司請在其他服務上使用相同電子郵件與密碼的人,作為預防措施予以更改。密碼並不在列出的項目之中,但請立即停止重複使用;密碼管理工具是實際可行的做法。
專案主:也請告知您的團隊
若公司或團體負責營運您的專案,員工可能會收到冒充撥款或審核通知的電子郵件。請團隊共同約定,在CAMPFIRE後台確認撥款帳戶變更,不要僅依電子郵件指示行事。
該公司專線為0120-188-070(日本境內免費,10:00–19:00 JST,7月起僅限平日),在日本,詐騙相關諮詢可撥打警察諮詢專線#9110。
事件經過(依CAMPFIRE公告)
該公司自2026年4月3日起陸續發布公告,直至6月2日的調查報告。以下內容均依據該公司官方公告所述。
2026年4月2日,約22:50 JST
識別出第三方未授權存取用於系統管理的GitHub帳戶,且部分原始碼可能遭檢視(如首份公告所述)。4月3日
偵測到部分GitHub儲存庫有可疑操作;相關帳戶遭移除,並更換可能已遭竊取的憑證。發布首份公告(當時未確認個人資料外洩)。4月7日
確認GitHub憑證外洩的原因。4月14日
第二份公告:GitHub帳戶可檢視一名業務合作夥伴的姓名與聯絡資訊,以及413名參與開發工作者的姓名與電子郵件地址。已向日本個人資料保護委員會通報。4月20日
偵測到用於內部業務的雲端環境遭未授權存取;遭不當使用的帳戶與資源已停止並停用。4月22–24日
第三份公告指出,管理客戶資訊的部分系統出現未授權存取的痕跡。第四份公告(24日)揭露可能外洩的範圍(225,846筆獨立受影響使用者紀錄),並開始逐一通知。4月27–28日
第五份公告細分了相關數據。28日開設專用諮詢專線。5月30日/6月2日
外部鑑識調查完成(5月30日)。6月2日,該公司公布調查結果與預防措施。
- 部分專案與社群主
- 姓名、地址、電話號碼、電子郵件地址、銀行帳戶資料。108,784筆(其中53,869筆含銀行資料)
- 部分支持者
- 姓名、地址、電話號碼、電子郵件地址、銀行帳戶資料。118,010筆(其中4,307筆含銀行資料)
- 合作夥伴
- 姓名。1,282筆
- 類別不明(例如註冊中)
- 2020年在帳戶頁面編輯過銀行帳戶資料者的銀行帳戶資料。10,521筆
- 其他
- 413筆與開發工作相關的姓名與電子郵件地址可被檢視
- 信用卡資料
- 未包含
- 鑑識結果
- 某特定雲端環境中儲存的憑證與API金鑰、部分不含個人資料的資料檔案,以及資料表名稱與設定資訊遭取得。探查過程中,一筆含個人資料的紀錄以查詢結果輸出。未發現含個人資料的檔案被傳出的跡象
- 公司評估
- 因部分區域未收集日誌,該公司無法排除資料曾被檢視的可能
- 次生危害
- 公告發布時,未有資料遭濫用造成損害的通報
給開發者與營運者:從GitHub權杖到內部雲端
該公司6月2日的報告對事件順序與成因描述得相當具體。下圖依該公司所述呈現路徑,右側為在各階段可防止或限制損害的設定。
1. 員工發行的GitHub憑證
無意中上傳至個人專案伺服器
↓→
組織政策:封鎖傳統權杖,限制有效期間
2. 組織儲存庫
部分原始碼與413名員工的資料可被檢視
↓→
最小預設權限,儲存庫中不放個人資料
3. 從GitHub資訊取得雲端憑證
↓→
不使用長期有效的雲端金鑰(改用短期驗證)
4. 內部雲端管理區域的一部分
憑證、API金鑰、資料表名稱遭取得
↓→
全面稽核日誌,針對異常操作發出警示
5. 225,846筆獨立受影響使用者紀錄中的客戶資料面臨風險
↓→
盤點正式環境之外的客戶資料
據該公司表示,服務運行於與發現未授權存取的雲端環境分離的環境中,且未發現服務平台遭不當使用或竄改。然而,客戶資料仍因可從內部業務雲端存取而面臨風險。
該公司表示,相關憑證原本應只在其管控的環境中處理,並限制在最低必要權限;其憑證管理與權限設計的機制與規範並不足夠。該公司表示已完成的措施包括:
- 從依賴個人存取權杖,改為權限受限的驗證方式
- 檢視組織內的預設存取權限
- 加強稽核日誌收集與警示
- 導入程式碼弱點掃描工具
若您想在自己的組織中採取相同做法,可以從這三項開始。
在GitHub組織中設定個人存取權杖政策
在組織的「設定」中的「Personal access tokens」,GitHub讓組織擁有者可以:
- 禁止個人存取權杖(傳統版)存取組織資源
- 要求管理員核准細粒度權杖(較新的類型,限定特定儲存庫與權限)
- 設定權杖的最長有效期間
由於無法完全防止工作權杖落入個人電腦或伺服器,務實的防禦方式是確保權杖即使外洩,也會很快失效,且可存取的範圍極小。
讓長期有效的雲端金鑰遠離儲存庫
該公司表示,第三方利用GitHub上可見的資訊找到並取得了雲端憑證。若GitHub Actions會部署到您的雲端,請改用透過OpenID Connect(OIDC)進行的短期驗證,為每次執行發放臨時憑證,並讓長期存取金鑰不出現在儲存庫與設定檔中。
請先掃描您的儲存庫(包括歷史紀錄),並撤銷及重新發行找到的任何憑證;參見使用gitleaks在提交前攔截機密。GitHub的推送保護可阻擋含有機密的推送,對公開儲存庫免費提供,私人儲存庫則需包含在付費的GitHub Secret Protection中。
列出所有位於正式環境之外的客戶資料位置
分析平台、內部工具、客服管理後台、匯出的CSV檔。無論正式環境防護得多嚴密,其他環境中的客戶資料副本仍可能外洩。針對每個位置,記錄哪些憑證可以讀取,以及操作是否有留下日誌。
CAMPFIRE表示,因部分區域沒有日誌,無法排除資料被檢視的可能。若沒有操作日誌,就無法證明沒有人檢視過資料。
本站觀點:權杖設計應假設它們會離開公司的機器
該公司表示,一名員工發行的GitHub憑證在無意中被上傳至該員工用於個人開發的伺服器。這不是針對任何個人的問題,而是每個組織都存在的事實——開發者也會在下班後寫程式。工作權杖離開受管理機器的機率無法降為零。因此,防止外洩並不足夠,權杖必須設計成:一旦外流,就會迅速過期,且可存取的範圍極小。
同年,南韓TVING的一名開發者的存取金鑰即足以存取所有原始碼與正式環境憑證(TVING資料外洩事件)。當年日本各起事件的共同入侵途徑,則在2026年的資料外洩事件都利用了合法憑證中說明。
資料來源(公開紀錄)
本文事實依據以下公開來源。我們不對未公開的手法進行推測。
- CAMPFIRE, Inc.,關於GitHub帳戶遭未授權存取的公告(2026年4月3日;日文)— campfire.co.jp
- 同上,第二份公告(2026年4月14日)— campfire.co.jp
- 同上,第三份公告(2026年4月22日)— campfire.co.jp
- CAMPFIRE, Inc.,因未授權存取而可能外洩個人資料的致歉與報告(2026年4月24日)— campfire.co.jp
- CAMPFIRE, Inc.,可能外洩範圍的後續說明(2026年4月27日)— campfire.co.jp
- CAMPFIRE, Inc.,開設專用諮詢專線(2026年4月28日)— campfire.co.jp
- CAMPFIRE, Inc.,未授權存取事件的調查結果(2026年6月2日)— campfire.co.jp
- GitHub Docs,「Setting a personal access token policy for your organization」— docs.github.com / 「About push protection」— docs.github.com / 「About security hardening with OpenID Connect」— docs.github.com
更新紀錄
2026-10-19:將單位由「人」更正為官方的獨立使用者紀錄數,區分可能外露與已確認的發現,並保留重疊的類別而不加總。
2026-09-30:首次發布,依據CAMPFIRE自2026年4月3日首份公告至6月2日調查報告的公告內容撰寫。紀錄數依6月2日報告的細分數字。
延伸閱讀
- 今年另一起日本案例:Medica Shuppan(醫療專業人員與作者的銀行帳戶資料)
- 後續詐騙:什麼是網路釣魚 / 如何選擇密碼管理工具
- 開發者:使用gitleaks在提交前攔截機密 / 自架Git與GitHub的安全性比較 / .env與API金鑰基礎
- 相同模式:利用合法憑證的資料外洩事件 / TVING資料外洩事件
- 其他2026年事件:2026年的資料外洩與網路攻擊