CBSE Smart Contract Vulnerabilities 3 — Questions and Answers
Question 1: What is a 'front-running' attack in the context of decentralized exchanges (DEXs)?
- Deploying a contract before the target contract is deployed
- Submitting a higher-gas transaction to execute before a pending victim transaction and profit from the price change (Correct answer)
- Stealing private keys from mempool data
- Exploiting a reentrancy bug before the developer can patch it
Correct answer: Submitting a higher-gas transaction to execute before a pending victim transaction and profit from the price change
Front-running (a form of MEV) involves observing a pending transaction in the mempool and submitting a competing transaction with higher gas to be mined first.
Question 2: A contract's 'selfdestruct' function is callable by any address. Which vulnerability category does this represent?
- Reentrancy
- Logic error / missing access control (Correct answer)
- Integer overflow
- Gas limit DoS
Correct answer: Logic error / missing access control
Allowing any address to call selfdestruct is a missing access control vulnerability; a proper guard (e.g., onlyOwner) should restrict this destructive function.
Question 3: Which attack exploits the fact that an ERC-20 'approve' operation can be front-run to spend both the old and new allowance?
- Double-spend attack
- Allowance race condition (approve/transferFrom race) (Correct answer)
- Overflow attack
- Griefing attack
Correct answer: Allowance race condition (approve/transferFrom race)
If an owner calls approve to change an existing non-zero allowance, a spender can front-run and spend the old allowance, then spend the new allowance too, extracting double the intended amount.
Question 4: What is a 'griefing attack' in smart contract security?
- Stealing funds from the contract treasury
- Making a contract unusable or forcing it into a bad state without direct financial gain (Correct answer)
- Forging a cryptographic signature to pass authentication
- Deploying a contract that mimics a legitimate one to phish users
Correct answer: Making a contract unusable or forcing it into a bad state without direct financial gain
A griefing attack aims to harm or permanently disrupt a contract's functionality (e.g., blocking withdrawals) rather than extracting funds.
Question 5: An attacker sends ETH directly to a contract address using 'selfdestruct' before the contract is deployed (via CREATE2). What impact can this have?
- The contract deployment will fail permanently
- The pre-loaded ETH may break invariants that assume the contract starts with zero balance (Correct answer)
- The attacker gains ownership of the contract
- The Ethereum network forks automatically
Correct answer: The pre-loaded ETH may break invariants that assume the contract starts with zero balance
Because a CREATE2 address is deterministic, an attacker can seed ETH to that address beforehand; contracts that assume they start with zero balance (e.g., checking address(this).balance == 0) will behave incorrectly.
Question 6: Which Solidity visibility specifier should be avoided on sensitive functions to prevent unauthorized external access?
- private
- internal
- public (without an access modifier check) (Correct answer)
- view
Correct answer: public (without an access modifier check)
Marking a sensitive function public without a role-based guard exposes it to all external callers, enabling unauthorized state changes or fund extraction.
Question 7: What does 'signature replay' mean in smart contract security?
- Reusing a valid cryptographic signature from a past transaction to authorize a new, unintended one (Correct answer)
- Resending the same Ethereum transaction multiple times to drain gas
- Copying source code from a verified contract to disguise malicious logic
- Replaying past oracle price data to manipulate on-chain state
Correct answer: Reusing a valid cryptographic signature from a past transaction to authorize a new, unintended one
A replay attack re-submits a legitimately signed message on the same or a different chain/contract where no nonce or chainId prevents its reuse.
What is a 'front-running' attack in the context of decentralized exchanges (DEXs)?