1. Home
  2. Announcement
  3. CVE-2026-46333 / ssh-keysign-pwn – Linux Kernel ptrace Exit-Race Vulnerability

CVE-2026-46333 / ssh-keysign-pwn – Linux Kernel ptrace Exit-Race Vulnerability

A new Linux kernel vulnerability, tracked as CVE-2026-46333 and publicly referred to as ssh-keysign-pwn, has been disclosed. The issue affects the Linux kernel’s ptrace access-check logic during process exit and may allow a local unprivileged user to read sensitive root-owned files under certain conditions. Public proof-of-concept exploits are already available.

This vulnerability is especially important for multi-user Linux systems, shared hosting servers, and environments where untrusted or semi-trusted local users have shell access.


What is CVE-2026-46333?

CVE-2026-46333 is a Linux kernel race condition in the ptrace access-check path. During the exit process of a privileged program, there is a short window where the process has already detached its memory descriptor but still has open file descriptors. An unprivileged local process may abuse this race to duplicate file descriptors from the exiting privileged process.

The public exploits currently demonstrate access to sensitive files through privileged SUID programs such as:

  • ssh-keysign, which may access SSH host private keys
  • chage, which may access /etc/shadow

This does not mean the vulnerability is remotely exploitable by itself. An attacker generally needs local code execution or shell access on the affected server. However, on shared or multi-user systems, this still represents a serious security risk.


Affected Systems

Based on vendor advisories available as of 15 May 2026:

AlmaLinux

AlmaLinux has confirmed that AlmaLinux 9 and AlmaLinux 10 are vulnerable, and public exploits work reliably on both. AlmaLinux 8 is not exploitable with the current public proof-of-concept, but the underlying kernel logic bug is present and AlmaLinux is also preparing patches for it.

Patched AlmaLinux kernels are currently available in the testing repository:

OSPatched kernel version
AlmaLinux 8kernel-4.18.0-553.124.4.el8_10
AlmaLinux 9kernel-5.14.0-611.54.6.el9_7
AlmaLinux 10kernel-6.12.0-124.56.5.el10_1

CloudLinux

CloudLinux has confirmed that CloudLinux 8 LTS, CloudLinux 9, and CloudLinux 10 are affected by the current public proof-of-concept. CloudLinux 7 is not affected. CloudLinux 7h and mainstream CloudLinux 8 contain the underlying kernel race, although the current public proof-of-concept does not exploit them directly.

CloudLinux has recommended an immediate host-wide mitigation using the CloudLinux-specific sysctl kernel.user_ptrace=0.


Immediate Mitigation

The permanent fix is to install a patched kernel from your operating system vendor and reboot into that kernel. Until the patched kernel is installed, the following mitigations can reduce exposure.


Mitigation for CloudLinux Servers

For CloudLinux systems, apply the following mitigation:

sysctl -w kernel.user_ptrace=0
echo 'kernel.user_ptrace = 0' | sudo tee /etc/sysctl.d/99-ptracenull.conf
sudo sysctl --system

Verify:

sysctl kernel.user_ptrace

Expected output:

kernel.user_ptrace = 0

This setting disables unprivileged ptrace usage on CloudLinux systems and blocks the currently known public proof-of-concept at the kernel level. CloudLinux notes that this may affect tools such as gdb -p, strace -p, and other debugging or monitoring tools that rely on unprivileged process attachment.


Mitigation for AlmaLinux Servers

For AlmaLinux systems, AlmaLinux recommends tightening Yama ptrace_scope:

sysctl -w kernel.yama.ptrace_scope=3
echo 'kernel.yama.ptrace_scope = 3' > /etc/sysctl.d/99-ssh-keysign-pwn.conf
sysctl --system

Verify:

sysctl kernel.yama.ptrace_scope

Expected output:

kernel.yama.ptrace_scope = 3

AlmaLinux states that setting kernel.yama.ptrace_scope to 2 or 3 blocks the known public exploits. Setting it to 3 disables ptrace attach entirely, which may affect debugging tools such as gdb or strace -p.


Optional Additional Hardening

Where appropriate, administrators may also remove the SUID bit from the currently known target binaries:

chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null
chmod u-s /usr/bin/chage

Verify:

ls -l /usr/libexec/openssh/ssh-keysign /usr/bin/chage

The permissions should no longer show s in the owner execute field.

This is only a partial mitigation. It covers the currently known public exploit targets, but it does not fix the underlying kernel issue. It may also affect host-based SSH authentication or non-root usage of chage. The correct long-term solution remains a patched kernel.


Permanent Fix: Update the Kernel

Once patched packages are available in your vendor’s production repositories, update the kernel and reboot:

dnf clean all
dnf update -y 'kernel*'
reboot

After reboot, verify the running kernel:

uname -r
rpm -q kernel | sort -V

For AlmaLinux 8, 9, and 10, patched kernels were first made available in the testing repository on 15 May 2026. Production availability should be confirmed from the vendor repository before applying updates on critical production systems.


KernelCare / Live Patching

CloudLinux has stated that KernelCare live patches are being prepared for affected systems. Once available, KernelCare-enabled servers should be able to receive the fix without a reboot through the standard KernelCare live patching process.

To update KernelCare manually:

kcarectl --update

To check applied patches:

kcarectl --patch-info | grep CVE-2026-46333

EuroVPS Recommendation

EuroVPS strongly recommends that all customers running affected Linux distributions take this vulnerability seriously, especially where local shell access is available to users.

Recommended action plan:

  1. Apply the temporary mitigation immediately based on your operating system.
  2. Review whether any untrusted users have shell access to the server.
  3. Install the patched vendor kernel as soon as it is available for your OS.
  4. Reboot into the patched kernel unless KernelCare or another verified live patching mechanism is used.
  5. Verify the running kernel version after the update.

For managed servers where EuroVPS has administrative access, our team can assist with checking exposure, applying mitigations, updating the kernel, and coordinating the required reboot window.


Need Assistance?

If you are unsure whether your server is affected, or if you would like EuroVPS to perform the mitigation or kernel update for you, please open a support ticket from the EuroVPS Client Area.

Our team can assist with:

  • Checking the running OS and kernel version
  • Applying the correct temporary mitigation
  • Updating to the patched kernel
  • Scheduling a safe reboot window
  • Verifying that the server is running the corrected kernel after reboot

CVE-2026-46333 is a local kernel vulnerability, but on shared or multi-user systems it should be treated as urgent. Temporary mitigation is recommended immediately, followed by a proper kernel update as soon as patched packages are available from the relevant vendor.

Updated on May 18, 2026
Was this article helpful?

Related Articles