What do exploit, exploitable, and exploit code mean in cybersecurity terms?

Trying to clear up some confusion.

“Words mean things,” as one of my Marine Corps instructors eloquently stated.

Jokes about eating crayons aside, sometimes Marines do make important points simply.

And in cybersecurity, using precise language is incredibly important for effective communication…and action.

So I wanted to drill down on the word “exploit” and some of its variations in this post. I have written quite a bit about it in different contexts. And I must unfortunately admit that I have conflated certain concepts myself.

For example, I have noted that 10% or less of Common Vulnerabilities and Exposures (CVEs) are exploitable in any given configuration. In the relevant article, however, I included studies regarding the public availability of exploit code, the exploitability of vulnerabilities, and the percentage of known vulnerabilities exploited in the wild.

These are all slightly different things, and, in addition to adjusting the above article, I wanted to define them all more carefully.

What is exploitation?

Exploitation is the use of a software vulnerability to impact a target’s desired data confidentiality, integrity, or availability. This can be through the use of manual or automated means.

The verb form would be to “exploit” a vulnerability.

Exploitation “in the wild” refers to that conducted by a malicious party (or a simulated one like a penetration tester, ethical hacker, security researcher, etc.) against a network or application not created solely for the purpose of being exploited.

Per my previous post, only a very narrow percentage of software vulnerabilities are exploited in the wild.

What does exploitable mean?

A vulnerability is exploitable in a given context if a (simulated) malicious actor could use it to impact the target’s desired data confidentiality, integrity, or availability in that context. Re-writing the target’s code necessarily changes the context.

To be a vulnerability, something must by definition be exploitable in at least one context. But considering which contexts it is exploitable in is extremely important from a risk management perspective.

I have no doubt the vast majority of submissions to the National Vulnerability Database (NVD) are good-faith statements from researchers that certain code meets my definition. But the vast majority of these entries are “science projects” and the context required for exploitation is highly unrealistic. In many real-world scenarios, one would in fact need permissions to re-write code in the target’s application or network to make use of the vulnerability in question.

Just as an example, according to one study only 15% of vulnerable aspects of third-party components are loaded to memory at runtime.

To exploit the remaining 85%, an attacker would need to rewrite the target application to load the vulnerable components. From a risk management perspective this isn’t really worth worrying about. Because if an attacker can re-write the target’s code, they almost certainly aren’t going to be risking detection by loading known vulnerable components to memory. There are rare cases, such as during a software supply chain attack, where this might be conceivable, but I am not aware of any real-world examples of it happening.

During the SolarWinds incident, the attackers inserted their own malicious code into the company’s software to use as a backdoor to compromise other organizations and may have leveraged existing exploitable vulnerabilities to do so. But I haven’t seen evidence they did anything as elaborate as making previously unaccessible vulnerabilities reachable by modifying code.

Thus, very few known vulnerabilities are exploitable in any given context.

What is exploit code?

Exploit code is human- or machine-readable instructions that allow a (simulated) malicious actor to exploit a software vulnerability.

Confusingly, practitioners often just use “exploit” in noun form to refer to this.

Public exploit code can be accessed by anyone with an internet connection and does not require authentication to view.

And just because valid public exploit code is available doesn’t mean a vulnerability has been (or ever will be) exploited in the wild. A security researcher could easily purpose-build an environment, exploit a vulnerability using it, and then post exploit code for it. And that might be the last time the exploit code is ever used.

But with that said, there is a a strong correlation between the presence of exploit code and occurrences of exploitations in the wild. And things like the Exploit Prediction Scoring System (EPSS) understandably take this into account as part of its model.

Conclusion

I find many disagreements in the cybersecurity world to be rooted in definitional misunderstandings, or the absence of an accepted definition entirely. My goal here has been to reduce some of the associated noise and give practitioners a base from which to operate. If you have recommended changes or a better model, then by all means let me know if the comments section.