Use of Expired File Descriptor is a flaw where software continues to use a file descriptor after it has been closed or reused. An attacker may cause reads or writes against the wrong resource, leading to data corruption or privilege abuse. Defenders should track descriptor lifetimes and clear stale references.
What Use of Expired File Descriptor Means
A file descriptor is a process-level handle to an open resource such as a file, socket, or pipe. This weakness appears when software keeps using that handle after it has been closed, reassigned, or otherwise no longer refers to the intended resource.
Why This Flaw Is Dangerous
Expired descriptor use can redirect reads or writes to the wrong object, which turns a simple lifetime bug into a security problem. The result may be data corruption, accidental disclosure, unexpected process behaviour, or writes that affect a more privileged or sensitive resource than the code intended.
The underlying issue is not the descriptor itself, but the gap between ownership and continued use. Once a descriptor’s lifetime is no longer tightly controlled, the program may act on stale state and lose the guarantee that an operation targets the same resource it was meant to protect.
Common Failure Patterns
This flaw often emerges in code paths with complex cleanup, error recovery, concurrency, or object reuse. A descriptor may be closed in one path while another part of the program still holds a reference, or the operating system may recycle the numeric value for a different resource before the stale reference is cleared.
That makes the bug closely related to resource-lifetime and race-condition problems: the dangerous moment is not only “after close,” but any time the program assumes the descriptor still names the original object. Static analysis, careful ownership rules, and explicit invalidation of handles help reduce that risk.
How to Check and Reduce Exposure
Defenders should review code and runtime behaviour for stale references, inconsistent close semantics, and shared ownership of descriptors across threads or callbacks. It is also important to test paths that reopen files, recycle objects, or retry I/O after failure, because those are common places where the wrong handle can be used.
For deeper background on the weakness class, see the CWE Top 25 Guide, which includes this pattern among the most dangerous software weaknesses. The broader lifecycle and governance angle is also covered in the NHI Lifecycle Management Guide, especially where resource ownership and stale references must be prevented.
For authoritative control guidance, the NIST SP 800-53 Rev 5 Security and Privacy Controls supports disciplined access control, integrity, and audit practices, while OWASP Non-Human Identity Top 10 is useful when the descriptor-handling flaw is part of a broader secret or automation control problem.
Risk and Threat Considerations
Expired descriptor use becomes more dangerous when the stale handle can be redirected toward another resource, because the program may corrupt data, bypass intended access boundaries, or leak information through the wrong channel. In multi-threaded or long-running services, these failures can be intermittent and hard to reproduce, which increases both operational risk and attacker opportunity.
Failure mechanism: A handle is closed or reused, but another code path still trusts the old reference and performs I/O against the recycled descriptor value or a different object that now occupies it.
Impact: The application may read or write the wrong file, socket, or pipe, causing corruption, privilege abuse, unintended disclosure, or a broader compromise if the mistaken target is security-sensitive.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Expired descriptor bugs are reduced by secure coding and safer default handling of resource state. |
| Recommendation — Enforce secure coding patterns that invalidate and track descriptor state explicitly. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The flaw arises when code mishandles state transitions and trusts stale resource references. |
| Recommendation — Validate resource state before each use and reject stale descriptor references. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | ASVS covers design and implementation defects that let stale handles reach sensitive operations. |
| Recommendation — Design code paths so closed or reused descriptors cannot be referenced again. | ||
| MITRE ATT&CK | T1205 — Traffic Signaling | Stale descriptor abuse can affect how processes exchange data and signal through file or pipe handles. |
| Recommendation — Inspect process-to-process I/O paths for handle reuse and unexpected redirection. | ||
Practitioner Guidance
What to watch for: Treat descriptor ownership as an explicit design concern, especially in code with retries, callbacks, shared state, or cleanup on error. Handle invalidation should be immediate and unambiguous so that stale references fail fast instead of silently operating on a recycled resource.
Practitioner takeaway: The safest implementations make descriptor lifetime visible in code structure, not just in developer expectation, because this class of bug is usually a control problem before it becomes an exploit.
Related resources from NHI Mgmt Group
- How should security teams use file-level classification in data security programmes?
- How should teams use file integrity monitoring to support identity governance?
- What breaks when a Linux kernel file descriptor theft bug is present?
- How should security teams use file integrity monitoring alongside other controls?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org