CyberIntel ⬡ News
★ Saved ◆ Cyber Reads
← Back ◬ AI & Machine Learning Apr 10, 2026

Vulnerability Abundance: A formal proof of infinite vulnerabilities in code

arXiv Security Archived Apr 10, 2026 ✓ Full text saved

arXiv:2604.07539v1 Announce Type: cross 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

Full text archived locally
✦ AI Summary · Claude Sonnet


    Computer Science > Computational Complexity [Submitted on 8 Apr 2026] Vulnerability Abundance: A formal proof of infinite vulnerabilities in code Eireann Leverett, Jeroen van der Ham-de Vos 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. Comments: The complete source code is provided in the appendix under an MIT licence Subjects: Computational Complexity (cs.CC); Cryptography and Security (cs.CR) Cite as: arXiv:2604.07539 [cs.CC]   (or arXiv:2604.07539v1 [cs.CC] for this version)   https://doi.org/10.48550/arXiv.2604.07539 Focus to learn more Submission history From: Jeroen Van Der Ham-De Vos [view email] [v1] Wed, 8 Apr 2026 19:30:53 UTC (32 KB) Access Paper: HTML (experimental) view license Current browse context: cs.CC < prev   |   next > new | recent | 2026-04 Change to browse by: cs cs.CR References & Citations NASA ADS Google Scholar Semantic Scholar Export BibTeX Citation Bookmark Bibliographic Tools Bibliographic and Citation Tools Bibliographic Explorer Toggle Bibliographic Explorer (What is the Explorer?) Connected Papers Toggle Connected Papers (What is Connected Papers?) Litmaps Toggle Litmaps (What is Litmaps?) scite.ai Toggle scite Smart Citations (What are Smart Citations?) Code, Data, Media Demos Related Papers About arXivLabs Which authors of this paper are endorsers? | Disable MathJax (What is MathJax?)
    💬 Team Notes
    Article Info
    Source
    arXiv Security
    Category
    ◬ AI & Machine Learning
    Published
    Apr 10, 2026
    Archived
    Apr 10, 2026
    Full Text
    ✓ Saved locally
    Open Original ↗