Track 7 · The Breach Lab · lesson 4

tx.origin phishing

15 min

Track 2 said tx.origin is almost always the wrong choice. Here is the attack that makes it true.

The wallet below authorises transfers by checking tx.origin == owner. The owner has just been tricked — by a fake airdrop, a "claim your NFT" button, anything — into calling attack() on your contract.

That is all you need.

Attacker.solAttacker

Loading editor…

The owner just called your contract. Drain their wallet.

PhishableWallet

? ETH

Nudge

Inside attack(), who is tx.origin? The owner, because they started this transaction by calling you.

Show me the approach

The wallet checks `tx.origin == owner`. When the owner calls you and you call the wallet, that check still passes.

Show me the code

Call `wallet.transferTo(address(this), address(wallet).balance)`.

Explain the exploit

This is why `tx.origin` must never be used for authorisation. `msg.sender` inside the wallet would be your contract, not the owner, and the attack would fail. The fix is one word: `msg.sender`.

Why this works

tx.origin is the account that started the transaction. msg.sender is the immediate caller. When the owner calls your contract, and your contract calls the wallet:

inside the wallet, msg.sender is your contract
inside the wallet, tx.origin is still the owner

The wallet asked the wrong question. It wanted to know "did the owner authorise this action?" and instead asked "did the owner start this transaction?" — which is true even when the owner has no idea what the transaction does.

msg.sender cannot be borrowed this way. Had the wallet checked msg.sender == owner, it would have seen your contract, not the owner, and reverted. The fix is a single word.

The social half

The technical flaw is one line, but the attack needs the owner to call your contract. That is the phishing part: a convincing reason to click.

This is why "just don't click suspicious links" is weak advice. The link only has to reach one function call, and a tx.origin wallet does the rest. The real defence is contracts that cannot be abused even when the owner is fooled.

Predict

Would this attack work if the wallet used `msg.sender == owner` instead?

No — msg.sender would be the attacker's contract, not the ownerYes — the owner still started the transactionOnly if the attacker also had an approval

The one place tx.origin is legitimately usefulOptional

There is a narrow, defensible use: require(tx.origin == msg.sender) to check that the caller is an externally owned account and not a contract.

It is used to block flash-loan-powered attacks that must run inside a single transaction. It is also increasingly discouraged, because it breaks smart-contract wallets — which are exactly the accounts you often want to support. Account abstraction is making it obsolete.

So: tx.origin for authorisation, never. tx.origin for EOA detection, rarely and with awareness of the cost.

Check

What is the correct authorisation check for the wallet?

require(msg.sender == owner)require(tx.origin == owner)require(tx.origin == msg.sender)

Worth remembering

`tx.origin` is the transaction's originator; `msg.sender` is the immediate caller.
A wallet checking tx.origin authorises anyone the owner can be tricked into calling.
The fix is `msg.sender == owner` — one word, and the intermediary is no longer trusted.
The attack needs a phishing click, so robust contracts must survive a fooled owner.
`tx.origin` has one narrow use (EOA detection) that is itself increasingly discouraged.