Parameter or JSON parser disagreement crosses a security check
Validation or authorization uses one interpretation of a request value while the protected operation uses another.
Candidate CWE: CWE-436
Test hypothesis#
With A-readable O1 and B-only O2, capture allowed/denied scalar controls. Send one duplicated parameter or literal repeated JSON name in both orders through the normal local ingress. Trace exactly which value each security and execution layer consumes.
Evidence required#
Preserved raw bytes, parse/type/precedence behavior at each component, O1 being authorized, and O2 being consumed with a forbidden controlled result. Include a consistent-parser or strict-schema negative control.
Rule out false positives#
Duplicate acceptance, last-value parsing, a supported multivalue API, or different error text without a violated permission or input contract is insufficient.
Playbook and command references#
- Request values: duplicate parameters, parser conflicts and downstream queries — Trace the value a security layer validates through to the value the application or downstream service actually consumes.
- Object, function, and property authorization — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
Find the associated command snippets
Referenced by these target playbooks#
Report checklist#
- Capture the affected version, configuration, identities, and object ownership.
- Preserve a valid baseline and a negative control.
- Reproduce the forbidden data access, action, or state change on controlled fixtures.
- Explain the intended security rule and why the observed behavior violates it.
- State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.
Conditional ATT&CK mapping#
No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the mapping guide.