Reading Root-Owned Files Without Privilege: What CVE-2026-46333 Reveals About Nine Years of Blind Spot in the Linux Kernel
A race window in the Linux kernel ptrace access control allows, via pidfd_getfd(2), the theft of file descriptors held by SUID root binaries about to terminate. Two public exploits exfiltrate SSH host private keys and the contents of /etc/shadow. A 2017 regression, flagged by Jann Horn in 2020, finally patched on May 14, 2026.
On May 14, 2026, Qualys reported a Linux kernel vulnerability. The same day, Linus Torvalds pushed the fix. A few hours later, the researcher _SiCk published two functional exploits allowing any local user to read SSH host private keys and the root password hash from /etc/shadow. A complete chain, from initial report to public PoC, in less than twenty-four hours, on a flaw that took nine years to be corrected after being publicly flagged by Jann Horn five years earlier.
A complete chain in twenty-four hours
On May 14, 2026, the Qualys research team reported to security@kernel.org a Linux kernel vulnerability affecting the __ptrace_may_access() function. The flaw received the identifier CVE-2026-46333. It allows an unprivileged local user to recover file descriptors held by a SUID root process about to terminate, and through this means to read files normally restricted to root (1)(2).
On the same day, Linus Torvalds pushed the upstream fix as commit 31e62c2ebbfd, titled ptrace: slightly saner ‘get_dumpable()’ logic (3). A few hours after the commit was published, a researcher operating under the handle _SiCk (GitHub account 0xdeadbeefnetwork) published a repository named ssh-keysign-pwn containing two functional exploits. The first, sshkeysign_pwn, exfiltrates SSH host private keys stored in /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key. The second, chage_pwn, exfiltrates the contents of /etc/shadow, enabling offline cracking of the root password hash (4).
At the time of writing, all Linux stable kernels referenced on kernel.org as of May 14, 2026 are vulnerable. The underlying regression was introduced in 2017 by commit bfedb589 in the v4.10-rc1 branch. Kernels predating this branch, in particular the 3.10 series used in RHEL 7 and CloudLinux 7, are not affected.
No in-the-wild exploitation has been reported to date, but two functional public PoCs have been available since May 14, 2026. The official Qualys bulletin, which will constitute the technical reference expected from this team in the lineage of the PwnKit, Sequoia and Looney Tunables LPE write-ups, has not been published yet at the time of writing.
The previous week, on May 7, 2026, the same researcher _SiCk had already published Copy Fail 2: Electric Boogaloo, an n-day exploit built from the upstream fix commit of Dirty Frag (CVE-2026-43284), which had been pushed publicly to netdev/net.git two days before the planned coordinated disclosure date. The production pattern is confirmed: any publicly visible upstream fix commit must now be treated as an active exposure window until binary patches propagate across distributions.
Anatomy of the flaw: skipping the dumpable check
The __ptrace_may_access() function is the kernel gatekeeper that determines whether one process may inspect another process’s state. It is invoked upstream of most introspection mechanisms: ptrace, access to /proc/$pid/mem, and most notably pidfd_getfd(2), a syscall introduced in Linux 5.6 to clone a file descriptor held by another process.
This function performs several checks. One of them, the dumpable check, verifies whether the target process allows the extraction of its memory image. The dumpable flag was originally designed as a property of a process’s memory image. A SUID binary that opens a root-restricted file before dropping its privileges typically sets its dumpable property to zero after the privilege transition, in order to prevent a memory dump from exposing secrets.
The flaw introduced in 2017 lies in an apparently innocuous logical optimization: when the target no longer has a memory descriptor (task->mm == NULL), __ptrace_may_access() simply skips the dumpable check entirely. The original rationale is that kernel threads and processes in the process of exiting have no memory image to protect, and that the check therefore makes no sense for these targets. Linus Torvalds summarizes the flaw in the fix commit message:
The second element of the flaw lies in the execution sequence of do_exit() in the Linux kernel. This function, which drives the termination of a process, releases resources in a specific order: exit_mm() is called before exit_files(). There exists, therefore, in the life of every process terminating normally, a time window during which the memory descriptor has already been released (task->mm == NULL) but the file descriptors opened by the process have not yet been closed (5)(6).
During this window, the dumpable check is skipped, and any process with the same UID as the target can call pidfd_getfd(2) to copy a file descriptor held by the target. The race is TOCTOU. The time window is short but largely sufficient for practical exploitation to succeed. The PoC published by _SiCk achieves a stable success rate within 100 to 2,000 spawns of the target binary, which means a few seconds to a few minutes on a standard machine.
Two primitives published, a broad class of attack
The ssh-keysign-pwn repository provides two independent exploitation binaries, each targeting a classic SUID root binary present on standard Linux distributions (4). Both primitives share the same kernel mechanic but target different sensitive assets.
The sshkeysign_pwn primitive
The first primitive targets ssh-keysign, the OpenSSH helper binary installed by default on most distributions and used in the context of host-based authentication. The binary is SUID root in order to read the machine’s SSH host private keys, stored with mode 0600 in /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key.
The source code of ssh-keysign.c has presented a peculiar execution sequence since 2002. The binary opens the host private key files before calling permanently_set_uid(), then checks whether the EnableSSHKeysign directive is set in sshd_config. If it is not, which is the default behavior on most modern installations, the binary exits immediately, with the file descriptors to the private keys still open. The process then enters its termination phase, triggers do_exit(), and during the mm == NULL window exposes the descriptors pointing to the host keys.
Once these descriptors are recovered via pidfd_getfd(2), the attacker can read the full contents of the private keys to standard output. The operational implications are significant. Possession of an SSH server’s host private keys enables full impersonation of that server in man-in-the-middle attack scenarios, decryption of captured SSH traffic where no forward secrecy mechanism was used, and more broadly the breakdown of the trust chain based on the host fingerprint.
The chage_pwn primitive
The second primitive targets chage, the shadow-utils utility that allows a user to consult or modify their own password aging information. The binary is SUID root in order to open /etc/shadow for reading.
When chage -l <user> is invoked, the binary calls spw_open(O_RDONLY) to open /etc/shadow, then executes setreuid(ruid, ruid) to drop its privileges. The double passing of the same argument (the real UID of the calling user) results in a full drop: uid = euid = suid = ruid. The descriptor pointing to /etc/shadow remains open while the binary prepares its exit. The race window is exploited in the same way as for ssh-keysign, and the attacker recovers the full content of /etc/shadow. The exploitation can be completed offline with a dictionary attack or brute force on the root password hash.
Both primitives illustrate a common class of attack. Any SUID root binary that opens a sensitive file before dropping its privileges, and whose process termination passes through the mm == NULL window with descriptors still open, becomes exploitable via CVE-2026-46333. This class is not limited to ssh-keysign and chage. Reasonable candidates for additional primitives include su, sudo, pkexec, passwd, gpasswd and newgrp, all of which have execution paths that open authentication-related files before dropping privileges. The emergence of additional exploitation primitives in the days following the publication of the fix should be expected.
Impact perimeter and the case of long-term kernels
All Linux stable kernels as of May 14, 2026 are affected, meaning all branches derived from mainline versions post-v4.10-rc1 (January 2017). The regression was introduced by commit bfedb589, whose original purpose was unrelated to the ptrace_may_access() path. The 3.10 kernels maintained in RHEL 7 and its derivatives do not contain the regression and are not exploitable through this path.
The following distributions have been successfully tested against the public exploits: Debian 13, Ubuntu 22.04 LTS, 24.04 LTS and 26.04 LTS, Arch Linux, CentOS Stream 9, Raspberry Pi OS Bookworm (kernel 6.12.75) (4)(7). Extrapolation to all distributions running a kernel post-v4.10 is immediate. Fedora, openSUSE, AlmaLinux, Rocky Linux, RHEL 8, RHEL 9, RHEL 10, Oracle Linux and their derivatives are to be considered affected in the absence of contrary indication in their respective bulletins.
The advisory published by CloudLinux provides a useful distinction between exposure to the underlying flaw and exploitability via the current public PoC (8). This distinction generalizes to other long-term kernel families and should be retained in risk assessments.
CloudLinux 7h and CloudLinux 8 hosts should not be considered definitively protected solely on the grounds that pidfd_getfd(2) is absent from their ABI. The underlying kernel race is present, and alternative exploitation through other paths to access file descriptors of a process in exit remains plausible. The absence of a syscall does not eliminate a class of vulnerability.
Operational environments particularly exposed include shared hosting providers where unprivileged local users have shell access to machines that share the same kernel, bastion hosts and multi-user SSH servers where compromise of the host keys would have a systemic impact on the chain of trust, continuous integration environments where third-party workloads execute with a local UID on persistent runners, and Kubernetes containers without restrictive seccomp profiles where pidfd_getfd(2) is not blocked.
Nine years of regression, five years after the Jann Horn signal
The most instructive temporal gap is not the nine years between the introduction of the faulty commit and its correction, but the five years between the public signaling of the exploitation pattern and the publication of the actual fix.
On October 16, 2020, Jann Horn, researcher at Google Project Zero, published on the lore.kernel.org list a patch proposing to fix a file descriptor theft pattern relying precisely on the skipping of dumpable when mm == NULL (9). The proposal describes the exact mechanic exploited six years later by the public PoCs from _SiCk. The patch was not integrated. No public advisory followed. The flaw remained latent in the kernel for five more years.
This delay raises a structural question that extends beyond CVE-2026-46333 alone. The lore.kernel.org lists and the public patch proposals constitute a substantial documentary record, in which flaws are regularly signaled without systematic follow-up on their actual remediation. AI-assisted audit capabilities, now accessible at low marginal cost, transform this record into a hunting ground for the rediscovery of dormant flaws. The gap between the Jann Horn signal and the Qualys fix concretely illustrates this mechanism.
The hypothesis put forward by Sysdig regarding Dirty Frag, according to which the elapsed time between the introduction of the flaws and their recent discovery would imply the use of AI-assisted analysis tools, is consistent with the ssh-keysign-pwn case. The Mozilla analysis published the same week confirms that this support is now industrialized on the publisher side, with 271 Firefox vulnerabilities identified over two months by Anthropic Mythos. The capability gap between actors with AI-assisted audit infrastructures and those without becomes a structuring factor in the dynamics of discoveries (10).
For CTI teams, this signal deserves to be integrated into prospective exercises. The probability of industrial rediscoveries of historical kernel flaws over the next twelve months is high. The Dirty Frag, Fragnesia, Copy Fail and now ssh-keysign-pwn family forms a cluster whose temporal concentration in May 2026 is probably not a statistical accident but the marker of a scale transition in Linux kernel audit capability.
Mitigations and patch status
Applying the upstream fix 31e62c2ebbfd is the only complete and reliable mitigation (3). Its propagation is taking place through the following channels: mainline on the Linus Torvalds tree since May 14, 2026; AlmaLinux 9 and 10 in testing repositories as of May 15, 2026 with promotion to production scheduled in the short term (11); CloudLinux 9 and 10 using the AlmaLinux kernel and following the same schedule; CloudLinux 8 LTS via its dedicated LTS channel; and Debian and Ubuntu distributions in the process of propagation. For CloudLinux and AlmaLinux environments, KernelCare is preparing a livepatch enabling the application of the fix without reboot.
Immediate mitigation via Yama ptrace_scope
Qualys published on the oss-security list a mitigation through hardening of the Yama module, pending the deployment of patched kernels (12). The mitigation consists of setting the kernel.yama.ptrace_scope sysctl to a restrictive value. Value 3 entirely disables ptrace attachment. Value 2 restricts attachment to administrators only. Both values block the current public PoCs, which rely on the access control of pidfd_getfd(2) transiting through __ptrace_may_access().
Side effect to anticipate: value 3 breaks local debugging tools (gdb attach, strace -p, attach-mode profilers). For development machines, value 2 represents a reasonable compromise. For production servers with no legitimate use of ptrace, value 3 is recommended.
The Yama mitigation is explicitly presented by Qualys as a workaround and not as a fix. Other exploitation paths for the same underlying flaw are theoretically possible and not necessarily covered by this measure. Applying the kernel fix remains the final target, and maintaining the Yama mitigation should be considered temporary while waiting for the full deployment of patched kernels.
Defense in depth via seccomp
For containerized environments, a seccomp profile explicitly blocking the pidfd_getfd(2) syscall neutralizes the public PoCs. This measure is to be considered as defense in depth, and not as an alternative to the kernel fix. For Kubernetes, the RuntimeDefault seccomp profile blocks pidfd_getfd(2) by default on most modern runtimes. Pods deployed without an explicit seccomp profile, or with an Unconfined profile, remain exposed. Verifying seccomp coverage at the cluster level is recommended ahead of deploying the kernel fix.
Auditing and hardening SUID binaries
In addition to direct mitigations, auditing the SUID root binary inventory makes it possible to identify binaries of the vulnerable class. For ssh-keysign specifically, the SUID bit can be removed on hosts that do not use host-based authentication, which is rarely deployed in production. Disabling ssh-keysign does not affect standard SSH functionality (key-based, password-based, or certificate-based authentication); it only impacts deployments that explicitly use host-based authentication.
CERT recommendations and outlook
For CERT, CSIRT and VOC teams, the actions to anticipate fall into three time horizons.
In the short term and immediately, it is appropriate to inventory the Linux kernels in scope, distinguishing branches predating v4.10-rc1 (not affected) from branches post-dating it (potentially affected); to deploy the Yama mitigation ptrace_scope=3 on production servers with no legitimate ptrace usage, and ptrace_scope=2 on development machines; to audit the seccomp profiles of containers and Kubernetes pods, ensuring that pidfd_getfd(2) is blocked by RuntimeDefault or by an explicit profile; to map hosts exposing unprivileged local access to third parties (shared hosting providers, CI runners, multi-user bastions) and to prioritize their remediation; for hosts not using SSH host-based authentication, to remove the SUID bit on ssh-keysign as a hardening measure.
In the short to medium term, it is necessary to follow the publication of kernel updates in official distribution bulletins (USN Ubuntu, DSA Debian, RHSA Red Hat, ALSA AlmaLinux, CLSA CloudLinux, SUSE-SU) and to schedule the associated reboots; to evaluate the opportunity of deploying KernelCare livepatch as an alternative to reboot for CloudLinux and AlmaLinux environments; to anticipate the publication of the official Qualys bulletin, which will likely provide additional elements regarding exploitation variants and implications for SUID binaries beyond ssh-keysign and chage. A second article will follow on the present blog at that occasion.
In the medium term, it is appropriate to reassess the default installation posture of SUID root binaries, by disabling the SUID bit on binaries not strictly necessary for the operational functions of each host; to integrate CVE-2026-46333 into threat hunting scenarios concerning post-initial compromises with unprivileged local access; for critical bastions and SSH servers, to implement periodic rotation of SSH host keys as part of a systematic remediation procedure in case of suspected compromise.
For organizations whose fleet partially relies on end-of-life distributions, the question of the kernel fix arises in specific terms. The options are, in order of sustainability preference: migration to a supported version, subscription to an extended support program (Ubuntu Pro / ESM, Red Hat ELS, KernelCare), or temporary maintenance with Yama and seccomp mitigations pending migration. Maintenance without any extended support and without mitigation is not a sustainable option in the face of a public PoC being distributed and a class of vulnerability whose other variants can reasonably be anticipated.
This article constitutes the first analysis published on this blog regarding CVE-2026-46333. When the official Qualys bulletin is released, a second article will go further into the additional technical elements, in particular the exploitation variants explored by the research team and the implications for SUID binaries other than ssh-keysign and chage. The ssh-keysign-pwn sequence will, in the context of an already dense fortnight (Dirty Frag, Fragnesia, Copy Fail), have constituted an additional marker of the scale transition in the dynamics of Linux kernel discoveries.
