A technique where an attacker obtains a live handle to a file or socket instead of reading the file directly. In this context, the concern is privileged handles that remain open long enough to be duplicated during a race, bypassing the normal permission model.
Expanded Definition
File descriptor theft is a privilege abuse technique in which an attacker acquires an already-open handle to a file, pipe, or socket rather than authenticating to the resource directly. In practice, the value of the attack lies in the fact that the descriptor inherits the access rights of the process that opened it, which can bypass the normal permission check path.
In NHI and agentic systems, this matters when a service account, daemon, or AI agent keeps privileged descriptors open while handling secrets, IPC channels, or network sessions. The concept is adjacent to handle hijacking and descriptor inheritance, but file descriptor theft usually implies a race or reuse opportunity against a live process boundary, not a broad class of access-control failures. Definitions vary across vendors on whether descriptor duplication through process introspection, inherited children, or kernel-assisted reuse should be grouped under one label. For NHI governance, the practical concern is whether a non-human workload can be tricked into exposing a live capability that was never meant to be separately accessible. The most common misapplication is treating it as a generic file permission problem, which occurs when teams focus on path access controls and ignore open-handle lifetime, process privileges, and descriptor inheritance.
For broader NHI context, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
Examples and Use Cases
Implementing protections against file descriptor theft often introduces process and runtime constraints, requiring organisations to weigh tighter handle hygiene against the operational convenience of long-lived connections and inherited resources.
- A privileged backup agent opens a socket to a storage service and a lower-privileged child process later duplicates that socket through an unsafe handoff.
- An automation job reads secrets from a protected file descriptor, but a local attacker races the process and reuses the live handle before it is closed.
- A containerised NHI workload inherits file descriptors from its launcher, allowing unintended access to a management channel that was meant to be transient.
- An API gateway process keeps a TLS session descriptor open long enough for a compromised plugin to duplicate it and issue requests under the gateway’s identity.
- A CI/CD helper opens a token file once and passes the handle across steps, creating an exposure path that survives normal file permission hardening.
For implementation context, pair these patterns with the NHI governance guidance in the Ultimate Guide to NHIs and align process protections with NIST Cybersecurity Framework 2.0 access-control expectations.
Why It Matters in NHI Security
File descriptor theft is important because many NHI compromises are not about cracking a secret from storage, but about capturing a live capability while it is in use. That distinction changes response priorities: revoking the secret after the fact may not help if an attacker already duplicated the descriptor and is operating through an established process context. In service-to-service architectures, this can expose TLS sessions, token files, message queues, or admin sockets that carry elevated authority beyond the visible identity record.
This risk becomes more severe when organisations rely on long-running agents, poorly isolated worker pools, or excessive privilege in service accounts. NHIMG research shows that 97% of NHIs carry excessive privileges, which increases the impact of any stolen live handle. In those environments, descriptor theft is not just a technical curiosity; it is a governance failure in how open handles, rotation, and runtime containment are managed. Teams should treat it as part of a broader Zero Trust and least-privilege review, supported by NIST Cybersecurity Framework 2.0 guidance on access control and protection. Organisations typically encounter this consequence only after a privilege escalation or lateral movement incident, at which point file descriptor theft becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Live handle abuse maps to secret and credential exposure risks in NHI runtime controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control applies to open descriptors and inherited process capabilities. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification even for live process-level access paths. |
Assume open descriptors can be abused and segment workloads so handle reuse is not implicitly trusted.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
