CWE-642 External Control of Critical State Data

Coverage: 5 rules in the SiteShadow rule registry target this CWE (registry v2.0.0). Regex 5 Also: Taint and heuristic analyzers may also detect related flows (see coverage for the authoritative list) Registry tagging shows intent, for sample-level behaviour and benchmarked gaps see known gaps.

What this means

SiteShadow flagged critical state being controlled by external input (request params/body/cookies) without strong verification. "Critical state" includes role, account ID, quota, workflow state, or security flags.

Why it matters

External control of state can bypass security logic.

• Privilege escalation if roles/permissions are client-controlled.
• Business logic abuse if quotas or access status are client-controlled.
• Workflow bypass if state transitions are client-controlled.

Safer examples

1) Keep critical state server-side

Look up roles, permissions, access state, and workflow state from the server/database.

2) Use signed tokens where appropriate

If state must be carried in a token, sign it and validate signature + claims (see JWT01 / CWE-347).

3) Enforce allowed state transitions

Validate transitions server-side and reject invalid transitions (see B01 / A11).

How SiteShadow detects it (high level)

• Detects request-derived values being used in sensitive decisions (authz, money, workflow).
• Flags missing verification/allowlists around critical state fields.

References

• CWE-642: https://cwe.mitre.org/data/definitions/642.html

---

← Back to Vulnerability Library