How to protect your Linux server from CVE-2026-46333 (ptrace exit-race / ssh-keysign-pwn)

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

  1. Confirm the running kernel with uname -r.
  2. If you applied the sysctl, verify it:
    sysctl kernel.user_ptrace
  3. 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
  4. 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.

Sources

Tags