Source-linked AI summary
Smart Contracts Claimed Vulnerable by the CVE Database, with Labels and Source Locations
Monika di Angelo, Gernot Salzer
TL;DR
Smart-contract vulnerability research needs reliable real-world artifacts with known labels and locations, but CVE records require artifact correspondence checks. CVE-Smart-Contracts curates CVE records with source and runtime artifacts, taxonomies, locations, reproducible pipelines, and manual review, producing a catalog whose labels and matches do not independently validate vulnerability claims.
Problem
Vulnerability-analysis evaluation needs artifacts with known vulnerability types and locations, while real-world smart-contract cases must be identified from sparse CVE records.
Method
The dataset uses scripted acquisition, evidence collection, correspondence validation, labeling, and localization, retaining external inputs and reviewing low-confidence cases.
Results
491 correspondence-matched, non-refuted deployed-contract records are cataloged with vulnerability labels and locations, alongside 26 project records and 45 records without validated artifacts.
Takeaways & Limitations
The dataset supports empirical security research, including benchmark evaluation of code analysis and repair techniques.
Takeaways & Limitations
The dataset is based on one CVE snapshot and does not independently establish the existence, severity, reachability, or exploitability of claimed vulnerabilities.
Abstract
from arXiv · showhide
The Common Vulnerabilities and Exposures (CVE) database catalogs vulnerability claims in hard- and software, among them those pertaining to blockchain programs a.k.a. smart contracts. We present CVE-Smart-Contracts, a curated dataset of CVE records up to July 2026 referring to Ethereum smart contracts. The dataset contains the vulnerable artifacts (source code and runtime bytecode), labels according to three taxonomies, and function-level locations. The retrieval of CVE records, collection of additional evidence, validation of the correspondence between records and artifacts, label assignment, and vulnerability localization are automated, leaving 15% to manual analysis. The dataset does not validate the original vulnerability claims, but marks a few records obviously wrong as `refuted'. For the sake of reproducibility, all external inputs are retained, so that rerunning the pipelines results in the same outputs. The dataset comprises 491 records linked to deployed contracts, 26 referring to projects (mostly libraries), 45 without validated artifacts, and six records with refuted claims. The dataset supports empirical security research, in particular the evaluation of code analysis and repair techniques.
Background & Summary
CVE-Smart-Contracts addresses the need for realistic, reliable smart-contract vulnerability data by curating CVE records with artifacts, labels, and vulnerability locations. It extends earlier collections in coverage and supporting evidence while retaining the caveat that labels and correspondence do not independently validate vulnerabilities.
- Motivation: Reliable test data pairs artifacts with known vulnerability types and locations, enabling comparison of automated analyses against ground truth.Generated data offers scale and control, whereas real-world data captures vulnerabilities that actually occurred.
- Dataset: CVE-Smart-Contracts collects CVE records addressing Ethereum smart-contract vulnerabilities and provides source code, deployed bytecode, three-taxonomy labels, and vulnerability locations.For repository projects such as libraries, it retains a manual snapshot of the vulnerable version.
- Dataset: 568 CVE records comprise 541 Ethereum contract records, one BNB Smart Chain contract record, and 26 library or package records.Among deployed-contract records, 497 match the retained artifacts and 45 do not; six matching records are marked refuted, leaving 491 cataloged contracts.
- Related work: Compared with VeriSmart and SmartFix, the dataset identifies CVE reports through mid-2026 and adds archived evidence, source and runtime artifacts, validation, taxonomies, and function-level localization.A file-level comparison found 485 of 487 VeriSmart artifacts substantially the same.
- Uses: The dataset supports vulnerability studies, benchmark construction and auditing, classification and retrieval, localization, evaluation of analysis and repair systems, and metadata research.Its scope includes static, dynamic, language-model-based, and repair systems.
Methods
The construction pipeline acquires CVE records and artifacts, validates source and deployment correspondence, localizes claims, assigns labels, and integrates the results into a catalog. It combines automated rules and scripted evidence collection with reviewed decisions for ambiguous or unsupported cases.
- Methods: Dataset construction uses five phases: acquisition, correspondence validation, localization, labeling, and catalog construction.The catalog joins outputs from preceding phases into a JSON file.
- Data acquisition: The filter selects in-scope EVM contract or library records from a July 24, 2026 CVE snapshot using textual and reference cues, yielding 568 retained records after manual exclusions.Client software, development tools, off-chain applications, and protocol-only issues are excluded.
- Data acquisition: Artifact acquisition associates records with deployment addresses where possible and retrieves source, compilation metadata, runtime bytecode, and selected token-contract call results from Etherscan.Maintained versioned projects are handled by retaining the repository version flagged as vulnerable.
- Correspondence validation: Validation establishes artifact correspondence rather than confirming that the retained code is vulnerable, severe, reachable, or exploitable.A non-match rejects the indexed correspondence, not the CVE claim itself.
- Correspondence validation: Validation separately checks whether a CVE refers to retained source and whether its named contract is deployed at the indexed address.This separation allows a missing deployment address without invalidating an otherwise supported source association.
- Correspondence validation: 450 records are automatically classified as matches and 39 as non-matches using address, name, token, function, and verbatim-snippet evidence.The remaining 53 records require review because observations are incomplete, contradictory, or outside automatic rules; reviews produce 47 matches and six non-matches.
Vulnerability labeling
Vulnerability claims are mapped independently to three taxonomies using declarative, evidence-tiered rules, with manual review resolving ambiguity and insufficient evidence. The released labels preserve the basis and provenance of each classification.
- Taxonomies: Labels map each reported vulnerability claim independently to the Iuliano-Di Nucci, CWE, and SWC taxonomies.The labels characterize retained evidence and do not independently establish that a weakness exists or is exploitable.
- Rule-based labeling: 13 declarative rules specify applicability constraints and primary or secondary assignments across all three taxonomies.Rules consume retained CVE records and provenance-preserving evidence.
- Rule-based labeling: Evidence is ordered into six tiers, and the strongest tier containing a rule match determines the suggestion.Matches in weaker tiers are retained only as diagnostics, while source code is allowed only through explicitly code-permitting rules.
- Rule-based labeling: All-constraints require every expression to match, any-constraints require at least one match, and none-constraints require no expressions to match.Constraints use case-insensitive regular expressions.
- Decision handling: A single applicable rule yields an automatic suggestion, whereas multiple rules are ambiguous and no applicable rule produces insufficient evidence.CVE-supplied CWE assertions are compared with suggestions but are not automatically adopted as final labels.
- Decision handling: 524 automatic suggestions and 44 insufficient-evidence results were produced; reviewed decisions covered the abstentions and replaced 12 automatic suggestions.The released file contains 512 rule-based classifications, 55 manually classified records, and one reviewed record retained as not classifiable.
Vulnerability localization
Localization assigns each non-refuted matching contract claim to function-like units in verified source by combining compiler-derived inventories with provenance-preserving evidence. Conservative automatic acceptance is supplemented by manual decisions, and every catalog record has a released location record.
- Scope: Localization reflects where the CVE record and supporting evidence place a claim, not an independent finding that the indicated code is vulnerable.It applies to non-refuted matching contract claims.
- Source analysis: Verified source is compiled into normalized inventories of source units, inheritance relations, functions, constructors, fallback functions, and receive functions.The compiler version is selected from retained compilation metadata, with a documented exception for unavailable Solidity 0.3.4.
- Candidate generation: Candidate generation matches evidence code blocks against source units and traverses call and modifier edges backward to identify externally callable entry points.Exact code matches rank above explicit function names, while contract-name evidence establishes scope but cannot select a function alone.
- Candidate scoring: Confidence values express evidential support for a location rather than the probability that the vulnerability claim is true.Candidate scoring uses the strongest occurrence of each signal type.
- Review and release: 415 records receive locations through conservative automatic acceptance, while 76 records are supported by manual decisions.Automatic acceptance requires a high-confidence leaf function or an uncontested medium-confidence function declared by the contract; unresolved reviewed outcomes are omitted from the released mapping.
Dataset integration and versioning
Dataset integration builds a catalog only from validated, non-refuted matches with resolved labels and released locations, then derives versioned metadata from component outputs. The normal build is reproducible because it uses retained inputs and rejects regenerated-output differences.
- Catalog selection: Of 497 correspondence matches, six refuted records are excluded, leaving 491 selected records for catalog construction.Every selected record must have resolved labels and released location data.
- Catalog construction: Each selected entry combines retained CVE records, source artifacts, verified Etherscan source, optional runtime bytecode, identities, taxonomy assignments, and location data.Missing required artifacts or component records stop the build.
- Versioning: Metadata records dataset and schema versions, release and snapshot dates, coverage counts, taxonomy provenance, selection rules, and schema locations.Coverage counts are recomputed from index and component outputs rather than copied from prose.
- Reproducibility: The normal build consumes retained acquisition inputs and versioned OCR text without refreshing external CVE, explorer, blockchain, reference, or OCR material.Network acquisition and platform-dependent OCR refreshes are separate maintainer operations because results can change over time.
- Reproducibility: The deterministic build proceeds through validation, labeling, localization, catalog construction, and metadata generation, with verification rejecting any regenerated-output difference.Dependencies and compiler selection are pinned or determined from retained metadata, and compiler failures stop the pipeline.
Data Records
The release separates a broad, auditable index and retained evidence from compact integrated records, labeling outputs, localization mappings, and reproducibility metadata. The integrated catalog provides 491 matched, non-refuted contract cases with resolved labels and function-level locations.
- Release structure: The archived dataset version described here is 2026-08-14 and is maintained on GitHub and deposited as a versioned Zenodo archive.The DOI-bearing archive is the citable frozen release, while GitHub remains the maintained development version.
- Index and retained artifacts: The broad index contains 568 CVE records: 542 contract records and 26 project or library records, while retaining refuted claims and rejected correspondences for auditability.Each row associates a canonical CVE identifier with an affected artifact.
- Index and retained artifacts: Retained folders store original CVE records, Solidity sources, Etherscan source with compilation information, and runtime bytecode for indexed addresses.These inputs support reproducible validation and compilation-based analysis.
- Integrated catalog: The integrated cve.json catalog contains 491 non-refuted contract records with matched artifacts, resolved labels, and released location data.It is the recommended compact entry point for correspondence-matched, labeled, and localized cases.
- Integrated catalog: Catalog labels contain parallel primary and secondary assignments for the Iuliano-DiNucci, CWE, and SWC taxonomies.A primary value is null when no supported assignment exists; classification provenance remains in labels.json.
- Integrated catalog: Each localization entry identifies source path, declaring contract, function or modifier, inclusive line range, and public or external entry-point paths.Statement-level locations are retained separately and are not exported at top level because only three records identify vulnerability lines sufficiently.
- Labeling outputs: labels.json covers all 568 indexed records, with all but one containing sufficient information to derive vulnerability labels from the record and supporting evidence.It also records applied rules, evidence tiers, or manual-decision locations.
- Reproducibility: Generated files explain results, decision files document reviewed exceptions, and retained evidence enables auditing without relying on live external pages.Later network refreshes may produce different retained inputs.
Data Overview
The dataset overview connects the complete curated index to the integrated catalog and reports vulnerability coverage by year, reporter, and frequency.
- Figure 2 traces population flow from the complete curated index to the integrated catalog.
Technical Validation
Technical validation checks structural integrity, cross-layer consistency, correspondence evidence, labels, locations, and reproducibility without independently verifying vulnerability existence or exploitability. The pipelines produce validated correspondence, taxonomy labels, and function-level locations for the released catalog.
- Validation scope: Five validation properties cover structural validity, data-layer consistency, artifact correspondence, taxonomy labels and source locations, and reproducible outputs.These checks validate dataset representation rather than independently confirming vulnerability existence or exploitability.
- Catalog construction: 491 records remain in the catalog after excluding six refuted records from the 497 correspondence matches.The catalog predicate is recomputed from row-level data rather than accepting reported totals.
- Correspondence validation: 497 matches and 45 non-matches result from correspondence checks across 542 deployed-contract records.Evidence combines CVE identity, retained source, interfaces, named functions, metadata, addresses, and runtime selectors; reviewed decisions resolve low-score cases.
- Label checks: 568 indexed records receive resolved label records, comprising 512 automatic classifications, 55 manual classifications, and one manually reviewed not-classifiable record.The generator produced 524 automatic suggestions and 44 insufficient-evidence results; 12 automatic suggestions were overridden during review.
- Localization checks: 491 catalog records have released location records, including 415 automatic localizations and 76 reviewed decisions.Localization validation checks source-unit membership, identities, compiler boundaries, line ranges, signatures, anchors, and reachability.
- Reproducibility: The verification script rebuilds all stages from a clean tracked worktree and rejects differences between regenerated and committed outputs.Pinned dependencies and compiler-selection requirements make the prescribed build reproducible.
Usage Notes
Usage guidance distinguishes the compact catalog from broader index-based studies and emphasizes that labels, correspondences, and locations describe retained CVE evidence rather than independently verified vulnerabilities.
- Selection: Use cve.json for compact correspondence-matched, non-refuted, localized contract cases, and data/index.csv for broader coverage or excluded record types.Validation, labeling, and localization directories contain the detailed supporting evidence and decisions.
- Interpretation: A correspondence match does not constitute an independent vulnerability finding, and labels characterize CVE claims rather than exploitability.Researchers may include refuted records, non-matches, library cases, and inherited entry points when appropriate.
- Artifact constraints: The dataset spans heterogeneous source artifacts and historical compiler behavior, so compiler versions should come from verified-source or provenance documentation.Users must also observe third-party source licenses and notices.
- Coverage limits: The snapshot is not a complete inventory of smart-contract vulnerabilities and inherits omissions, errors, changing status, and uneven detail from CVE records.Referenced supporting evidence may disappear or be revised, although retained evidence and provenance document the release inputs.
- Validation limits: Correspondence validation checks agreement between claims and artifacts, not vulnerability existence, severity, reachability, or exploitability.A non-match rejects the indexed correspondence rather than the upstream CVE claim.
- Annotation limits: Taxonomy mappings may remain ambiguous, and locations may cover multiple functions, statements, or entry points rather than one minimal vulnerable statement.
- Distribution bias: The dataset is biased toward Ethereum and records associated with Solidity 0.4.x and integer bugs because yearly coverage is uneven.Only one record refers to a BNB Smart Chain contract.
- Licensing: Redistribution of acquired materials is constrained by third-party rights and documented in THIRD_PARTY_NOTICES.md.
Data Availability
The dataset is archived on Zenodo and maintained on GitHub, with the archive preserving the catalog, artifacts, evidence, decisions, schemas, and metadata described in the data records.
- Repositories: Zenodo provides the dataset archive, while GitHub hosts the maintained development repository.The archive includes the integrated catalog, complete index, CVE records, artifacts, validation assessments, labels, locations, evidence, review decisions, schemas, and metadata.
Code Availability
The Zenodo archive and development repository provide the scripts and documentation needed to construct, validate, label, localize, integrate, and rebuild-verify the dataset.
- The repositories include scripts for dataset construction, validation, labeling, localization, integration, metadata, and rebuild verification.
- README.md and REPRODUCIBILITY.md document installation, pinned dependencies, required Solidity compilers, execution order, and rebuild commands.
- Repository code is licensed under the MIT License unless a file states otherwise.