Magpie Protocol security record

In MagpieCelerBridgeV2, within the swapIn function the refundAddresses[depositDataHash] is always set to msg.sender. However, the swapIn can be called either by swapInWithMagpieSignature or swapInWithUserSignature which have different authorisation. Therefore, whenever swapInWithUserSignature is called, the refundAddresses can be set to the internal caller. As a result, in the event of the bridge transfer failure, the tokens will be transferred back to the incorrect address.

The MagpieRouterV3 contract implements the Pausable library. Functions: estimateSwapGas and swapWithMagpieSignature are marked as whenNotPaused. However, there is no public or external function that allows the protocol’s owner to toggle paused state on or off. Thus, it is not possible to use the emergency-stop pattern in the event of an emergency situation.

Within the MagpieCelerBridgeV2, the bridgeIn function has an ‘if’ condition suggesting that native tokens can be bridged as well. However, the final call to the sendMessageWithTransfer only passes bridgeFee and not the bridgeFee + amount (amountOut from swapIn). Also, on the contrary the MagpieStargateBridgeV3 calculates the valueToSend, to determine the amount that should be sent. Ultimately, within the Celer Network the separate function exists to send native tokens: sendNative. Thus, this bridge only supports ERC20 tokens and wrapped native token, but not native.

Within the MagpieRouterV3 contract three functions: estimateSwapGas, swapWithMagpieSignature, swapWithUserSignature make use of permit functionality for ERC20 tokens to set gas-less allowance. However, the permit function can be called by anyone anytime whenever the permit’s signature becomes public. Thus, an adversary can extract the permit signature from the functions’ calldata, front-run legitimate call and execute ERC20 token’s permit. As a result, the legitimate call will revert as the permit's nonce is incremented and the signature is not valid anymore.

Within the MagpieRouterV3 contract the swapWithMagpieSignature allows the user to trigger swap operation, if only the user has been given the valid signature signed by the internalCaller. However, this signature-based authorisation is flawed as it does not include from address in the signed message - thus, it is not bound to a particular user. As a result, any user can use any signature generated by the internal caller, triggering swap operation.

The MagpieCelerBridgeV2 contract implements the executeMessageWithTransferRefund function, which is designed to handle bridge’s refund in the event of unsuccessful bridging. However, this function attempts to immediately transfer refunded assets to the user. This feature may revert in following use cases:• Whenever a refunded asset is a native token and the receiver address is a contract with custom receive()/fallback function, the transaction can revert due to Out Of Gas error. • Whenever a refunded asset is a USDC or similar token implementing the blacklisting, whenever the address get blacklisted between bridging and refund, it will revert due to ERC20 transfer revert.

The swapOut function in the MagpieCelerBridgeV2 contract has a condition check to handle the event when Celer changes the mapping for native token address. However, this if and else if conditions lack final else fallback, to handle citation when depositAmount is equal to 0 and it is not native asset.

The *Bridge contracts have defined the swapSequence variable with uint64 type. Thus, this state variable occupies only 8 bytes from the storage slot. However, it is declared in between two other variables that occupy full slots. Eventually, such order of variables impacts the storage slots used, as swapSequence starts occupying a new slot, when it could be attached to other variable which occupies only 20 bytes out of 32.

The MagpieCCTPBridge and MagpieSymbiosisBridge contracts implement the execute() function which is meant to be called by the gateway. However, this function can be called by anyone. If the function is front-run, the legitimate call by the gateway will be reverted, as a second call with the same data to validateContractCall function will revert. No identified risk is associated with this behavior in on-chain processing, however, it may have an impact on the off-chain processing. If off-chain expects that this function is called only by specific address and processes the emitted event only in such a case, it may pose a risk that the call will be unhandled.

The swapOut function in the LibBridge library attempts to swap tokens considering an exchange between native and non-native tokens. Whenever a swap occurs for not equal non-native tokens, the function firstly calls approve for router contract for fromAssetAddress token with amountIn as amount. Then, it attempts to swap tokens, which in the event of failure returns a boolean flag. If the swap is unsuccessful, the fromAssetAddress tokens are transferred to the toAddress instead. However, the allowance set before the swap operation is not reset.