适用对象:在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(自7月起仅限工作日10:00–19:00,日本境内免费);在日本,如有诈骗相关疑问,可拨打警察咨询热线#9110。
事件经过(依据CAMPFIRE的公告)
公司自2026年4月3日起陆续发布了一系列公告,并于6月2日发布调查报告。以下内容均依据公司官方公告。
2026年4月2日,约22:50(日本时间)
发现第三方未经授权访问了用于系统管理的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,《为组织设置个人访问令牌策略》— 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年的数据泄露与网络攻击