Search arXiv⌕ Search
Home/Archive/arXiv

arXiv · 2610.13170

Understanding Verification Vulnerabilities in Cross-chain Bridges: An Empirical Study

Yuying Wang·Yi Guo·Jiachi Chen·Hanwen Zhang·Yi Sun
View original source ↗Read source document ↗Export metadata ↓

Abstract

With the rapid development of blockchain technology, numerous heterogeneous blockchains have emerged, each featuring distinct architectures, consensus mechanisms, and application ecosystems. Cross-chain bridges have consequently become a critical infrastructure component, typically relying on smart contracts to facilitate message passing and asset transfers across heterogeneous blockchains. Unlike single-chain contracts, bridge contracts introduce additional verification logic to validate external-chain data, such as state proofs, message sender identities, and signatures. However, correctly implementing such logic is challenging. We refer to vulnerabilities that violate the security guarantees of cross-chain verification as Cross-chain Verification Vulnerabilities (CVVs). To characterize CVVs, we conduct the first systematic empirical study of this vulnerability class. By analyzing 588 security audit reports from 36 real-world cross-chain bridge projects, we derive 11 CVV patterns and organize them into 5 high-level categories according to the affected verification properties. Following this taxonomy, we construct a CVV dataset containing 830 vulnerability instances across 786 contract files. The dataset establishes mappings among audit reports, audited source-code versions, affected source files, and CVV-pattern labels. We then assess existing detection approaches. Current tools provide limited documented coverage of CVV patterns, while only two of four evaluated LLMs outperform an all-pattern constant baseline of 29.3% Macro-F1; the best reaches 51.2%. Together, the limited tool coverage and inconsistent LLM gains motivate detection methods tailored to cross-chain verification semantics.

Explore related subjects

cs.CRcs.SE

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Yuying Wang, Yi Guo, Jiachi Chen, Hanwen Zhang, Yi Sun. 2026-10-09. Understanding Verification Vulnerabilities in Cross-chain Bridges: An Empirical Study. https://arxiv.org/abs/2610.13170

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

KEEP EXPLORING

Related papers

arXiv2026

SoK: Systematizing LLM Prompt Security: Taxonomies, Datasets, and Unified Evaluation of Attacks and Defenses

Prompt-security claims for large language models (LLMs) are often compared as properties of individual attacks or defenses, although measured harmfulness depends on the target model, access setting, attack and defense configuration, prompt sample, and judger. We systematize 272 studies through three linked, multi-label taxonomies of jailbreak attacks, defenses, and model vulnerabilities. To make these dependencies explicit, we introduce an access-compatible evaluation protocol over configured $\langle M,A,D,S,J\rangle$ tuples and instantiate it in PromptSecurity, an open-source platform that records method settings, outputs, judgments, and query costs. We release two complementary datasets: JailbreakDB, with 445,752 jailbreak system-user prompt pairs and 1,094,122 benign prompts, and PromptSecurity-Eval, with 166,200 harmful-query and 9,200 benign-utility output records. We evaluate 11 target models, 20 attacks, nine defenses, and three automated judgers under a matched, single-turn protocol using 100 harmful queries and separate benign-utility tasks. Lower attack success can reflect failure to execute transformed requests rather than stronger safety; attack-category advantages can reverse when one method is excluded, and attack success varies with assistant choice. Defenses can reduce harmful outputs while degrading benign-task utility or causing backfire. Rejudging identical outputs also shows that measured attack success is sensitive to the behavior supplied to the judger, highlighting the need to report judger configurations alongside ASR. These findings motivate configuration-aware reporting rather than context-free method rankings. Leaderboard: https://datasec-lab.github.io/PromptSecurityLeaderboard/. Dataset: https://huggingface.co/datasets/youbin2014/JailbreakDB. GitHub: https://github.com/datasec-lab/PromptSecurity.

cs.CR↗
arXiv2026

The Ghosts of Polymarket: When Off-Chain Matches Meet On-Chain Reverts

Polymarket has emerged as a prominent prediction market platform and one of the fastest-growing applications in DeFi. To achieve low-latency trading, it adopts a hybrid architecture that matches orders off-chain but settles them on-chain for final execution. This design creates a consistency gap we call Ghost Fills: an order that is successfully matched off-chain may later fail during on-chain settlement. To understand the security implications of this gap, we investigate such failed settlements by building GhostHunter, which reconstructs them from on-chain traces and attributes them to concrete attack patterns. Across 2,037,304 reverted matchOrders() transactions, we find that attackers exploit the time gap between matching and settlement to invalidate already matched orders before they are finalized on-chain. We identify four attack vectors, Nonce Bump, Balance Drain, Allowance Revoke, and Proxy Trap, realized via 37 evolving variants. These vectors account for 994,196 of the reverts, enabling risk-free prediction, arbitrage-bot hunting, and liquidity reward manipulation. The cancelled orders spare their owners $103.7 M in net losses that settlement would have locked in, and the attacks cost the operator 2.17 M POL (about $162 K) in gas. During peak hours, up to 24.3% of transactions reverted, causing de facto DoS attacks. We also find that code derived from the flawed contract still appears in 167 independent contracts across 10 chains holding at least $23 M in user funds, extending the impact beyond Polymarket. We have disclosed our evidence to affected parties, and the issue has been partially mitigated.

cs.CR↗
arXiv2026

Bulkhead: Automated Semantic Detection and Remediation of Container Escape Vulnerabilities

Container filesystem isolation depends on safely resolving container-controlled paths during privileged host-container interactions. As third-party plugins and agent sandboxes introduce more interactions, unsafe path resolution can redirect host operations across isolation boundaries, expanding the attack surface for path traversal vulnerabilities. These logic flaws are difficult to mitigate: kernel defenses require intrusive redesign, static rules miss cross-boundary semantics, and manual auditing cannot scale. Large Language Model (LLM) based methods can detect syntax flaws through stable code patterns and identify logic flaws in domains such as smart contracts by comparing equivalent implementations. Container components, however, provide neither form of regularity: their heterogeneous interfaces operate under trust boundaries, filesystem views and interaction orders, making the security invariant difficult to find. We present Bulkhead, an automated framework for detection and remediation. Bulkhead summarizes historical CVEs into structured semantic patterns, correlates documentation with entry and effect side code evidence, and recovers source-to-sink execution contexts. Grounded patterns guide LLM reasoning, while isolated Proof-of-Concept (PoC) execution validates findings. For remediation, Bulkhead generates repository-specific patches, checks that they build, and iteratively verifies path safety and functionality using pattern derived model checking templates and counterexamples before runtime validation. Across container repositories, Bulkhead discovered 20 zero-day vulnerabilities, accounting for 43% of the total number discovered over the past decade. Among them, 3 have been assigned CVEs and the verified patch suggestions have been submitted to the upstream.

cs.CR↗