2026年9月16日，CrowdSec获悉其GitHub仓库发生源代码泄露，泄露发生在同年5月，团队已核实并确认了该报告。CrowdSec的源代码分为两部分：一部分为私有代码，另一部分托管其免费开源软件（即安全引擎），后者本就公开，不在本次范围内。私有部分则包含其SaaS控制台的源代码、部分AWS云例行程序、一些连接器和自动化脚本。
正文
9月16日，CrowdSec 接到通报：我们的 GitHub 仓库发生源代码泄露，事件发生在 2026 年 5 月。团队已核实并确认了该通报。CrowdSec 的源代码分为两部分：一部分是私有的，另一部分托管我们的自由开源软件（即安全引擎），后者本就是公开设计，因此不在本次范围内。私有部分则包含 SaaS 控制台、部分 AWS 云例程、部分连接器和自动化的源代码。
关于「300 个不同仓库」的说法是准确的（包含 130 多个公开仓库），但这个数字主要反映代码的细分程度，而非特定体量。我们不确认所谓「包含其他文件」或「内部开发材料」，因为所有代码都发布在这些仓库里。API 相关信息是 CI/CD 组件自身使用的 token。
没有任何客户数据、登录名/密码、姓名、组织或其他信息泄露，CrowdSec 也不存储 PII 或客户日志，影响仅限于 CrowdSec 自身。团队迅速排查了任何可能用于横向移动的 token、凭证或敏感泄露，目前未发现。
这些私有仓库中的代码有价值，但并不会真正伤害 CrowdSec，因为我们的效率取决于网络效应和规模，仅靠代码无法复制。我们定期审计 SaaS 源代码，其泄露也不应构成直接威胁。大部分泄露代码在这四个月里已大幅演进，但我们仍会密切监控任何异常活动。此外，在 CrowdSec 之外使用它似乎不太可能，因为它只与我们的数据和工具交互，无法在别的场景中发挥作用。
我们会继续调查并更新进展，但 Tanstack 入侵极有可能是泄露途径（更多内容参见此处），与 Mistral AI 的情况类似。该组件今年 5 月曾在我们的组织中使用，似乎被植入了后门，用以提取一个有权读取私有代码库的 API 密钥。泄露仅在 2026 年 5 月的一个短暂时间窗口内可被利用。
我们仍立即轮换了所有必要的 token 和凭证，以防后续事件。
团队感谢 Fuites Infos 及时、专业地通报了此问题。
评论
整体气氛偏幸灾乐祸加技术不信任：多数人认为 CrowdSec 被黑说明它连自己的运维都保不住，配不上“安全公司”的自我定位；少数人则把问题归到 IP 信誉方案的结构性缺陷和供应链凭据管理上。分歧主轴是——这只是一次丢人的运维事故，还是这类黑名单聚合/SaaS 模式的必然结果。
认为它算不上真正的安全公司，只是坏 IP 聚合器
- 官网标语号称知道谁在攻击你，却漏掉了攻击自己的人；其本质是坏 IP 聚合器，这类数据更适合由可信的非营利机构运营，靠象征性查询费维持。（较多人）
- 又一家不践行自己信条的安全公司；即便据称没有泄露 PII，内部运维之烂仍是明显红旗，足以让采购方警惕。（较多人） > 他们号称知道谁在攻击你，却偏偏不知道谁攻击了自己。（@sandeepkd）
认为 IP 信誉方案本身就有误报和依赖问题
- 实际用于机器人/爬虫缓解时，架构合理但误报率高得无法接受，可能任何基于 IP 信誉的做法都逃不掉；团队准备数月，上线几天就关闭。（较多人）
- 有人同一天在 Debian 13 VPS 上修 CrowdSec：因为跑的是旧 Debian 打包版而非官方源，社区黑名单被停止供应并返回 HTTP 500；最后让 LLM 从公开来源自建黑名单，避免更深地绑定其 SaaS。（较多人） > 架构是合理的，但误报率高到我们无法接受，可能任何 IP 信誉方案都有这个问题。（@itintheory）
质疑轮换 API key 是否真能“防止进一步事件”
- 疑似攻击者拿到了提取代码所需的凭据；若用 Ubikey 加 SSL 证书做 git 访问控制，或许能阻止整起泄露。（较多人）
- 引述 Tanstack 被后门以提取可读私有代码库的 API key；轮换 key 不等于防止后续事件，下一次 PyPI/npm 供应链攻击仍可能拿到新 key；应审查并收窄 key 权限；还追问 GitHub 能否限制 API key 的请求来源。（较多人） > 轮换 API key 并不真能让他们“防止进一步事件”，下一次 PyPI/npm 供应链问题会拿到新 key 吗？（@6thbit）
名字相近但 CrowdStrike 未必是正面参照
- 多位用户玩 CrowdSec 与 CrowdStrike 的谐音梗，其中一位提醒别把两者混淆，称后者是“严肃的安全公司”，却附上 2024 年 CrowdStrike 全球宕机的维基链接，反讽意味明显。（少数人）
有价值的补充
- 对 CrowdSec 这类公共黑名单数据，有观点认为更适合由可信非营利机构运营，以象征性查询费维持，而不是绑定商业 SaaS。
- 关于 GitHub 能否限制 API key 的请求来源，评论只是提出疑问，没有结论；同一讨论里有人建议用 Ubikey 加 SSL 证书做 git 访问。
- 已有用户用 LLM 从公开来源生成替代黑名单，说明厂商 SaaS 锁定正在成为实际迁移动机。
- “安全公司被黑”本身成了社区情绪出口，一句式调侃就足以概括不少人的第一反应。