● Patternvalidation_bypassPolicy boundaryPublic-safe
Proof / Validation boundary bypass
CS.02
Validation boundary bypass.
A denylist, blocklist, finality threshold, recipient validation, or governance constraint is enforced on one route or one representation, while another route consumes a different representation without reapplying the same policy.
The shape
- A value, account, recipient, validator, controller or message is blocked by one policy boundary.
- A second execution path receives a transformed, alternate, remote, or derived value.
- The second path validates message shape or caller authority, but not the blocked object itself.
- The protected action completes despite the object being policy-denied.
Representative findings (redacted)
| Redacted ID | Pattern | Impact class |
|---|---|---|
| BB-VAL-001 | Destination-side denylist omitted during inbound value release | Policy-bypassed mint or release |
| BB-VAL-002 | Outbound policy enforced, inbound recipient policy skipped | Blocked account receives value |
| BB-VAL-003 | Minimum finality threshold downgraded across a message boundary | Premature acceptance |
| BB-VAL-004 | Revoked delegate path still able to burn or withdraw | Role revocation bypass |
| BB-VAL-005 | Blocklisted authority can create a fresh mint path | Blocklist escape |
Detection logic
validation_bypassscope_guardbizlogic_hunterpoc_validator
High-signal checks
- Does the final execution value exactly match the value that was validated?
- Is the policy applied to the object, or to a transformed representation?
- If revoked or denied, is the object refused at the point of action — not just at the entry point?
Related: Runtime authorization replay · Cross-domain / cross-asset logic abuse