ClickUp把API密钥写死在代码里，959封企业邮箱裸奔15个月

你打开一个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线程时，现有的漏洞协调机制是否已经失效。