一个缓冲区溢出缺陷导致了数据泄露，少量发往Cloudflare proxies的请求拿到了其他不相关请求数据，包括潜在的敏感数据，例如密码、其他秘密信息。这个问题已经被命名为“Cloudbleed”，由谷歌零漏洞项目组研究员Tavis Ormandy发现并记录。部署了修复程序并尝试清空搜索引擎缓存之后，Cloudflare的John Graham-Cumming在一篇博客文章里详细地做出了解释。尽管有一些敏感数据泄漏，Cloudflare的创始人和CEO Matthew Prince在推特发表申明“我认为我们很大程度上避开了实际影响”。

在这篇解释性博客文章，以及CEO Matthew Prince致客户的邮件里，Cloudflare费尽心力强调要保护好SSL私钥，因为这些私钥被用于单独隔离的Nginx实例中。这次泄漏是由于Nginx插件组合引起的，Cloudflare使用这些插件去处理客户请求。新引入的插件让一个隐藏在老插件里的问题暴露了出来，在解析不规范的HTML文档时会出现问题。

这次事故预计已经影响了2017年2月13日到2017年2月18日之间，通过Cloudflare proxies的每3,300,000个HTTP请求当中的1个。安全专家Troy Hunt在他的文章“实际思考CloudBleed”中指出，这一可能性可以和“中大奖”相媲美，虽然这里的问题有双重性：首先，制造泄漏的网站本身也是无辜的受害网站，它又进一步放大了泄露问题，其次，我们没有办法“检查信息”，确保是否是泄漏受害者（同样适用于调用Cloudflare和它们的访客网站）。Tony指出这些访客或者例如博客一类的公共站点没有什么可以担心的，对于那些对数据敏感的网站来说就不一样了，例如约会网站和银行。AgileBits费尽全力指出1-Password是安全的，同时Monzo指出这次问题只是潜在地影响了开发人员API用户的一小部分。

Cloudflare推迟了通知时间，同时联合搜索引擎一起清空缓存数据，追踪从161个独立域名发送过来的770个请求URI。这样做的目的是防止通过进入搜索引擎缓存的方式使用私人数据。虽然Cloudflare和Google从一开始就进行合作，这个问题看起来有点紧迫，清除行动可能没有像最初预期的那么快完成。

Graham-Cumming的博客文章建议事故修复之后，通过非常容易理解的日志引导，允许Cloudflare确定问题的范围和规模，并且设定补救措施的目标。就像最初希望的那样达到目标。它的观点是，Cloudflare躲过的风险很有可能是真实的，不仅仅危害了Cloudflare和它们的客户，也对大量的web用户产生危害。Cloudflare预估可以在大于所有web峰值的10%的情况下正常工作，而且对于大多数人来说，不可能一天内不使用Cloudflare，因为它为很多程序提供后台支撑。如果这个缺陷已经明晰，那么它应该很快就会被注意到，但是也可能对于Cloudflare和它的客户造成更大的伤害。使用类似于Cloudflare一类服务的风险正在增加，它们充当了web用户和真实访问服务之间的“裁判”角色，必须找到平衡方式，就好像加强羊群内部的群体免疫能力一样。事情的另一面，很少有组织愿意对于自身基础设施这类错误进行快速而彻底地响应，就像Cloudflare做的那样。他们使用的全局特性标志允许他们快速地把引起问题的堆栈信息移除掉。

事故发生后我们通常会问：“我是不是应该修改密码？”，舆论（反感风险）的回答是应该，安全比到时候说抱歉有用得多。总的来说，任何一个人的私密信息被以一个可以利用的方式泄漏的机会非常低（可能远远低于相同的私密信息通过恶意软件或者其他类似方式泄漏的可能性）。Cloudflare和更广义的网络安全社区已经从这起事故中学到了很多，但是当类似于C语言这样的不安全语言被继续用在对安全敏感的基础设施领域的话，我们可以确信类似的事故会再次发生（是的，再一次发生时goto陷阱仍然会是元凶）。

查看英文原文： Cloudbleed - Cloudflare Proxies Memory