# #41689 \[SC-Insight] Blacklisting a Kodiak vault unintentionally whitelists a previously blacklisted token

**Submitted on Mar 17th 2025 at 15:32:22 UTC by @peppef for** [**Audit Comp | Yeet**](https://immunefi.com/audit-competition/audit-comp-yeet)

* **Report ID:** #41689
* **Report Type:** Smart Contract
* **Report severity:** Insight
* **Target:** <https://github.com/immunefi-team/audit-comp-yeet/blob/main/src/contracts/Zapper.sol>
* **Impacts:**
  * Contract fails to deliver promised returns, but doesn't lose value

## Description

In the `Zapper.sol` contract the methods `updateSwappableTokens()` and `updateWhitelistedKodiakVault()` helps the blacklisting token and vault processes.\
\`\`\`solidity

````
function updateSwappableTokens(address token, bool isWhitelisted) external override onlyOwner { 
    _updateWhitelistedTokens(token, isWhitelisted);
}

function _updateWhitelistedTokens(address token, bool isWhitelisted) private {  
    require(token != address(0), "Zapper: token is zero address");
    whitelistedTokens[token] = isWhitelisted;
    emit TokenWhitelisted(token, isWhitelisted);
}

function updateWhitelistedKodiakVault(address vault, bool isEnabled) external override onlyOwner {
    ... // other code
    whitelistedKodiakVaults[vault] = isEnabled;
    ... // other code
    if (!whitelistedTokens[token0]) {
        _updateWhitelistedTokens(token0, true);
    }
    if (!whitelistedTokens[token1]) {
        _updateWhitelistedTokens(token1, true);
    }
}
```
````

However they both edit the state of the mapping `_updateWhitelistedTokens[]` which can lead to a weird scenario where blacklisting a vault which involves a blacklisted token has the contrary effect to whitelist it again in `_updateWhitelistedTokens[]`.

## Proof of Concept

Suppose the following scenario:

* A token named $BAD\_TOKEN is blacklisted by the owner using the following code

  ```solidity
  updateSwappableTokens(bad_token_address, false)
  ```

  This, through `_updateWhitelistedTokens()` private function sets `whitelistedTokens[bad_token_address] = false`
* At this point zapIn and zapOut methods are still usable on vaults involving $BAD\_TOKEN since the `onlyWhitelistedKodiakVaults()` modifier only checks for whitelisted vaults in the mapping `whitelistedKodiakVaults[]`
* For this reason the owner proceeds to blacklist the first vault involving $BAD\_TOKEN, for example `wBERA/BAD_TOKEN` vault with

  ```solidity
  updateWhitelistedKodiakVault(wBera_BadToken_vault, false)
  ```

  This function call sets `whitelistedKodiakVaults[wBera_BadToken_vault] = false` but at the same time whitelists again bad\_token\_address inside `whitelistedTokens[]` which was previously blacklisted due to the how `updateWhitelistedKodiakVault()` is implemented
* Additionally the owner needs some time to blacklist all the other vaults involving $BAD\_TOKEN for example: HONEY/BAD\_TOKEN, USDT/BAD\_TOKEN, USDC/BAD\_TOKEN and thus, in the meanwhile, those vaults are still being usable by users and every potential blacklisting call to `updateSwappableTokens()` is useless due to next `updateWhitelistedKodiakVault()`call.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://reports.immunefi.com/yeet/41689-sc-insight-blacklisting-a-kodiak-vault-unintentionally-whitelists-a-previously-blacklisted-tok.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
