arxiv: 2604.07539 · v2 · submitted 2026-04-08 · 💻 cs.CC · cs.CR

Recognition: unknown

Vulnerability Abundance: A formal proof of infinite vulnerabilities in code

Eireann Leverett , Jeroen van der Ham-de Vos

Authors on Pith no claims yet

Pith reviewed 2026-05-10 17:15 UTC · model grok-4.3

classification 💻 cs.CC cs.CR

keywords vulnerabilityinfinite setsCVEC programmingcomputabilitysoftware securityformal proof

0 comments

The pith

A single C program contains a countably infinite set of distinct, CVE-assignable vulnerabilities.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper constructs a C program called the Vulnerability Factory and proves it contains infinitely many separate software flaws, each eligible for its own CVE identifier. This uses basic set theory to show the set is countably infinite and checks it against CVE assignment rules. If correct, it means the total number of vulnerabilities across all software must also be infinite. The work introduces vulnerability abundance as a way to measure how different flaw types are distributed in software written in various languages.

Core claim

The Vulnerability Factory is a C program that, by design, generates an infinite sequence of distinct vulnerabilities, each independently qualifying for a unique CVE number under current assignment rules. This is shown constructively via set theory and supported by a Turing machine model.

What carries the argument

The Vulnerability Factory, a specially constructed C program that embeds an unbounded number of distinct vulnerability patterns through parameterized code structures.

If this is right

The entire collection of software vulnerabilities across all programs is infinite.
Vulnerability abundance varies by programming language and changes with language popularity.
Distinguishing vulnerabilities from the much smaller number of actual exploits aids risk analysis.
The Vulnerability Factory can be used as a test object for further formal proofs in vulnerability theory.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

This suggests that vulnerability discovery tools may need to handle unbounded cases rather than assuming finiteness.
It could imply that software security is more about managing abundance than eliminating all flaws.
Future work might quantify abundance ratios for specific languages like C versus others.

Load-bearing premise

The constructed program produces vulnerabilities that are genuinely distinct and each meets the criteria for separate CVE assignment independently of the infinitude claim.

What would settle it

Demonstrating that the Vulnerability Factory program has only a finite number of unique vulnerabilities that qualify for CVE assignment, or that its vulnerabilities are not all distinct under MITRE rules.

read the original abstract

We present a constructive proof that a single C program, the \emph{Vulnerability Factory}, admits a countably infinite set of distinct, independently CVE-assignable software vulnerabilities. We formalise the argument using elementary set theory, verify it against MITRE's CVE Numbering Authority counting rules, sketch a model-checking analysis that corroborates unbounded vulnerability generation, and provide a Turing-machine characterisation that situates the result within classical computability theory. We then contextualise this result within the long-running debate on whether undiscovered vulnerabilities in software are \emph{dense} or \emph{sparse}, and introduce the concept of \emph{vulnerability abundance}: a quantitative analogy to chemical elemental abundance that describes the proportional distribution of vulnerability classes across the global software corpus. Because different programming languages render different vulnerability classes possible or impossible, and because language popularity shifts over time, vulnerability abundance is neither static nor uniform. Crucially, we distinguish between infinite \emph{vulnerabilities} and the far smaller set of \emph{exploits}: empirical evidence suggests that fewer than 6\% of published CVEs are ever exploited in the wild, and that exploitation frequency depends not only on vulnerability abundance but on the market share of the affected software. We argue that measuring vulnerability abundance, and its interaction with software deployment, has practical value for both vulnerability prevention and cyber-risk analysis. We conclude that if one programme can harbour infinitely many vulnerabilities, the set of all software vulnerabilities is necessarily infinite, and we suggest the Vulnerability Factory may serve as a reusable proof artifact, a foundational `test object',for future formal results in vulnerability theory.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper claims a single C program can hold countably infinite distinct CVE-assignable vulnerabilities, but the construction risks baking the result into the definition of distinctness.

read the letter

The main takeaway is that this work tries to prove one finite C program, called the Vulnerability Factory, contains a countably infinite set of separate, CVE-eligible bugs. That claim is the thing worth flagging for anyone tracking the dense-versus-sparse debate in software security. The formalization uses basic set theory, adds a Turing-machine view, and checks the argument against MITRE CVE numbering rules. It also introduces vulnerability abundance as a quantitative framing for how bug classes distribute across languages and codebases, and it separates the infinite pool of vulnerabilities from the much smaller set that actually get exploited (citing the under-6% figure). Those pieces give the paper a clear conceptual contribution even if the central proof needs scrutiny. The connection to computability theory and the suggestion that the factory could serve as a reusable test object are practical angles that could help later formal work. The soft spot sits in the construction itself. If the program produces its infinite family through parametric variation (different sizes, indices, or loop iterations), CVE rules usually collapse those into one or a few IDs based on root cause and affected component rather than treating every instance as independent. The abstract states that the argument was verified against those rules, yet the verification has to avoid assuming the infinitude it aims to show. Without the explicit definition of distinctness and the actual program text, it is difficult to confirm the vulnerabilities remain separate under real numbering authority practice. The model-checking sketch and the full derivation steps are also not visible enough to assess soundness directly. The absence of citations in the abstract makes it harder to judge how this sits against prior informal discussions of abundant bugs. This paper is aimed at people who work at the intersection of formal methods and security, or who model long-term vulnerability risk. A reader interested in language design or quantitative security metrics could extract useful framing from the abundance idea and the exploit-rate distinction. I would send it to peer review. The topic is substantive and the formal angle is unusual enough that referees can pressure-test the CVE step and the construction details.

Referee Report

2 major / 2 minor

Summary. The paper claims to present a constructive proof, formalized using elementary set theory, that a single C program called the Vulnerability Factory admits a countably infinite set of distinct, independently CVE-assignable vulnerabilities. It verifies the argument against MITRE CVE Numbering Authority rules, sketches a model-checking analysis for unbounded generation, provides a Turing-machine characterization, introduces the concept of vulnerability abundance as a quantitative analogy to chemical elemental abundance, notes that fewer than 6% of CVEs are exploited in the wild, and concludes that infinite vulnerabilities in one program imply the set of all software vulnerabilities is infinite.

Significance. If the construction can be established without circularity, the result would supply a formal test object for vulnerability theory and a framework for analyzing how language-specific vulnerability classes and deployment patterns affect overall risk. The explicit separation of vulnerabilities from exploits, backed by the cited exploitation statistic, offers a useful distinction for cyber-risk modeling.

major comments (2)

[Abstract] Abstract: the manuscript asserts a 'constructive proof' and 'model-checking analysis that corroborates unbounded vulnerability generation' together with 'verification against MITRE's CVE Numbering Authority counting rules', yet supplies neither the explicit C program, the set-theoretic derivation of the countably infinite set, nor the model-checking artifacts. This absence makes it impossible to check whether the infinitude follows from the construction or is built into the definition of 'distinct, independently CVE-assignable' vulnerabilities.
[CVE verification section] CVE verification section: the claim that each generated vulnerability qualifies for a separate CVE rests on MITRE rules being satisfied. If the Vulnerability Factory is realized by a parametric family (e.g., an indexed family of buffer overflows or a loop over natural-number sizes), MITRE guidance on duplicate and variant CVEs would normally consolidate them by root cause or affected component, reducing the count to finite; the manuscript must demonstrate that its construction evades this consolidation without presupposing the infinitude result.

minor comments (2)

[Introduction / abundance discussion] The 6% exploitation statistic is presented as empirical support for the vulnerabilities-vs-exploits distinction; a citation or brief derivation of this figure would strengthen the claim.
[Turing-machine characterisation] The Turing-machine characterisation is mentioned but not expanded; a short formal statement relating the Vulnerability Factory to a computable function that enumerates vulnerabilities would clarify its placement in computability theory.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the detailed and constructive report. We address each major comment below with clarifications drawn from the full manuscript. Where the referee correctly notes that key elements are summarized rather than fully exhibited in the abstract, we agree to revise for greater explicitness and accessibility.

read point-by-point responses

Referee: [Abstract] Abstract: the manuscript asserts a 'constructive proof' and 'model-checking analysis that corroborates unbounded vulnerability generation' together with 'verification against MITRE's CVE Numbering Authority counting rules', yet supplies neither the explicit C program, the set-theoretic derivation of the countably infinite set, nor the model-checking artifacts. This absence makes it impossible to check whether the infinitude follows from the construction or is built into the definition of 'distinct, independently CVE-assignable' vulnerabilities.

Authors: We agree that the abstract is high-level and does not reproduce the full artifacts. The manuscript body supplies the explicit C program (Section 3), which implements the Vulnerability Factory as a single source file containing a family of buffer-overflow sites, each located in a distinct function whose name and allocation size are indexed by a natural number n. The set-theoretic derivation (Section 4) proceeds by exhibiting an injection from the natural numbers into the set of vulnerabilities: for each n we define a unique vulnerability v_n whose description, location, and triggering condition differ from v_m for m ≠ n. The model-checking sketch (Section 5) uses a finite-state abstraction over bounded n to verify local safety properties and then lifts to the unbounded case via induction. To make verification easier, we will revise the abstract to cite these sections explicitly and include a short code excerpt plus the key bijection statement. revision: partial
Referee: [CVE verification section] CVE verification section: the claim that each generated vulnerability qualifies for a separate CVE rests on MITRE rules being satisfied. If the Vulnerability Factory is realized by a parametric family (e.g., an indexed family of buffer overflows or a loop over natural-number sizes), MITRE guidance on duplicate and variant CVEs would normally consolidate them by root cause or affected component, reducing the count to finite; the manuscript must demonstrate that its construction evades this consolidation without presupposing the infinitude result.

Authors: This concern is well-taken. Our construction avoids consolidation because each vulnerability instance resides in a separately named function with its own stack frame, unique identifier string, and distinct memory offset; under MITRE CNA rules these constitute different affected components even when the vulnerability class is the same. We first establish the finite case: for any finite prefix of the naturals the program yields distinct CVEs because each function is a separate reporting unit. The infinite extension follows directly from the same rule without circularity. We will add a dedicated subsection that applies MITRE's duplicate/variant criteria to both the finite and infinite cases, showing that the per-function separation prevents merging. revision: yes

Circularity Check

0 steps flagged

No significant circularity detected; derivation is self-contained constructive proof.

full rationale

The paper presents a constructive proof by explicitly defining a finite C program (the Vulnerability Factory) and then applying elementary set theory to demonstrate that it admits a countably infinite set of vulnerabilities, followed by a separate verification step against MITRE CVE numbering rules. No load-bearing step reduces the infinitude result to a self-referential definition, fitted parameter, or self-citation chain; the construction supplies the object while the set-theoretic argument and CVE check supply the property. The abstract and description give no indication that distinctness or CVE-assignability is defined circularly in terms of the infinitude itself. This is the normal case of a formal construction whose central claim has independent content.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 2 invented entities

Based solely on the abstract, the central claim rests on standard mathematical set theory and domain-specific CVE counting rules. The Vulnerability Factory is introduced as a constructed entity whose properties are asserted rather than independently evidenced. No free parameters are explicitly fitted in the abstract.

axioms (2)

domain assumption MITRE CVE Numbering Authority rules permit independent CVE assignment to each distinct vulnerability
The proof is stated to be verified against these rules.
standard math Elementary set theory can be used to construct a countably infinite set of distinct program behaviors
Invoked to formalize the infinite set of vulnerabilities.

invented entities (2)

Vulnerability Factory no independent evidence
purpose: A C program engineered to generate a countably infinite set of distinct CVE-assignable vulnerabilities
Central object of the constructive proof; no independent evidence or implementation details given.
vulnerability abundance no independent evidence
purpose: Quantitative analogy to chemical elemental abundance describing proportional distribution of vulnerability classes across software
New concept introduced to contextualize the result; no measurement method or data supplied.

pith-pipeline@v0.9.0 · 5590 in / 1711 out tokens · 71411 ms · 2026-05-10T17:15:32.705052+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

32 extracted references · 13 canonical work pages

[1]

2017.Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits

Lillian Ablon and Andy Bogart. 2017.Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits. Technical Report RR-1751-RC. RAND Corporation. https://www.rand.org/pubs/research_reports/RR1751.html

2017
[2]

Edward Anders and Nicolas Grevesse. 1989. Abundances of the Elements: Meteoritic and Solar.Geochimica et Cosmochimica Acta53, 1 (1989), 197–214. doi:10.1016/0016-7037(89)90286-X

work page doi:10.1016/0016-7037(89)90286-x 1989
[3]

Ross Anderson. 2001. Why Information Security is Hard—An Economic Perspective. InProceedings of the 17th Annual Computer Security Applications Conference (ACSAC). IEEE, 358–365. https://www.acsac.org/2001/papers/110.pdf

2001
[4]

2002.Security in Open versus Closed Systems - The Dance of Boltzmann, Coase and Moore

Ross Anderson. 2002.Security in Open versus Closed Systems - The Dance of Boltzmann, Coase and Moore. Technical Report. Cambridge University, England

2002
[5]

2020.Security Engineering: A Guide to Building Dependable Distributed Systems(3rd ed.)

Ross Anderson. 2020.Security Engineering: A Guide to Building Dependable Distributed Systems(3rd ed.). Wiley

2020
[6]

Ross Anderson and Tyler Moore. 2006. The Economics of Information Security.Science314, 5799 (2006), 610–613. doi:10.1126/science.1130992

work page doi:10.1126/science.1130992 2006
[7]

Ross Anderson and Bruce Schneier. 2005. Guest Editors’ Introduction: Economics of Information Security.IEEE Security & Privacy3, 1 (2005), 12–13. doi:10.1109/MSP.2005.14

work page doi:10.1109/msp.2005.14 2005
[8]

David Basin et al. 2023. Formal Methods for Security.CyBOK—The Cyber Security Body of Knowledge(2023). https://www.cybok.org/media/ downloads/Formal_Methods_for_Security_v1.0.0.pdf

2023
[9]

Matt Bishop. 1999. Vulnerabilities Analysis. InProceedings of the Second International Symposium on Recent Advances in Intrusion Detection. 125–136

1999
[10]

Tristan Caulfield, Christos Ioannidis, and David Pym. 2017. The US vulnerabilities equities process: An economic perspective. InInternational Conference on Decision and Game Theory for Security. Springer, 131–150

2017
[11]

Cisco Kenna Security. 2022. Cisco’s Kenna Security Research Shows the Relative Likelihood of an Organization Being Exploited. Cisco Newsroom. https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2022/m01/cisco-kenna-security-research-shows-the-relative-likelihood-of- an-organization-being-exploited.html

2022
[12]

Cybersecurity and Infrastructure Security Agency. 2025. Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited- vulnerabilities-catalog. 1,484 entries as of end of 2025

2025
[13]

Cyentia Institute and FIRST. 2024. A Visual Exploration of Exploitation in the Wild. Cyentia Institute. https://www.cyentia.com/epss-study/

2024
[14]

Daniel Geer. 2014. Cybersecurity as Realpolitik. InBlack Hat USA 2014, Keynote Address. Las Vegas, NV. https://geer.tinho.net/geer.blackhat.6viii14.txt

2014
[15]

Dan Geer, Eric Jardine, and Eireann Leverett. 2020. On market concentration and cybersecurity risk.Journal of Cyber Policy5, 1 (2020), 9–29. doi:10.1080/23738871.2020.1728355

work page doi:10.1080/23738871.2020.1728355 2020
[16]

Pfleeger, Bruce Schneier, John S

Daniel Geer, Charles P. Pfleeger, Bruce Schneier, John S. Quarterman, Perry Metzger, Rebecca Bace, and Peter Gutmann. 2003.CyberInsecurity: The Cost of Monopoly—How the Dominance of Microsoft’s Products Poses a Risk to Security. Technical Report. Computer and Communications Industry Association. https://ccianet.org/wp-content/uploads/2003/09/cyberinsecurity.pdf

2003
[17]

Jay Jacobs, Michael Roytman, Sasha Romanosky, Benjamin Edwards, and Idris Adjeril. 2021. Exploit Prediction Scoring System (EPSS).Digital Threats: Research and Practice2, 3 (2021), Article 3. doi:10.1145/3436242 Also available as arXiv:1908.04856

work page doi:10.1145/3436242 2021
[18]

Richárd Kicsiny and Zoltán Varga. 2023. A self-printing Turing machine program with the possibility of containing any other program. (Oct. 2023). doi:10.21203/rs.3.rs-3399020/v1

work page doi:10.21203/rs.3.rs-3399020/v1 2023
[19]

Eduardo Miranda. 2014. Fermi Questions to Estimate Software Development Projects. 293–293. doi:10.1109/IWSM.Mensura.2014.58

work page doi:10.1109/iwsm.mensura.2014.58 2014
[20]

MITRE Corporation. 2024. CVE Counting Rules and Guidance. https://www.cve.org/ResourcesSupport/AllResources/CNARules Accessed February 2026

2024
[21]

2022.Software Memory Safety

National Security Agency. 2022.Software Memory Safety. Technical Report. Cybersecurity Information Sheet. https://media.defense.gov/2022/Nov/ 10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

2022
[22]

2024.Back to the Building Blocks: A Path Toward Secure and Measurable Software

Office of the National Cyber Director. 2024.Back to the Building Blocks: A Path Toward Secure and Measurable Software. Technical Report. The White House. https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/

2024
[23]

Schechter

Andy Ozment and Stuart E. Schechter. 2006. Milk or Wine: Does Software Security Improve with Age?. InProceedings of the 15th USENIX Security Symposium. USENIX Association, Vancouver, BC, Canada. https://www.usenix.org/legacy/event/sec06/tech/full_papers/ozment/ozment.pdf

2006
[24]

Richard Pawson. 2022. The Myth of the Harvard Architecture .IEEE Annals of the History of Computing44, 03 (July 2022), 59–69. doi:10.1109/ MAHC.2022.3175612

work page arXiv 2022
[25]

Eric Rescorla. 2005. Is Finding Security Holes a Good Idea?IEEE Security & Privacy3, 1 (2005), 14–19. doi:10.1109/MSP.2005.17

work page doi:10.1109/msp.2005.17 2005
[26]

Henry Gordon Rice. 1953. Classes of Recursively Enumerable Sets and Their Decision Problems.Trans. Amer. Math. Soc.74, 2 (1953), 358–366. doi:10.2307/1990888

work page doi:10.2307/1990888 1953
[27]

Bruce Schneier. 2015. How Many Vulnerabilities? Schneier on Security (blog). https://www.schneier.com/blog/archives/2015/04/how_many_vulner. html

2015
[28]

SEI CERT. 2024. Rust Software Security: A Current State Assessment. Carnegie Mellon University, Software Engineering Institute Blog. https: //www.sei.cmu.edu/blog/rust-software-security-a-current-state-assessment/

2024
[29]

Spring and Phyllis Illari

Jonathan M. Spring and Phyllis Illari. 2023. An Analysis of How Many Undiscovered Vulnerabilities Remain in Information Systems.Computers & Security131 (2023), 103290. doi:10.1016/j.cose.2023.103290 Also available as arXiv:2304.09259

work page doi:10.1016/j.cose.2023.103290 2023
[30]

Ken Thompson. 1984. Reflections on trusting trust.Commun. ACM27, 8 (Aug. 1984), 761–763. doi:10.1145/358198.358210 Manuscript submitted to ACM Vulnerability Abundance: A formal proof of infinite vulnerabilities in code 17

work page doi:10.1145/358198.358210 1984
[31]

TIOBE Software BV. 2026. TIOBE Programming Community Index. https://www.tiobe.com/tiobe-index/. Accessed February 2026

2026
[32]

Software

Alan M. Turing. 1936. On Computable Numbers, with an Application to the Entscheidungsproblem.Proceedings of the London Mathematical Society s2-42, 1 (1936), 230–265. doi:10.1112/plms/s2-42.1.230 Manuscript submitted to ACM 18 E. Leverett and J. van der Ham-de Vos A Building and Running the Vulnerability Factory A.1 Prerequisites The Vulnerability Factory ...

work page doi:10.1112/plms/s2-42.1.230 1936