SSH host key leak via ptrace, and why I almost nuked my prod patching it
---
Last week my automated security scanner flagged CVE-2026-46333, also known as
ssh-keysign-pwn. The vulnerability is a ptrace race condition in the Linux kernel
that lets any local unprivileged user read the SSH host private keys of the server,
and as a bonus, /etc/shadow.
The mechanics are straightforward. When a suid or sgid process exits, there is a
brief window during which ptrace() can attach and read its open file descriptors.
ssh-keysign is suid. So is chage. An attacker with a local shell account, a tight
loop, and a bit of patience can win that race and walk away with your server's SSH
identity and your password hashes.
A public PoC dropped the same day as disclosure. The CVSS score is 5.5 (Medium),
which badly undersells it. On a server where SSH is your only entry point, leaking
the host private key means an attacker who later gets a network position can silently
MITM every future connection. No warning. No changed fingerprint.
The kernel patch landed in Ubuntu's linux-generic 6.8.0-117 (USN-8278-1). But
applying it requires a reboot. The interim mitigation is a single sysctl:
Value 2 means only processes with CAP_SYS_PTRACE can use ptrace. Debuggers stop
working for regular users. On a production VPS that is an acceptable tradeoff.
Now for the embarrassing part.
My security report also recommended applying the kernel update and rebooting.
I copy-pasted the commands into a terminal without thinking:
I caught myself before hitting Enter. The server was running 45 Docker containers:
three PostgreSQL databases, two Redis instances, a voice agent, n8n, Typebot,
Traefik, Prometheus, Grafana, and several production SaaS apps with live users.
A blind dist-upgrade with -y on a server you have not reviewed in weeks is risky.
Packages get added. Packages get removed. Things break in ways that are annoying at
2am. And a reboot without a maintenance window means downtime with zero preparation.
The thing is, the mitigation does not require a reboot at all. sysctl -w applies
immediately. I was already protected the moment I ran that one-liner. The reboot
could wait for a proper maintenance window.
Two lessons I am taking away.
One: CVSS scores describe the vulnerability, not your exposure. A 5.5 on a server
where SSH is the perimeter is not a 5.5 in practice.
Two: "apply patch and reboot" is not a procedure. On a production server with
stateful services it is a plan waiting to fail. The question is always: what is the
fastest mitigation that requires zero downtime, and when is the maintenance window
for the rest.
Check your ptrace_scope:
sysctl kernel.yama.ptrace_scope
If it returns 0 or 1, you are exposed on any unpatched kernel. Two commands fix it
with no reboot required.
---
Last week my automated security scanner flagged CVE-2026-46333, also known as ssh-keysign-pwn. The vulnerability is a ptrace race condition in the Linux kernel that lets any local unprivileged user read the SSH host private keys of the server, and as a bonus, /etc/shadow.
The mechanics are straightforward. When a suid or sgid process exits, there is a brief window during which ptrace() can attach and read its open file descriptors. ssh-keysign is suid. So is chage. An attacker with a local shell account, a tight loop, and a bit of patience can win that race and walk away with your server's SSH identity and your password hashes.
A public PoC dropped the same day as disclosure. The CVSS score is 5.5 (Medium), which badly undersells it. On a server where SSH is your only entry point, leaking the host private key means an attacker who later gets a network position can silently MITM every future connection. No warning. No changed fingerprint.
The kernel patch landed in Ubuntu's linux-generic 6.8.0-117 (USN-8278-1). But applying it requires a reboot. The interim mitigation is a single sysctl:
Value 2 means only processes with CAP_SYS_PTRACE can use ptrace. Debuggers stop working for regular users. On a production VPS that is an acceptable tradeoff.
Now for the embarrassing part.
My security report also recommended applying the kernel update and rebooting. I copy-pasted the commands into a terminal without thinking:
I caught myself before hitting Enter. The server was running 45 Docker containers: three PostgreSQL databases, two Redis instances, a voice agent, n8n, Typebot, Traefik, Prometheus, Grafana, and several production SaaS apps with live users.
A blind dist-upgrade with -y on a server you have not reviewed in weeks is risky. Packages get added. Packages get removed. Things break in ways that are annoying at 2am. And a reboot without a maintenance window means downtime with zero preparation.
The thing is, the mitigation does not require a reboot at all. sysctl -w applies immediately. I was already protected the moment I ran that one-liner. The reboot could wait for a proper maintenance window.
Two lessons I am taking away.
One: CVSS scores describe the vulnerability, not your exposure. A 5.5 on a server where SSH is the perimeter is not a 5.5 in practice.
Two: "apply patch and reboot" is not a procedure. On a production server with stateful services it is a plan waiting to fail. The question is always: what is the fastest mitigation that requires zero downtime, and when is the maintenance window for the rest.
Check your ptrace_scope:
If it returns 0 or 1, you are exposed on any unpatched kernel. Two commands fix it with no reboot required.