# `deleverageAccount` can be used by an address to enter a vault that would otherwise be restricted by the `requireValidAccount` check in `enterVault`

deleverageAccount instantiates a vault account for liquidators, bypassing enterVault's requireValidAccount check and letting restricted system accounts enter vaults.

- Payout: Contest reward
- Severity: medium
- Program: Notional
- Credited: Arbitrary-Execution
- Disclosed: 2022-09-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-09-notional-judging/issues/19
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-09-notional%3AM-22
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** VaultAccountAction.sol (deleverageAccount / enterVault)
**Root cause:** deleverageAccount calls _transferLiquidatorProfits which instantiates a vault account for the liquidator without running requireValidAccount, so system-level accounts blocked in enterVault can still acquire vault positions.
**Steps:**
1. Call `enterVault` from a system account (e.g. nToken address) — reverts due to `requireValidAccount`.
2. Have another account enter the vault via `enterVault`.
3. Lower the vault exchange rate (e.g. `vault.setExchangeRate(0.95e18)`) to make the position liquidatable.
4. Call `deleverageAccount(accounts[1], vault, systemAccount, 1_000e8, True, "")` from the system account.
5. Observe `getVaultAccount(systemAccount, vault)` now returns a nonzero maturity — system account entered the vault.
**How found:** Code reading of enterVault's requireValidAccount guard versus deleverageAccount's _transferLiquidatorProfits path, noticing the latter instantiates vault accounts without the same validation.
**Exploitation:** A liquidator without an existing vault position calls deleverageAccount on a liquidatable account; _transferLiquidatorProfits instantiates a vault account for them and deposits the seized vault shares, granting vault entry that enterVault would have blocked. Combined with a separate issue allowing forced deleverage, a system account could be forced into a vault.
**Escalation:** Chained with the ability to force arbitrary addresses to deleverage, enabling a Notional system account to be pushed into a vault.
**Insight:** When a privileged entry function has a validation guard, check every other code path that creates the same state (here, liquidator profit transfer instantiating a vault account) for the missing guard.