Severity Standard
If you have any feedback or suggestions: https://secure3.io/feedback
Blockchain security vulnerabilities are security flaws and security risks that arise during the design, implementation, configuration, and operation of blockchain systems. These defects and risks exist in different forms in the system architecture, business logic, algorithm design, code implementation and other aspects of the blockchain system. Once exploited by attackers, the vulnerabilities will cause huge damage to the security of the funds, data, network, nodes, etc. of the blockchain system, thereby affecting the normal operation. To objectively and quantitatively assess the threat level of vulnerabilities in blockchain systems, Secure3 has formulated a set of detailed vulnerability grading rules based on CVSS 2.0 (Common Vulnerability Scoring System) and in combination with blockchain characteristics and application scenarios. The methods described in these rules are applicable to the security vulnerability grading scenarios of Smart Contracts.
Severity Rating System
Vulnerabilities are essentially unintended security flaws or risks, which can be classified into four threat levels: "High", "Medium", "Low" and "Informational". The rating is mainly based on the degree of damage and effort to exploit:
| high damage | medium damage | low damage | |
|---|---|---|---|
low effort to exploit | High | Medium | Low |
medium effort to exploit | Medium | Medium | Informational |
high effort to exploit | Low | Informational | Informational |
Degree of Damage
High Damage
High damage generally refers to the vulnerability that can have a bad impact on confidentiality, integrity, availability or its economic model of a smart contract, and can cause a lot of economic losses to the contract business features, large-scale data issue, privilege access compromise, failure of critical functions, and loss of credibility, or affecting the normal operation of other smart contracts interacting with it and cause a lot of losses and irreversible damage. Including but not limited to:
Financial
Permanent Asset Freezing: The smart contract facilitates the permanent freezing of assets, rendering them inaccessible indefinitely, causing irreversible loss and financial hardship for affected users.
Significant Fraud: Large-scale fraud that results in substantial financial losses.
Transaction Manipulation: Alteration or interception of transactions resulting in significant financial losses.
Market Manipulation: Exploits causing severe market price fluctuations and financial damage, such as Oracle Manipulation.
Critical Transaction Failures: Failures in high-value transactions leading to major financial loss.
Economic Model Design Invalidity: The core economic model design of smart contracts is invalid or can be altered, for example, introducing mining incentives with serious problems in the mechanism, leading to economic instability and distrust among stakeholders.
Major Fund Theft: Unauthorized withdrawal or spending of large sums of assets from the smart contract.
Unauthorized Issuance: Unauthorized large-scale additional issuance or overspending of assets, such as unauthorized minting of tokens.
Liquidity Draining: Vulnerabilities that allow attackers to drain liquidity from decentralized exchanges or liquidity pools.
Systematic Double-Spending: Large-scale double-spending attacks causing substantial economic loss.
Others: Operations result in a large amount of assets locked or lost (please specify).
Functional
Core Functionality Compromise: The core business functions are arbitrarily tampered with or bypassed, rendering the projects cannot operate as expected, such as signature verification, proof verification, etc.
Denial of Service(DoS): The vulnerabilities can be exploited to exhaust resources such as gas, CPU cycles, or storage, etc., rendering the contract unusable.
RPC API Crash: RPC API crash affects projects with greater than or equal to 25% of the market capitalization on top of the respective layer.
Governance Voting Manipulation: Manipulation of Governance voting results deviating from the voted outcome and resulting in a direct change from the intended effect of the original results, undermining the democratic process.
Network Downtime: Network not being able to confirm new transactions, resulting in total network shutdown, halting all transaction processing activities.
Hard Fork: Unintended permanent chain split requiring a hard fork, leading to network partition and divergence in consensus, disrupting network operations.
Chain Split: Unintended chain split causing network partition, leading to inconsistency in transaction validation and potential data inconsistencies.
Critical Data Integrity Compromise: Vulnerabilities that compromise the integrity and reliability of data stored within the smart contract, allowing unauthorized modification, deletion, or exposure of sensitive information, compromising user trust and confidentiality.
Transaction Processing Overload: Causing network processing nodes to process transactions from the mempool beyond set parameters, leading to congestion, delays, and potential network instability.
Fairness Design Invalidity: The core fairness design of smart contracts is invalid, such as voting, lottery, auction, etc., leading to unfair outcomes and loss of trust among participants.
Non-Standard Interface Significant losses Issues: Certain types of smart contracts use non-standard interfaces or implementations(e.g. EIP), affecting safe calls or interface compatibility, resulting in significant losses and operational disruptions.
Others: Other flaws of functions can cause a severe system crash and cannot be recovered, resulting in significant losses(please specify).
Medium Damage
Medium damage generally means that vulnerability can have a bad impact on confidentiality, integrity, availability or its economic model of the smart contract, and can cause moderate economic losses to the contract business system, partial function unavailability, and reduced credibility. Including but not limited to:
Financial
Temporary Asset Freezing: The smart contract allows for the temporary freezing of assets, disrupting normal operations and causing inconvenience to users.
Minor Fund Freezing: Temporary/Permanent locking of minor funds(e.g., unclaimed royalties, yield, etc.), resulting in moderate financial inconvenience for users.
Minor Fund Theft: The smart contract enables the theft of minor funds(e.g., unclaimed royalties, yield, etc.), resulting in financial losses for rightful owners.
Partial Fee Skimming: Exploits that allow attackers to skim a moderate but not total portion of transaction fees from users without immediate detection, leading to increased costs for users and reduced revenue for the platform. For example, an attacker could manipulate gas fees for transactions in a decentralized exchange to collect excess fees.
Interest Rate Manipulation: Partial Interest Rate Manipulation: Manipulating interest rates in DeFi applications to partially benefit certain users or exploit arbitrage opportunities, resulting in moderate financial losses for others. For example, an attacker could manipulate interest rates in a lending protocol to attract borrowers and lenders to their advantage.
Unfair Airdrop Distribution: Exploits that allow certain users to receive a disproportionate share of airdropped tokens.
Others: Other operations result in a moderate amount of assets locked or lost (please specify).
Functional
Non-Standard Interface Moderate losses Issues: Certain types of smart contracts use non-standard interfaces or implementations(e.g. EIP), affecting safe calls or interface compatibility, resulting in moderate losses and operational disruptions.
Unintended Alteration of NFT Representations: Vulnerabilities that result in the unintended alteration of what a non-fungible token (NFT) represents, such as its token URI, payload, or artistic content. For example, a vulnerability in a decentralized marketplace for NFTs could allow an attacker to modify the metadata associated with NFTs, leading to misrepresentation or loss of value for affected tokens.
Unbounded Gas Consumption: Vulnerabilities in smart contracts that allow for unbounded gas consumption, leading to denial-of-service (DoS) attacks or causing the contract to become unusable. This could occur due to recursive function calls, complex looping structures, or other factors that result in excessive gas usage without termination.
Smart Contract Funds Depletion: Smart contracts becoming unable to operate due to a lack of funds, leading to disruptions in service or functionality. For example, a decentralized lending protocol may run out of reserves, preventing users from borrowing or lending assets.
Unexpected leakage of data: Unexpected leakage of non-critical data that will not directly cause moderate harm.
Operation Stability Issues: Issues affecting contract stability, such as high invocation failure rates or resource consumption. For example, such as a contract experiencing frequent transaction failures.
Others: Other flaws of functions can cause a severe system crash and cannot be recovered, resulting in significant losses(please specify).
Low Damage
Low Damage generally refers to the risks and hazards that the vulnerability can have a slight impact on the smart contract, can pose a security threat to the contract business system, and need to be improved. Including but not limited to:
Financial
Minor Fee Miscalculations: Slight discrepancies in transaction fee calculations that result in minimal financial impact. For example, such as rounding errors causing users to overpay by a negligible amount.
Tiny Token/Fund Accumulation: Accumulation of tiny, negligible amounts of tokens or funds left over from transactions.
Incorrect Exchange Rate: The contract uses an outdated or inaccurate exchange rate for calculations, leading to minor discrepancies in token values.
Incorrect Interest Calculation: The contract calculates interest payments with minor errors, resulting in slightly higher or lower payouts than intended.
Dust Theft: An attacker can exploit the contract to steal small amounts of tokens that are considered "dust" due to their insignificant value.
Others: Other operations result in a tiny amount of assets locked or lost (please specify).
Functional
Minor UI/UX Glitches: User interface issues that do not affect the underlying smart contract operations.
Gas Optimisation: Small issues with gas optimization that cause minor inefficiencies. For example, functions or variables that consume gas but serve no purpose.
Non-Critical Function Deprecation: Deprecation of non-critical functions, for example, outdated features that are rarely used.
Minor Validation Errors: Small errors in data validation processes, for example, occasional incorrect validation messages.
Event Emission Errors: Emitting events incorrectly or missing events affects monitoring but not core functions.
Intermittent Function Failures: Vulnerabilities causing intermittent failures of smart contract functions. For example, such as a function that occasionally fails under specific conditions.
Non-Standard Interfaces: Certain types of smart contracts use non-standard interfaces or implementations, which affect safe calls or interface compatibility without causing losses.
Display Data Mistakes: Mistakes in how data is displayed to users without affecting the actual data.
Transaction Fee Modification: Modification of transaction fees outside of design parameters.
Block Stuffing: Deliberate actions aimed at disrupting normal network operations by filling blocks with excessive transactions, leading to congestion and increased transaction fees.
White Paper/Comment Implementation Errors: Code logic does not implement the content of the white paper, or code implementation conflicts with the white paper or comment.
Attacker forced other users to take action: The attacker forced other users to take action, but the users did not incur any financial loss.
Useless data: Test or useless data in the contract.
Panics: Improper error handling implementation causes the program to panic.
Others: Other flaws of functions can cause intermittent or minor system failures and severely impact the user experience (please specify).
Degree of Exploitability
Low Effort to Exploit
Low effort to exploit generally means that the cost of exploiting a vulnerability is low, there is no special exploitation threshold, and the vulnerability can be triggered consistently. Including but not limited to:
Cost
0 capital cost: The Attack requires a small or close to 0 capital cost, such as gas fee, protocol fee, flash loan fee, etc.
0 resource cost: The Attack requires a small or close to 0 resource cost, such as bandwidth, computation, etc.
Small amount of asset: The Attack needs to hold a small amount of a certain asset.
Others: Other operations that qualify for low cost (please specify).
Complexity
Without any attack: Once the contract is successfully deployed, the vulnerability will occur without any attack.
Attack path is straightforward: The attack path is very straightforward. To be specific, the call flow consists of 1-2 functions.
Bypass security checks: Vulnerabilities that can be exploited without needing to authenticate or bypass any form of security check.
Lack of access control: Permissions or access control mechanisms that are too lenient, allowing unauthorized users to gain access to restricted areas or functionalities.
Common Web3 Attack Methods: The attack methods are very common and have been disclosed many times in past web3 security events, such as flash loan, etc.
Other: Other operations that qualify for low complexity (please specify).
Medium Effort to Exploit
Medium effort to exploit generally means that the vulnerability requires a certain cost, or there are certain exploitation conditions, and the vulnerability is not easily triggered consistently. Including but not limited to:
Cost
Costs lower than profit: It requires a certain amount of capital cost that is less than the profit of the attack.
A certain amount of assets: It requires the attacker's own account assets or assets in the contract to reach a certain scale.
Higher transaction fees: It requires attackers to use higher transaction fees, such as higher gas for front-running.
Others: Other operations that qualify for moderate costs (please specify).
Complexity
Normal conditions of attacker: It requires the attacker to meet certain normal conditions, such as collaboration with a miner or block producing node, or the ability to package transactions and produce blocks to rearrange or filter transactions.
Normal conditions of victim: It requires the victim to meet certain normal conditions, such as the asset amount being in a certain range.
Common attack methods in non-smart contracts: It needs to be combined with common attack methods in non-smart contracts, such as attacking off-chain data sources.
Attacking other contracts on the chain: It needs to be combined with known attack methods in smart contracts, such as attacking other Oracle contracts on the chain.
A certain time frame: It needs to be triggered within a certain time frame, such as a specific block height.
Transactions to be executed in specific scenarios: It requires transactions to be executed in specific scenarios, such as specific transactions packaged in Uncle Block.
A certain time cost: It requires a certain time cost, such as several days.
A minimal amount of resources: It requires a minimal amount of network/computing resources.
Predictable random number/Hash: Predictable or manipulable random number or hash generation.
The path of attack is a bit complicated: The path of attack is a bit complicated. To be specific, the call flow consists of 3-6 main functions.
Uncommon attack methods : These attack methods are uncommon and have rarely been disclosed in past web3 security events.
Other: Other operations that qualify for moderate complexity (please specify).
High Effort to Exploit
High effort to exploit generally means that the vulnerability requires a higher cost, or the exploitation conditions are very strict, and the vulnerability is difficult to trigger. Including but not limited to:
Cost
Costs equalling/exceeding the profit: It requires significant capital expenditure, which may closely equal or exceed the potential profit from the attack.
Required a lot of assets: The attacker's own account or contract needs to hold assets at a scale equivalent to hundreds or more normal users.
Others: Operations that qualify for high cost (please specify).
Complexity
Difficult-to-fulfill conditions of attacker: The attacker needs to meet certain difficult-to-fulfill conditions, such as obtaining particularly crucial admin-like permissions within the contract.
Difficult-to-fulfill conditions of victim: It requires the victim needs to meet certain difficult-to-fulfill conditions, such as reaching a specific value threshold in assets.
Substantial time expenditure: It requires a significant time investment, such as several months or even longer.
Required substantial resources: It requires a substantial amount of resources (e.g. network, computing, etc.)
Unpredictable random number/Hash: Unpredictable random number or hash generation.
Unexpected operation: Attacks that rely on unexpected operations by administrators or users.
Low Probability: Any factor that causes a really low probability of the attack occurring.
Others: Operations that qualify for high complexity (please specify).
Additional Notes
The above criteria may not encompass all potential cases, the final determination of severity will be adjudicated by the Secure3 team on a case-by-case basis.
Any issue that is not exploitable within the scope of the contest is defined as speculating on future code. Any such speculation only has the potential to be valid if the root cause is demonstrated to be in the contest scope.
When an in-scope contract composes/inherits with an out-of-scope (OOS) contract, and the root cause exists in the OOS contract, the finding is to be treated as OOS. Exceptional scenarios are at the discretion of the Secure3 team.
Please note the location of the submitted code. If it is not the link to the repository provided by secure3, it will be considered invalid. The format is as follows:
For the out-of-scope issue, unless the severity is high or medium and the client accepts it, it will not be accepted by Secure3.
In most cases, we will make the final decision on the issue based on customer feedback.
Last updated