CWE-344, Use of Invariant Value in Dynamically Changing Context, is the weakness of using a constant where the value can, or should, vary. MITRE describes it as a product that uses a constant value, name or reference, when that value should differ across environments.
It is a design smell more than a single bug class. It hits anyone who ships the same build to many machines, users or sessions, which is nearly everyone.
How it happens
A developer picks a convenient fixed value during development. A file location, a resource name, a reference to a window or object. It works on every machine in the team. Then the code ships, and the fixed value is the same everywhere.
Once an attacker knows the value, they know where to look. They do not need to guess or probe. The constant is published by the product itself, in every install.
The one observed example in the MITRE record shows the pattern. CVE-2002-0980 describes a web browser component that writes an error message to a known location. Attackers could reference that location to get HTML or script processed in a less restrictive context. The fixed location was the weakness. Nobody had to find it.
What an attacker gains
MITRE lists the consequence as "Other, Varies by Context." That is honest. The impact depends on what the constant guards. A fixed path might let an attacker plant content. A fixed reference might let one session touch another. A fixed name might let one tenant collide with a second.
How to find it
MITRE's record lists no specific detection methods for this entry, so you are mostly reviewing by hand. Ask three questions in code review.
- Is this literal a path, name, key or reference that will exist in more than one environment?
- If an attacker learned this value from our own build, what would they be able to do?
- Could this value be generated per install, per user or per session instead?
How to fix it
MITRE gives no formal mitigation list here, so the steps below are design practice drawn from the definition.
- Generate values at runtime when they identify a resource, rather than hardcoding them.
- Make them unpredictable when an attacker should not be able to guess them.
- Keep environment specific values in configuration, not in code.
- Treat any location that your product writes to and later trusts as hostile territory, and check what you read back.
Quick check
Why is a fixed location a security problem and not just a style problem?
Because every install shares it. An attacker who learns the value once knows it for all targets, as in the browser example where a known error message location could be referenced to run content in a less restrictive context.
Sources
- MITRE CWE-344: https://cwe.mitre.org/data/definitions/344.html
