#Three kernel root exploits in six weeks. This is getting routine.

First it was CopyFail — a 732-byte exploit that gave any user root on every major Linux distro. Then Dirty Frag dropped a week later with the same impact through the networking stack. I wrote both of those up and told you to patch. If you did, good. Now do it again.

CVE-2026-46333, colloquially called "CopyFail 3" (the researchers who found it call it "ssh-keysign-pwn"), is a local privilege escalation vulnerability in the Linux kernel's ptrace subsystem. Disclosed May 21, 2026. Working proof-of-concept exploits are publicly circulating. Secondary severity estimates put it at CVSS 7.1-7.8.

This one is different from the first two CopyFail vulnerabilities in a way that makes it worse: it doesn't just get you root. It steals credentials on the way there.

#How it works (without the jargon).

Every Linux system has programs that temporarily run with elevated privileges. When you change your password, when SSH verifies a key, when PolicyKit checks whether you're allowed to do something — these programs briefly run as root, do what they need to do, and then drop back down to normal privileges.

The bug is in the kernel function that decides whether one process is allowed to inspect another. It's called __ptrace_may_access(), and it has a timing flaw. There's a brief window — fractions of a second — during which a privileged program is in the process of dropping its elevated credentials, but the kernel still thinks it has them. The old credentials haven't been cleared yet.

An attacker who catches that window can use a Linux system call called pidfd_getfd() to grab file descriptors that the privileged process was about to close. Those file descriptors can point to files like /etc/shadow (where password hashes are stored) or SSH host private keys.

Four setUID-root binaries that ship on default Linux installations serve as reliable targets: chage, ssh-keysign, pkexec, and accounts-daemon. The attacker doesn't need to find the right moment manually. The exploit runs in a tight loop until it catches the race. On modern hardware, it wins within seconds.

The result: root access and a copy of your password hashes and SSH keys, without writing anything suspicious to disk.

#Why the credential theft part matters.

CopyFail 1 and Dirty Frag gave attackers root on the box they exploited. That's bad, but the damage is contained to that server. You patch it, you rotate credentials, you move on.

CopyFail 3 gives attackers your /etc/shadow file and your SSH host keys. That means:

• Password reuse becomes catastrophic. If anyone on that server reuses their password anywhere else (and they do — you know they do), the attacker now has hashes they can crack offline. No rate limiting, no lockout policies, no alerts. Just a GPU cluster and time.
• SSH trust is compromised. If the attacker has your SSH host private keys, they can impersonate your server. Man-in-the-middle attacks. Credential harvesting from anyone who connects. And because SSH host key verification is something most people click through without reading, they won't notice.
• No forensic trace. The exploit reads file descriptors. It doesn't open files, doesn't write to disk, doesn't create new processes that would show up in logs. If you're not specifically monitoring for anomalous ptrace activity, you won't know it happened.

This has been exploitable on any distro shipping kernels since v4.10, which came out in November 2016. That's nearly ten years of affected kernels. Confirmed vulnerable: Debian 13, Ubuntu 24.04 and 26.04, Fedora 43 and 44 default installs. If you're running Linux, assume you're affected.

#What to do.

1. Patch your kernels. Vendor updates are available. Same process as the last two times:

`

#Ubuntu/Debian

sudo apt update && sudo apt upgrade linux-image-$(uname -r)

#RHEL/CentOS/Rocky/Alma

sudo dnf update kernel

#Then reboot

sudo reboot

`

2. If you can't patch immediately, set the ptrace scope to admin-only:

`

#Block all non-admin ptrace attach (stops all known public exploits)

echo "kernel.yama.ptrace_scope=2" | sudo tee -a /etc/sysctl.d/99-ptrace-restrict.conf

sudo sysctl -w kernel.yama.ptrace_scope=2

`

This restricts ptrace to processes running as root. It blocks every known public exploit for this vulnerability. Some debugging tools (strace, gdb) will stop working for non-root users. That's a trade-off worth making right now.

3. Rotate credentials on any unpatched server. Because this vulnerability exfiltrates /etc/shadow hashes and SSH host keys, patching alone isn't enough if the server was already compromised. After patching:

• Force password changes for all local accounts
• Regenerate SSH host keys (sudo ssh-keygen -A and restart sshd)
• Update any known_hosts files that reference the server

4. Audit for password reuse. If any user on an affected server uses the same password for other systems, email, cloud dashboards, anything — those credentials should be considered compromised. This is a good time to enforce unique passwords and push your team toward a password manager if you haven't already.

5. Monitor for ptrace abuse. If you're running Falco, Wazuh, or auditd, add rules for anomalous ptrace calls targeting setUID binaries. If you're not running any of those, this is the third time in six weeks I've told you to set up runtime monitoring. The pattern is clear: kernel exploits are coming faster than patches, and detection is your safety net when patching falls behind.

#The bigger picture.

Three privilege escalation vulnerabilities in the same general family in six weeks. CopyFail in the crypto subsystem, Dirty Frag in the networking stack, CopyFail 3 in ptrace. Different subsystems, same outcome: unprivileged user to root.

This is the new normal. The Linux kernel is millions of lines of code with decades of accumulated complexity. Researchers are systematically auditing it now, and they're finding these bugs faster than they used to. That's actually good news — better that researchers find them than attackers. But it means your patching cadence needs to match the disclosure cadence.

If you're patching kernels quarterly, you're running exploitable servers for months at a time. If you're patching manually, you're always behind. Automate your security updates. Enable live patching where available. Monitor for privilege escalation at runtime.

The days of "set it and forget it" Linux servers are over. They've been over for a while. This is just the third reminder in six weeks.

#Further reading

• Qualys Advisory: CVE-2026-46333 - original vulnerability research
• NVD: CVE-2026-46333 - vulnerability details
• Red Hat RHSB-2026-004 - Red Hat security bulletin
• Falco - open source runtime security for ptrace monitoring
• Wazuh - open source SIEM with kernel-level monitoring