# SubAccount operator can steal funds via the gas refund mechanism

Brahma SubAccount operator abuses Gnosis Safe gas refund params omitted from validator signature to drain Safe ETH/ERC-20 to themselves.

- Payout: Audit contest
- Severity: medium
- Program: Brahma
- Found by: Taylor_Webb
- Disclosed: 2023-11-21
- Write-up quality: 7/10
- Original: https://code4rena.com/reports/2023-10-brahma#m-02
- Library page: https://bugbountylibrary.com/r/c4%3A2023-10-brahma%3AM-02
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm technique:source-review vuln:access-control vuln:business-logic

**Target:** Gnosis Safe SubAccount execTransaction / trusted validator signature
**Root cause:** Trusted validator signature omits safeTxGas, baseGas, gasPrice, gasToken, refundReceiver, so operator can set arbitrary gas refund values without invalidating the validated signature.
**Steps:**
1. Operator (owner on SubAccount Safe) calls `execTransaction` with valid to/value/data/operation/signatures matching policy so validator signs.
2. Same call sets `safeTxGas`, `baseGas`, `gasPrice`, `gasToken`, `refundReceiver` to attacker-chosen values.
3. Safe executes and `handlePayment` transfers ETH or ERC-20 to `refundReceiver` (operator).
**How found:** Noticed validator signature covers only to/value/data/operation/signatures while execTransaction also accepts gas refund params, so those params are unauthenticated.
**Exploitation:** Operator sets gasPrice arbitrarily high with refundReceiver = self; minuscule gas use yields large refund paid from Safe balance in ETH or chosen ERC-20, bypassing SafeModerator checks.
**Insight:** When a validator signs a subset of a function's parameters, enumerate every other parameter the callee acts on (here gas refund fields) as an unauthenticated lever for value extraction.