ssh-keysign-pwn (CVE-2026-46333): Linux Kernel Secret Leak

Any Local User Can Read Your SSH Host Keys and /etc/shadow

A six-year-old Linux kernel flaw, now tracked as CVE-2026-46333 and named ssh-keysign-pwn after one of the public exploits, lets an unprivileged local user read root-owned secrets - including SSH host private keys and the /etc/shadow password database - without ever becoming root. Working exploits are public. If you run multi-user Linux hosts, shared CI runners, bastion or jump hosts, or any box where untrusted code can execute as a normal user, treat this as a same-day patch.

The good news: the upstream fix landed before most people heard about the bug, and the immediate mitigation is a single sysctl. The catch: the real fix needs a kernel upgrade and a reboot.

What CVE-2026-46333 Actually Is

The bug lives in the kernel's ptrace access-check path. __ptrace_may_access() skips its "dumpable" check when the target task's mm (its memory descriptor) is NULL. That looks harmless until you follow process teardown. During do_exit(), the kernel calls exit_mm() before exit_files(). For a brief window a dying process has already dropped its mm - so the dumpable check is skipped - but still holds its open file descriptors.

Now add pidfd_getfd(2), the syscall that lets one process pull a file descriptor out of another. An unprivileged process running under the same UID as a setuid-root binary that is in the middle of exiting can call pidfd_getfd() during that window and lift the still-open, root-owned file descriptors straight out of the dying process.

The natural targets are setuid-root binaries that open sensitive root-owned files on their normal path: ssh-keysign, which reads the SSH host private keys, and chage, which reads /etc/shadow. The result is a clean local disclosure of exactly the material an attacker wants for lateral movement.

A "Medium" Score That Understates the Risk

NVD published the record on 2026-05-15 with a CVSS 3.1 base score of 5.5 (Medium), vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, classified CWE-269 (Improper Privilege Management). The score is honest about what it measures: local access required, no integrity or availability impact, confidentiality impact high. NVD still lists the entry as awaiting full analysis, and the score currently comes from the CISA-ADP enrichment.

Ubuntu's security team rates it High priority, and that is the more useful framing for operators. A leaked SSH host private key enables host impersonation and machine-in-the-middle against everyone who connects to that server. A copy of /etc/shadow is an offline cracking job against every account on the box. "Medium, local only" is technically accurate and operationally misleading when the host in question fronts production.

A Six-Year-Old Bug, Patched in a Day

The underlying logic error is not new. A 2020 patch proposal from Jann Horn flagged the same dumpability gap and was never merged. The Qualys research team reported the issue to the kernel security list, and Linus Torvalds merged the upstream fix, commit 31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a, on 2026-05-14, a day before the CVE went public. The fix requires a proper CAP_SYS_PTRACE capability before the access check can be bypassed for tasks without an mm.

This is the latest in a run of Linux kernel local-privilege and local-disclosure issues we have covered in a matter of weeks, after the copy_file_range privilege escalation in CVE-2026-31431 and the Fragnesia kernel LPE in CVE-2026-46300. The pattern is consistent: old code, freshly weaponized, public exploit within days of disclosure.

Are You Exposed

Assume yes if you run a general-purpose distribution kernel and have not rebooted since mid-May 2026. Greg Kroah-Hartman shipped the fix in the stable series 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, and 5.10.256.

Distribution status, from vendor advisories:

• AlmaLinux: 9 and 10 are fully exploitable with the public proof-of-concept code; 8 carries the logic bug but the current exploits are unreliable there. Fixed kernels are kernel-5.14.0-611.54.6.el9_7 (AlmaLinux 9), kernel-6.12.0-124.56.5.el10_1 (AlmaLinux 10), and kernel-4.18.0-553.124.4.el8_10 (AlmaLinux 8, shipped preventively).
• Ubuntu: 22.04 LTS, 24.04 LTS, 25.10, and 26.04 LTS are listed as affected. Check the live status and your exact kernel ABI at ubuntu.com/security/CVE-2026-46333.
• RHEL and Debian track it under the same CVE id; consult the Red Hat and Debian security pages for your minor release.

Mitigation: Do This Now, Patch Right After

Immediate, no reboot, and it blocks the public exploitation paths. Tighten the Yama ptrace policy:

# inspect current value
sysctl kernel.yama.ptrace_scope

# 2 = admin-only attach, 3 = no ptrace attach at all
sysctl -w kernel.yama.ptrace_scope=2

Make it persist across reboots:

echo 'kernel.yama.ptrace_scope = 2' > /etc/sysctl.d/10-ptrace.conf
sysctl --system

Scope 2 restricts ptrace attach to administrators; scope 3 disables it entirely and is the stronger setting if nothing on the host relies on ptrace. Be deliberate: scope 3 breaks debuggers, strace, gdb, crash-dump tooling, and some container and APM agents. Test it where that matters before rolling it fleet-wide. This is containment, not a fix - it blocks the known exploits, not the underlying race.

The actual remediation is a patched kernel and a reboot:

# RHEL / AlmaLinux / Rocky
sudo dnf clean metadata && sudo dnf upgrade && sudo reboot

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade && sudo reboot

A running kernel keeps executing the vulnerable code until you reboot into the new one. dnf upgrade without the reboot is not done.

Bottom Line

Prioritize by what the host protects, not by the Medium label. Any machine whose SSH host key matters - bastions, jump hosts, anything fronting production - and any multi-tenant or shared-runner box where untrusted code runs as a normal user belongs at the top of the list. Apply the ptrace_scope mitigation now, schedule the kernel upgrade and reboot in the same change window, and rotate SSH host keys on any host you cannot rule out as already exposed.

If you want this triaged and patched across a fleet without guesswork, including the host-key rotation most teams skip, our security and compliance and server management teams handle exactly this kind of coordinated kernel response.