Linux CVE-2026-46333: file descriptor theft turns process teardown into a secrets exposure risk

Red Hat's May 2026 bulletin for CVE-2026-46333 describes a Linux kernel problem that security teams should not dismiss just because it is local. According to Red Hat, a low-privileged local user could exploit the flaw to access sensitive root-owned files during process teardown. The examples Red Hat gives are exactly the kind defenders worry about: SSH host private keys and password hashes from /etc/shadow.

That turns this into more than a technical kernel curiosity. It becomes a secrets exposure event waiting to happen on the wrong kind of system.

Why local still matters

Local vulnerabilities are frequently treated as second-tier because they are not directly internet-triggered. In real operations, that is often the wrong instinct. Attackers regularly obtain low-privileged execution through a stolen account, a compromised web application, a container foothold, a CI job, or administrative tooling that was too widely granted.

Once they have that foothold, a local secrets theft bug can be enough to escalate the incident dramatically. Access to SSH keys, credential material, or privileged files can support lateral movement, persistence, stealthier access, and broader credential compromise.

What Red Hat says is happening

Red Hat explains that the flaw exists in __ptrace_may_access(), where a permission check is skipped after a process's memory is released. During process shutdown, memory is released before files are closed. That creates a short window where an attacker may be able to copy files that a privileged process still has open.

The critical operational point is not memorizing the symbol name. It is understanding the outcome: sensitive file access can happen without the attacker already being root.

Affected environments

Red Hat lists RHEL 8, 9, and 10 as affected, and also warns that products relying on the RHEL kernel may be impacted. That includes layered environments such as RHEL CoreOS, OpenShift Container Platform, OpenStack Platform, and Red Hat Virtualization-related stacks.

That broadens the response significantly. This is not just a classic standalone server problem. It can matter anywhere enterprise Linux kernels underpin higher-value platforms.

The environments that deserve fast triage include:

• bastion and jump hosts
• OpenShift nodes and RHEL CoreOS-backed platforms
• CI/CD runners
• shared developer shell systems
• multi-user application servers
• systems where support teams frequently use debug or attach tooling

Mitigation before the fix lands everywhere

Red Hat is clear that applying the kernel fix is the only comprehensive remediation. Still, the bulletin gives useful short-term guidance. Because current exploitation relies on pidfd_getfd(2), restricting ptrace behavior can block known paths.

Red Hat describes two practical options:

• set ptrace_scope=2 to limit ptrace attach to processes with CAP_SYS_PTRACE
• set ptrace_scope=3 to disable all ptrace attach operations

These mitigations are not free. They can break debugging, monitoring, and development workflows. The more restrictive option can even affect root-based attachment flows and needs careful validation before production rollout.

That tradeoff is important. This is one of those vulnerabilities where mitigation can help, but only if operations understands what it will interrupt.

Exposure reduction beyond ptrace

Red Hat also repeats broader hardening guidance that matters here:

• limit SSH and other direct local access paths
• keep SELinux enforcing
• run workloads as non-root
• restrict oc debug access to trusted administrators
• reduce unnecessary local execution opportunities

These controls will not magically fix the kernel bug, but they reduce the number of identities and workflows that can take advantage of it.

Detection and response questions

Because the bug can expose highly sensitive files, incident response should include questions like:

• which low-privileged users or workloads had local execution on the host?
• was debug access or ptrace-heavy tooling widely available?
• were SSH host keys rotated if compromise is suspected?
• did container or CI systems provide an untrusted local foothold?
• were there unusual attempts to read or access sensitive files?

If a host is believed to have been compromised during the exposure window, defenders should think in terms of secrets theft, not only temporary local abuse.

Why this matters for clusters and platforms

The OpenShift angle is easy to underestimate. A local kernel issue on a cluster node does not stay local for long if workloads, service accounts, or node trust relationships help the attacker move outward. Even when a vulnerability begins as "host local," its business effect can quickly become platform-wide.

That is why kernel advisories on shared infrastructure deserve priority based on blast radius, not just on CVSS language.

Bottom line

CVE-2026-46333 is a practical reminder that local kernel bugs can expose crown-jewel secrets without first becoming classic root RCE headlines. If an attacker can run code locally, reading sensitive privileged files may be enough to reshape the whole incident.

Patch the affected kernel as fixes become available, prioritize shared and platform-critical Linux environments, apply ptrace restrictions where operationally acceptable, and be prepared to rotate sensitive material if compromise is suspected. In this case, the real damage is not only privilege escalation. It is what the attacker can steal on the way there.