ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

ssh-keysign-pwn refers to a set of exploitation paths around a logic flaw in Linux kernel __ptrace_may_access(), assigned CVE-2026-46333. It is not a remote unauthenticated flaw and it does not directly hand out a root shell, but the risk is still high: a low-privileged local user may read root-owned sensitive files that should be inaccessible, such as SSH host private keys or /etc/shadow.

For operations teams, the priority is not reproducing a PoC. The priority is to identify affected machines, upgrade the kernel, reboot into the fixed kernel, and rotate SSH host keys or reset passwords when necessary.

Bottom line

This vulnerability deserves high handling priority for four reasons:

It can be triggered by a low-privileged local user and does not require root.
Public PoC code is available, lowering the exploitation barrier.
The potential targets are not ordinary files, but SSH host private keys and /etc/shadow.
The fix requires a kernel patch and reboot; installing packages without rebooting is not enough.

If your servers have multiple users, local shell access, shared hosting, CI runners, container hosts, student lab machines, bastion hosts, or any local users you do not fully trust, handle this first.

What the vulnerability is

Qualys disclosed details on oss-security on May 15, 2026. They had previously reported a Linux kernel __ptrace_may_access() logic issue to security@kernel.org, and the upstream fix had already been merged by Linus. Public exploit code then appeared, so Qualys posted the details to oss-security.

The Linux kernel CVE team later assigned CVE-2026-46333. The NVD page lists kernel.org as the source, and the description maps to the kernel commit ptrace: slightly saner 'get_dumpable()' logic.

In simple terms, the bug sits in a process exit path. When some privileged processes are exiting, ptrace-related access-check logic in the kernel may bypass a dumpable check that should have applied because the target task no longer has an mm. An attacker can race a very narrow timing window and obtain file descriptors that the exiting privileged process still has open.

That is why the issue is called ssh-keysign-pwn: one public exploitation path uses ssh-keysign to read SSH host private keys.

Why SSH host private keys and /etc/shadow may be exposed

At its core, this is a local information disclosure issue. It abuses a window during privileged process exit where the memory descriptor is gone, but file descriptors have not yet been closed.

The AlmaLinux advisory explains the risk clearly: if a privileged program opened sensitive files before dropping privileges, and an attacker successfully grabs the corresponding file descriptor during the exit window, those sensitive files may become readable.

Two commonly discussed targets are:

ssh-keysign: may involve SSH host private keys such as /etc/ssh/ssh_host_*_key.
chage: may involve /etc/shadow.

If SSH host private keys leak, an attacker may impersonate the host and undermine SSH host identity trust. If /etc/shadow leaks, an attacker can crack password hashes offline and expand the compromise later.

That is why this should be treated as high priority even though it is not a “direct root shell” bug.

How to assess exposure

From the upstream perspective, this is a Linux kernel vulnerability. NVD records show the issue entered the NVD dataset on May 15, 2026, with no CVSS score assigned at that time.

Distribution status should be checked against each vendor’s own advisory:

AlmaLinux 8, 9, and 10 published guidance and updated it on May 16, 2026 to say patched kernels had reached production repositories.
Debian Security Tracker lists vulnerable and fixed states, plus fixed versions, for bullseye, bookworm, trixie, sid, and other branches.
For other distributions, check the official security pages or repositories for Ubuntu, Red Hat, SUSE, Arch, Alpine, and so on.

Do not judge safety only by the upstream kernel version. Distributions backport fixes, so the same upstream-looking version number may mean different patch states across distributions.

Which machines to prioritize

Prioritize remediation in this order:

Multi-user servers and shared hosts.
Bastion hosts, teaching machines, development machines, and other systems with normal shell accounts.
CI runners, build machines, and hosting platform nodes.
Container and virtualization hosts, especially where not-fully-trusted workloads coexist.
Public service machines. The vulnerability needs local access, but the risk compounds once a web bug, RCE, weak password, or similar path gives an attacker a low-privileged foothold.

Pure single-user desktop systems are lower risk, but they should still be updated. Local low-privileged code execution is common on desktops through browsers, developer tools, scripts, and third-party software.

Remediation guidance

The preferred fix is to install the fixed kernel supplied by your distribution and reboot.

Commands differ by distribution, but the principle is the same:

Refresh package metadata.
Install the kernel package containing the CVE-2026-46333 fix.
Reboot into the new kernel.
Use uname -r and the distribution security advisory to verify the running kernel is fixed.

The AlmaLinux advisory says fixed kernels are available in production repositories and users can run the usual dnf upgrade and reboot. The Debian tracker also lists fixed versions for multiple branches.

Important: if you only install a new kernel package but do not reboot, the old vulnerable kernel is still running.

Temporary mitigation: tighten ptrace_scope

If you cannot reboot immediately, tighten Yama ptrace_scope first.

Qualys confirmed in a follow-up oss-security reply that setting /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only attach) or 3 (no attach) blocks the public exploitation paths they know about. They also noted that other theoretical exploitation paths may exist, so this is only a mitigation, not a fix.

Temporary setting:

1

sudo sysctl -w kernel.yama.ptrace_scope=3

Persistent setting:

1

echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf

ptrace_scope=3 disables ptrace attach and may affect debugging workflows such as gdb and strace -p. If production debugging is required, evaluate 2. Either way, schedule the kernel upgrade and reboot as soon as possible.

Should SSH host keys be rotated?

Use a conservative approach if the machine had any of the following conditions around the disclosure window:

Untrusted local users.
Shared hosting or container/CI multi-tenant environments.
Web vulnerabilities, weak passwords, supply-chain scripts, or other paths that could give an attacker a local foothold.
Suspicious local processes, unusual debugging behavior, or public PoC files in logs.
Long exposure before patching.

Conservative handling includes:

Rotate SSH host keys after patching and rebooting.
Update known-host fingerprint management systems.
Notify automation that depends on the host fingerprint.
Review SSH connection alerts so legitimate fingerprint changes are not mistaken for man-in-the-middle attacks, and real risks are not ignored.

If /etc/shadow may have leaked, also evaluate password resets, weak-password bans, and whether old hashes could be cracked offline.

What to monitor

The exploitation window is short, so traditional logs may not capture everything. Still, watch for:

Files such as ssh-keysign-pwn, chage_pwn, or similar PoC artifacts in normal user directories.
Suspicious compilation activity, such as unfamiliar C programs compiled in a short window.
Signs of abnormal access to /etc/ssh/ssh_host_*_key or /etc/shadow.
Unusual pidfd_getfd, ptrace, or debugger-related activity.
External reports of unexpected SSH host fingerprint changes.

These signals cannot prove exploitation occurred, and their absence cannot prove it did not. The real priorities remain patching, rebooting, credential rotation, and risk isolation.

Common misconceptions

First: this is not an OpenSSH remote vulnerability. The name includes ssh-keysign, but the root cause is Linux kernel ptrace access-check logic, not the remote authentication path in sshd.

Second: no local users does not mean no risk. The bug does require local execution, but real attack chains often obtain a low-privileged local foothold first through web services, CI, scripts, weak passwords, or container escape paths.

Third: setting ptrace_scope is not enough. It is a temporary mitigation, not the root fix. Kernel update and reboot are still required.

Fourth: “no root shell” does not mean “no incident.” Exposure of SSH host private keys or /etc/shadow can be enough to enable lateral movement, host impersonation, and offline password cracking.

Response checklist

Suggested order:

Inventory affected Linux hosts, especially multi-user and shared environments.
Check distribution security advisories and identify the fixed kernel version.
Install the fixed kernel and reboot.
For machines that cannot reboot immediately, set kernel.yama.ptrace_scope=2 or 3.
After remediation, verify the running kernel version.
Rotate SSH host keys on high-risk machines.
If /etc/shadow exposure is suspected, evaluate password resets and account audits.
Check for public PoCs, unusual compilation, and suspicious local debugging behavior.

Summary

ssh-keysign-pwn (CVE-2026-46333) is a local information disclosure vulnerability rooted in Linux kernel __ptrace_may_access() logic. It does not allow a remote attacker to break in directly and it does not directly grant a root shell, but it may let a low-privileged local user read high-value sensitive files, making it especially important in multi-user, shared hosting, CI, and container-host environments.

The reliable fix is to upgrade to a distribution-provided fixed kernel and reboot. ptrace_scope=2/3 can be used as a temporary mitigation, but it does not replace patching. Critical hosts exposed during the risk window should also be evaluated for SSH host key rotation and password risk.

References: