Smart Contract Security Vulnerabilities and Mitigation Methods: A Scoping Review

2.6. Data Charting

A structured charting form was used to extract bibliographic and technical information from each included evidence source. The chart included the year of publication, evidence type, blockchain platform, programming language or representation, type of vulnerability, detection, prevention, verification, or mitigation mechanism, validation mechanism, sample or benchmark details, and significant finding. Primary empirical tools and experiments were coded as primary evidence, whereas systematic reviews, technical reviews, taxonomies, and meta-analytic comparisons were coded as secondary evidence. This distinction prevents synthesis-level observations from being treated as independent attack observations. The categories in data-charting were merged when they used semantically similar labels to describe the same concept, e.g., transaction-ordering dependence and front-running or arithmetic overflow and underflow. The final extraction matrix is given in Table 3.

2.7. Coding, Thematic Synthesis, and Frequency Analysis

The synthesis used directed qualitative coding followed by cross-source comparison. The labels of vulnerability were coded on the evidence-source level and subsequently aggregated into seven higher-order families such as external-call / control-flow, arithmetic / state, block/transaction context, authorization / access control, resource / availability, lifecycle / fund-safety, and logic/semantic/exception handling. Security approaches were coded into distinct detection, prevention, verification, and mitigation families, including static analysis, symbolic / formal methods, fuzzing and runtime monitoring, machine / deep learning, secure coding and design patterns, multi-tool auditing and benchmarking, and taxonomy/evidence mapping. Document-level reporting frequency was then calculated for each vulnerability family. Each included publication could contribute a maximum of one count to a given vulnerability family. Source type was retained during coding to limit overlap in interpretation: the six secondary evidence sources were used to harmonise terminology, support taxonomy development, and contextualise recurring vulnerability-method relationships, but they were not treated as independent empirical replications of primary findings. Primary studies remained the principal basis for interpreting tool performance, exploitability, validation, and operational effectiveness. Consequently, a vulnerability reported in both a primary study and a secondary synthesis could contribute to document-level coverage, but this was interpreted as convergence in the literature rather than two independent empirical observations. The resulting frequencies therefore represent coverage across the 25 evidence sources rather than prevalence, effect size, or independent attack incidence.

2.8. Quality and evidence considerations

No formal risk-of-bias scoring was done since the evidence included in this study consists of incompatible designs, such as software tools, benchmark experiments, runtime defenses, empirical chain analyses, taxonomies, systematic reviews, and meta-analytic comparisons. Following the mapping objective of a scoping review, methodological heterogeneity was managed by mapping evidence type, validation method, dataset or benchmark, and evidence level, instead of statistically combining results. Special care was taken in the interpretation of accuracy or precision values since benchmark composition, vulnerability labelling, source-code availability, compiler version, and platform coverage vary across sources. Claims of comparative effectiveness are therefore interpreted within the validation conditions reported by each publication rather than as universal performance rankings.

3. RESULTS

3.1. Study Selection and Corpus Profile

This section presents the study-selection process and the profile of the final evidence corpus.

Search interfaces found 1,200 records: 240 in Scopus, 469 in Web of Science Core Collection, 389 in IEEE Xplore and 102 in Springer Nature Link. Following the deletion of 210 duplicate records, 990 records were screened by title and abstract, with 720 being eliminated. Among the 270 reports requested to be retrieved, 15 were not retrieved, and 255 full-text reports were available to assess eligibility. An additional 230 reports were filtered out based on the reasons indicated in Fig. (1) to arrive at 25 evidence sources that were included. The final corpus spans 2016–2025 and comprises 19 primary technical or empirical studies and six secondary reviews, syntheses, or taxonomies. It is highly focused on Ethereum, Solidity, and EVM-level analysis. It encompasses primary vulnerability-detection tools, symbolic and formal analysers, fuzzing, and runtime-defense systems, machine- and deep-learning models, empirical benchmark comparisons, vulnerability taxonomies, and secondary syntheses. Table 3 presents the cross-source extraction matrix, and Fig. (2) presents the temporal distribution. The distribution indicates an early focus on static, symbolic, and exploit-oriented analysis followed by growth in learning-based approaches.

3.3. Detection, Prevention, Verification, and Mitigation Approaches

The included evidence sources demonstrate three broad methodological stages. The first stage focuses on symbolic execution, static analysis, fuzzing, and exploit generation. Oyente demonstrates symbolic execution over Ethereum contracts [10]. SmartCheck instantiates vulnerability knowledge as source-level patterns [12], and Securify as dependency graphs and security patterns [14]. ContractFuzzer introduces execution-based testing with vulnerability-specific oracles [13]. MAIAN, teEther, and ETHBMC also show that multi-transaction or exploitable states can be determined by symbolic and bounded reasoning as opposed to local syntax alone. Together, these methods form a robust basis for pre-deployment analysis, though their reach is limited by the semantics of the modeled EVM, path exploration, vulnerability specifications, and available computational resources.

A second stage deals with deployed or operational contracts. Instead of having to replace contracts, Sereum defends against reentrancy by runtime monitoring and dynamically tracking tainted contracts [17]. This shifts the mitigation goal from finding a defect before deployment to limiting damaging execution after deployment. A complementary empirical view is given by Perez and Livshits [22], who demonstrate that a small share of the contracts that were deemed vulnerable were actually exploited on-chain. Through their analysis, they justify the need to keep vulnerability detection, exploitability, and realised harm analytically separate. Even a technically correct detector can produce findings with substantially different practical risk, which supports exploitability-aware prioritisation and validation.

The third stage is defined by machine and deep learning. Graph-based learning represents contract structure and control relations, as demonstrated by Zhuang et al. [20]. Multi-task learning shares information across vulnerability classes [23], and CBGRU employs convolutional and recurrent representations [24]. Eth2Vec trains contract-wide representations that can remain useful under code rewriting [25]. Subsequent works augment the richness of representation by hierarchical graphs, semantic pretrained models, multimodal fusion, and heterogeneous AST-CFG-DFG graphs. Ma et al. [28] employed hierarchical attention, Tang et al. [29] reported high-performance results for a CodeBERT-based approach, and Deng et al. [30] used a combination of multiple code modalities. Xu et al. [31] expand graph learning to contract-level and line-level detection, indicating a shift toward finer-grained vulnerability localisation alongside classification and explainability.

Another form of security-assurance evidence is provided by secondary syntheses and taxonomies. Kushwaha et al. [26] and Zhou et al. [27] categorise vulnerabilities, tools and countermeasures within the Ethereum ecosystem. OpenSCV addresses terminology fragmentation by creating a hierarchical vulnerability taxonomy using heterogeneous classifications and detection tools [32]. Bresil et al. [33] compare deep-learning strategies based on the published evidence. In contrast, Azimi et al. [34] review the security design patterns and discover that a limited number of them directly address the known types of vulnerabilities. Together, these sources suggest that detection research has grown faster than preventive design coverage. Table 5 therefore distinguishes methodological families by control point, evidence base, and recurring limitations rather than treating detection, prevention, verification, and mitigation methods as equivalent.

3.4. Vulnerability-to-Security-Approach Cross-Map

According to the cross-map, smart-contract security assurance is layered. Design-time checks, effects, interactions, and reentrancy guards address external-call vulnerabilities, which can be detected using fuzzing during testing, reentrancy guards before deployment, or by static or symbolic methods before deployment. Checked arithmetic and secure coding can help eliminate arithmetic weaknesses, although it is also a goal of a static analyser and learning-based classifier. Block-context weaknesses either involve code-level limitations and the reasoning of transaction or environmental state, and lifecycle and fund-safety defects can frequently involve trace or value-flow analysis. This trend implies that the general security assurance cannot be narrowed down to the option of using the most successful detector in a single benchmark. Table 6 associates the seven vulnerability families with the most defensible detection, prevention, verification, and mitigation strategies embodied in the corpus.

4. DISCUSSION

4.1. Persistent Vulnerability Structure

The synthesis provides the answer to RQ1 by demonstrating that the research on smart-contract security is highly focused on external calls, control flow, and transaction context. At the document level, external-call/control-flow weaknesses were reported in 92% of the included evidence sources, and block/transaction-context weaknesses were reported in 76%. The prominence of these families is technically consistent since smart contracts are a mixture of program logic and externally triggered calls, publicly ordered transactions, economic transfer of value, and deterministic execution on a shared state. Atzei et al. [11] already conceptualised many attacks as language, EVM, and blockchain layer interactions, and subsequent evidence does not refute that framework. Rather, more modern approaches recode the same underlying flaws in various forms again and again. This continuity suggests that improvements have been made in analysis capability, scale, and representation, as opposed to the removal of the underlying classes of smart-contract risk.

The frequency analysis also explains why arithmetic or access-control bugs cannot be considered obsolete merely because more recent languages or compiler checkers address some instances. At the document level, arithmetic/state weaknesses were reported in 56% of the included evidence sources, and authorisation/access-control weaknesses were reported in 44%. This continuity is partially due to benchmark continuity, but also demonstrates that security failures are not entirely compiler problems. Huang et al. [23] utilise arithmetic and reentrancy as targets of multi-task detection, and MVD-HG consists of arithmetic and access-control targets in a more general heterogeneous-graph framework [31]. The field thus still considers these classes of vulnerabilities as useful analytical categories regardless of the change in the implementation environment.

These frequencies require careful interpretation because six included sources are secondary reviews, syntheses, or taxonomies that may discuss primary studies also represented directly in the corpus. Secondary sources were retained to stabilise terminology, corroborate vulnerability categories, and map broader methodological coverage, but they were not treated as additional independent empirical confirmations. Repeated reporting of a vulnerability family in a primary study and in a secondary synthesis therefore indicates convergence in the literature rather than empirical replication. The cross-map should consequently be interpreted as a descriptive synthesis of recurring vulnerability-method relationships, with primary studies providing the principal empirical basis and secondary sources providing contextual corroboration and taxonomy harmonisation.

4.2. Evolution from Rule-Based Analysis to Learned Representations

The obvious methodological shift over the decade provides an answer to RQ3. Initial studies focus on symbolic execution, pattern-based static analysis, fuzzing, dependency-graph analysis, and exploit generation. These techniques expose their assumptions and tend to leave traceable results or rule violations. An example of symbolic execution is provided by Luu et al. [10], and formalization of source-level patterns is implemented in SmartCheck [12]. teEther generates concrete exploits, whereas ETHBMC identifies bounded counterexamples or triggering inputs [16, 19]. Interpretability is the key advantage of this generation, and scalability and semantic completeness are recurring limitations.

Representation learning has gained more and more prominence since 2020. Graph neural networks are able to capture structural relationships, multi-task models are able to share information across vulnerability classes, and code-language models learn semantic representations. Tang et al. [29] and Deng et al. [30] indicate that an optimized CodeBERT-based model has good F1 performance, and that integrating source, opcode, and control-flow information can enhance multi-class detection, respectively. MVD-HG continues this orientation with heterogeneous graph relations as well as line-level localisation [31]. Nevertheless, improved benchmark performance does not always result in stronger operational security. Results based on learning are sensitive to labels, datasets, injection strategies, compiler versions, and train-test distributions; the values of performance must be viewed as evidence conditioned on the benchmark but not as evidence of universal superiority.

4.3. Effectiveness, Validation, and Exploitability

RQ2 requires distinguishing detection, prevention, verification, and mitigation from demonstrated risk reduction. Durieux et al. [21] demonstrate that even within the same population of contracts, automated analysers can diverge significantly, which implies that the output of tools is sensitive to implementation, supported compiler versions, as well as vulnerability definitions. Perez and Livshits [22] introduce another critical risk factor: only a small proportion of the contracts identified as vulnerable in their large sample were observed to be exploited (1.98%). This does not diminish the importance of vulnerability detection; rather, it shows that exposure, exploitability, attacker incentives, and contract value mediate realised harm. A stronger assurance process should therefore integrate vulnerability identification with exploit validation, contextual severity assessment, and mitigation verification.

Design- and runtime-oriented evidence also demonstrates the necessity of layered controls. Sereum is able to defend against reentrancy in existing contracts during execution time [17], but design patterns aim to defend against unsafe structures prior to deployment. But Azimi et al. [34] conclude that only a small number of established security patterns can be directly related to recognised vulnerability categories, which suggests a prevention-coverage gap. OpenSCV also illustrates the scope and terminological disaggregation of the vulnerability domain [32]. These results suggest that security engineering cannot be based on one lifecycle stage. Prevention, detection, formal reasoning, exploit validation, and runtime safeguards deal with various failure modes and should be integrated based on the criticality of the contract.

4.4. Research Gaps and Implications

There are four significant evidence gaps that are identified in RQ4. First, the corpus is largely Ethereum- and Solidity-focused, which means that the generalizability across platforms is low. Second, the comparability of benchmarking is limited due to the fact that the evidence sources contain various vulnerability labels, injected defects, real-world contracts, compiler versions, and metrics. Third, numerous learning-based primary studies maximize classification performance but do not have similar evidence on exploitability, remediation efficacy, or post-deployment behavior. Fourth, the coverage of preventive design is still significantly less than the list of known vulnerabilities. Future reports should give standardised definitions of vulnerabilities, provenance of data sets, compiler and platform versions, class distribution, false-positive and false-negative analysis, and reproducible code or benchmark artifacts where feasible.

The results also carry practical implications for auditors and developers. Coverage can be fast with static analysis, but it should be complemented with analyses of vulnerabilities that are sensitive to multi-transaction state or runtime circumstances. Symbolic and formal methods provide more powerful execution reasoning, but can have more limited specifications and demand more computation. Fuzzing provides tangible evidence of execution, and runtime protection can decrease the risk of already deployed contracts. Learning-based models are also scale- and multi-class-sensitive, though when the contract value is high, they should be used in combination with rule-based or semantic checks. The cross-map in Table 6 therefore supports a defense-in-depth strategy in which techniques should be selected according to the vulnerability family, lifecycle phase, and required assurance level.

LIMITATIONS AND FUTURE DIRECTIONS

This review has several limitations. Only four information sources and English-language literature were searched, which means that potentially eligible work that is indexed elsewhere or published in other languages might not have been found. The title-based search query limited the amount of general blockchain-security literature, but this method can suppress sensitivity to articles whose titles focus on a tool name or platform-specific terms instead of security or vulnerability terms. Titles and abstracts were screened and full texts evaluated by two reviewers who discussed and agreed on disagreements, though no formal inter-rater reliability coefficient was computed. The numerical study-selection pathway and full-text exclusion categories applied in this review are reported in Fig. (1).

The final corpus contained 25 evidence sources from 1,200 identified records, comprising 19 primary technical or empirical studies and six secondary reviews, syntheses, or taxonomies. This substantial reduction reflects the strict eligibility criteria requiring direct smart-contract security relevance, peer review, readable full text, sufficient extractable technical detail, English language, and publication within 2016–2025. These restrictions increased topical specificity but reduced empirical breadth and may have omitted relevant work with tool-specific titles, incomplete reporting, non-English publication, or indexing outside the four searched sources. Accordingly, the vulnerability-to-security-method cross-map should be interpreted as a structured synthesis of the eligible evidence captured by this protocol rather than a comprehensive or universally generalisable representation of all smart-contract security research. The limited primary-study base also reduces confidence in sparsely represented vulnerability-method associations and cross-platform conclusions.

The evidence included is heterogeneous, and primary software tools, benchmark studies, empirical on-chain analyses, taxonomies, systematic reviews, and meta-analytic comparisons do not offer directly equivalent types of evidence. No formal risk-of-bias score was used since no single appraisal tool is suitable for all these designs; evidence type and validation basis were charted directly. Document-level frequencies indicate how often a family of vulnerabilities is reported in the sources of evidence included in the analysis and cannot be understood as actual prevalence of vulnerabilities or attack rates. Performance measures should also not be compared across incomparable datasets as though they had been measured in equal conditions. Lastly, the research on Ethereum, Solidity, and EVM is predominant, which restricts the inferences to other smart-contract ecosystems. These restrictions do not obstruct evidence mapping, but limit conclusions regarding universal security efficacy. Although secondary sources were not given independent empirical weight, overlap remains possible because some of their underlying primary studies may also appear separately in the corpus. This further support interpreting the frequencies and cross-map as descriptive evidence mapping rather than quantitative estimates of independent evidence strength. Future reviews could broaden database coverage, relax title-field constraints, or conduct primary-study-only synthesis where sufficiently comparable data permit.

Fig. (D1). Final Springer Nature Link result page showing 102 results with 2016–2025 and English filters.
Appendix E

PRISMA-ScR Reporting Crosswalk

This crosswalk maps the principal PRISMA-ScR reporting domains to their locations in the manuscript and identifies how each domain is reported.