CWE-454 External Initialization of Trusted Variables or Data Stores

Coverage: 9 rules in the SiteShadow rule registry target this CWE (registry v2.0.0). Regex 9 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 "trusted" values being initialized or populated from an untrusted source (client input, unsigned webhooks, headers, environment, files). This becomes dangerous when the value is later treated as authoritative (roles, quotas, account IDs, feature flags, security settings).

Why it matters

Attackers can influence trusted values, leading to privilege escalation or logic bypass.

• Privilege escalation: initializing isAdmin, role, scope, or permissions from a client payload.
• Business logic abuse: initializing quota or access state from client-controlled fields.
• Security feature disablement: insecure flags set via env/config without verification or guardrails.

Safer examples

1) Make the server the source of truth

Load roles, access state, quotas, and permissions from your database or trusted internal service, not from the request (see CWE-642 / B01).

2) Verify external inputs that must be trusted

For webhooks/config files, require signatures, enforce schemas, and restrict who can write them (see CWE-347 / A08).

3) Treat environment/config as privileged and validated

Use allowlists for env-driven options and avoid "insecure mode" toggles in production.

How SiteShadow detects it (high level)

• Detects initialization of sensitive variables from untrusted sources.
• Flags when those values later influence authorization, money, or security controls.

References

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

---

← Back to Vulnerability Library