# Malicious Relayer Could Cause A Router To Provide More Liquidity Than It Should

Relayer can reorder the routers array so one router supplies all liquidity for a transfer, since the router signature hash omits the router list.

- Payout: Audit contest
- Severity: medium
- Program: Connext
- Found by: xiaoming90
- Disclosed: 2022-10-17
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-06-connext-findings/issues/149
- Library page: https://bugbountylibrary.com/r/c4%3A2022-06-connext%3AM-08
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:signature-replay

**Target:** BridgeFacet._executeSanityChecks router signature verification
**Root cause:** routerHash is keccak256(transferId, pathLength) only, so router signatures don't bind to the specific routers array; duplicates/reordering pass sanity checks as long as pathLength matches.
**Steps:**
1. Sequencer assigns routers [A,B,C] for a 90 DAI fast transfer, each providing 30 DAI.
2. Malicious relayer rewrites _args.routers[] to [A,A,A] keeping pathLength=3.
3. Each entry passes approvedRouters check and _recoverSignature(routerHash, sig) since routerHash only covers transferId+pathLength.
4. Execution forces Router A to provide the full 90 DAI, overwriting sequencer's split.
**How found:** Code review of _executeSanityChecks noticed routerHash is built only from transferId and pathLength, then reasoned that array contents are unconstrained, allowing duplicate/reordered routers.
**Exploitation:** A whitelisted relayer alters the routers array in the execute call to duplicate one router, causing that router to fund the entire transfer and griefing other routers out of the fees/liquidity allocation.
**Insight:** When a signature hash omits an array whose elements are individually validated, check whether duplicates or reordering of that array still satisfy per-element checks — binding only length leaves ordering/identity malleable.