CVE-2026-46333 (ssh-keysign-pwn): The Fourth Linux Kernel Vulnerability in Three Weeks and What to Do About It

On May 14, 2026, the Qualys Threat Research Unit publicly disclosed CVE-2026-46333, a Linux kernel logic flaw that lets any unprivileged local user read root-owned files including SSH host private keys and the contents of /etc/shadow. A working public proof-of-concept named ssh-keysign-pwn is available on GitHub. Linus Torvalds committed the upstream fix (commit 31e62c2ebbfd) the same day the bug was disclosed. The flaw is six years old, originally identified in a 2020 patch proposal by Jann Horn that was never merged.

This is the fourth Linux kernel security issue requiring attention in three weeks, following Copy Fail (April 29), Dirty Frag (May 7), and Fragnesia (May 13). Each is a different bug with a different mitigation, and the mitigations do not substitute for each other. If you applied the module blacklist for Dirty Frag, it does nothing against this issue.

If you are a Gotekky managed server customer, your server has been mitigated. We deployed the host-wide sysctl mitigation across the fleet within hours of disclosure. The rest of this guide explains what the vulnerability does, why this one is structurally different from the previous three, and what self-managed operators should do today.

What CVE-2026-46333 actually does

The bug lives in __ptrace_may_access(), the kernel function that decides whether one process can inspect another. Specifically, the function skips an important security check (the "dumpable" check) when the target task no longer has an associated memory map (mm == NULL). That sounds like an obscure corner case, but it is exactly the state every process enters during its exit sequence: the kernel runs exit_mm() to release the memory map before it runs exit_files() to close file descriptors. There is a brief window where the dying process has no memory map but still owns its file descriptors. During this window, an unprivileged user matching the target's uid can call pidfd_getfd(2) and steal file descriptors from the dying process.

The exploit chosen by Qualys targets ssh-keysign, a setuid binary that ships on every Linux system with OpenSSH installed. ssh-keysign is normally invoked briefly by the SSH client to sign authentication challenges with the host's private keys, and during that brief lifetime it has the SSH host private key files open as root. The proof-of-concept races against ssh-keysign's exit, calls pidfd_getfd on its file descriptor table, and steals the open handles to /etc/ssh/ssh_host_ecdsa_key, ssh_host_ed25519_key, and ssh_host_rsa_key. A second variant of the proof-of-concept targets chage, another setuid binary, and steals the open handle to /etc/shadow, which contains every user's password hash on the system.

The category is information disclosure, not privilege escalation. An attacker exploiting this does not become root directly. What they get is more useful in some ways and less useful in others: the SSH host private keys let them impersonate the server for SSH man-in-the-middle attacks against future connections, and the shadow file gives them every user's password hash for offline cracking, including root's. In a hosting context, this is the kind of foothold that turns into long-term compromise rather than instant takeover.

Why this is structurally different from the previous three kernel CVEs

Copy Fail, Dirty Frag, and Fragnesia share a pattern: write attacker-controlled bytes into the kernel page cache, modify an in-memory copy of a privileged binary, then execute it for instant root. The mitigations for those three are all module blacklists (esp4, esp6, algif_aead, rxrpc, ipcomp4, ipcomp6) plus a page cache drop. CVE-2026-46333 does none of that. It does not write anything anywhere. It races against process exit and reads file descriptors from a dying process. The page cache is not involved. ESP, XFRM, rxrpc, and algif_aead are not involved.

This means the existing mitigations on your servers do not protect against CVE-2026-46333. A server that has the Dirty Frag and Fragnesia blacklists in place is still vulnerable here. You need a separate mitigation, and the good news is that it is simpler than the previous three. The bad news is that you need to apply it explicitly.

The mitigation is a single kernel sysctl: kernel.yama.ptrace_scope. The Yama Linux Security Module restricts which processes can use ptrace and related APIs on which other processes. The vulnerability path through pidfd_getfd checks ptrace_may_access permissions. By tightening Yama's ptrace_scope to its most restrictive setting (3, which disallows all ptrace attachment for non-CAP_SYS_PTRACE processes), the kernel rejects the exploit attempt before the buggy code path is reached. The setting is fully reversible with a single sysctl write.

Affected CloudLinux versions

CloudLinux published version-specific guidance for this CVE. The current state is:

• CloudLinux 8 LTS, CloudLinux 9, CloudLinux 10: affected and exploitable by the current public proof-of-concept. Apply the mitigation immediately.
• CloudLinux 7h and CloudLinux 8: the underlying kernel race is present, but the public PoC does not work against them because the pidfd_getfd syscall is not exposed on their kernel line. They will receive patches on the same timeline as other versions. Apply the mitigation as defense in depth even if the public exploit does not work today, since a syscall-independent variant may be developed.
• CloudLinux 7: not affected.

For AlmaLinux, the affected versions are 8, 9, and 10. AlmaLinux 7 is end of life and not affected by this specific CVE because of its older kernel line. The same mitigation pattern applies on AlmaLinux as on CloudLinux because both share the upstream Linux kernel and the same Yama LSM. CloudLinux and AlmaLinux patched kernels and a KernelCare livepatch are in active build and test at the time of this writing.

What Gotekky did on managed servers

Within hours of the disclosure, we deployed the kernel.yama.ptrace_scope=3 sysctl setting across every managed server in our Toronto infrastructure, persisted through /etc/sysctl.d/, and verified the running value on every node. This is a host-wide mitigation that takes effect immediately, requires no reboot, has no measurable performance impact, and does not interact with the existing Dirty Frag or Fragnesia mitigations. All four mitigations are now in place simultaneously on every managed server.

For CloudLinux managed servers with KernelCare, we will apply the patched livepatch as soon as CloudLinux publishes it, after which the sysctl mitigation becomes defense in depth but stays in place. For AlmaLinux nodes, we will apply the patched kernel during the next scheduled maintenance window. Customers on Gotekky managed plans need to take no action.

If you operate self-managed servers, do this today

The mitigation is a single sysctl change. As root:

echo 3 > /proc/sys/kernel/yama/ptrace_scope
echo "kernel.yama.ptrace_scope = 3" > /etc/sysctl.d/cve-2026-46333.conf
sysctl --system

The first line takes effect immediately on the running kernel. The second and third lines make the change survive reboots by adding it to a sysctl.d configuration file. Verify with:

sysctl kernel.yama.ptrace_scope
# Expected output: kernel.yama.ptrace_scope = 3

If this returns a value other than 3 after running the commands above, check that Yama is actually compiled into your kernel (cat /sys/kernel/security/lsm should include yama in the output). On almost every modern distribution Yama is enabled by default, so this is rarely an issue, but containers and minimal kernel builds can omit it.

What ptrace_scope=3 actually does and what it breaks

Yama's ptrace_scope sysctl has four settings. Most modern distributions default to 1 (which restricts ptrace to parent-child relationships only). Setting it to 3 means no ptrace attachment is permitted at all, including parent-child. Once set to 3, the sysctl cannot be changed back without a reboot.

Practical consequences on a hosting server:

• gdb attach to running processes breaks. Launching gdb against a binary directly still works because that creates a child process. Attaching gdb to an existing PID does not.
• strace -p PID breaks. Tracing a process you launched (strace progname) still works.
• perf record -p PID breaks. Whole-system perf still works.
• Crash handlers in browsers (Chromium, Firefox) cannot capture crash dumps via ptrace. Hosting servers typically do not run desktop browsers so this is rarely relevant.
• Some monitoring agents that use ptrace stop collecting per-process data. Most modern observability uses eBPF or /proc rather than ptrace, but verify your monitoring stack.

For cPanel, Webuzo, Plesk, and DirectAdmin servers, none of these consequences typically matter. Customers do not run gdb on production hosting environments and the panel's own diagnostic tools do not rely on attaching to running PIDs. For an internal Gotekky engineering server where the team genuinely needs to attach debuggers to running processes, we use a temporary downgrade to ptrace_scope=0 during the troubleshooting session, then restore to 3 with a reboot. The setting being one-way until reboot is part of its security value: an attacker who briefly gains root cannot trivially lower it back to the vulnerable setting and persist.

If you need to revert the mitigation temporarily

Because ptrace_scope=3 is sticky until reboot, reverting requires removing the persistent setting and rebooting:

rm /etc/sysctl.d/cve-2026-46333.conf
reboot

After reboot, the system returns to its previous default (usually 1 on modern distributions). If you only need ptrace temporarily for a single debugging session, this is the correct path. For permanent change, edit the persistence file rather than removing it.

CloudLinux with KernelCare

If you run CloudLinux 7h, 8 LTS, 8, 9, or 10 with KernelCare, a livepatch for CVE-2026-46333 is in active build. Once published, it deploys automatically without reboot. Check status with:

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

If the CVE appears as patched, your kernel is fixed at the source and the sysctl mitigation becomes optional. We recommend leaving the sysctl in place anyway as defense in depth, since ptrace_scope=3 also defends against other ptrace-related issues that may surface in the future.

For AlmaLinux without KernelCare

Patched kernels for AlmaLinux 8, 9, and 10 will follow the same publication path as the Fragnesia kernels last week (testing repo first, then production). Once released:

sudo dnf clean metadata
sudo dnf upgrade kernel
sudo reboot

Until then, the sysctl mitigation is sufficient. The fix in mainline kernel commit 31e62c2ebbfd will be backported to the AlmaLinux supported branches over the next few days.

Audit and credential rotation considerations

Information disclosure vulnerabilities raise a question that pure privilege escalation bugs do not: did exploitation happen before mitigation? CVE-2026-46333 has been a six-year-old latent bug, and while the public proof-of-concept only landed on May 14, 2026, it is possible that this primitive was known privately to some attackers earlier.

For a hosting server, the conservative posture is to treat SSH host keys and the shadow file as potentially compromised on any server that was internet-reachable with shell access for non-trusted users before the mitigation was applied. The remediation in that case is:

• Rotate SSH host keys. Generate new host keys, restart sshd, and accept that returning SSH clients will see a host-key-changed warning until their known_hosts is updated. Specifically: rm /etc/ssh/ssh_host_*_key* and run ssh-keygen -A or systemctl restart ssh to regenerate.
• Force password resets for all local accounts whose hashes were on the system. The shadow file contains every account's password hash. Offline cracking on modern GPUs makes weak passwords recoverable. Force rotation of root and every user account password.
• Monitor for unusual SSH authentication patterns over the next few weeks. If host keys were exfiltrated, the most likely abuse is a man-in-the-middle attack where the attacker impersonates your server to intercept SSH connections from administrators. Logging and alerting on unusual SSH client behavior is the right defensive control.

This is heavy work for what may have been zero actual compromises. For most hosting servers that ran under normal monitoring with no known intrusion attempts, treating the issue as a preventive patch (apply mitigation, schedule kernel upgrade, no rotation) is reasonable. The rotation discussion is for environments where you have specific reason to suspect prior exploitation or where compliance frameworks like SOC 2, PCI DSS, or PIPEDA breach notification rules require a more conservative response.

The pattern this represents

Four Linux kernel vulnerabilities in three weeks, found by four different research groups, in four different kernel subsystems, with four different exploitation patterns. The lessons from previous disclosures hold: AI-assisted code review is now genuinely effective at finding deterministic primitives like these, and the kind of bug found is whatever pattern the researcher trained their tooling to look for. Copy Fail and Dirty Frag and Fragnesia were a page-cache-write family. CVE-2026-46333 is a ptrace-during-exit family. Neither family is exhausted by these disclosures, and similar bugs in adjacent areas (signal delivery during exit, namespace teardown, file descriptor cleanup) are plausible candidates for the next disclosure.

For Canadian hosting infrastructure operating under PIPEDA, Law 25 in Quebec, and SOC 2 frameworks, the operational reality is that monthly patch windows are not sufficient when emergency disclosures are arriving roughly weekly. Defense in depth, automated mitigation deployment, and an incident response playbook for kernel CVEs are now table stakes. Gotekky has invested in this throughout 2026 and the response cadence on these four disclosures reflects that work. We will continue publishing guides as new disclosures land and updating mitigation strategies as the threat landscape evolves.

The complete current security posture on a Gotekky managed server now includes: the cPanel and WHM CVE-2026-41940 patch from April 28, the WHMCS CVE-2026-29204 patch from May 13, the algif_aead module blacklist for Copy Fail, the esp4/esp6/ipcomp4/ipcomp6/rxrpc module blacklist for Dirty Frag and Fragnesia, and now kernel.yama.ptrace_scope=3 for CVE-2026-46333. Each is independent. Each is necessary. We have published separate guides for the cPanel and WHMCS issues and a dedicated guide for each of the four kernel CVEs, and we recommend reading the relevant guide in detail if you operate self-managed servers.