Visor Finance (vVISR) Exploit — Free Share Minting via Attacker-Controlled `delegatedTransferERC20`

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: 2021-12-Visor_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/Visor_exp.sol.

Vulnerability classes: vuln/dependency/unchecked-return-value · vuln/logic/missing-validation

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. Full verbose trace: output.txt. Verified vulnerable source: RewardsHypervisor.sol.

Key info#

TL;DR#

RewardsHypervisor.deposit(visrDeposit, from, to) mints vVISR shares to to proportional to a claimed visrDeposit, but never verifies that the VISR was actually received. When from is a contract, the hypervisor:

1. trusts IVisor(from).owner() (an attacker-controlled return value) to gate access, and
2. delegates the token pull to IVisor(from).delegatedTransferERC20(...) — a function the attacker implements as an empty no-op.

So the attacker passes their own contract as from, that contract returns owner() == msg.sender (whitelist passes) and does nothing on delegatedTransferERC20 (no VISR moves). The hypervisor then runs vvisr.mint(to, shares) unconditionally (RewardsHypervisor.sol:64), minting shares for free.

In the PoC, a single deposit(100,000,000 VISR, attackerContract, attackerEOA) mints 97,624,975 vVISR while transferring 0 VISR. Those shares are ≈ 91.5% of the post-mint supply — instantly redeemable via withdraw() for the hypervisor's full 9.22M VISR. On-chain the attacker repeated the deposit→withdraw cycle to extract ≈ 8.8M VISR (~$8.2M).

Background — what RewardsHypervisor / vVISR do#

Visor Finance's staking layer let VISR holders deposit VISR into the RewardsHypervisor and receive vVISR — a fractional, snapshot-enabled share token (vVISR.sol). vVISR is a standard ERC20 whose mint/burn are onlyOwner, and the owner is the RewardsHypervisor (vVISR.sol:25-31). So the only way to create vVISR is through RewardsHypervisor.deposit().

The deposit path was designed to support Visor vaults (smart-contract wallets that hold a user's VISR). Instead of a plain transferFrom, the hypervisor would ask the vault to push its own tokens via a delegated transfer hook. To express that, it imports a minimal interface:

// sources/RewardsHypervisor_C9f27A/contracts_interfaces_IVisor.sol
interface IVisor {
    function owner() external returns(address);
    function delegatedTransferERC20(address token, address to, uint256 amount) external;
}

On-chain parameters at the fork block (read from the trace's staticcalls):

The whole exploit hinges on the deposit path trusting two values it does not control: the from contract's owner(), and whether delegatedTransferERC20 actually moved any VISR.

The vulnerable code#

deposit() — mints shares without proving receipt#

// sources/RewardsHypervisor_C9f27A/contracts_RewardsHypervisor.sol:41-65
function deposit(
    uint256 visrDeposit,
    address payable from,
    address to
) external returns (uint256 shares) {
    require(visrDeposit > 0, "deposits must be nonzero");
    require(to != address(0) && to != address(this), "to");
    require(from != address(0) && from != address(this), "from");

    shares = visrDeposit;
    if (vvisr.totalSupply() != 0) {
      uint256 visrBalance = visr.balanceOf(address(this));
      shares = shares.mul(vvisr.totalSupply()).div(visrBalance);   // shares from CLAIMED amount
    }

    if(isContract(from)) {
      require(IVisor(from).owner() == msg.sender);                 // ⚠️ attacker-controlled return
      IVisor(from).delegatedTransferERC20(address(visr), address(this), visrDeposit); // ⚠️ no-op for attacker
    }
    else {
      visr.safeTransferFrom(from, address(this), visrDeposit);
    }

    vvisr.mint(to, shares);   // ⚠️ unconditional mint, never checks VISR actually arrived
}

Two independent flaws compose here:

1. require(IVisor(from).owner() == msg.sender) is meant to ensure the caller owns the vault they're spending from. But from is fully attacker-chosen, and its owner() is whatever the attacker's contract returns. The attacker makes it return msg.sender, so the check is vacuous.

2. IVisor(from).delegatedTransferERC20(...) is the only mechanism that moves VISR on the contract path — and it is a call into attacker code. The attacker's implementation does nothing. The hypervisor never re-reads its own VISR balance to confirm visrDeposit actually arrived before minting.

The mint is owner-gated but reachable through the bug#

// sources/vVISR_3a84aD/contracts_vVISR.sol:25-27
function mint(address account, uint256 amount) onlyOwner external {
  _mint(account, amount);
}

onlyOwner looks like protection, but the owner is RewardsHypervisor, and the bug lets anyone drive the hypervisor into calling mint. The access control guards the wrong boundary.

The attacker's from contract (the PoC harness itself)#

// test/Visor_exp.sol:23-27
function owner() external returns (address) {
    return (address(this));          // returns the caller (msg.sender of deposit) → whitelist passes
}
function delegatedTransferERC20(address token, address to, uint256 amount) external {} // ← empty: no VISR moves

Root cause#

The protocol delegates the act of receiving funds to an untrusted, caller-supplied contract, then mints shares as if the funds were received — without ever checking its own balance.

A safe vault-deposit pattern must either:

• pull tokens with transferFrom from an address the protocol can hold accountable (and only credit what was actually pulled), or
• if it must call into an external "vault" to push tokens, measure the balance delta (balanceAfter - balanceBefore) and mint shares against that delta — never against a self-reported visrDeposit.

RewardsHypervisor.deposit does neither. It computes shares from the claimed amount, calls a no-op transfer hook on attacker code, and mints. The owner() check provides a false sense of security because both the identity it checks and the transfer it triggers live in the attacker's contract.

This is the canonical "trusting external call to move funds" bug: access control (onlyOwner on mint, owner() whitelist on from) is present but defends a boundary the attacker fully controls on both sides.

Preconditions#

• The hypervisor holds VISR (visr.balanceOf > 0) and vVISR supply is nonzero — true at the fork block (9.22M VISR / 9.00M vVISR).
• from is a contract whose owner() returns msg.sender and whose delegatedTransferERC20 does not revert. The attacker simply deploys such a contract (the PoC's test contract is that contract).
• No capital required: zero VISR is spent. The "deposit" amount is a pure lie.

Step-by-step attack walkthrough#

The PoC (test/Visor_exp.sol) calls deposit once, with the test contract playing the role of the attacker's vault (from) and msg.sender as the share recipient (to). All numbers below are taken directly from output.txt (the testExploit() trace, lines 1572-1597).

The minted shares (97.62M) exceed the pre-existing supply (9.00M), so the attacker ends up holding ≈ 91.5% of all vVISR (97.62M / (9.00M + 97.62M) = 0.9156). Calling withdraw() would then redeem that fraction of the hypervisor's VISR — i.e., essentially its entire 9.22M VISR balance — in exchange for shares that cost nothing to create.

PoC scope note: the test asserts only the free mint (the trace ends after mint, logging Attacker VIST Balance: 97624975481815716136709737). It does not execute the withdraw() redemption. In the live incident the attacker ran the deposit→withdraw cycle repeatedly to drain ≈ 8.8M VISR; the PoC proves the load-bearing primitive that makes that drain possible.

Profit / loss accounting#

The shares are worth 100M VISR at the recorded price (97.62M × 1.0243 ≈ 100M), but the redeemable cap is the hypervisor's actual 9.22M VISR balance — which is exactly the prize.

Diagrams#

Sequence of the attack#

Control flow inside deposit()#

Why it is theft: claimed vs. received#

Remediation#

1. Mint against the measured balance delta, never the claimed amount. Snapshot visr.balanceOf(address(this)) before the transfer, perform the transfer, then compute received = balanceAfter - balanceBefore and base both shares and the mint on received. If received == 0, revert. This single change neutralizes the exploit regardless of what the from contract does.
2. Do not delegate fund movement to caller-supplied contracts. Use visr.safeTransferFrom(from, address(this), amount) uniformly. If a vault-push model is truly required, the vault contract must be a protocol-deployed, whitelisted address — not an arbitrary from chosen at call time.
3. Don't use a caller-controlled owner() as access control. The require(IVisor(from).owner() == msg.sender) check trusts attacker-returned data. Authorization must be derived from state the protocol controls (e.g. a registry of legitimate Visor vaults), not from a value the counterparty reports about itself.
4. Follow checks-effects-interactions and verify post-conditions. Any function that mints liability (shares) in exchange for an asset must confirm the asset is held before the liability is created.

How to reproduce#

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

_shared/run_poc.sh 2021-12-Visor_exp -vvvvv

• RPC: an Ethereum archive endpoint is required (createSelectFork("mainnet", 13_849_006)).
• Result: [PASS] testExploit() — the attacker EOA receives 97,624,975.48 vVISR while depositing 0 VISR.

Expected tail:

Ran 1 test for test/Visor_exp.sol:ContractTest
[PASS] testExploit() (gas: 137151)
Logs:
  Attacker VIST Balance: 97624975481815716136709737

Suite result: ok. 1 passed; 0 failed; 0 skipped

Reference: Visor Finance / VISR exploit, Ethereum mainnet, December 21, 2021, ~$8.2M. SlowMist Hacked — https://hacked.slowmist.io/ ; PeckShield / Rekt post-mortems.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2021-12-Visor_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Visor_exp.sol.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "Visor Finance (vVISR) 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.