你打开一个SaaS产品的官网,右键查看页面源代码,复制一段字符串,然后拿到了近千家Fortune 500企业的员工邮箱。这不是电影桥段,是2025年1月到2026年4月之间真实发生的事。

场景还原:一次"过于简单"的数据泄露

打开网易新闻 查看精彩图片

安全研究员的发现过程简单到令人不适:访问ClickUp首页,打开页面源码,在JavaScript文件中找到硬编码的第三方API密钥,复制,发送一个GET请求。返回结果:959个邮箱地址,3,165个内部功能开关。

整个过程不需要认证,不需要绕过,不需要任何复杂工具。密钥在页面加载时就暴露给每一个访客,早于任何用户登录环节。

泄露的邮箱名单横跨企业和政府领域:Home Depot、Fortinet、Autodesk、Tenable、Rakuten、Mayo Clinic、私募机构Permira、律所Akin Gump,以及美国怀俄明州、阿肯色州、北卡罗来纳州、蒙大拿州、澳大利亚昆士兰州和新西兰的政府工作人员,外加一名微软承包商和71名ClickUp自家员工。

这份名单的讽刺之处在于,Fortinet生产企业级防火墙,Tenable开发的Nessus是网络安全行业广泛部署的漏洞扫描器。两家安全公司的员工邮箱,因为一家生产力工具的密钥管理疏漏,躺在公开可访问的接口里。

正方:这不是技术失误,是流程崩塌

硬编码密钥是安全社区讨论多年的基础问题。客户端JavaScript中嵌入密钥属于"文档完备且完全可预防"的漏洞类别,任何现代开发规范都会明确禁止。

ClickUp的融资记录显示其累计获得5.35亿美元投资,估值40亿美元,公开宣称85%的Fortune 500企业使用其平台。以这种资源密度,基础设施安全团队理应有能力识别并修复此类问题。

时间线更令人困惑。漏洞于2025年1月17日通过HackerOne上报,至2026年4月下旬已逾15个月,密钥仍未轮换。研究员在公开披露前几分钟仍能拉取完整数据响应。这不是零日漏洞,是已知漏洞在生产环境持续 harvesting 企业个人信息超过一年。

泄露的3,165个功能开关同样构成风险。这些内部信号暴露产品路线图、Beta功能配置、A/B测试参数——对竞争对手有价值,对攻击者则是精准利用平台弱点的情报。

反方:SaaS规模化下的隐蔽债务

但换个角度,这件事也反映了超高速增长SaaS公司的典型困境。

ClickUp的功能边界持续扩张,从项目管理延伸至文档、白板、聊天、目标追踪。产品模块的堆砌意味着第三方集成数量的指数级增长,每个集成点都是一个潜在的密钥管理节点。

前端JavaScript的密钥暴露问题之所以顽固,部分原因在于技术债的隐蔽性。这类密钥往往服务于"看似无害"的功能——分析埋点、A/B测试分流、客户支持工具——在业务优先级排序中难以获得安全审查资源。

15个月的修复周期看似荒谬,但在大型代码库中,一个嵌入首页JavaScript的第三方服务密钥,可能牵扯多个团队的协调:前端架构、基础设施安全、第三方供应商关系、数据合规。任何一环的响应延迟都会累积成公开可见的失职。

更值得追问的是披露机制本身。HackerOne等平台的漏洞报告在厂商侧往往流入复杂的内部工单系统,缺乏强制性的修复时限约束。研究员的公开披露成为最后的问责手段,而非第一道防线。

判断:密钥管理正在从"技术问题"变为"信任基础设施"

这起事件的核心矛盾不在于ClickUp是否"应该"犯错,而在于企业客户如何重新评估SaaS供应商的安全边界。

传统上,Fortune 500企业的安全团队将资源集中在自身基础设施和核心供应商的SOC 2审计报告上。但ClickUp这类"生产力层"工具处于尴尬位置:它处理敏感工作流数据,却常被归类为"低风险"通用SaaS,采购流程中的安全审查深度远低于核心系统。

959个邮箱的泄露规模本身有限,但攻击面指向精准的后续利用。企业安全人员的邮箱是钓鱼攻击的高价值目标,功能开关数据则支持针对性的社会工程学设计。Fortinet和Tenable的员工成为受害者,恰恰说明攻击者会优先瞄准安全从业者——他们掌握着更多内部系统的访问路径。

更深层的信号是SaaS供应链的脆弱性传导。ClickUp的一个JavaScript文件,成为连接数十家企业和政府机构的单点故障。这种"小供应商、大暴露面"的结构在云计算普及后愈发常见,却缺乏对应的风险定价机制。

对于科技从业者,这起事件提供了具体的检查清单:审查团队使用的SaaS工具是否存在客户端硬编码密钥,验证漏洞响应SLA是否写入合同,以及重新评估"低风险"分类下的工具权限范围。密钥管理工具如Doppler、HashiCorp Vault的普及正在降低技术门槛,但流程层面的责任归属仍是多数组织的盲区。

ClickUp的15个月沉默,最终由一次公开披露终结。这种叙事模式在网络安全领域反复上演,却鲜少改变厂商的行为 incentives。真正的问题或许是:当"修复已知漏洞"需要依赖外部研究员的Twitter线程时,现有的漏洞协调机制是否已经失效。