Nine-year-old Linux kernel flaw can expose SSH private keys and root access paths

A Linux kernel vulnerability tracked as CVE-2026-46333 can let a local unprivileged attacker steal sensitive data from privileged processes, including SSH host private keys and password hashes. The flaw affects the kernel’s ptrace access-control path and has existed in mainline Linux since late 2016.

The issue was disclosed by the Qualys Threat Research Unit, which demonstrated working exploit paths against default installations of several major Linux distributions. The vulnerability does not allow a remote attacker to break into a server by itself, but it can turn a low-privilege foothold into access to root-owned secrets or root command execution.

That makes CVE-2026-46333 especially important for servers, cloud workloads, developer machines, shared Linux hosts, and CI/CD runners. If an attacker already has shell access through a compromised account or service, the flaw can give them a way to cross the boundary between normal user access and highly sensitive system resources.

What CVE-2026-46333 actually affects

The bug sits in the Linux kernel function __ptrace_may_access(), which helps decide whether one process can inspect or interact with another process. The problem appears during a short race window when a privileged process is exiting or dropping credentials.

The NVD entry for CVE-2026-46333 describes the fix as a change to the kernel’s dumpable logic. In simple terms, the kernel could skip key checks when the target process no longer had a normal memory descriptor, creating a path for an attacker to duplicate file descriptors from privileged processes.

Qualys showed that attackers can combine this race condition with pidfd_getfd(), a Linux system call that duplicates a file descriptor from another process when access checks pass. Under the vulnerable logic, those checks could pass when they should not.

Detail	Current information
CVE	CVE-2026-46333
Bug class	Linux kernel ptrace access-control race
Affected area	__ptrace_may_access() and dumpable-state logic
Introduced	Linux 4.10-rc1, in late 2016
Attack type	Local privilege escalation and credential disclosure
NVD severity	Medium, CVSS 5.5
Patch status	Kernel and distribution updates are available

Why SSH private keys are at risk

The most visible public exploit path has been called ssh-keysign-pwn because it can abuse ssh-keysign to read SSH host private keys. Those keys usually live under /etc/ssh/ and should only be readable by root.

The Ubuntu security write-up says the exploit demonstrates disclosure of OpenSSH server host private keys and /etc/shadow, which stores hashed local user passwords. Leaked SSH host keys can support on-path attacks or affect SSH host-based authentication, while leaked password hashes can enable offline cracking attempts.

This does not mean every attacker can remotely steal SSH keys from any Linux server. They still need local access first. However, many real breaches begin with limited shell access, a compromised service account, a developer token, or a foothold inside a container or build runner.

Qualys tested several real-world exploit paths

Qualys validated multiple attack scenarios to show that the bug has practical impact beyond a theoretical race condition. The examples included ssh-keysign for SSH host key disclosure, chage for /etc/shadow exposure, pkexec for root command execution, and accounts-daemon for privilege escalation through D-Bus behavior.

The Qualys advisory says working exploits were confirmed on default installations of Debian 13, Ubuntu 24.04, Ubuntu 26.04, Fedora 43, and Fedora 44. That does not mean only those systems are affected, since the underlying kernel issue reached many Linux distributions.

The bug’s age also increases its exposure. A flaw introduced in 2016 can sit across many servers, appliances, containers, and long-lived enterprise images unless administrators patch aggressively.

Public exploits increased the urgency

Kernel fixes began landing before the full advisory became widely known, but public exploit code appeared quickly after the patch became visible. That compressed the response window for administrators because attackers no longer needed to rediscover the bug on their own.

AlmaLinux said two working exploits appeared hours after the upstream kernel fix, including one aimed at reading SSH host keys and another aimed at reading /etc/shadow through chage. The project also noted that the flaw is being referred to as ssh-keysign-pwn because of one of those public exploit paths.

That timeline matters for enterprise defenders. Once a working local exploit becomes public, any exposed system with shared users, stale accounts, compromised workloads, or weak endpoint controls deserves faster patching and post-patch credential review.

Which systems need attention

The vulnerability affects Linux systems with vulnerable kernels, especially where untrusted or low-privilege users can run local code. Servers that allow SSH access to many users, developer workstations, CI/CD infrastructure, cloud instances, shared hosting systems, and container hosts should receive priority.

The Ubuntu advisory explains that updated Ubuntu kernels are available and that the vulnerability can disclose sensitive files to unprivileged local users. Other major distributions have also released fixes or mitigation guidance.

The CloudLinux advisory says CloudLinux 8 LTS, CloudLinux 9, and CloudLinux 10 were affected and that public proof-of-concept exploit code exists. Hosting environments should treat this seriously because one local user account can sit near many unrelated workloads.

What administrators should do now

Administrators should apply kernel updates from their Linux distribution as soon as possible. Rebooting into the fixed kernel or applying a verified live patch matters because installing an update alone may not protect a system still running the old kernel.

• Install the latest kernel security update from the distribution vendor.
• Reboot systems or confirm that live patching fully applied the fix.
• Set kernel.yama.ptrace_scope to 2 as a temporary mitigation where patching cannot happen immediately.
• Rotate SSH host keys on systems where untrusted local users had access.
• Rotate exposed credentials and review /etc/shadow exposure risk.
• Audit sudo, pkexec, SSH, and account-management logs for unusual activity.
• Review CI/CD runners, build agents, and shared Linux hosts with extra care.

The ptrace_scope mitigation can reduce known exploit paths by requiring CAP_SYS_PTRACE for broader ptrace-style access. However, it may disrupt debugging tools such as gdb and strace, along with some crash-reporting, monitoring, or container workflows.

Why the medium score can still hide serious impact

The NVD vulnerability record lists the issue with a CVSS 3.x base score of 5.5. That score reflects the local attack requirement and other scoring factors, but it does not remove the operational risk for systems where attackers already have limited access.

The AlmaLinux update highlights why administrators should not treat the issue as routine. Public exploits can read root-owned secrets, and stolen SSH host keys may require rotation even after patching.

The practical risk depends on where the vulnerable system runs. A single-user desktop faces a different threat model than a shared server, hosting node, CI runner, cloud jump box, or internet-facing application server where one compromised process can give an attacker local code execution.

Why this kernel flaw matters for cloud and enterprise teams

CVE-2026-46333 shows how local Linux bugs can still create large security problems. Cloud environments often assume that a low-privilege service account or container compromise stays limited, but kernel-level access-control bugs can weaken that boundary.

The CloudLinux guidance recommends kernel updates and mitigation steps for affected systems, especially in environments where many users or workloads share the same underlying host. Those environments should also review whether exposed SSH host keys need replacement.

For enterprises, the right response combines patching, reboot verification, credential rotation, and log review. If a vulnerable host allowed untrusted local execution, teams should assume attackers may have attempted to read sensitive root-owned files.

The safest path is straightforward: patch quickly, confirm the fixed kernel is running, apply ptrace_scope hardening where compatible, and rotate credentials on systems with realistic local compromise risk.

FAQ