A person asking whether an online account was exposed needs a more specific answer than whether encryption keys were stolen. In the Cloudflare incident disclosed on February 23, 2017, the company said web responses had included private memory containing cookies, authentication tokens and submitted request data. This February 24 retrospective concerns those categories, not a finding that every customer lost information. [cf]
Cloudflare attributed its protection of customer SSL private keys to a separate process and memory space. That is a boundary around one kind of information, not an assurance about everything an account sends. For workers and small businesses following an incident notice, the useful distinction is between certificate protection and the application data described in the same report. [cf]
The February 24 Bitsight analysis raised another question: whether copies could remain outside the caches already contacted for removal. The security vendor warned that unknown caching services and historical archives might retain exposed pages. That was a possibility, not proof of a surviving copy for any particular account. Stopping the original disclosure therefore did not answer every question about previously exposed information. [bitsight]
Our suggested follow-up checklist asks the service operator what kinds of account information were involved, what evidence relates to the account and what advice it has issued about sessions or submitted data. Record unresolved cache questions separately. This approach avoids treating certificate-key protection as blanket reassurance, while also avoiding an unsupported instruction that every reader must reset every account. The sources establish a serious incident, not individual exposure determinations. [cf][bitsight]
Source documents
- Last Friday,https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
- Cloudbleed: Breakdown of Cloudflare's Memory Leakhttps://www.bitsight.com/blog/cloudbleed-breakdown-of-cloudflares-memory-leak