What is CVE-2026-46333?
CVE-2026-46333, known as ptrace exit-race or ssh-keysign-pwn, is an information disclosure vulnerability in the Linux kernel that in practice amounts to a privilege escalation. It was disclosed on May 15, 2026.
The flaw lives in the ptrace access check on the process exit path. Between the moment a task's memory descriptor is detached and the moment its file descriptor table is closed, the ptrace access check skips its dumpable safeguard because the task's memory descriptor is already NULL. During that window an unprivileged local attacker uses pidfd_getfd(2) (available in Linux 5.6 or later) to copy file descriptors from exiting privileged processes.
The primary targets are SUID binaries that open sensitive files during their exit routine: ssh-keysign (SSH host private keys) and chage (the /etc/shadow password database). With those contents an attacker can impersonate the SSH host or crack root hashes.
A public proof-of-concept exists. Patches are in active development upstream (commit 31e62c2ebbfd).
Are you affected?
The vulnerability exists in any kernel carrying the bug, but it is only practically exploitable on kernels that include pidfd_getfd(2) (Linux 5.6 or later):
- Exploitable: CloudLinux 8 LTS, CloudLinux 9, CloudLinux 10, AlmaLinux 9, AlmaLinux 10, Rocky Linux 9/10, RHEL 9/10, modern Ubuntu and Debian.
-
Vulnerable but not exploitable (4.18 kernel without
pidfd_getfd): CloudLinux 7h, CloudLinux 8 base. - Not affected: CloudLinux 7.
Environments with CageFS active protect their caged tenants (the target SUID binaries don't exist inside the cage). Host-level mitigation is still required.
How to check your server
Check the kernel version:
uname -r
Confirm whether pidfd_getfd is exposed to userspace (without it, the public exploit doesn't work):
grep -w __NR_pidfd_getfd /usr/include/asm-generic/unistd.h 2>/dev/null || \
grep -w __NR_pidfd_getfd /usr/include/x86_64-linux-gnu/asm/unistd_64.h 2>/dev/null
How to mitigate
| Option | Best for | Reboot? | Durable? |
|---|---|---|---|
| Install vendor patched kernel | Everyone, long-term fix | Yes | Yes |
| KernelCare livepatch | Servers running KernelCare | No | Yes |
Sysctl kernel.user_ptrace=0
|
CloudLinux servers waiting for the patch | No | Temporary |
Remove SUID from ssh-keysign and chage
|
Defense in depth | No | Yes |
Option A: vendor patched kernel
Minimum patched versions (the remaining branches are in development at the time of writing):
- AlmaLinux / CloudLinux / Rocky 9:
kernel-5.14.0-611.54.6.el9_7 - AlmaLinux / CloudLinux / Rocky 10:
kernel-6.12.0-124.56.5.el10_1 - CloudLinux 8 LTS, CloudLinux 7h, and CloudLinux 8: patches in development, follow the vendor advisory.
Apply the update and reboot:
dnf -y update 'kernel*'
reboot
Option B: KernelCare livepatch
The livepatch is being built at the time of writing. When available:
kcarectl --update
kcarectl --patch-info | grep CVE-2026-46333
Option C: sysctl kernel.user_ptrace=0 (CloudLinux servers)
This CloudLinux-specific sysctl disables unprivileged users' ability to attach ptrace to their own processes, blocking the exploitation path at the kernel level:
sysctl -w kernel.user_ptrace=0
To persist the setting across reboots:
echo 'kernel.user_ptrace = 0' > /etc/sysctl.d/99-ptracenull.conf
sysctl --system
Cost: unprivileged users will no longer be able to use gdb -p, strace -p, or similar tools on their own processes. For most production servers this is acceptable.
Option D: remove SUID from target binaries (defense in depth)
Reduce the attack surface by removing the SUID bit from the binaries that open sensitive files during exit:
chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null
chmod u-s /usr/bin/chage
This does not cover every SUID-root binary on the system, but it neutralizes the two vectors used by the public PoC. It complements but does not replace the patched kernel.
After mitigating
- Confirm the running kernel with
uname -r. - If you applied the sysctl, verify it:
sysctl kernel.user_ptrace - If your server was exposed to unprivileged users while unpatched, rotate the SSH host keys and force password changes for root and privileged accounts:
rm /etc/ssh/ssh_host_* dpkg-reconfigure openssh-server # Debian/Ubuntu sshd-keygen # RHEL family systemctl restart sshd - Distribute the new host fingerprints (
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub) to your users and monitoring tooling.
Need help?
Open a ticket at soporte.telecu.cloud and reference: CVE-2026-46333.