Linux kernel flaw “ssh-keysign-pwn” can expose SSH keys and shadow passwords

A newly disclosed Linux kernel vulnerability can let a low-privileged local user read sensitive root-owned files, including SSH host private keys and password hashes stored in /etc/shadow.

The flaw is tracked as CVE-2026-46333 and is widely known as “ssh-keysign-pwn,” after one of the public proof-of-concept exploits. It affects the kernel’s ptrace access-control logic during a short process shutdown window.

The vulnerability does not directly give attackers a root shell. However, the ability to read SSH host keys or password hashes can still create serious follow-on risk, especially on shared servers, hosting environments, and systems with local user access.

What CVE-2026-46333 does

CVE-2026-46333 affects the Linux kernel’s permission checks during process teardown. When a privileged process exits, the kernel releases its memory context before it closes all open file descriptors.

During that brief gap, the vulnerable ptrace access path can allow a local attacker to copy open file descriptors from the exiting privileged process. If that process opened a root-owned file, the attacker may gain a readable handle to it.

Public examples target ssh-keysign and chage. The ssh-keysign path can expose OpenSSH host private keys, while the chage path can expose /etc/shadow, which stores local password hashes.

Item	Details
CVE	CVE-2026-46333
Nickname	ssh-keysign-pwn
Bug class	Local information disclosure through process exit race
Affected component	Linux kernel ptrace access-control logic
Main impact	Read access to sensitive root-owned files opened by privileged programs
Public PoC	Available

Why SSH keys and /etc/shadow matter

OpenSSH host private keys identify a server to SSH clients. If attackers steal them, they may be able to support on-path attacks until administrators rotate the affected host keys.

The /etc/shadow file contains hashed local passwords. Attackers still need to crack those hashes before gaining plain-text passwords, but exposure gives them a starting point for offline attacks.

The risk grows when administrators reuse passwords or when host keys support automation, legacy trust relationships, or host-based authentication. In those cases, one exposed machine can create a wider security problem.

How the race condition works

The issue sits in __ptrace_may_access(), a kernel function that helps decide whether one process can inspect or interact with another process.

During normal shutdown, a process can briefly have no memory context while still holding open file descriptors. The vulnerable logic can skip an important dumpability check in this state.

Attackers can race that exit window and use pidfd_getfd to copy file descriptors from a privileged process. The known PoCs focus on privileged utilities that open sensitive files as part of normal behavior.

Which systems are affected?

Several Linux vendors have issued advisories or mitigation guidance. Ubuntu says its listed supported and extended releases are affected, while Red Hat says Red Hat Enterprise Linux 8, 9, and 10 are affected.

AlmaLinux confirmed that AlmaLinux 9 and 10 were vulnerable to the public exploits and shipped patched kernels. AlmaLinux also patched AlmaLinux 8 because the underlying logic bug exists there, even though the current public PoCs did not work reliably on that line.

CloudLinux said CloudLinux 8 LTS, 9, and 10 were affected by the public PoC, while CloudLinux 7 was not affected because its kernel predates the regression.

Vendor or platform	Status from vendor or public testing
Ubuntu	Multiple releases listed as affected, including 22.04 LTS, 24.04 LTS, and 26.04 LTS
Red Hat Enterprise Linux	RHEL 8, 9, and 10 listed as affected
AlmaLinux	AlmaLinux 9 and 10 vulnerable to public PoCs, with AlmaLinux 8 also patched
CloudLinux	CloudLinux 8 LTS, 9, and 10 affected by current public PoC
Public PoC testing	Reported against Ubuntu, Debian, Arch, CentOS 9, and Raspberry Pi OS Bookworm

Patch status and available mitigations

The upstream Linux fix landed on May 14, 2026, in commit 31e62c2ebbfd. Linux distributions are now shipping the fix through their normal kernel update channels.

Administrators should install the patched kernel package from their distribution and reboot into the updated kernel. Live patching may also be available in some enterprise environments.

Where a kernel update cannot happen immediately, vendors recommend tightening ptrace restrictions. Setting kernel.yama.ptrace_scope to 2 limits ptrace attach to users with CAP_SYS_PTRACE, while setting it to 3 disables ptrace attach more broadly.

• Apply the latest kernel update from the Linux distribution vendor.
• Reboot into the patched kernel after installation.
• Use a trusted livepatch if the environment supports it.
• Temporarily restrict ptrace access if patching cannot happen right away.
• Review any workflows that rely on gdb, strace, or similar debugging tools before changing ptrace settings.

What administrators should do now

Security teams should treat this flaw as urgent on multi-user systems, shared hosting servers, developer workstations, and systems where untrusted users can run local commands.

The vulnerability requires local access, so internet-facing exposure alone does not mean attackers can exploit it directly. The risk increases if attackers already have a low-privileged shell through another vulnerability, stolen credentials, or a compromised account.

If administrators suspect exploitation, they should rotate SSH host keys and review authentication logs. They should also assess whether exposed password hashes could lead to account compromise.

1. Identify all Linux systems that allow local user access.
2. Patch and reboot the highest-risk servers first.
3. Apply ptrace restrictions as a temporary mitigation where appropriate.
4. Check whether SSH host keys may have been exposed.
5. Rotate exposed or high-risk SSH host keys.
6. Review /etc/shadow exposure risk and enforce strong password policies.
7. Monitor for suspicious local process inspection activity.

Why this flaw is important even without root access

Many Linux security incidents depend on chaining several weaknesses together. A local information disclosure bug can become more damaging when combined with malware, weak passwords, reused credentials, or exposed developer accounts.

Stealing SSH host keys can also undermine trust in server identity. If clients trust those keys, attackers may have a stronger path for impersonation or on-path attacks until the keys change.

The safest approach is to patch quickly, reduce local attack surface, and treat any sensitive data that may have been exposed as potentially compromised.

FAQ