一個緩沖區溢出缺陷導致了數據泄露，少量發往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做的那樣。他們使用的全局特性標志允許他們快速地把引起問題的堆棧信息移除掉。

事故發生后我們通常會問：“我是不是應該修改密碼？”，輿論（反感風險）的回答是應該，安全比到時候說抱歉有用得多?？偟膩碚f，任何一個人的私密信息被以一個可以利用的方式泄漏的機會非常低（可能遠遠低于相同的私密信息通過惡意軟件或者其他類似方式泄漏的可能性）。Cloudflare和更廣義的網絡安全社區已經從這起事故中學到了很多，但是當類似于C語言這樣的不安全語言被繼續用在對安全敏感的基礎設施領域的話，我們可以確信類似的事故會再次發生（是的，再一次發生時goto陷阱仍然會是元兇）。

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