CWE-834 is a loop or iteration with no sufficient limit on how many times it runs. MITRE marks it as not language specific. It is a parent of the infinite loop weakness, CWE-835.
How it happens
If an attacker can influence the count, such as a length field, a repeat count or a nested structure, they can make each request cost far more than it should. MITRE points out the loop need not be infinite. Enough resources can be burned per iteration to hurt the product or its host.
# Vulnerable: attacker supplies count
def handle(req):
for _ in range(int(req["repeat"])):
expensive_step()
MITRE's record shows chains where an off-by-one error led to an infinite loop on invalid hex-encoded characters (CVE-2011-1027), and a browser crash from loop logic relying on floating point math to exit (CVE-2006-6499).
What an attacker gains
Availability: CPU and memory consumption, amplification, and crashes. The product slows down or stops answering.
How to find it
MITRE lists fuzz testing and similar dynamic techniques, manual source review focused on loops, and automated static analysis with configured rules. Review each loop and ask what bounds it, and who controls the bound.
How to fix it
The record has no formal mitigations. General guidance:
- Put a hard maximum on any loop count that comes from input.
- Reject oversized values early, before work starts.
- Add timeouts and per request resource budgets.
- Make sure every loop makes progress toward its exit.
MAX_REPEAT = 100
n = min(int(req["repeat"]), MAX_REPEAT)
Quick check
Does a finite loop count as safe?
Not if the count is huge or the work per iteration is heavy. What matters is the total resource use.
