Why Ethereum Transactions Get Hijacked: The 300‑Second Unlock Vulnerability

Stolen Ether Scenarios

A user reported multiple incidents where ether was transferred from a server‑hosted account (A address) to unknown addresses (H or K) after failed transactions, despite the account appearing normal when checked locally. The pattern repeated after changing passwords, updating the client, and even after reformatting the server.

Problem Reconstruction and Answer

The root cause lies in the Ethereum node’s unlock mechanism. The node was publicly accessible without IP restrictions, and the default unlock duration is 300 seconds when no explicit timeout is provided.

Code Analysis

func (s *PrivateAccountAPI) UnlockAccount(addr common.Address, password string, duration *uint64) (bool, error) {
    const max = uint64(time.Duration(math.MaxInt64) / time.Second)
    var d time.Duration
    if duration == nil {
        d = 300 * time.Second
    } else if *duration > max {
        return false, errors.New("unlock duration too large")
    } else {
        d = time.Duration(*duration) * time.Second
    }
    err := fetchKeystore(s.am).TimedUnlock(accounts.Account{Address: addr}, password, d)
    return err == nil, err
}

If the unlock duration parameter is omitted, the system defaults to unlocking the account for 300 seconds. During this window, anyone who can reach the node can invoke a transfer on the unlocked account.

Root Cause and Mitigation

The 300‑second default unlock window creates a critical security gap on unsecured nodes. An attacker monitoring the network can detect when an account is unlocked and immediately issue a transaction that drains the balance. The simplest protection is to restrict network access to the node (e.g., firewall rules, VPN, IP whitelisting). More advanced safeguards—such as hardware wallets, multi‑signature accounts, or custom unlock timeouts—are discussed in future articles.

Conclusion

This common theft scenario highlights the importance of securing Ethereum node access and configuring appropriate unlock durations. New developers should verify node exposure and consider tighter security controls to prevent similar losses.