CVE-2026-46333 'ssh-keysign-pwn': the Linux kernel flaw that hid for six years

The Friday phone call

Last Friday several clients pinged us with the same question: "I've read about a critical kernel CVE — are we exposed?". The short answer was yes, pretty much every Linux server in the world is. The good news: the patch is out and rolls in a few minutes. The bad: until it's applied, a local user with no special privileges can quietly read root's SSH keys and /etc/shadow without exploiting anything complicated.

This is the story of CVE-2026-46333, nicknamed "ssh-keysign-pwn" by the researchers who published it. And of why a bug that landed in the kernel back in 2017 sat there for six years in plain sight without anyone raising a hand.

In one sentence

There's a race condition in the kernel's exit path (do_exit). For a narrow window while a privileged process is shutting down, the ptrace checks relax further than they should. A local user can sneak in during that instant with pidfd_getfd(2) and copy file descriptors out of a privileged process — for example ssh-keysign (which opens private SSH host keys) or chage (which opens /etc/shadow).

No root needed. No special capabilities. Just a binary that was already there.

Who's affected

• Distributions hit: Ubuntu, Debian, Arch Linux, CentOS, AlmaLinux, RHEL, CloudLinux, Raspberry Pi OS. Effectively the whole server Linux ecosystem.
• Kernel versions: the race was introduced in Linux v4.10-rc1 (January 2017, commit bfedb589). Every kernel released since carries the crack.
• Who can pull it off: any local user. It's not remotely exploitable on its own, but every scenario with unprivileged SSH users, shared hosting, mis-scoped containers or service accounts sits inside the blast radius.

The detail that makes it particularly ugly: there's a public proof of concept on GitHub from disclosure day. This isn't theoretical.

Why six years without anyone spotting it

Fair question: if the bug landed in 2017, why did it take this long to surface? Three reasons stacked on top of each other:

1. The race window is very tight: you need to coincide with the do_exit of a privileged process. The public PoC needs between 100 and 2000 tries to succeed.
2. The modern exploitation path leans on pidfd_getfd(2), which only joined the kernel in 2020. Before that, the race was there but no public ergonomic primitive existed to abuse it.
3. SUID binaries that open genuinely sensitive secrets (ssh-keysign, chage) are a small, specific list. You have to know the exact targets to know what to ask for.

So: the flaw has been there since 2017, but only practically exploitable since 2020 — and nobody put the pieces together until this month. A good lesson on why kernel auditing is hard even for the right people.

Patched kernel versions per distro

The table below was cross-checked against each distro's official advisory. Numbers may bump as point releases land, but these are the minimum versions where the flaw is closed:

If your server isn't on this list, check your running kernel with uname -r and read your distro's security advisory. Don't trust the "official" version number without checking the package date: some distros keep the version string and only backport the fix.

What you should be doing today

No fluff. This is what we've been running on client boxes these past few days.

1. Update the kernel and reboot

It's the only proper fix. Yes, it needs a reboot (or kpatch/kexec if you have live-patching in place).

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade linux-image-generic
sudo reboot

# RHEL / AlmaLinux / Rocky / CloudLinux
sudo dnf update kernel
sudo reboot

Before rebooting, confirm grub points at the new kernel (grubby --default-kernel on RHEL-family, dpkg --list | grep linux-image on Debian/Ubuntu). Booting back into the old kernel by mistake is annoyingly easy when you're working at 3am.

2. Temporary mitigation if you can't reboot yet

If the box can't take an immediate restart (production with end-user load, maintenance window already past), there are two stopgaps:

Block user-controlled ptrace via sysctl. No reboot needed:

sudo sysctl -w kernel.user_ptrace=0

To persist across reboots:

echo "kernel.user_ptrace=0" | sudo tee /etc/sysctl.d/99-cve-2026-46333.conf

Drop the SUID bit on the sensitive binaries, if you don't use them:

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

Heads up: stripping SUID from ssh-keysign breaks OpenSSH host-based authentication. Check lsattr and your SSH config before you do it.

These mitigations close the vector the public PoC uses. They do not let you skip the patch.

3. Audit past activity

Assume any server with untrusted local users may have been touched between the disclosure date and the patch date. Look at:

• /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL): unusual SSH logins.
• journalctl _COMM=ssh-keysign --since="2026-05-14": executions of ssh-keysign by users who shouldn't be running it.
• auditd if you have it enabled: ptrace or pidfd_getfd calls from unprivileged processes.

If anything looks off, assume compromise and rotate credentials.

4. Rotate SSH keys if you have doubts

On shared, multi-tenant or many-user servers, rotate host SSH keys after applying the patch:

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server   # Debian/Ubuntu
sudo systemctl restart sshd

This invalidates any private-key copies that might have leaked. Clients will see a "host key changed" warning on first reconnect — warn them upfront.

What we did this week

At Atenea Systems we started rolling the patch out on Friday morning, the moment Debian and Ubuntu published signed kernels. Order was the usual one:

1. Servers with external users first: shared hosting, client jails, SFTP-only boxes.
2. Database servers next: a compromise there escalates badly.
3. Dedicated VPS last: usually a single admin user, so the local attack surface is smaller.

As of today every server we manage is either running a patched kernel or, where the reboot window hasn't arrived yet, has kernel.user_ptrace=0 set.

The lesson, again

Once a year a CVE like this lands and the same five gestures repeat:

• Check the kernel version.
• Check when it last rebooted.
• Run apt/dnf update.
• Reboot.
• Verify.

A patching plan isn't something you do "when there's time". It's what separates the servers that survive a bad Friday from the ones that don't. If your current plan is "whenever I remember", let's talk.

References

• Critical Linux Kernel Flaw 'ssh-keysign-pwn' Exposes SSH Keys and Shadow Passwords — Cyber Security News
• CVE-2026-46333 Mitigation and Kernel Update on CloudLinux — CloudLinux Blog