TX.ORIGIN AUTHENTICATION: CALL-CHAIN CONFUSION

tx.origin is the sender at the top of the EVM call chain; msg.sender is the immediate caller of the current frame. The authentication flaw is not that an attacker can spoof tx.origin. It is that an authorized account can start a transaction which passes through an untrusted contract, while a downstream victim still sees the authorized account as the origin.

THE CONFUSED-DEPUTY PATH

Assume a wallet protects withdraw with require(tx.origin == owner). The owner interacts with an attacker-controlled contract, perhaps through an apparently unrelated action. That contract calls the wallet. Inside the wallet, msg.sender is the attacker contract but tx.origin is still the owner, so the origin check passes. The wallet has confused proof that the owner initiated the overall transaction with proof that the owner directly authorized this particular call.

Solidity's security guidance therefore says never to use tx.origin for authorization. Replacing it with msg.sender makes the immediate caller part of the authorization decision. That does not mean all contract callers should be banned: multisigs, smart accounts, routers, and relayers are contracts. They should be supported through explicit roles, validated signatures, or a deliberately designed forwarding standard.

REVIEW AND TESTING

Search every use of tx.origin, including inline assembly and inherited modifiers. Classify logging or telemetry separately from any branch that controls funds, roles, configuration, signatures, or execution. Follow internal helpers to ensure an origin-based boolean is not computed in one place and enforced elsewhere.

For each authorization path, write a test with three actors: the authorized account, an intermediate attacker contract, and the victim. Have the authorized account call the intermediate contract and make it invoke the protected function. The attempt must fail unless that intermediate caller is itself explicitly authorized. Also test intended multisig and relayer paths so the fix preserves composition.

Firepan can flag tx.origin data flow into authorization decisions in a submitted repository and commit. It cannot establish user intent from code alone or continuously monitor every deployed call chain.

MITIGATION AND LIMITS

• Authorize the immediate caller with msg.sender or a reviewed role modifier.
• For relayed authority, verify a domain-separated signature that binds the action, nonce, deadline, chain, and verifying contract as required by the protocol.
• Give routers and proxies the minimum explicit permissions they need; do not infer their authority from the transaction origin.
• Test calls through malicious and legitimate intermediaries.

require(msg.sender == tx.origin) is not a general repair. It excludes contract wallets and does not express who may perform the action. Likewise, tx.origin can remain useful for diagnostics, but using it in a security decision recreates the confused-deputy boundary.

SOURCES

• Solidity Documentation: tx.origin
• Solidity Documentation: Block and Transaction Properties