CWE-835 Base Incomplete

Loop with Unreachable Exit Condition ('Infinite Loop')

An infinite loop occurs when a program's iteration logic contains an exit condition that can never be satisfied, causing the loop to run indefinitely and consume system resources.

Definition

What is CWE-835?

An infinite loop occurs when a program's iteration logic contains an exit condition that can never be satisfied, causing the loop to run indefinitely and consume system resources.
This vulnerability typically stems from flawed loop logic where the condition for termination is incorrectly defined. Common causes include using a loop counter that never updates, checking against a variable that doesn't change within the loop body, or creating circular dependencies where the exit state becomes mathematically impossible to reach. Developers might introduce these errors through simple typos, incorrect operator usage, or misunderstanding how loop variables interact with other parts of the code. When an infinite loop executes, it can lead to denial of service by exhausting CPU cycles, memory, or other finite resources, potentially freezing the application or the entire system. To prevent this, always validate that loop control variables are properly modified inside the loop and that exit conditions are based on values that will eventually change. Using timeouts, circuit breakers, or defensive programming techniques like maximum iteration limits can provide safety nets for unexpected logic errors.
Vulnerability Diagram CWE-835
Infinite Loop while (cond) // cond never updates repeat forever CPU 100% — process unresponsive other threads / requests starve Loop exit condition can never become false.
Real-world impact

Real-world CVEs caused by CWE-835

  • CVE-2022-22224

    Chain: an operating system does not properly process malformed Open Shortest Path First (OSPF) Type/Length/Value Identifiers (TLV) (CWE-703), which can cause the process to enter an infinite loop (CWE-835)

  • CVE-2022-25304

    A Python machine communication platform did not account for receiving a malformed packet with a null size, causing the receiving function to never update the message buffer and be caught in an infinite loop.

  • CVE-2011-1027

    Chain: off-by-one error (CWE-193) leads to infinite loop (CWE-835) using invalid hex-encoded characters.

  • CVE-2011-1142

    Chain: self-referential values in recursive definitions lead to infinite loop.

  • CVE-2011-1002

    NULL UDP packet is never cleared from a queue, leading to infinite loop.

  • CVE-2006-6499

    Chain: web browser crashes due to infinite loop - "bad looping logic [that relies on] floating point math [CWE-1339] to exit the loop [CWE-835]"

  • CVE-2010-4476

    Floating point conversion routine cycles back and forth between two different values.

  • CVE-2010-4645

    Floating point conversion routine cycles back and forth between two different values.

How attackers exploit it

Step-by-step attacker path

  1. 1

    In the following code the method processMessagesFromServer attempts to establish a connection to a server and read and process messages from the server. The method uses a do/while loop to continue trying to establish the connection to the server when an attempt fails.

  2. 2

    However, this will create an infinite loop if the server does not respond. This infinite loop will consume system resources and can be used to create a denial of service attack. To resolve this a counter should be used to limit the number of attempts to establish a connection to the server, as in the following code.

  3. 3

    For this example, the method isReorderNeeded is part of a bookstore application that determines if a particular book needs to be reordered based on the current inventory count and the rate at which the book is being sold.

  4. 4

    However, the while loop will become an infinite loop if the rateSold input parameter has a value of zero since the inventoryCount will never fall below the minimumCount. In this case the input parameter should be validated to ensure that a value of zero does not cause an infinite loop, as in the following code.

Vulnerable code example

Vulnerable C

In the following code the method processMessagesFromServer attempts to establish a connection to a server and read and process messages from the server. The method uses a do/while loop to continue trying to establish the connection to the server when an attempt fails.

Vulnerable C 
int processMessagesFromServer(char *hostaddr, int port) {
  		...
  		int servsock;
  		int connected;
  		struct sockaddr_in servaddr;
```
// create socket to connect to server* 
  		servsock = socket( AF_INET, SOCK_STREAM, 0);
  		memset( &servaddr, 0, sizeof(servaddr));
  		servaddr.sin_family = AF_INET;
  		servaddr.sin_port = htons(port);
  		servaddr.sin_addr.s_addr = inet_addr(hostaddr);
  		
  		do {
  		```
```
// establish connection to server* 
  				connected = connect(servsock, (struct sockaddr *)&servaddr, sizeof(servaddr));
  				
  				
  				 *// if connected then read and process messages from server* 
  				if (connected > -1) {
  				```
```
// read and process messages* 
  						...}
  				
  		
  		 *// keep trying to establish connection to the server* 
  		} while (connected < 0);
  		
  		
  		 *// close socket and return success or failure* 
  		...}
Secure code example

Secure C

However, this will create an infinite loop if the server does not respond. This infinite loop will consume system resources and can be used to create a denial of service attack. To resolve this a counter should be used to limit the number of attempts to establish a connection to the server, as in the following code.

Secure C 
int processMessagesFromServer(char *hostaddr, int port) {
  		...
```
// initialize number of attempts counter* 
  		int count = 0;
  		do {
  		```
```
// establish connection to server* 
  				connected = connect(servsock, (struct sockaddr *)&servaddr, sizeof(servaddr));
  				
  				
  				 *// increment counter* 
  				count++;
  				
  				
  				 *// if connected then read and process messages from server* 
  				if (connected > -1) {
  				```
```
// read and process messages* 
  						...}
  				
  		
  		 *// keep trying to establish connection to the server* 
  		
  		
  		 *// up to a maximum number of attempts* 
  		} while (connected < 0 && count < MAX_ATTEMPTS);
  		
  		
  		 *// close socket and return success or failure* 
  		...}
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-835

  • Architecture Use safe-by-default frameworks and APIs that prevent the unsafe pattern from being expressible.
  • Implementation Validate input at trust boundaries; use allowlists, not denylists.
  • Implementation Apply the principle of least privilege to credentials, file paths, and runtime permissions.
  • Testing Cover this weakness in CI: SAST rules + targeted unit tests for the data flow.
  • Operation Monitor logs for the runtime signals listed in the next section.
Detection signals

How to detect CWE-835

SAST High

Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.

DAST Moderate

Run dynamic application security testing against the live endpoint.

Runtime Moderate

Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.

Code review Moderate

Code review: flag any new code that handles input from this surface without using the validated framework helpers.

Plexicus auto-fix

Plexicus auto-detects CWE-835 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free
Frequently asked questions

Frequently asked questions

What is CWE-835?

An infinite loop occurs when a program's iteration logic contains an exit condition that can never be satisfied, causing the loop to run indefinitely and consume system resources.

How serious is CWE-835?

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-835?

MITRE has not specified affected platforms for this CWE — it can apply across most application stacks.

How can I prevent CWE-835?

Use safe-by-default frameworks, validate untrusted input at trust boundaries, and apply the principle of least privilege. Cover the data-flow signature in CI with SAST.

How does Plexicus detect and fix CWE-835?

Plexicus's SAST engine matches the data-flow signature for CWE-835 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-835?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/835.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-835

CWE-834 Parent

Excessive Iteration

This vulnerability occurs when a program runs a loop too many times because it lacks proper limits on its iterations.

CWE-1322 Sibling

Use of Blocking Code in Single-threaded, Non-blocking Context

This vulnerability occurs when an application designed to be single-threaded and non-blocking, for performance and scalability,…

CWE-674 Sibling

Uncontrolled Recursion

This vulnerability occurs when an application fails to limit how deeply a function can call itself. Without proper controls, this…

Resources

Further reading

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.