Computer vulnerabilities compromising a digital system or service – may allow unauthorized access to digital systems. When they are exploitable, these vulnerabilities can compromise the security of operations and transactions, the confidentiality of data, the privacy of our (digital) lives, the credibility of a company and many more.
A vuln is not an unitary object across the intl. infosec arena. Like in the case of EFAIL (cf. art Tsantsa): a vuln is/might be a series of debates, tech issues, an academic interest, of activism importance, etc. i.e. a lot of very different things, groups, concerns, utility, etc. Therefore, when we met people interested about the vuln X, we always have to start asking about which instance are they talking about.
A vuln like EFAIL is found in every instance or piece of software or library that is implementing OPENPGP and SMIME; at least until a patch is shiped. then, it depends if the user patch its software. by nature this is patchy. but the vuln exist before it is known as a vuln, with a shiny website and a logo following a more or less orchestrated public disclosure. It exists before the researchers found it. at least in the potentiality of a vulnerable code. a risk, an acknowledgment that every piece of code is and will remain vulnerable. security is never acheived, it is not a state, it is a process. the researchers, with the help of the research process itself, bring to a certain existence this potentiality, that takes shape in a particular form, a PoC, a call, a vuln report, ect. (and sometimes that particular existence is only one form taken by the potentiality as it happen that few weeks or months after disclosure another team find another similar attack in the remediated code, re-opening again, so to say, the same wound).
