Linux has a new local kernel vulnerability, and this one is worth treating with more seriousness than the phrase “local-only” usually gets.

The issue is being called ssh-keysign-pwn. It is tracked as CVE-2026-46333, and the practical impact is blunt: on affected systems, an unprivileged local user may be able to read root-owned files that should be unreachable.

That includes sensitive targets like SSH host private keys and /etc/shadow, the file that stores password hash data on many Linux systems.

This is not a remote bug that lets a stranger on the internet instantly compromise a server. The attacker needs local code execution first. But that does not make it small. Modern Linux systems are full of ways for low-privilege code to exist: user accounts, web services, containers, CI runners, shared hosting, compromised applications, development shells, and background jobs. Once code is already running somewhere on the box, bugs like this decide how much damage that foothold can do.

What the bug does

The vulnerability lives in the Linux kernel’s ptrace access-check logic. Ptrace is the mechanism that lets one process inspect or control another process. Debuggers need it. Tracing tools need it. Attackers like it for the same reason: it crosses process boundaries.

The kernel normally has to be careful about who can inspect what. One of the checks involved is tied to whether a process is considered “dumpable,” meaning whether its memory image can safely be exposed through things like core dumps or debugging interfaces.

The problem appears during process exit. A privileged process can enter a narrow state where its memory descriptor is already gone, but its file descriptors are still open. In that gap, the relevant ptrace check can lose the context it needs to make the right decision.

That creates a race. If an unprivileged process hits the timing correctly, it can use the file descriptor cloning path to grab an open descriptor from a privileged process that is shutting down. If that descriptor points to a protected file, the attacker gets access to the file without opening it normally.

The important part is not that the attacker becomes root. The important part is that the attacker may not need to. Reading the wrong root-owned file can be enough.

Why ssh-keysign is in the name

The public name comes from one of the demonstrated targets: ssh-keysign.

ssh-keysign is part of OpenSSH. Under certain conditions, it can open SSH host private keys. Those keys are supposed to be protected because they identify the machine itself. If an attacker can read them, the damage can move beyond the local system and into trust relationships around SSH.

A second demonstrated target involves chage, a tool used for password aging information. The public proof-of-concept shows a path to reading /etc/shadow. That file does not usually contain plaintext passwords, but it can contain password hashes. Leaking those hashes gives an attacker material to attack offline.

That is the shape of this bug: not flashy remote execution, not instant root, but protected secrets crossing a boundary they were never supposed to cross.

The local-only trap

Security language has a bad habit of making “local” sound safe.

It is not safe. It is just a different starting point.

A remote vulnerability starts from outside the machine. A local vulnerability starts after the attacker already has some presence. For a personal laptop, that might mean malware or a malicious local user. For a server, it might mean a compromised web app, a low-privilege shell, a container, or a normal account that should not be able to inspect system secrets.

Many real compromises are chains. One bug gets code running. Another bug exposes secrets. Another bug turns those secrets into persistence, impersonation, or lateral movement. ssh-keysign-pwn fits into that middle stage. It gives a local attacker information that can make the next step easier.

What got fixed

The upstream Linux fix landed in commit 31e62c2ebbfd, titled ptrace: slightly saner 'get_dumpable()' logic. The patch changes how the kernel handles dumpability when a task no longer has a normal memory descriptor attached.

In simpler terms: the kernel now keeps enough state around to avoid treating the disappearing process as safe to inspect just because part of its memory context has already gone away.

That is a small patch for a large class of consequences. The code change is not dramatic. The impact is.

Who should care

Desktop Linux users should update, but the sharpest risk is on multi-user or service-heavy machines.

  • Shared servers should treat this as urgent.
  • Hosting providers should treat this as urgent.
  • Systems running untrusted workloads should treat this as urgent.
  • Developer boxes with lots of local tooling should update quickly.
  • Production servers with exposed applications should not ignore it just because the bug is local.

The systems that matter most are the ones where a low-privilege process should never be able to see machine-level secrets.

What to do

The real fix is a patched kernel.

  • Check your distribution’s security advisory for CVE-2026-46333.
  • Install the latest available kernel update.
  • Reboot into the patched kernel.
  • Confirm the running kernel with uname -r.
  • If you suspect exposure on a shared or compromised host, consider rotating SSH host keys after patching.

Some distributions also describe a temporary mitigation using Yama’s ptrace restrictions:

sudo sysctl -w kernel.yama.ptrace_scope=3
echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf

That setting can interfere with debugging tools such as gdb and strace -p. It is a mitigation, not a replacement for updating the kernel. If your workflow depends on attaching debuggers to running processes, check your distribution’s guidance before applying it blindly.

The bigger pattern

This bug arrives after several recent Linux kernel security issues, including Dirty Frag and Fragnesia. The details differ, but the rhythm is familiar: kernel internals, local attack surface, fast upstream patches, distribution maintainers racing to ship rebuilds, and administrators stuck deciding how quickly they can reboot machines that are supposed to stay online.

That is the operational reality of Linux security. The kernel is shared infrastructure. A bug in a narrow subsystem can suddenly matter to laptops, cloud servers, CI workers, hosting platforms, and embedded systems. The distance between “weird internal edge case” and “patch this fleet” is short.

ssh-keysign-pwn is not the loudest kind of vulnerability. It does not need to be. A local process reading root-owned secrets is already loud enough.

Sources