A newly disclosed Linux kernel vulnerability has raised alarms among system administrators, hosting providers and security teams. The flaw, identified as CVE-2026-46333 and nicknamed “ssh-keysign-pwn” by one of the public exploits, allows an unprivileged local user to read root-owned files under certain conditions. Among the most sensitive targets are SSH host private keys and /etc/shadow, the file where Linux systems store password hashes.
This is not a direct privilege escalation to root in the classic sense. It does not immediately grant an administrative shell by itself. But in many real-world environments, that distinction is almost academic: if an attacker can read SSH private keys or password hashes, they may move towards server impersonation, offline cracking, lateral movement or compromise of other systems. The risk is especially serious in shared infrastructure, multi-user servers, hosting environments and machines where third parties can run local code.
NVD published the CVE-2026-46333 entry on May 15, 2026, although at the time of review it had not yet assigned a CVSS score. The official description comes from kernel.org and points to a change in the get_dumpable() logic inside the ptrace subsystem. The fix landed in the mainline kernel on May 14, 2026 through commit 31e62c2ebbfd, according to AlmaLinux, Red Hat and other security advisories.
A ptrace race with uncomfortable consequences
The vulnerability lies in the __ptrace_may_access() function, which the kernel uses to decide whether one process may inspect or interact with another. ptrace is a highly sensitive part of the system: it is used by debuggers, diagnostic tools and tracing utilities, but it can also become dangerous if permission checks fail.
The bug appears during process exit. At that stage, the kernel releases the process memory context (mm) before cleaning up its file descriptor table. For a very short window, the process no longer has an associated memory context, but it still holds open files. According to the technical descriptions published by AlmaLinux and Red Hat, __ptrace_may_access() skips a “dumpability” check when task->mm is NULL. That logic allows an unprivileged process to capture file descriptors opened by a privileged process that is shutting down.
The mechanism that makes the attack practical is pidfd_getfd(2), an interface that allows a process to duplicate another process’s file descriptors under certain conditions. On a vulnerable system, a local attacker can try to win that race against privileged binaries that open sensitive files during normal execution. The most cited examples are ssh-keysign, which can access SSH host private keys, and chage, which interacts with password-related information.
The consequence is clear: the attacker does not need to directly break file permissions. It is enough to copy a descriptor opened by a process that legitimately had permission to read the file. This becomes an information leak that breaks a basic system expectation: that a root-owned file cannot be read by an unprivileged user.
The case is even more striking because the general class of issue was not entirely unknown. Red Hat notes that Jann Horn had already pointed out a similar class of file descriptor theft in October 2020. The current fix aims to make the use of “dumpability” more consistent when a process no longer has an associated memory context.
Why servers are especially exposed
Exploitation requires local presence. This means an attacker needs to run code on the vulnerable system, even from an unprivileged account. On a single-user personal machine, the impact will depend heavily on context. On shared servers, hosting platforms, SSH bastions, multi-user development environments or systems where third parties can execute processes, the scenario changes completely.
Reading SSH host private keys may enable impersonation attacks if those keys are not rotated after the incident. An attacker who obtains a server’s private key could impersonate that machine to clients that already trust its fingerprint, at least until the keys are replaced and known host fingerprints are updated. This may enable man-in-the-middle attacks in poorly controlled networks or more targeted campaigns against administrators.
Access to /etc/shadow should not be underestimated either. The file does not contain plaintext passwords, but it does contain hashes. If passwords are weak or reused, an attacker can attempt offline cracking without generating further noise on the server. Once a valid password is recovered, moving to other systems becomes much easier, especially in organisations where credentials are reused or multi-factor authentication is not enforced everywhere.
CloudLinux has described the flaw as a race in the kernel exit path and warns that a public proof of concept exists. It also explains that not all older kernels are equally exploitable with the current PoC, because exploitation depends on the availability of pidfd_getfd(2). Even so, the underlying logic bug may still exist in branches that would require different adaptations to exploit. That is why several vendors are preparing or publishing fixes even for versions where the public exploit does not work directly.
AlmaLinux has confirmed patched kernels for its affected branches and notes that a kernel update followed by a reboot also applies recent fixes for other kernel vulnerabilities. Debian has also added CVE-2026-46333 to its security tracker, and NVD already links several kernel.org commits for different stable branches.
What administrators should do
The main measure is to update the kernel as soon as the relevant distribution publishes a patch and reboot the system, unless a reliable live-patching solution explicitly covers CVE-2026-46333. Updating user-space packages is not enough: the flaw is in the kernel.
On critical systems, administrators should also review whether there are untrusted local users, old accounts, third-party access, shared environments or processes that allow code execution on the machine. With this kind of vulnerability, reducing local attack surface matters almost as much as applying the patch.
If there is a reasonable suspicion of exploitation, the response should go beyond updating. SSH host private keys on affected servers should be rotated, especially on exposed systems, bastions, administration nodes and machines with many users. Known fingerprints, automation, key inventories and access logs should also be reviewed. In the case of /etc/shadow, exposure may justify changing local account passwords and auditing authentication policies.
Some temporary mitigations involve hardening ptrace or disabling unprivileged user namespaces, but these are not substitutes for the patch. LWN notes that kernel.yama.ptrace_scope = 2 may not be enough in some scenarios if user namespaces remain enabled, while stricter options may break legitimate debugging workflows. Each environment therefore needs to be assessed carefully.
The lesson for system teams is familiar, but once again urgent: local kernel flaws are not minor. In cloud infrastructure, multi-user environments and shared servers, a local vulnerability can become a secret-leakage issue with broad consequences. SSH keys, password hashes and file descriptors opened by privileged processes are too valuable to assume that an unprivileged user cannot cause serious damage.
ssh-keysign-pwn is not just another CVE in a week full of patches. It is a reminder that Linux’s internal isolation depends on very fine kernel details. When one of those details fails, the gap between “unprivileged local user” and “access to root-owned secrets” can shrink to a race measured in milliseconds.
Frequently asked questions
What is CVE-2026-46333?
It is a Linux kernel vulnerability in the ptrace access logic. Under certain conditions, it allows an unprivileged local user to read root-owned files.
Why is it called ssh-keysign-pwn?
The nickname comes from one of the public exploits, which targets ssh-keysign to attempt to read SSH host private keys.
Is this a direct root escalation?
Not exactly. The flaw allows attackers to read protected secrets, such as SSH keys or /etc/shadow. That can later lead to account compromise, impersonation or lateral movement.
What is the recommended fix?
Update the kernel with the patches released by the distribution and reboot. If exposure is suspected, SSH keys should also be rotated and local passwords reviewed.