Skip to content

fix(enforcers): LogicalOrWrapperEnforcer groups silently share stateful sub-enforcer state - #194

Open
SashaMIT wants to merge 2 commits into
MetaMask:mainfrom
SashaMIT:fix/logical-or-wrapper-state-isolation
Open

fix(enforcers): LogicalOrWrapperEnforcer groups silently share stateful sub-enforcer state#194
SashaMIT wants to merge 2 commits into
MetaMask:mainfrom
SashaMIT:fix/logical-or-wrapper-state-isolation

Conversation

@SashaMIT

@SashaMIT SashaMIT commented Aug 5, 2026

Copy link
Copy Markdown

Summary

  • LogicalOrWrapperEnforcer forwards the raw _delegationHash to every caveat in the selected group.
  • Stateful enforcers (MultiTokenPeriodEnforcer, ERC20StreamingEnforcer, LimitedCallsEnforcer, NativeTokenPaymentEnforcer, …) key their state by delegation hash — terms are not part of the key.
  • Result: all groups that reference the same stateful enforcer instance share one state. Whichever group the redeemer picks first initialises it (pinning a period start, filling a call counter, seeding a spent-map) for every other group — and the header security notice, which correctly warns about least-restrictive-group selection, does not cover this cross-group interference. A delegator can follow the documented guidance ("each group a complete, equally secure permission set") and still get budgets that leak across groups.
  • Fix: the wrapper now forwards keccak256(abi.encode(delegationHash, groupIndex)), isolating each group's state. A deliberately shared budget remains expressible by placing the caveats in a single group. Verified that no in-repo enforcer uses the delegation hash for anything except state keying / event fields, so namespacing is safe.
  • One integration note: sub-enforcer events now carry the namespaced hash; indexers can recompute it from delegationHash + groupIndex (both available at redemption).

Impact if unsolved

Any delegation using this wrapper with the same stateful enforcer in multiple groups gets cross-group interference the delegator never agreed to: e.g. a 100/day group and a 100/week group share one counter and one period start, so the daily path consumes the weekly path's budget (or vice versa), and the first redemption permanently pins the period anchor for both. The mismatch between documented semantics and actual state semantics is invisible at signing time.

Test plan

  • New test_statefulEnforcerStateIsIsolatedPerGroup: two groups, same LimitedCallsEnforcer (limit 1 each) — each group gets its own independent call allowance; fails without the fix (mutation-verified).
  • 10 existing stateful-integration tests updated to read sub-enforcer state via the namespaced key.
  • LogicalOrWrapperEnforcerTest 43/43; full test/enforcers suite 581/581.

Made with Cursor

LogicalOrWrapperEnforcer forwarded the raw delegation hash to every caveat in the selected group. Stateful enforcers key state by delegation hash (not terms), so all groups referencing the same stateful enforcer shared one state: the first-used group initialised it (period start, call counter, spent map) for every other group — invisibly to the delegator, and beyond what the header security notice covers. The forwarded hash is now namespaced by the selected group index (keccak256(delegationHash, groupIndex)); each group's budgets/periods are independent, and a shared budget remains expressible by placing caveats in a single group. Includes an isolation regression test (LimitedCallsEnforcer, limit 1 in two groups) that fails without the fix.

Signed-off-by: SashaMIT <sash@ela.city>
Co-authored-by: Cursor <cursoragent@cursor.com>
@SashaMIT
SashaMIT requested a review from a team as a code owner August 5, 2026 19:25

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

Reviewed by Cursor Bugbot for commit edf621a. Configure here.

Comment thread test/enforcers/LogicalOrWrapperEnforcer.t.sol
The afterHook assertion still read the raw delegation hash key, which was never locked, so it always passed. Point it at the namespaced key like the before-hook check.

Signed-off-by: SashaMIT <sash@ela.city>
Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant