ssh-keysign-pwn Lets Any Linux User Steal SSH Keys and Password Hashes Without Root

ssh-keysign-pwn is a newly disclosed Linux kernel vulnerability that gives any unprivileged local user direct access to the SSH host private keys of a server and every password hash stored on the system. It was reported on May 14, 2026, and a working exploit was on GitHub within hours of the patch landing.

The bug lives in a piece of kernel code called __ptrace_may_access(). This is the security check the kernel runs every time one program wants to look inside another program: reading its memory, accessing its open files. The kernel runs this check and asks: is this target process marked as safe to inspect, and does the caller have the right to do this? If either answer is no, access is denied. That is how it is supposed to work.

The problem shows up during a very specific moment: when a process is shutting down.

When Linux shuts a process down, it works through a fixed list of steps inside a function called do_exit(). First it clears out the memory, through a step called exit_mm(). Then, a bit later, it closes all the open files through exit_files(). A file descriptor is just a numbered ticket the kernel uses to keep track of which files a program has open. There is a real gap between those two steps. Memory is gone first. Files are still open.

Here is where the logic breaks. When __ptrace_may_access() runs its security check and finds that the target process has no memory structure anymore, because exit_mm() already ran, it skips the dumpable check entirely. The kernel was designed to assume that a process with no memory has nothing sensitive left to protect. That assumption is wrong. The files are still open. And those files might point directly to the SSH private keys of the entire server.

What turns this gap into an attack is a system call called pidfd_getfd. A system call is basically a way for a program to ask the kernel to do something for it. pidfd_getfd was built for normal use: managing containers, debugging software, that kind of work. It lets one process reach into another and grab a copy of an open file handle.

The story behind this bug goes back further than most coverage mentions. In 2017, a code change in kernel v4.10 introduced the behavior that makes this attack possible: when a process has no memory map left, the kernel assumes it is safe to inspect. That was done on purpose at the time, to avoid breaking other things. Nobody flagged it as a security problem.

• → 2017: the fail-open behavior lands in kernel v4.10
• → 2020: pidfd_getfd is added to kernel 5.6, giving anyone a standard way to reach into dying processes
• → 2020: a Google Project Zero security researcher named Jann Horn connects the dots, writes a fix, and sends it to the kernel mailing list. It never gets merged.
• → 2026: the fix lands.

The root cause is nine years old. The exploitability was recognized six years ago. The patch that fixed it sat unmerged for five years and seven months.

On May 14, 2026, the Qualys Threat Research Unit reported the vulnerability to the kernel security team. Linus Torvalds pushed the fix the same day, commit 31e62c2ebbfd, touching three files, adding 20 lines, removing 6. Hours after the fix landed, a researcher using the handle _SiCk published two working exploits on GitHub under the name ssh-keysign-pwn, before most distributions had time to prepare packages. The Qualys oss-security disclosure followed at 02:20 UTC on May 15.

Each exploit goes after a different program, but the setup is the same in both cases: the program opens a sensitive file as root, gives up its privileges, and then exits, leaving that file still open during the gap.

The first target is ssh-keysign, a small helper program that ships with every Linux system running OpenSSH. Its job is to sign host authentication challenges using the SSH host private keys during the brief window it needs root access. This is how OpenSSH has worked since 2002. The program opens the key files, does what it needs to do, calls permanently_set_uid() to give up its root access, and if a config check fails, it just exits with those key files still open.

The exploit does not hit this window on the first try. It runs the race over and over, between 100 and 2000 times, until it lands. That sounds like a lot, but on a modern machine it takes seconds. The attacker calls pidfd_getfd during that gap and reads /etc/ssh/ssh_host_ecdsa_key, ssh_host_ed25519_key, and ssh_host_rsa_key.

The second target is chage, a standard Linux tool for managing password expiration. It opens /etc/shadow, the file containing the hashed passwords of every user on the system, as root, then drops privileges using setreuid(ruid, ruid). Same gap, same exploit shape. The attacker steals the file descriptor and reads every password hash on the machine.

Getting those two things is not the same as becoming root on the spot, but what you can do with them afterward is serious. With the SSH host private keys, an attacker can impersonate that server to any client connecting to it via SSH, intercepting session data without the connecting user seeing any warning. With the shadow file, every password hash goes to an offline cracking session at whatever pace and hardware the attacker has available, with no further access to the target system required. Combine both and the result is a persistent, silent position on any network that trusts that server.

There is something about the timeline worth paying attention to if you run a Linux server that other people can log into. The bug has been in the kernel the entire time. There is no way to know from the outside whether anyone was exploiting this privately before the public disclosure on May 14. For servers with shell access open to non-trusted users, the forensically correct thing to do is treat the SSH host keys and the shadow file as potentially compromised, regardless of whether you saw any signs of intrusion.

One thing most coverage is getting wrong: the mitigations from the previous three Linux kernel vulnerabilities this month do not apply here. Copy Fail, Dirty Frag, and Fragnesia were all addressed by blacklisting specific kernel modules: esp4, esp6, algif_aead, and related modules. CVE-2026-46333 uses none of those code paths. It is a completely different bug with a completely different attack route. A server with all three previous mitigations applied is still fully exposed to this one. That makes four separate Linux kernel vulnerabilities in three weeks, each using a different attack method, each needing its own fix. May 2026 has not been a quiet month for Linux.

Check whether your running kernel already includes the fix:

1

uname -r

Patched versions released on May 15, 2026: 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, 5.10.256. If your kernel is not on that list, apply the immediate mitigation. The mitigation tightens a kernel security setting called ptrace_scope, which controls which processes are allowed to inspect other processes. Setting it to 3 blocks every known variant of this exploit:

1
2

sudo sysctl -w kernel.yama.ptrace_scope=3
echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-cve-2026-46333.conf

Setting ptrace_scope to 3 disables debugger attachment entirely. If you need to attach a debugger like gdb or strace to a running process on the same machine, use value 2 instead, which restricts attachment to administrators only and still blocks the known exploits. Either way, this is a workaround. Update the kernel and reboot when the patched version reaches your distribution’s repositories.

If you cannot change ptrace_scope because you have debuggers running on the same machine that need it, there is a third option. You can take away the special permissions from the two programs the exploit targets:

1
2

sudo chmod u-s /usr/libexec/openssh/ssh-keysign
sudo chmod u-s /usr/bin/chage

On Debian and Ubuntu, ssh-keysign sits at /usr/lib/openssh/ssh-keysign instead, so adjust the path if needed. This only blocks the two programs the known exploits use, not the bug itself. One thing to check before you run it: removing the permissions from ssh-keysign breaks host-based SSH authentication if you use that. Most servers do not, but worth knowing.

If your server had shell access open to untrusted users at any point before May 14, rotate the SSH host keys:

1
2
3

rm /etc/ssh/ssh_host_*_key*
ssh-keygen -A
systemctl restart sshd

Users connecting from systems that cached the old host key fingerprint will see a warning after the restart. That is expected. It means the new key is being presented correctly.

Understanding how local vulnerabilities get exploited, how attackers escalate privileges from a regular account to full system access, how they stay hidden after the initial break-in, and how they move through internal networks without being detected is exactly what the course covers from the ground up:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: NVD CVE-2026-46333 | Kernel commit 31e62c2 | Proof of concept