CWE-1126 is a variable declared in one scope but used only within a narrower one. A counter declared at the top of a function and used only inside a single loop is the usual case.
MITRE allows this entry for mapping as a base level weakness, with the standard caution to read the name and description and not force a fit. It sits under CWE-710, improper adherence to coding standards.
How it happens
Older style guides and habits put every declaration at the top of a function. Or a variable starts out needed in a wide scope and later the use narrows, but nobody moves the declaration.
What an attacker gains
MITRE lists reduced maintainability and increased analytical complexity. It says the issue makes the product harder to understand and maintain, which indirectly affects security by making vulnerabilities more difficult or time-consuming to find and fix, and might make them easier to introduce.
The concrete risk is stale state. A variable that stays alive after its job is done can be read or reused by later code with a leftover value.
/* Wide scope: len survives past its purpose */
int len = 0;
if (hdr_ok) {
len = parse_len(buf);
copy(dst, buf, len);
}
/* much later, len is still visible and holds an old value */
send(dst, len);
/* Narrow scope: len exists only where it is valid */
if (hdr_ok) {
int len = parse_len(buf);
copy(dst, buf, len);
}
With the narrow version, a later misuse of len fails to compile instead of silently using an old value.
How to find it
MITRE notes static analysis can find some instances. Compilers and linters often warn about variables that could be declared closer to their use.
How to fix it
The record has no formal mitigations. Declare variables at first use, in the smallest scope that works, and prefer immutable bindings where the language offers them.
Quick check
Why does scope matter for security?
A smaller scope means fewer lines that can read or change the value, so there is less to review.
