# An inactive vault can disrupt rebalancing of active vaults

Inactive Derby vaults could still report underlying balances to XChainController, inflating underlyingReceived and either excluding an active vault from rebalancing or permanently blocking it.

- Payout: Contest reward
- Severity: medium
- Program: Derby
- Credited: Ch_301
- Disclosed: 2022-10-17
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-01-derby-judging/issues/326
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-01-derby%3AM-6
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:chained technique:source-review vuln:access-control vuln:business-logic vuln:dos

**Target:** XChainController / MainVault cross-chain rebalancing contracts
**Root cause:** MainVault.pushTotalUnderlyingToController lacks a vaultOff check, so inactive vaults can call it and increment XChainController.underlyingReceived, which is compared against activeVaults in the onlyWhenUnderlyingsReceived modifier.
**Steps:**
1. Mark a vault inactive via settleCurrentAllocation (no allocations).
2. Call `MainVault.pushTotalUnderlyingToController` from the inactive vault; XChainController.setTotalUnderlying increments `underlyingReceived`.
3. Call `XChainController.pushVaultAmounts` in the same transaction: if counter equals activeVaults, an active vault is skipped; if greater, the require reverts and rebalancing is stuck.
**How found:** Code review of the rebalancing flow: noticed pushTotalUnderlyingToController's onlyWhenIdle modifier doesn't check vaultOff, and that underlyingReceived is compared to activeVaults without validating sender is active.
**Exploitation:** Attacker reports an inactive vault's balance and immediately calls pushVaultAmounts in one transaction, applying the corrupted state before the guardian can reset underlyingReceived; cross-chain messages then propagate wrong allocations.
**Escalation:** Same-transaction call to pushVaultAmounts bypasses guardian reset, making the disruption irreversible for the period.
**Insight:** When a counter gates a multi-party stage (all vaults reported), check whether every writer of that counter is constrained to the same set the gate counts; inactive/removed actors often retain write access.