Flawed Slashing Conditions
id: LS24H
title: Flawed Slashing Conditions
baseSeverity: H
category: consensus-mechanism
language: solidity
blockchain: [ethereum]
impact: Honest participants may be punished or malicious actors may evade slashing
status: draft
complexity: high
attack_vector: internal
mitigation_difficulty: hard
versions: [">=0.6.0", "<latest"]
cwe: CWE-697
swc: SWC-132
π Description
- Flawed slashing conditions arise when the logic responsible for penalizing validators, stakers, or participants:
- Incorrectly identifies misbehavior,Fails to detect actual violations, Can be abused to penalize honest actors or evaded by malicious ones.
- This typically affects staking protocols, validator networks, or oracles, and can result in:
- Unfair slashing of good actors (loss of funds, reputation),No punishment for actual malicious behavior (downtime, equivocation, delay),Governance disputes and loss of network trust.
π¨ Vulnerable Code
function slash(address validator, bool evidence) external onlySlasher {
if (evidence) {
stake[validator] = 0; // β No validation of evidence, no protection
emit Slashed(validator);
}
}
π§ͺ Exploit Scenario
Step-by-step breakdown:
- A malicious actor gains access to the slasher role (e.g. governance, multisig).
- They pass a true flag as evidence, regardless of validator behavior.
- The validatorβs stake is immediately zeroed out, despite being honest.
- Meanwhile, another malicious validator avoids slashing due to missing checks or poor liveness detection.
Assumptions:
- Validators avoid slashing by exiting before finalization.
- Network latency causes false downtime slashing.
- Lack of cryptographic proof in misbehavior evidence.
β Fixed Code
function slash(address validator, bytes calldata evidence) external onlySlasher {
require(validateEvidence(evidence, validator), "Invalid or insufficient proof");
require(block.timestamp < evidenceExpiry[evidence], "Evidence expired");
uint256 penalty = (stake[validator] * penaltyRate) / 100;
stake[validator] -= penalty;
emit Slashed(validator, penalty);
}
function validateEvidence(bytes calldata data, address validator) internal view returns (bool) {
// e.g. double-signature, equivocation proof, signed block hash
// β
Use verifiable cryptographic checks
return isValidProof(data, validator);
}
π§ Contextual Severity
- context: "Anyone can slash using loosely defined uptime logic"
severity: H
reasoning: "Leads to griefing and full stake loss"
- context: "Slashing requires governance or multisig approval"
severity: M
reasoning: "Impact contained by oversight"
- context: "Slashing disabled or only used for reputation"
severity: L
reasoning: "No asset loss, minimal impact"
π‘οΈ Prevention
Primary Defenses
- Require cryptographic proof of misbehavior (e.g., BLS signatures, PoS equivocation).
- Enforce time bounds, cooldowns, and challenge periods before slashing.
- Ensure only authorized, auditable sources (e.g. consensus or quorum) can initiate slashing.
Additional Safeguards
- Emit detailed Slashed logs with reason, evidence hash, and proof for on-chain audits.
- Allow appeal or dispute mechanisms for challenged slashing events.
- Use off-chain consensus proofs (e.g., attestation reports or ZK-based evidence) for accuracy.
Detection Methods
- Slither: unconditional-slash, missing-evidence-check, slasher-role-danger detectors.
- Manual audit of all slashing conditions and roles.
- Simulation of false positive slashing attacks in fuzz tests.
π°οΈ Historical Exploits
- Name: Beaconcha.in Slashing Misreporting Incident
- Date: April 2023
- Loss: Potential misinterpretation of validator behavior; no direct financial loss
- Post-mortem: Link to post-mortem
π Further Reading
- SWC-132: Incorrect Event Conditions
- CWE-697: Incorrect Comparison
- Ethereum PoS Slashing Conditions
- Tendermint Slashing Logic
β Vulnerability Report
id: LS24H
title: Flawed Slashing Conditions
severity: H
score:
impact: 5
exploitability: 3
reachability: 3
complexity: 4
detectability: 4
finalScore: 4.15
π Justifications & Analysis
- Impact: Critical β could unjustly destroy validator capital or let malicious actors go free.
- Exploitability: Moderate β needs privileged access or flawed logic.
- Reachability: Common in custom staking, L2, or oracle systems.
- Complexity: High β safe slashing systems require protocol-grade engineering.
- Detectability: High β flaws are exposed in audits and validator testing.