Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
CWE-606 Base Draft
Unchecked Input for Loop Condition
This vulnerability occurs when an application fails to properly validate or limit user-supplied values that control loop iterations. Without these checks, malicious input can force the program into…
Definition
What is CWE-606?
This vulnerability occurs when an application fails to properly validate or limit user-supplied values that control loop iterations. Without these checks, malicious input can force the program into an endless or excessively long loop, consuming system resources and leading to denial of service or application instability.
At its core, this weakness allows an attacker to manipulate a program's flow by controlling how many times a loop executes. Common scenarios include using an unexpectedly large integer for a counter, a negative number that bypasses termination logic, or a specially crafted string that causes unexpected parsing behavior within the loop condition. Developers often trust these values from sources like configuration files, APIs, or user inputs without implementing strict bounds checking.
To prevent this, always validate and sanitize any external input before it determines loop behavior. Implement explicit limits on maximum iterations, use signed/unsigned integer checks to prevent wrap-around issues, and consider adding timeout mechanisms for processing loops. Treat loop control variables with the same level of distrust as any other user input, as they directly control resource consumption and application availability.
Real-world impact
Real-world CVEs caused by CWE-606
No public CVE references are linked to this CWE in MITRE's catalog yet.
How attackers exploit it
Step-by-step attacker path
- 1
The following example demonstrates the weakness.
- 2
In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.
- 3
However, the message length variable (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body (CWE-606). If msgLength indicates a length that is longer than the size of a message body (CWE-130), then this can result in a buffer over-read by reading past the end of the buffer (CWE-126).
Vulnerable code example
Vulnerable C
The following example demonstrates the weakness.
void iterate(int n){
int i;
for (i = 0; i < n; i++){
foo();
}
}
void iterateFoo()
{
unsigned int num;
scanf("%u",&num);
iterate(num);
} Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-606
- Implementation Do not use user-controlled data for loop conditions.
- Implementation Perform input validation.
Detection signals
How to detect CWE-606
CWE-606
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-606?
How serious is CWE-606?
What languages or platforms are affected by CWE-606?
How can I prevent CWE-606?
How does Plexicus detect and fix CWE-606?
Where can I learn more about CWE-606?
Frequently asked questions
What is CWE-606?
This vulnerability occurs when an application fails to properly validate or limit user-supplied values that control loop iterations. Without these checks, malicious input can force the program into an endless or excessively long loop, consuming system resources and leading to denial of service or application instability.
How serious is CWE-606?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-606?
MITRE has not specified affected platforms for this CWE — it can apply across most application stacks.
How can I prevent CWE-606?
Do not use user-controlled data for loop conditions. Perform input validation.
How does Plexicus detect and fix CWE-606?
Plexicus's SAST engine matches the data-flow signature for CWE-606 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-606?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/606.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-606
CWE-1284 Parent
Improper Validation of Specified Quantity in Input
This vulnerability occurs when an application accepts user input meant to define a quantity—like a number, size, or count—but fails to…
CWE-834 Can precede
Excessive Iteration
This vulnerability occurs when a program runs a loop too many times because it lacks proper limits on its iterations.
Ready to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.