[Bug] Adapter initialize() is unauthenticated, front-runnable

[collinsezedike]

Description

BlendAdapter::initialize() (packages/contracts/blend-adapter/src/lib.rs:148-161) sets the adapter's vault, pool, and USDC addresses with no require_auth() call anywhere in the function, only a re-initialization guard (AlreadyInitialized). The same pattern exists in DefindexAdapter::initialize() (packages/contracts/defindex-adapter/src/lib.rs:67-79).

Anyone can call initialize() on a freshly deployed, uninitialized adapter and set themselves as the vault address, becoming the sole party able to invoke deposit/withdraw on it.

This is exploitable in practice because deploy and initialize happen as separate transactions. scripts/deploy-testnet.sh deploys the adapter at line 74 and only initializes it later at lines 84-86, with the mUSDC asset deploy step in between. Anyone watching the ledger in that window could front-run the real initialize call with their own vault address.

Steps to Reproduce

1. Deploy a BlendAdapter (or DefindexAdapter) contract without initializing it.
2. Before the legitimate deployer calls initialize(), call initialize() yourself with an address you control as vault.
3. Observe that the legitimate initialize() call now fails with AlreadyInitialized, and the adapter is permanently bound to the attacker's address.

Expected Behavior

initialize() should require authorization from the intended deployer/admin, and deployment should minimize any window where an uninitialized adapter sits exposed.

Actual Behavior

Any address can call initialize() on an uninitialized adapter with no authorization check, permanently claiming it. The deploy script also leaves a multi-step window between deploying the adapter and initializing it.

Environment

Field	Value
Network	testnet
Wallet	N/A
Protocol affected	Blend, DeFindex
Browser (if frontend)	N/A
Node.js version	N/A
pnpm version	N/A

Possible Cause / Fix

Two changes, both in this issue:

1. Add require_auth() on the deployer/admin address as a parameter to initialize() in both BlendAdapter and DefindexAdapter, matching the pattern MeridianVault::initialize already uses. This is the real fix: it closes the vulnerability in the contract itself, for every deployment path, not just the current script.
2. Tighten scripts/deploy-testnet.sh so each adapter is initialized immediately after its own deploy call, with no other operations (like the mUSDC asset deploy) in between. This doesn't replace the contract fix, but it shrinks the exposure window as cheap defense in depth, including for any deployment that happens before the contract fix ships.

Additional Context

Found during an independent audit of the adapter contracts, verified directly against current source (packages/contracts/blend-adapter/src/lib.rs, packages/contracts/defindex-adapter/src/lib.rs, scripts/deploy-testnet.sh) rather than taken on the audit's word alone. Same gap exists in both adapters, filing as one issue since the fix is the same shape in each.

[Chigybillionz]

Hi, I’ve reviewed this issue and I’m confident I can fix it. I’d like to take it on.

[blockchain-maxis]

Hi, I would like to work on this issue. I will add require_auth() on the deployer or admin address parameter to initialize() in both BlendAdapter and DefindexAdapter, matching the pattern already used in MeridianVault::initialize, so the contract itself rejects any unauthorized caller regardless of the deployment path or timing. I will also tighten scripts/deploy-testnet.sh to initialize each adapter immediately after its own deploy call with no intervening operations so the window between deployment and initialization is as small as possible, providing defense in depth even before the contract fix is fully propagated. I will write tests that verify an unauthorized address cannot call initialize() and that the legitimate deployer can, as well as a test that confirms the AlreadyInitialized guard still fires correctly after a legitimate initialization, and verify the fix on testnet before submitting. Can I be assigned?

[collinsezedike]

@blockchain-maxis require_auth() on a caller-supplied admin parameter only proves the caller controls whatever address they passed in, it doesn't stop someone from front-running with initialize(their_own_address) and having that require_auth() trivially pass. How does your fix actually close the front-running window, not just require a signature from whoever gets there first?

[blockchain-maxis]

@collinsezedike Good catch, you're right that require_auth() on a caller-supplied parameter alone doesn't close this. It only proves whoever calls first controls the address they pass in; it does nothing to stop them from passing their own address and satisfying that check trivially. The front-running problem is about transaction ordering, not a missing signature, so an auth check on the racer's own input can't fix it.

The actual fix needs to remove the window itself, not add a check inside it:

1. Atomic deploy+init: Soroban contracts can define a __constructor function that runs as part of the CreateContract host operation itself, in the same transaction as deployment, not as a separate call afterward. If BlendAdapter/DefindexAdapter move their init logic into a constructor, there's no gap between deploy and init at all, so there's no transaction for anyone to front-run.
2. If a constructor isn't feasible on the current toolchain version, the fallback is making deploy + initialize a single atomic transaction (one XDR envelope with both the CreateContract op and the initialize invoke op), instead of two separate script steps like deploy-testnet.sh does now. Since a transaction either applies fully or not at all, nobody can land an operation in between.

require_auth() on the admin/deployer param is still worth keeping on top of that (it stops someone re-pointing a call at a vault they don't control by forging the parameter), but on its own it doesn't touch the race. I was wrong to present it as the fix for front-running specifically. I'll revise the plan to lead with the constructor/atomic approach and treat require_auth() as a secondary check, and add tests that specifically try to front-run within the same ledger close to prove the window is gone before submitting. Want me to confirm whether the Soroban SDK version pinned in this repo supports __constructor before scoping further, or is there a different direction you'd rather I take?

[collinsezedike]

@blockchain-maxis Thank you for catching your own gap instead of defending it. The constructor-based atomic deploy+init is the right fix. Assigning this to you, confirm __constructor support on the pinned SDK version before you start.