The Vulnerability Identity Crisis
Jay Jacobs and Art Manion presented "The Vulnerability Identity Crisis" at the 38th Annual FIRST Conference, Denver, June 14–19, 2026.
Art Manion and I have been spending roughly an hour a week for the past couple of years working through what sounds like a simple question: What are the minimum viable elements needed to define and identify a vulnerability? We had a few early attempts at frameworks, and talked through several fields and options, but we couldn’t find something that worked in every case. As we kept talking, we found that we had to be more precise, we had to stop and talk about concepts like “weakness” and we got wrapped up in questions like “what makes a vulnerability different from a regular bug?”. All of this leads us to a deceptively complex question: “What is a vulnerability?” But not in a “make a glossary” sense, we wanted to get at what a vulnerability is in the structural sense. We needed to understand the concept of a vulnerability. We needed to understand what a vulnerability is so we could separate vulnerabilities from bugs and define what is vulnerable, how it’s vulnerable and what happens when it’s exploited. After nearly two years of our weekly discussions we realized we need a working definition that captures the concept of vulnerability in order to know how to accurately describe and identify a vulnerability when we see it.
We've presented pieces of this at VulnCon (2025 and 2026). We've been forced to change our minds more than once (which we consider a really good sign). This talk at the FIRST 2026 Annual conference was our latest iteration, and we think we've arrived somewhere worth talking about.
The Problem We Keep Hitting
The problem we kept running into is that for every possible set of elements we would come up with (to describe and define a vulnerability in a record), we would find exceptions. Art has been studying vulnerabilities for years and can generally remember some vulnerability that didn’t fit into whatever mold we attempted to craft.
As an example of this in practice, go flip through the vulnerabilities with a “disputed" tag. Every disputed record is an example of where the system fails. Probably the best example of this is CVE-2020-19909: an integer overflow in cURL's --retry-delay argument parser. It prompted the cURL maintainer, Daniel Stenberg, to write a blog post where he said, “A bug, sure. Security problem? No.” The argument against it being a vulnerability is that in order to set the value of a command line argument, the actor must have access to run something at the command line. Exploiting this integer overflow would then allow them to… run something at the command line. In that scenario, nothing is gained by the attacker, or to rephrase that, there is no security property (or security policy/boundary) violated during exploitation.
The point here is that after reading a small handful of disputed CVEs (and then searching to figure out exactly why they are disputed), an obvious question is raised: if we cannot agree on what exactly a vulnerability is, how can we be sure we are collecting the right data? If two security professionals can look at an integer overflow and one says it is just a bug and the other says it is a vulnerability, clearly we’ve got a serious misalignment and any definition we may have for a vulnerability is insufficient. We need a working definition.
To move forward on this, we found 29 definitions of "vulnerability" across academic papers, frameworks, and standards bodies. They share many surface features: some notion of weakness, some notion of an affected system, some mention attackers and many included probabilistic language (“can”, “may”, “could”) around the outcome/impact or exploitation. But they are all generally superficial and do not cover the edge cases, the disputed cases. Another interesting discovery is that most definitions limit to “vulnerability”. In order for us to clearly communicate a vulnerability we actually needed to define six different terms and concepts. We found that the other terms around a vulnerability are equally vague and undefined.
The Dispositional Definition
A vulnerability is a disposition.
The word “disposition” is not exactly common, and that is intentional. We need a shock, we need a shift in our perspective and we need to be humble enough to accept it. Disposition has been heavily discussed and developed in philosophical circles.
A disposition, in the philosophical sense, is a property of a thing that exists whether or not it ever manifests, but when triggered, it produces characteristic outcomes. Glass has a disposition to shatter. It isn't shattered now but under the right conditions (the right force, the right location, the right angle), it will shatter. The disposition exists prior to any manifestation. A vulnerability is a property of a system that exists independently of whether anyone has ever exploited it or ever will. What makes a vulnerability what it is (a disposition) is the complete structure: a fault in the system, conditions under which an actor can reach and trigger that fault, and a security failure as the outcome. The last part is what differentiates a bug from a vulnerability.
The full definition we're working with:
A vulnerability is a disposition of a system S, arising from a fault f, that manifests as a security failure F when attacker and environmental conditions C are jointly satisfied.
We decided to do the academic practice of adding letters next to the important concepts to draw attention to them as a placeholder that must be filled in as we describe a vulnerability. Therefore, in order to define a vulnerability we must define and describe:
System (S): the vulnerable thing
Fault (f): the core problem enabling exploitation
Security Failure (F): what separates a vulnerability from a bug
Conditions (C): What must hold true for a successful exploitation
Why this is interesting
Every vulnerability record currently focuses on the first two. CVE requires the affected product and has a place to record the underlying fault (weakness). But we are lacking the shared vocabulary to accurately describe the security failure and the conditions for exploitation. Think about that for a moment. Our vulnerability records currently define half of what’s needed to understand and describe (with precision) a vulnerability.
Let’s go back to that curl example and talk about how this definition becomes a working definition. The system is curl and needs to be identified at a specific, individual release to determine affected from unaffected installation of curl, for now we use the software version and this affects 7.65.2. The fault is an integer overflow, unchecked input accepted as the value to a command line argument. Generally to turn an integer overflow into code execution is rare, the overflow could create an out-of-bounds write which could lead to code execution. The security failure and conditions are where this gets interesting. First conditions: the attacker needs to craft and supply the value for the retry-delay command line argument and the system must be in a state that the out-of-bounds write leads to that over-written memory space being executed. The manifestation is an action of code execution, but that’s not enough to describe a security property: an actor, taking an action, on an object. Now we have some language to describe how Daniel Stenberg’s argument makes sense. With the assumption that the condition is an authenticated user executing something at the command line, that actor is already authorized to execute at the command line, so there is no change in any security property. When there is an underlying fault and realistic conditions exist to trigger the fault but there is no security property we do indeed have a bug and not a vulnerability.
The Record Architecture
A definition is only as useful as the record format that implements it. Current CVE records don't structurally require any of these components. The description is prose. CVSS vectors partially consider conditions, but any helpful information is masked by subjective high/low values. CVSS also mumbles about violation of the security properties through the crude language of Confidentiality, Integrity and Availability. It was quite an interesting revelation when we realized that our ability to properly encode a full definition of a vulnerability does not exist in the current vulnerability records and this was the second part of our talk at the FIRST annual conference.
The architecture we discussed separates the identifier from any of the assertions about the vulnerability. We frame this as a “pegs and bags” architecture. A CVE ID should be thought of as a “peg” on which we can hang all of the assertions, or “bags”. The bags are a nice analogy because assertions should be self-contained and independent of all other assertions (e.g. an assertion about the CWE is independent of the security property being compromised). This also allows disputes to be a self-contained assertion and tied directly to the assertion it is disputing. Additionally each assertion carries provenance: who made it, when, and on what basis which carries multiple benefits such as accountability, temporal context and auditability. With regulations like the EU CRA, being able to go back and see who said what when, leaves an audit trail.
Where to Follow This
The slides from the talk are TLP:CLEAR and will be shared publicly. We're also involved in VulnOptiCON, September 23–25, 2026 in Luxembourg, where this work will continue.
If you're sitting on disputed or undecided vulnerability records and want to test it against these definitions, we’d love to explore it with you, please get in touch!
