Linux kernel fd theft bug exposes SSH keys and shadow files

At a glance

What this is: A Linux kernel race condition can let a local attacker steal privileged file descriptors and expose SSH host keys or /etc/shadow.

Why it matters: It matters because host keys and shadow files sit at the boundary between system trust, workload identity, and privilege escalation risk for Linux estates.

Context

This Linux kernel flaw sits in the trust boundary between a privileged process and the file descriptors it has already opened. The vulnerable behavior appears when process exit narrows the window between memory teardown and descriptor closure, allowing local code execution to duplicate handles that were never meant to survive privilege dropping.

For IAM and infrastructure teams, the concern is not remote exploitation but local trust breakage on Linux hosts that support SSH, shared workloads, developer access, or CI runners. When privileged file access can be copied out of an exit path, host identity, password storage, and administrative trust all become reachable from a single local foothold.

Key questions

Q: What breaks when a Linux kernel file descriptor race is exploitable locally?

A: The break is in the kernel's exit-time trust boundary. A local attacker can race process teardown, duplicate file descriptors from a privileged process, and turn an allowed file open into unauthorised access to SSH host keys or /etc/shadow. That is a lifecycle failure, not a simple permission issue.

Q: Why does this kind of Linux bug create host impersonation risk?

A: Because SSH host private keys are identity material for the server itself. If an attacker steals them from a privileged file descriptor, they may impersonate the host in SSH trust relationships, weakening authentication and enabling broader lateral movement or session interception.

Q: How should teams decide which Linux systems to patch first?

A: Patch systems where local compromise would be most damaging first: shared servers, developer workstations, CI runners, and cloud workloads that can reach privileged files. The decision should reflect exposure context, not just kernel version, because the exploit's impact depends on what the host stores and who can reach it.

Q: What should security teams do when /etc/shadow exposure is possible?

A: Treat it as a privilege-escalation precursor, not only a file disclosure event. Rotate or review local credentials where needed, look for suspicious access to shadow data, and confirm that the vulnerable kernel branch has been removed from all reachable systems before assuming the environment is safe.

Technical breakdown

How pidfd_getfd() turns a process exit race into file theft

The core issue is a race in the Linux kernel's access-control path around __ptrace_may_access(). If the target task has already lost its mm pointer during exit, the dumpability check can be skipped at the wrong moment. That matters because pidfd_getfd() can then duplicate file descriptors from a privileged process before its open files are fully closed. In practice, this is not about reading memory directly. It is about stealing an already-open handle to a sensitive object after the process has crossed a lifecycle boundary but before the kernel has finished cleaning it up.

Practical implication: patch the kernel first, because the failure is in the kernel lifecycle path rather than in user-space permissions.

Why SSH host private keys and /etc/shadow are exposed

The exploit value comes from what privileged helpers tend to open before dropping rights or exiting. If a setuid-root helper or similar process opens SSH host private keys or /etc/shadow, those file descriptors can become a theft target during the exit window. SSH host private keys can let an attacker impersonate a host in trust relationships, while /etc/shadow can support offline password cracking. The risk is therefore not just disclosure. It is trust substitution, credential recovery, and downstream privilege escalation from a local foothold.

Practical implication: reduce local execution paths on sensitive Linux hosts and treat privileged file exposure as a host identity incident, not only a confidentiality issue.

Why affected Linux estates need workload context, not just version checks

Versioning alone tells you whether the fix is present, but not whether the asset is an attractive target. Developer workstations, multi-user servers, CI runners, and cloud workloads all change the likelihood that a local foothold can be achieved and converted into sensitive file theft. Kernel-level exposure also means compensating controls are limited. Monitoring for attempts to access SSH host key material and shadow password data helps, but it does not replace remediation. The architecture lesson is that privileged file descriptors must be treated as high-value identity assets for the full duration of their lifecycle.

Practical implication: pair kernel inventory with workload criticality so remediation prioritises the hosts where local compromise would create the largest blast radius.

Threat narrative

Attacker objective: Steal privileged file descriptors that expose host keys or password material and then turn local access into broader trust and privilege compromise.

1. Entry occurs through local code execution on an affected Linux host, not through a remote unauthenticated request.
2. Escalation happens when the attacker races process exit and uses pidfd_getfd() to duplicate privileged file descriptors before closure.
3. Impact follows when stolen descriptors expose SSH host keys or /etc/shadow, enabling host impersonation and offline password cracking.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kernel-level file descriptor theft creates identity exposure, not just memory disclosure. The important shift here is that the attacker is not reading arbitrary bytes from RAM. They are stealing already-authorised access to identity-bearing files that were opened inside a privileged execution path. That means the trust boundary is defined by descriptor lifecycle, not by static file permissions alone. For practitioners, the lesson is to treat privileged file handles as governed identity assets for as long as they remain open.

Standing assumptions about exit-time cleanup fail when privileged processes outlive their own privilege context. __ptrace_may_access() was designed for a world where access checks and object teardown stay aligned. That assumption fails when a task drops its memory descriptor before file descriptors are closed, because the kernel state no longer reflects the original privilege boundary. The implication is that host security cannot rely on exit sequencing behaving like a clean revocation event.

SSH host keys are workload identity material, not just secrets. A stolen host private key can let an attacker impersonate a trusted Linux system, which turns a kernel flaw into a trust-chain problem across orchestration, SSH, and administrative access. That is why this issue belongs in both NHI and infrastructure governance conversations. Practitioners should assess where host identity material lives, who can reach it locally, and which workloads create the highest impersonation risk.

Shadow file exposure is a credential governance failure mode, not merely a file-read bug. Access to /etc/shadow opens the door to offline password cracking and follow-on privilege escalation after initial local compromise. The control gap is not limited to patch latency. It is the absence of a lifecycle view of privileged data paths on Linux hosts. Teams that govern only authentication at login miss the file-level asset that makes escalation possible.

High-risk Linux exposure is determined by exploitability context, not kernel version alone. The article's own examples show why multi-user systems, developer workstations, CI runners, and cloud workloads deserve different urgency even when they run the same vulnerable kernel branch. That is a governance problem because remediation priority must reflect blast radius, not just CVE style scoring. Practitioners should rank hosts by the privilege value of the files their local workloads can reach.

What this signals

Host file descriptors deserve the same governance attention as other privileged identity assets. This flaw shows that a Linux host can leak trust material even when the underlying files are protected by strong permissions. Programs that only track who can open the file miss the more important question of who can inherit or duplicate the handle during privilege transition.

The more sensitive the workload, the less useful generic patch guidance becomes. Security teams should combine kernel inventory with workload criticality, local access exposure, and the presence of SSH identity material so the first remediation wave lands where a stolen descriptor would hurt most.

For practitioners

• Patch the kernel to the fixed commit or vendor backport Move affected Linux systems onto a kernel build that includes the upstream fix or an equivalent distribution backport, and verify the fix on every deployed image and running host.
• Reduce local shell reach on sensitive hosts Limit who can obtain local execution on servers that hold SSH host keys, password files, or privileged helper processes, especially shared systems and CI runners.
• Harden privileged helper workflows Review setuid-root or similar helpers that open sensitive files before privilege changes, and remove unnecessary access to SSH host key material and shadow data.
• Monitor for access attempts to host key and shadow data Alert on suspicious reads, duplicates, or process interactions involving /etc/ssh/ssh_host_* and /etc/shadow so local exploitation attempts are visible during triage.
• Prioritise exposure by workload criticality Rank remediation by whether the affected asset is internet reachable, multi-user, a developer endpoint, a CI runner, or a workload that stores privileged identity material.

Key takeaways

• This Linux kernel flaw converts a narrow exit race into a path for stealing privileged file descriptors from local code execution.
• The exposure matters because SSH host keys and /etc/shadow can support host impersonation, offline password cracking, and privilege escalation.
• Patch the affected kernel branch first, then reduce local execution on sensitive hosts and prioritise assets by workload criticality.

Key terms

• File Descriptor Theft: 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.
• Host Identity Material: Files and keys that let systems prove who they are, such as SSH host private keys. If these are exposed, the risk extends beyond file access because attackers can impersonate the host, weaken trust relationships, and trigger downstream authentication failures.
• Privilege transition: A change in access state that increases what an identity can do, such as becoming a group member, receiving delegated admin rights, or activating elevated permissions. Tracking these transitions is essential because abuse often appears at the moment access expands, not at initial login.
• Shadow File Exposure: Exposure of /etc/shadow or similar password-hash stores to an attacker who should not see them. Even without immediate login credentials, the data can support offline cracking and become a stepping stone to broader privilege escalation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.