Smart Contract Vulnerabilities Flashcards
7 cards from real CBSE practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.
Read the first 7 Smart Contract Vulnerabilities flashcards as text
Which vulnerability allows an attacker to repeatedly call a withdrawal function before the balance is updated, draining contract funds?
Answer: Reentrancy
Reentrancy allows an attacker to re-enter a function before the first execution completes, exploiting the fact that the state update happens after the external call.
In Solidity, which pattern best mitigates reentrancy attacks by updating state before making external calls?
Answer: Checks-Effects-Interactions pattern
The Checks-Effects-Interactions pattern mandates updating all state variables before interacting with external contracts, preventing reentrancy.
A smart contract stores the block timestamp as a source of randomness for a lottery. What vulnerability does this introduce?
Answer: Miner manipulation of block.timestamp
Miners can adjust block.timestamp within a ~15-second window, allowing them to influence outcomes that depend on it as a randomness source.
What is a 'tx.origin' attack in Ethereum smart contracts?
Answer: Using tx.origin instead of msg.sender for authorization, which can be exploited via phishing contracts
tx.origin returns the original external account that initiated the call chain, so a malicious intermediate contract can trick a victim into authorizing an action unintentionally.
Which EVM feature limits the depth of nested calls, and what vulnerability arises when this limit is hit unexpectedly?
Answer: Call stack depth limit (1024) — causes unexpected call failures
The EVM enforces a maximum call stack depth of 1,024; an attacker can pre-fill the stack so a subsequent call in the victim contract fails silently if unchecked.
A contract uses 'delegatecall' to load logic from a library. The library's storage layout differs from the calling contract's layout. What is the risk?
Answer: Storage collision, leading to unintended state overwrites
delegatecall executes the library code in the caller's storage context, so mismatched slot layouts cause the library to overwrite critical state variables.
Which vulnerability occurs when a Solidity contract performs arithmetic that silently wraps around due to type constraints in versions below 0.8.0?
Answer: Overflow/underflow
Prior to Solidity 0.8.0, integer arithmetic did not automatically revert on overflow or underflow; values would silently wrap, enabling exploits like minting unlimited tokens.