# ssh-keysign-pwn (CVE-2026-46333): how Ubuntu fixes the /etc/shadow and SSH key leak

- **Published on:** 2026-05-19
- **Category:** News
- **Original page:** https://linuxgratis.com/en/articles/ssh-keysign-pwn-cve-2026-46333-kernel-linux

A Linux kernel race condition let local users read sensitive files through ptrace. Ubuntu has patches out for Focal, Jammy, Noble, Questing and Resolute.

---

Canonical has shipped fixes for CVE-2026-46333, a Linux kernel vulnerability that Qualys named **ssh-keysign-pwn** and disclosed on 15 May 2026. Nobody gets in from outside with this one, but an unprivileged local user can read files they have no business reading. Among those files: `/etc/shadow` and OpenSSH's host private keys.

## What actually happens

The bug is a race condition that fires right as a privileged process exits. A local attacker uses the `ptrace()` system call to inspect that process at that precise moment and walk away with the contents of files the binary had opened. The trick works because plenty of `suid` and `sgid` binaries open files a normal user can't touch, and that's where the leak slips through.

The proof of concept that ships with the advisory shows two clear cases:

- Reading `/etc/shadow` via `/usr/bin/chage`, which is `sgid`.
- Pulling the OpenSSH server's host private keys through `/usr/lib/openssh/ssh-keysign`, which is `suid`. That's where the name comes from.

Leaking SSH host keys is no small thing: with them an attacker can impersonate the server on future connections. And `/etc/shadow` holds the password hashes for every account on the machine.

## How it's rated

CVSS 3.1 puts it at 5.5, which lands in medium severity. Ubuntu, though, marks it **High** priority. That gap makes sense once you look at what leaks: a middling score in the abstract math, but a serious real-world impact on a server with local users or any multi-user system.

## Affected releases and the fixes

The bug touches a wide range of Ubuntu versions. These are the kernel versions that already carry the fix:

- **Focal Fossa 20.04 LTS**: `5.15.0-181.191~20.04.1`
- **Jammy Jellyfish 22.04 LTS**: `5.15.0-181.191` or `6.8.0-124.124~22.04.1`
- **Noble Numbat 24.04 LTS**: `6.8.0-124.124` or `6.17.0-35.35~24.04.1`
- **Questing Quokka 25.10**: `6.17.0-35.35`
- **Resolute Raccoon 26.04 LTS**: `7.0.0-22.22`

## What to do

The answer is the usual one for a kernel bug: install the security updates and reboot so the fixed kernel takes over.

```bash
sudo apt update && sudo apt upgrade
sudo reboot
```

If you can't reboot straight away, there's a temporary measure: restrict `ptrace()` with

```bash
sudo sysctl -w kernel.yama.ptrace_scope=2
```

That blocks `ptrace` access for unprivileged users, which is exactly what the attack needs. Mind the side effect: debugging tools like `gdb` and `gcore` will stop working for non-root users. It's a stopgap while you roll out the real update, not something you want to leave in place long term.

If you run Ubuntu servers with multiple user accounts, this is one to patch soon. And if you manage production fleets, kernel livepatching to cut down on reboots fits well here.

You can find more on the distribution and its support in the [Ubuntu page](/en/ubuntu).

## Source

[CVE-2026-46333 (ssh-keysign-pwn) Linux kernel vulnerability mitigations](https://ubuntu.com/blog/ssh-keysign-pwn-linux-vulnerability-fixes-available) — Canonical, on the official Ubuntu blog.