# Slashing would not be executed in the case of veto slasher since only middleware has the right to execute slash, while it can't

MevCommitMiddleware requests veto-slasher slashes but never implements executeSlash, and only the middleware may call it, so misbehaving validators escape slashing.

- Payout: Contest reward
- Severity: high
- Program: Primev
- Credited: sashik-eth
- Disclosed: 2025-08-27
- Write-up quality: 7/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_primev_oct2024.pdf#3.1.4
- Library page: https://bugbountylibrary.com/r/cantina%3Aprimev_oct2024%3A3.1.4
- Tags: domain:web3 impact:integrity kind:contest platform:cantina sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** MevCommitMiddleware.sol / Symbiotic VetoSlasher integration
**Root cause:** For veto-type slashers, _slashValidator only calls requestSlash; execution requires IVetoSlasher.executeSlash which is gated to the network middleware, but MevCommitMiddleware never implements it and the oracle cannot call it.
**Steps:**
1. Register a validator with a Symbiotic vault whose slasher TYPE() == _VETO_SLASHER_TYPE.
2. Oracle calls `slashValidators`, which invokes `_slashValidator` and `IVetoSlasher.requestSlash(...)` returning a slashIndex.
3. After the veto period, oracle attempts `IVetoSlasher.executeSlash(slashIndex, hints)`.
4. Call reverts in `_checkNetworkMiddleware(request.subnetwork)` because msg.sender is the oracle, not MevCommitMiddleware.
5. Slash never executes; validator remains unpunished.
**How found:** Code-reading of _slashValidator's slasher-type branch plus README claim that oracle calls executeSlash; cross-checked VetoSlasher.executeSlash's _checkNetworkMiddleware access control to find the contradiction.
**Insight:** When integrating a two-step slasher, verify who is authorized to complete step two: middleware-gated executeSlash cannot be driven by an external oracle, so the middleware must expose a passthrough.