This document summarizes common security vulnerabilities and attack patterns in blockchain systems. It focuses on key risks across the network layer and ledger layer, helping project teams, security researchers, and auditors build a practical risk baseline and audit checklist.
For ease of use, each entry typically includes the following fields:
- Severity: Indicates the potential impact of the issue on system security and business operations.
- Description: Explains the vulnerability mechanism, attack path, and possible consequences.
- Recommendation: Provides engineering mitigation ideas or audit directions.
- Reference: Adds papers, incident reports, or further reading materials.
- Blockchain Common Vulnerability List
This document focuses on common lower-layer and infrastructure risks in blockchain systems, mainly covering:
- Network-layer and ledger-layer issues in public blockchains, consortium chains, and application-specific chains.
- Risks related to nodes, validators, miners, RPC services, transaction processing, and consensus.
- Issues involving cryptographic implementation, transaction consistency, and asset-accounting correctness.
The following topics are intentionally not expanded in this document, although they remain important:
- Smart contract business-logic details.
- Internal exchange risk-control and settlement workflows.
- Wallet frontend, browser extension, and mobile-client security.
- Complex bridge protocol design, oracle systems, and application-layer DeFi mechanisms.
Severity in this document is assessed mainly by combining the following factors:
- Asset impact: Whether the issue may directly lead to significant asset loss.
- Exploitation difficulty: Whether the attack is easy to reproduce or requires substantial resources.
- Blast radius: Whether the issue affects a single node, a local segment of the network, or global ledger state.
- Recovery cost: Whether the issue is easy to detect, roll back, or remediate once triggered.
Even if exploitation conditions are relatively strict, an issue may still be rated high if it can cause network-wide consequences once triggered.
| Layer | Submodule | Primary Focus |
|---|---|---|
| Network Layer | P2P, RPC | Node connectivity, transport security, exposed interfaces, and remote attack surfaces |
| Ledger Layer | Consensus, Cryptographic, Transaction | Consensus safety, cryptographic implementation safety, transaction consistency, and asset integrity |
| Extended Infrastructure | Bridges, Node Operations, Supply Chain | Message validation, key protection, build integrity, and dependency hygiene |
In practical audits, it is often useful to start in the following order:
- Confirm high-risk exposure first, such as public RPC endpoints, unencrypted communications, missing consensus penalties, and weak transaction-confirmation logic.
- Then review systemic weaknesses that can be exploited at scale, such as insufficient connection limits, weak randomness, and incomplete event-field validation.
- Finally, evaluate lower-frequency but high-impact issues in concrete business scenarios, such as chain reorganization, timejacking, false top-ups, and abuse of governance privileges.
Network-layer risks mainly affect node connectivity, message propagation, and exposed external interfaces. They often lead to node isolation, service disruption, privacy leakage, or remote exploitation.
When auditing P2P, start by checking the following:
- Whether peer discovery and inbound/outbound connection strategies can be manipulated by malicious peers.
- Whether connection limits for single IPs, subnets, and same-type nodes are reasonable.
- Whether the P2P protocol includes chain identifiers, network identifiers, or handshake authentication.
- Whether node communications are encrypted and whether metadata is exposed in plaintext.
- Whether time synchronization depends excessively on external peer time.
- Severity: High
- Description:
An attacker can subvert the blockchain by creating a large number of pseudonymous identities and pushing legitimate entities into the minority. These virtual nodes can behave like genuine nodes and exert disproportionate influence on the network. This may lead to several follow-on attacks such as DoS and DDoS. - Recommendation:
Increase the maximum number of peer connections and limit the number of hosts associated with a single IP address. - Reference:
Preventing Sybil Attack in Blockchain using Distributed Behavior Monitoring of Miners
- Severity: High
- Description:
The attacker monopolizes all of the victim's inbound and outbound connections, isolating the victim from the rest of the network. - Recommendation:
Increase the maximum number of peer connections and limit the number of hosts associated with a single IP address. - Reference:
Eclipse Attacks on Bitcoin's Peer-to-Peer Network
Low-Resource Eclipse Attacks on Ethereum's Peer-to-Peer Network
- Severity: Low
- Description:
The attacker passively listens to network communications to obtain private information such as node identifiers, routing updates, or application-sensitive data. This information can then be used to compromise nodes, disrupt routing, or degrade application performance. - Recommendation:
Encrypt communications using transport encryption such as TLS. - Reference:
The RLPx Transport Protocol
- Severity: Medium
- Description:
A denial-of-service attack attempts to make a host or network resource unavailable by flooding it with superfluous requests, exhausting capacity, or triggering failure paths, thereby preventing legitimate requests from being processed. - Recommendation:
a. Increase the number of nodes across different regions.
b. Prevent malformed parameters from crashing the software.
c. Limit memory queue size.
- Severity: Low
- Description:
BGP hijacking, also referred to as prefix hijacking or route hijacking, is the illegitimate takeover of groups of IP addresses by corrupting Internet routing tables maintained through BGP. - Recommendation:
Increase the number of nodes across different regions. - Reference:
BGP Hijacking Hijacking Bitcoin: Routing Attacks on Cryptocurrencies
KlaySwap crypto users lose funds after BGP hijack
- Severity: Low
- Description:
The Alien Attack vulnerability was first discovered by the SlowMist team. Also known as peer-pool pollution, it refers to an attack that induces nodes of similar chains to invade and pollute each other. The root cause is that same-family blockchain systems fail to distinguish dissimilar nodes at the protocol layer. - Recommendation:
Add network identifiers to the P2P connection protocol, such as ChainID in Ethereum and Magic in Bitcoin. - Reference:
Alien Attack Vulnerability from P2P Protocols
- Severity: High
- Description:
Timejacking exploits a theoretical weakness in Bitcoin timestamp handling. An attacker alters the node's perception of network time and forces it to accept an alternative blockchain. This can happen when a malicious actor adds multiple fake peers with inaccurate timestamps. - Recommendation:
Restrict acceptable time ranges or rely on the node's local system time.
When auditing RPC, start by checking the following:
- Whether RPC endpoints are publicly exposed and whether authentication and access control are enforced.
- Whether dangerous features are enabled, such as remote wallet unlocking, transaction signing, or administrative interfaces.
- Whether cross-origin access, weak input validation, or missing rate limits exist.
- Whether HTTP/HTTPS configuration is appropriate and whether communications remain in plaintext.
- Whether exception handling is robust enough to prevent crashes or resource exhaustion under malicious requests.
- Severity: Low
- Description:
The attacker passively listens to network communications to obtain private information such as node identifiers, routing updates, or application-sensitive data. This information can then be used to compromise nodes, disrupt routing, or degrade application performance. - Recommendation:
Encrypt communications using HTTPS or similar protections.
- Severity: Medium
- Description:
An attacker constructs malformed requests to crash the node or exhaust service resources. - Recommendation:
a. Prevent malformed parameters from crashing the software.
b. Limit memory queue size.
- Severity: Low
- Description:
The Ethereum Black Valentine's Day vulnerability was first discovered by the SlowMist team. An attacker can steal cryptocurrency through RPC requests when a remote node unlocks its wallet. - Recommendation:
a. Disable external access to the RPC interface.
b. Disable wallet functionality on public nodes. - Reference:
A Billion-Scale Token Theft Incident Caused by an Ethereum Ecosystem Flaw
- Severity: Low
- Description:
This category includes XSS, template injection, third-party component vulnerabilities, HTTP parameter pollution, SQL injection, XXE, deserialization vulnerabilities, SSRF, code injection, local file inclusion, remote file inclusion, command injection, buffer overflow, and format-string issues. - Recommendation:
Perform dedicated interface penetration testing. - Reference:
SlowMist Exchange Security Audit Program
- Severity: Low
- Description:
The attacker tricks a victim into opening a malicious webpage, connects to the cryptocurrency wallet's RPC port through a cross-domain request, and then steals crypto assets. - Recommendation:
Disable cross-domain access on exposed nodes.
Ledger-layer risks mainly affect state consistency, transaction validity, consensus safety, and the correctness of cryptographic implementations. This is the layer most directly tied to ledger integrity and asset security.
When auditing consensus, start by checking the following:
- Whether finality rules are clear and whether confirmation thresholds match the business risk of rollback.
- Whether validators or miners face sufficient cost for malicious behavior and whether penalty or slashing mechanisms exist.
- Whether randomness, leader election, and block-ordering logic can be manipulated.
- Whether censorship, liveness denial, and double-production behavior can be detected, attributed, and recovered from.
- Whether stake concentration, hash-power concentration, or coin-age amplification weakens safety boundaries.
- Whether validators, sequencers, or block builders can extract value through transaction ordering.
- Severity: High
- Description:
A Long Range Attack occurs when the adversary goes back to the genesis block and forks the blockchain. The new branch is populated with partially or completely different history. The attack succeeds when the adversarial branch becomes longer than the main chain and overtakes it. In PoS systems, this is related to secret block production and historical rewriting. - Recommendation:
Exchanges or recipients should finalize payment only after sufficient confirmations. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
Also referred to as a short-range attack, it relies on bribing validators or miners to work on particular blocks or forks. By doing so, the attacker can present arbitrary transactions as valid and incentivize dishonest nodes to verify them. In PoS systems, this may also connect to the nothing-at-stake problem. - Recommendation:
Enforce slashing conditions or remove violators from their privileged role. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
A race attack occurs when an attacker creates two conflicting transactions. The victim accepts one transaction before confirmation, while the attacker broadcasts a conflicting transaction returning the funds to themselves, eventually invalidating the victim-facing transaction. - Recommendation:
Exchanges or recipients should finalize payment only after sufficient confirmations. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Liveness Denial is a DoS-style attack in PoS protocols. Some or all validators intentionally stop publishing blocks, causing the blockchain to halt because new blocks cannot be validated and published. - Recommendation:
Where liveness cannot be reliably assessed, the community may need off-chain coordination to remove inactive validators. Validators performing this attack should face slashing or equivalent penalties. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
Validators or block producers control which transactions enter blocks, allowing them to blacklist or deprioritize certain addresses or actions. As more validators participate in censorship, the practical danger increases significantly. - Recommendation:
Enforce liveness guarantees, punish out-of-protocol block production, and consider privacy-preserving approaches such as zk-SNARKs where appropriate. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
A Finney Attack occurs when one transaction is pre-mined into a block and a second conflicting transaction is created before the pre-mined block is released, invalidating the later transaction. - Recommendation:
Exchanges or recipients should finalize payment only after sufficient confirmations. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Vector76 combines a Race Attack and a Finney Attack. The attacker selectively shows a pre-mined block containing a high-value transaction to an exchange-facing node while the broader network does not accept that transaction on the main chain. - Recommendation:
Exchanges or recipients should finalize payment only after sufficient confirmations. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Also known as a blockchain reorganization attack. Even after multiple confirmations, an attacker with very large computational power may mine a longer alternative chain and invalidate previously accepted transactions. - Recommendation:
Exchanges or recipients should finalize payment only after sufficient confirmations. - Reference:
blockchain-attack-vectors
- Severity: High
- Description:
Also known as a majority attack. In PoW systems, an entity controlling majority hash power can fork the chain and overtake the main branch. In PoS systems, coordinated validators with sufficient stake may challenge finality and trigger rollback, censorship, or liveness failures. - Recommendation:
Exchanges or recipients should finalize payment only after sufficient confirmations. - Reference:
A Survey on Long Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
Also known as a precomputation attack. This is an implementation-specific problem in PoS systems where insufficient randomness in leader selection allows validators to manipulate the probability of future selection. - Recommendation:
Enforce stronger randomness and minimize validator-controlled influence factors in leader election. - Reference:
A Survey on Long-Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
In early Peercoin versions, stake weight increased indefinitely with time. Given enough time, an attacker could accumulate enough effective stake to take over the network. Coin age acted as an amplification mechanism for validator weight. - Recommendation:
Cap coin-age weight or remove coin-age amplification entirely. - Reference:
A Survey on Long-Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
In selfish mining, also known as block withholding, the attacker mines blocks on a private fork without publishing them immediately. Once enough blocks are accumulated, they are released to override the public chain, wasting honest participants' work and increasing attacker rewards. - Recommendation:
For incentive abuse, use slashing or remove violators from privileged positions where applicable. - Reference:
A Survey on Long-Range Attacks for Proof of Stake Protocols
- Severity: High
- Description:
A block producer creates multiple blocks at the same height, which may be a precursor to long-range or short-range consensus attacks. - Recommendation:
Apply economic penalties to block producers that violate the protocol.
- Severity: High
- Description:
In systems with public mempools or centralized sequencing, validators, block builders, sequencers, or infrastructure providers may extract value by front-running, sandwiching, delaying, or reordering transactions. This can affect execution outcomes and amplify liquidation, price-manipulation, and arbitrage risk. - Recommendation:
a. Evaluate whether transaction ordering directly affects price, liquidation, or asset ownership.
b. Introduce anti-sandwich, anti-front-running, or batch-matching mechanisms where appropriate.
c. Review the trust boundaries around sequencers, block builders, and private order flow channels. - Reference:
Flash Boys 2.0
This section covers private-key randomness, ECDSA, EdDSA, Schnorr, BLS, RSA, hash security, AES, and other cryptographic protocol risks. Because the topic is extensive, the detailed content has been moved to the following document:
Common Cryptographic Risks in Blockchain Applications
When auditing transactions, start by checking the following:
- Whether transaction uniqueness, anti-replay mechanisms, and nonce or UTXO state checks are sound.
- Whether confirmation strategy matches the finality model of the target chain.
- Whether signature encoding, event logs, input fields, and state transitions are fully validated.
- Whether time-locks, partial payments, or specially structured transactions could lead to accounting errors.
- Whether administrative privileges, liquidity control, or upgrade authority could enable a rug pull.
- Whether the protocol relies on a single price source, single-block price, or flash-loan-manipulable on-chain state.
- Severity: High
- Description:
Also known as a double-spend attack. The attacker attempts to spend the same asset multiple times by presenting conflicting transactions, often across different branches or timing windows. - Recommendation:
a. Check whether a UTXO has already been spent.
b. Use nonce-based replay protection where applicable.
-
Severity: High
-
Description:
Transaction malleability allows an attacker to modify a Bitcoin transaction identifier before confirmation. This can make external systems believe that the original transaction did not occur, potentially causing double deposits or double withdrawals.Signature Malleability The first form of malleability exists in the signature itself. Each signature should have a unique DER-encoded ASN.1 representation, but OpenSSL historically did not strictly enforce this. In addition, for each ECDSA signature
$(r, s)$ , the signature$(r, -s \bmod N)$ is also valid for the same message.ScriptSig Malleability In Bitcoin, the signing algorithm does not sign the entire ScriptSig. While signing the entire ScriptSig would be impossible because the signature would sign itself, this still allows additional data to be inserted before the required signatures and public keys. Similarly, OP_DROP can be inserted so that the stack state remains effectively unchanged before scriptPubKey execution.
-
Recommendation:
Check whether the signature library or transaction parsing logic remains malleable. -
Reference:
Transaction_Malleability
bip-0066-Strict DER signatures
eip-2-Homestead Hard-fork Changes
- Severity: Low
- Description:
Makes tokens temporarily unavailable to recipients by specifying the block height or condition at which the UTXO becomes spendable. - Recommendation:
Check whether a transaction is time-locked before treating the asset as available. - Reference:
XMR transfer lock
- Severity: High
- Description:
Uses specially structured transactions to create the appearance of a successful transfer, causing an exchange or accounting system to record a real top-up incorrectly. - Recommendation:
a. Validate all relevant fields in the transaction event log.
b. Finalize deposits only after sufficient confirmations. - Reference:
USDT false top-up
EOS false top-up
XRP false top-up
ETH false top-up
BTC RBF false top-up
Understanding how fake top-up attacks break through exchanges' layers of defense
Solana false top-up
THORChain false top-up- UTXO multisig false top-up
- Severity: High
- Description:
A rug pull is a malicious maneuver in which project operators abandon a project and drain user funds. It is especially common in DeFi environments, where malicious actors create and list a token, pair it with a major asset such as ETH, and then exploit privileged control or liquidity access. - Recommendation:
Check whether the development team still controls critical contract permissions, liquidity controls, or other governance privileges that can be abused.
- Severity: High
- Description:
If a protocol depends on a single trading pair, a short observation window, a low-liquidity market, or state that can be manipulated with flash loans, an attacker may distort the price source and trigger incorrect liquidation, lending, minting, or asset exchange behavior. - Recommendation:
a. Use multiple data sources, TWAP-style pricing, or more robust aggregation mechanisms.
b. Review price update frequency, tolerance ranges, and extreme-market protections.
c. Stress-test liquidation, minting, and lending logic that depends on price inputs. - Reference:
SoK: Decentralized Finance (DeFi)
The following topics do not fall cleanly into the traditional network or ledger layers, but in real audit engagements they are often directly related to core system risk and should be included in scope.
When auditing cross-chain bridges, start by checking the following:
- Whether cross-chain message proofs, aggregated signatures, or light-client validation can be forged.
- Whether multisig groups, committees, or relayers introduce single points of failure or concentrated trust.
- Whether deposit, mint, unlock, and rollback flows can enter inconsistent states across chains.
- Severity: Critical
- Description:
When a bridge has flaws in source-chain event verification, block proof validation, aggregated signature checking, or light-client logic, an attacker may forge a cross-chain message and thereby mint assets, release locked funds, or execute unauthorized calls on the destination chain. - Recommendation:
a. Strictly audit message proofs, signature thresholds, and validation logic.
b. Add pause controls, transfer limits, and anomaly monitoring around critical bridge paths.
c. Verify that finality assumptions and confirmation strategies are consistent across all connected chains. - Reference:
Nomad Bridge Incident Analysis
When auditing node operations, start by checking the following:
- Whether validator, sequencer, bridge-relayer, or admin keys are isolated and securely stored.
- Whether hot wallets, node-signing keys, and cloud credentials are reused or exposed together.
- Whether deployment, upgrade, backup, and disaster-recovery flows may leak sensitive credentials.
- Severity: Critical
- Description:
If validator keys, bridge-signing keys, sequencer keys, or administrator credentials are exposed through insecure hosts, CI/CD environments, logs, or shared storage, an attacker may take over node identity, forge signatures, execute malicious governance actions, or move critical assets. - Recommendation:
a. Use HSMs, dedicated signers, or isolated signing environments to protect critical keys.
b. Review logs, images, environment variables, and deployment scripts for secret leakage.
c. Establish rotation, revocation, dual approval, and disaster-recovery workflows for high-privilege keys.
When auditing the supply chain, start by checking the following:
- Whether client dependencies, build toolchains, image sources, and plugins are trustworthy.
- Whether known-vulnerable versions or abandoned components are in use.
- Whether build outputs are reproducible and whether the release pipeline can be replaced or polluted.
- Severity: High
- Description:
If a node client, build script, SDK, cryptographic library, or operations component is poisoned, malicious, or affected by known vulnerabilities, an attacker may inject logic, steal keys, bypass validation, or achieve remote execution. - Recommendation:
a. Review the origin, version, maintenance status, and security advisories of critical dependencies.
b. Enable integrity verification, artifact signing, and reproducible build strategies.
c. Establish upgrade and alerting mechanisms for high-risk dependencies such as crypto libraries, serialization libraries, and RPC frameworks. - Reference:
Software Supply Chain Attacks