Overlayer Disclosed Report

Vulnerability details

The OverlayerWrapCore contract contains a critical logic flaw in the _credit function. The function attempts to decrement the global variable totalBridgedOut whenever funds are received via the bridge: totalBridgedOut -= amountReceivedLD;.

However, on side-chains (Spoke chains), totalBridgedOut is initialized to 0 upon deployment. Since the contract uses Solidity 0.8.20+, any subtraction that results in a negative value (e.g., 0 - amount) will trigger an automatic Arithmetic Underflow (Panic 0x11).

Impact

This vulnerability leads to a Permanent Lock of End-User Funds. When a user bridges assets from the Hub chain (Ethereum) to a Spoke chain, the assets are locked/burned on the source. When the message reaches the destination Spoke chain, the _credit execution will consistently revert due to the underflow. The user will never receive their funds on the destination chain, and the funds remain stuck in the bridge's logic.

Recommended Mitigation

Ensure that totalBridgedOut is only tracked and decremented on the Hub chain, or wrap the subtraction in an unchecked block if the logic allows, or (preferably) refactor how global supply is tracked on Spoke chains to avoid subtracting from zero.

Validation Steps

To reproduce the vulnerability and verify the permanent lock of funds, follow these steps using the Foundry development framework:

1. Environment Setup Ensure you have Foundry installed. If not, install it via curl -L https://foundry.paradigm.xyz | bash.
2. Repository Preparation Initialize Foundry in the project root (if not already initialized) and ensure the mapping for OpenZeppelin and LayerZero is correct:

forge init --force

3. PoC Implementation Create a new test file at test/BridgeUnderflow.t.sol and paste the following single-file PoC. This PoC uses a Harness to expose the internal _credit function from the original OverlayerWrapCore.sol and provides the necessary ConstructorParams.

4. Configuration Ensure your foundry.toml is configured to support the Cancun EVM version (to avoid mcopy compilation errors) and has auto_detect_solc = true.

5. Execution & Verification Run the specific test using the following command to see the detailed execution trace:

forge test --match-test test_ProveBridgeUnderflow -vvvv

6. Expected Result (Proof of Vulnerability) The test will result in a [PASS] status, which confirms that the vm.expectRevert successfully caught the expected error. Observe the terminal output for the following trace:

Status: ok. 1 passed; 0 failed; 0 skipped

Error Trace: ← [Revert] panic: arithmetic underflow or overflow (0x11)

This trace confirms that when _credit is called on a freshly deployed Side-chain contract (where totalBridgedOut is 0), the arithmetic operation fails, causing a Permanent Denial of Service for any inbound bridge message.

Log output:

wazeid@LAPTOP-4V17UD99:~/contracts$ forge test --match-test test_ProveBridgeUnderflow -vvv
[⠢] Compiling...
[⠢] Compiling 1 files with Solc 0.8.33
[⠆] Solc 0.8.33 finished in 2.47s
Compiler run successful!

Ran 1 test for contracts/test/BridgeUnderflow.t.sol:BridgeUnderflowPoC
[PASS] test_ProveBridgeUnderflow() (gas: 61098)
Logs:
  --- Proof of Concept: Bridge Underflow ---
  SUCCESS: Underflow Confirmed!

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 159.40ms (92.63ms CPU time)

Ran 1 test suite in 170.62ms (159.40ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)