Search arXiv⌕ Search
Home/Archive/arXiv

arXiv · 2608.30648

Lie to Me: Finding Bugs in ZK DSL Toolchains with Adversarial Witness Injection

Sebastian Watzinger·Christoph Hochrainer·Valentin Wüstholz·Maria Christakis
View original source ↗Read source document ↗Export metadata ↓

Abstract

Zero-knowledge domain-specific language (ZK DSL) toolchains compile programs into constraint systems and generate witnesses for cryptographic proofs. Bugs in these toolchains can leave the enforced constraints weaker than the source-program semantics, admitting proofs for invalid executions. Such soundness bugs may remain invisible to valid-execution testing because all valid executions still behave correctly. We present Liezz, a testing framework that generates ZK DSL programs and exposes these bugs through adversarial witness injection. For each generated deterministic program, Liezz executes two public input assignments with different outputs and splices their witnesses, combining the input of one execution with the output of the other. The resulting witness is invalid by construction. A correct toolchain must reject it; acceptance exposes a soundness bug. Controlled divergence and multiple witness-splicing strategies preserve enough consistency to expose missing constraints. Liezz also generates parameterized standard-library calls to reach complex functionality. Liezz supports Circom, Corset, Gnark, and Noir. It finds 13 bugs, including seven with soundness impact. Several are reachable only through generated standard-library calls. Under the same testing budget, a valid-execution baseline does not expose any of the soundness failures revealed by accepted injected witnesses, showing that adversarial witness injection reaches failures missed by valid-execution testing.

Explore related subjects

cs.CRcs.SE

Keep this discovery

BibTeXRIS

Sebastian Watzinger, Christoph Hochrainer, Valentin Wüstholz, Maria Christakis. 2026-08-31. Lie to Me: Finding Bugs in ZK DSL Toolchains with Adversarial Witness Injection. https://arxiv.org/abs/2608.30648

Cite the original work for its findings. Save a collection to share your selection of sources.

Discover connections

cs.CR subjectcs.SE subject

Connections use source metadata and explicit phrase matches, not verified experimental comparisons.

KEEP EXPLORING

Related papers

arXiv2026

The Popularity Hypothesis in Software Security: A Large-Scale Replication with PHP Packages

There has been a long-standing hypothesis that a software's popularity is related to its security or insecurity in both research and popular discourse. There are also a few empirical studies that have examined the hypothesis, either explicitly or implicitly. The present work continues with and contributes to this research with a replication-motivated large-scale analysis of software written in the PHP programming language. Two datasets are used: the first contains nearly four hundred thousand open source software packages written in PHP and the second addresses over six thousand WordPress components. According to the results based on vulnerabilities reported, the hypothesis holds: packages having seen reported vulnerabilities over their release histories are generally more popular than packages for which fewer or no vulnerabilities have been reported. With this replication results, the paper contributes to the efforts to strengthen the empirical knowledge basis in cyber and software security. In addition, the paper makes a contribution to the recent discussion on the terminology about software vulnerabilities and the associated construct validity problems that follow.

cs.SE↗
arXiv2026

Smart Contracts Claimed Vulnerable by the CVE Database, with Labels and Source Locations

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.

cs.CR↗
arXiv2026

Automated Vulnerability Injection in Smart Contracts Using Large Language Models

Assessing vulnerability detection tools for smart contracts requires datasets with known ground truth, yet such datasets are scarce and difficult to build by hand. We propose an approach that uses Large Language Models (LLMs) to automatically inject vulnerabilities into Solidity smart contracts, and demonstrate it in a case study targeting 49 vulnerability types from OpenSCV. Injected contracts are validated through a multi-step pipeline checking compilation, execution, business logic, and the presence of the intended vulnerability. Applied to real-world contracts from SmartBugs, LLMs generate nearly 1,000 candidate variants; after deduplication and validation, 32 confirmed vulnerable contracts spanning 25 vulnerability types survive (a 16.58% survival rate). Surviving contracts concentrate in structurally simpler targets and vulnerability types with localized syntactic patterns. We report practical challenges including LLMs' non-determinism and the difficulty of preserving contract semantics. We then use the validated contracts to assess three static analyzers, revealing complementary and incomplete coverage profiles. Results show that LLM-based vulnerability injection is feasible, while exposing key limitations in scalability and diversity.

cs.SE↗