Improper Resource Shutdown or Release

A resource - a file handle, a network connection, a database connection, a lock - isn't properly closed or released after use, which over time and repeated triggering can exhaust the pool of available resources (leading to denial of service) or, in some cases, leave a resource in a state where its stale data is still accessible to a later, unrelated request that reuses it.

Resource lifecycle management (are file handles and connections actually being closed) is an internal runtime behavior of the compiled/running application - observable at scale only by exhausting the resource pool through sustained load, which risks causing a genuine denial-of-service against the live target and isn't something a safety-conscious scan attempts.

Source-level review of resource-acquisition code paths, checking that every acquired resource has a corresponding release on every code path (including error paths), and load testing in a controlled, non-production environment.

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 Improper Resource Shutdown or Release 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.