Uncontrolled Recursion

A recursive function has no limit (or an insufficient one) on how deep it can recurse, so a specially crafted input - deeply nested JSON, a recursive data structure, a regular expression pattern that triggers exponential recursive backtracking - can drive the recursion deep enough to exhaust the call stack and crash the process. It's the recursive-function counterpart to an infinite loop, and one of the more common practical routes to a denial-of-service bug.

Where uncontrolled recursion manifests as a directly triggerable, externally observable denial-of-service (deeply nested GraphQL queries, or catastrophic regex backtracking), it's testable and already covered by dedicated modules; genuinely internal recursive logic with no externally reachable trigger requires source-level review instead.

Testing unbounded GraphQL query nesting depth, and testing for catastrophic regex backtracking, both cover concrete, externally triggerable instances of this general pattern. Purely internal recursive logic with no external trigger requires source review.

Tip: Static analysis tuned for these specific patterns (format-string misuse, unchecked error paths, unbounded recursion) catches most of this family reliably in code review — the dangerous pattern itself is what's being flagged, independent of any specific runtime input.

Real-World Impact

This family covers code that reaches a function or pattern that's dangerous by construction, regardless of how carefully its specific inputs are validated: format-string functions given a user-influenced format argument, inherently unsafe functions whose entire contract assumes trusted input, unchecked error paths that leave the program in an undefined state, and unbounded recursion or loops that never reach their exit condition.

An externally-controlled format string is a particularly severe example, since format-string functions in C can be coerced into arbitrary memory reads and writes through format specifiers alone, without needing a separate buffer-overflow bug at all. Unchecked exceptional conditions and unreachable-exit-condition loops trend toward denial-of-service rather than code execution, but both share the same underlying pattern: a code path that assumes something will always go as expected, with no handling for the case where it doesn't.

What unifies this category is that the fix isn't input validation in the usual sense — it's recognizing that certain functions or patterns simply shouldn't be reachable with any attacker-influenced input at all, no matter how that input is sanitized.

Prevention and Secure Design

Preventing Uncontrolled Recursion takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Never pass user-influenced data as a format string. Use a fixed format string with the user data as an argument (printf("%s", userInput), never printf(userInput)) — this closes off format-string vulnerabilities entirely.

Avoid inherently dangerous functions outright, don't try to use them safely. Where a function's entire contract assumes trusted input (an unsafe deserialization or eval-equivalent function, for instance), replace it with a safe alternative rather than attempting to sanitize input into safety.

Handle every exceptional condition explicitly. An unchecked error return or uncaught exception should be treated as a security-relevant gap, not just a robustness nicety — undefined state after a missed error is where a lot of this family's real-world exploitation begins.

Bound recursion depth and loop iteration explicitly. Any recursive or looping operation whose bound is influenced by external input needs an explicit maximum, independent of what the input claims its size to be.

Static analysis specifically tuned for these patterns. Format-string misuse, unchecked error paths, and unbounded recursion are all patterns static analyzers detect reliably — run one tuned for exactly this family as part of CI.