Why You Should Never Use tx.origin for Authorization

Updated 2026-06-18 · VRF7 Security Guides

Of all the subtle pitfalls in Solidity, misusing tx.origin for authorization stands out because it looks reasonable at first glance. The value always contains the address of the original externally owned account (EOA) that signed the transaction, so it seems like a trustworthy identity check. In practice, it creates a phishing vector that lets an attacker drain funds or trigger privileged actions without the victim ever realizing they have been exploited. This guide explains exactly why, walks through a concrete attack, and shows you the correct authorization pattern.

tx.origin vs msg.sender: The Core Difference

tx.origin and msg.sender are both global variables in Solidity, but they refer to different things depending on the call stack.

• tx.origin is always the EOA that originally signed and submitted the transaction. It never changes as the call travels through multiple contracts.
• msg.sender is the immediate caller of the current function. When contract A calls contract B, inside B the value of msg.sender is A's address, not the original EOA.

Consider this call chain: EOA → Contract A → Contract B. Inside Contract B:

• tx.origin equals the EOA's address.
• msg.sender equals Contract A's address.

This distinction is the root of the vulnerability. When you guard a function with require(tx.origin == owner), you are asserting that somewhere in the call chain there is a specific EOA, not that the direct caller is trusted. Any contract in that chain can satisfy the check as long as it tricks the right EOA into making a transaction.

The Phishing Attack, Step by Step

Imagine a simple wallet contract with a transfer function guarded by tx.origin:

// VULNERABLE: do not use this pattern
contract TxOriginWallet {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function transfer(address payable recipient, uint256 amount) external {
        // BUG: uses tx.origin instead of msg.sender
        require(tx.origin == owner, "Not owner");
        recipient.transfer(amount);
    }

    receive() external payable {}
}

Now consider an attacker who deploys the following malicious contract and tricks the wallet owner into calling it. The lure could be anything: a fake airdrop, a token approval for a DeFi protocol, a game transaction. The social-engineering angle is the same as any phishing attack.

// ATTACKER CONTRACT
contract PhishingContract {
    TxOriginWallet private target;
    address payable private attacker;

    constructor(TxOriginWallet _target, address payable _attacker) {
        target = _target;
        attacker = _attacker;
    }

    // Victim calls this function, thinking it is harmless
    function claimAirdrop() external {
        // At this point:
        // tx.origin == victim (the wallet owner)
        // msg.sender == this contract
        // The wallet's require(tx.origin == owner) passes!
        uint256 balance = address(target).balance;
        target.transfer(attacker, balance);
    }
}

When the wallet owner calls claimAirdrop(), the EVM executes the following call chain:

1. EOA (owner) calls PhishingContract.claimAirdrop().
2. PhishingContract calls TxOriginWallet.transfer(attacker, balance).
3. Inside TxOriginWallet.transfer, tx.origin is still the owner's EOA address. The require passes.
4. The entire wallet balance is sent to the attacker.

The victim signed exactly one legitimate transaction. They never approved a transfer. The authorization check passed correctly according to its own flawed logic, and there is no on-chain evidence of deception beyond the call trace.

The Correct Authorization Pattern

The fix is straightforward: replace tx.origin with msg.sender for all authorization checks. The direct caller is the party you have a contractual relationship with, not whoever originally initiated the transaction.

// SAFE: use msg.sender for authorization
contract SafeWallet {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function transfer(address payable recipient, uint256 amount) external {
        require(msg.sender == owner, "Not owner");
        recipient.transfer(amount);
    }

    receive() external payable {}
}

Now the same phishing attack fails. When PhishingContract calls SafeWallet.transfer, msg.sender inside the wallet is PhishingContract's address, not the owner's address. The require reverts the call immediately.

When Is tx.origin Acceptable?

There is exactly one common, legitimate use case: asserting that the caller is not a contract. The check require(tx.origin == msg.sender) reverts if the immediate caller is a contract rather than an EOA. This pattern is used in some contexts to block flash loan attacks or prevent certain composability patterns. Note, however, that this check is not a security silver bullet. Account abstraction wallets (ERC-4337) involve smart contract accounts as the transaction origin, so this guard breaks compatibility with them and is increasingly considered an antipattern in modern Solidity design.

For role-based and ownership-based authorization, always use msg.sender. For more complex scenarios, consider battle-tested libraries such as OpenZeppelin's Ownable and AccessControl, which are built entirely around msg.sender. You can read more about the broader landscape of permission bugs in our guide to Access Control Vulnerabilities in Smart Contracts.

How Automated Tools Catch tx.origin Misuse

Static analysis tools are highly effective at detecting this specific pattern because it reduces to a simple AST query: find any comparison involving tx.origin inside a conditional that guards state-changing logic.

• Slither includes a dedicated tx-origin detector that flags every use of tx.origin in a conditional and reports the exact source location.
• Solhint raises a linting warning when tx.origin appears in expressions used for access control.
• Semgrep can match the pattern with custom rules targeting require and if conditions that reference tx.origin.

Because this is a well-defined syntactic pattern, automated scanning reliably surfaces it before deployment. If you want to verify whether your codebase contains any tx.origin authorization checks alongside other common vulnerabilities, you can run an automated scan against your contracts and review each finding with a plain-language explanation of the risk.

It is worth noting that while automated scanning catches known patterns effectively, it does not replicate the judgment a human auditor applies to novel logic flaws or complex business logic. Treat automated results as a baseline that eliminates known vulnerabilities before deeper review.

Related Vulnerability: Unchecked External Calls

The phishing scenario above involves an external contract call that the victim initiates unwittingly. A related class of bugs concerns what happens when your own contract makes external calls and does not verify the result. If the called contract behaves unexpectedly or reverts silently, your contract may proceed in an inconsistent state. For a detailed treatment of that risk, see our guide on Unchecked External Calls and the Risks of call, send and transfer.

Summary

The tx.origin vulnerability is deceptive precisely because the global variable does contain a real, authenticated address. The flaw is not in the data itself but in what that data actually represents: the origin of a transaction, not the identity of a trusted caller. Any contract in the call stack can exploit an authorization check based on tx.origin as long as it can trick the right EOA into making any transaction.

• Use msg.sender for all ownership and role-based authorization.
• Reserve tx.origin == msg.sender only for EOA-only guards, and understand the account abstraction compatibility trade-off.
• Run static analysis as part of your CI pipeline to catch this and similar patterns before they reach mainnet.