Web3Exploit logoWeb3Exploit
← Back to Attack Patterns
Attack pattern

Private Key Compromise

Keys or signing devices are stolen or tricked into signing, so on-chain actions are fully valid yet unauthorized.

Definition

Private-key compromise covers any path where an attacker obtains signing capability or induces a legitimate signer to approve a malicious action. The chain sees valid signatures; the failure is operational — malware, supply-chain tampering of the signing UI, phishing, or poor key management.

How it works

  1. The attacker gains signing capability (stolen key) or manipulates the signing environment (tampered UI, malware).
  2. A transaction is signed that the operator did not intend — or intended based on a falsified display.
  3. The action executes with fully valid signatures; on-chain controls cannot distinguish it from a legitimate one.

Vulnerable vs. fixed

Vulnerable: single hot key controls high-value fundstext
- One EOA (single private key) authorizes large transfers
- Signing UI trusted implicitly (no independent calldata verification)
- No spending limits, timelocks, or multi-party approval
Fixed: defense-in-depth around signingtext
- Multisig / MPC with independent signers and hardware isolation
- Out-of-band calldata verification before signing
- Timelocks + spending limits on high-value operations
- Integrity checks / pinning for the signing frontend and its dependencies

Detection steps

  1. Identify the sensitive value or permission the pattern can influence.
  2. Trace every path that can update or consume that value, including callbacks, routers, and privileged helpers.
  3. Reproduce the worst-case attacker flow with adversarial ordering, manipulated inputs, and maximum feasible capital.

Common signals

  • Security depends on an assumption that is not enforced by code.
  • A critical value is consumed immediately after an attacker-controlled interaction.
  • A privileged call path crosses multiple contracts without one clear authorization boundary.

False positives

  • The risky-looking operation is read-only and cannot affect settlement or authorization.
  • The value is bounded by independent checks before it moves assets.
  • All privileged entry points share the same tested guard and monitoring path.

Review questions

  • Which invariant would fail if this input or caller were attacker-controlled?
  • Can the attacker compose setup, trigger, settlement, and cleanup atomically?
  • What independent check stops the exploit if the first guard is wrong?

Defensive checklist

  • Use multisig or MPC with hardware-isolated, independent signers.
  • Verify calldata out-of-band on a separate device before approving.
  • Add timelocks and spending limits to high-value flows.
  • Protect the signing frontend supply chain (integrity checks, dependency pinning).