# xBundle(...) and xReceive(...) should have nonReentrant modifiers Low/Info · Three Sigma · Lending aggregator · 6th May, 2023 Finding 3S-FUJI-N10 of the Fuji Finance security review. - Report: /reports/fuji-finance - Source: https://cdn.sanity.io/files/qoqld077/staging/32181a28eac3175d15fb8924d249bb0d91ca350c.pdf --- ### Description xBundle(...) and xReceive(...) make several external calls and check the balances before and after these calls. It's safer to include nonReentrant modifiers to prevent reentrancy. ### Recommendation Check the [Connext implementation](https://github.com/connext/monorepo/blob/main/packages/deployments/contracts/contracts/core/connext/facets/BaseConnextFacet.sol#L51) for an example. Using non zero state variables as mutex saves gas, because the second write is to the same slot as the first write. Add a check such that if msg.sender is the flasher, it can reenter. ### Status [Fujicracy/fuji-v2#622](https://github.com/Fujicracy/fuji-v2/pull/622) --- Related findings: - [ETH withdrawals from EigenLayer always fail due to `OperatorDelegator`'s nonReentrant `receive()`](https://0xsimao.com/findings/renzo-eth-withdrawals-delegator-reentrant): Renzo - [ERC20AssetPool and ERC721AssetPool should have the nonReentrant modifier as ERC721 and some tokens have callbacks](https://0xsimao.com/findings/singularity-erc20-erc721-reentrant-callbacks): Singularity - [Missing nonReentrant functionality in some execution paths](https://0xsimao.com/findings/yieldoor-iii-reentrant-functionality-execution-paths): Yieldoor LoopedVault Update