By ByteBot
A nine-year-old race condition in the Linux kernel was publicly disclosed on May 20, and it is uglier than most. Any unprivileged user with a shell on a vulnerable host can read /etc/shadow, steal SSH host private keys, or execute commands as root — no special permissions required. Working exploits are already public. If you run shared CI/CD runners, that is the first thing you should fix 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. Qualys researchers found a narrow race window in the process exit sequence: the kernel nulls out the memory descriptor before it closes the file descriptor table. In that gap, an unprivileged attacker can call pidfd_getfd(2) — a Linux 5.6 syscall — to clone open file descriptors straight out of a dying privileged process.
The targets are SUID-root binaries that open sensitive files during their normal run: ssh-keysign (which holds SSH host private keys), chage (which opens /etc/shadow), and pkexec or accounts-daemon (dbus paths to root command execution). No kernel exploit, no memory corruption — just a timing trick and a system call that already exists on every modern Linux install.
Qualys confirmed root shells on default installations of Debian, Fedora, and Ubuntu. CVSS score: 7.8 HIGH. The vulnerability is tracked as CVE-2026-46333 and nicknamed ssh-keysign-pwn.
Why Your CI/CD Runners Are the Hottest Target
The standard framing for a local privilege escalation is “attacker with existing shell access.” That sounds contained. It is not, once you factor in shared CI/CD runners.
When a developer opens a pull request from a fork, your CI runner executes that code. On GitHub Actions and GitLab CI, shared runners are multi-tenant by default — multiple jobs share a host. If one of those jobs races a SUID binary exit using this exploit, it walks away with the host’s SSH private keys. Those keys unlock whatever your runner can reach: deployment servers, cloud APIs, internal registries.
Container isolation does not save you here. Docker containers share the host kernel. A containerized job running on a vulnerable kernel can trigger this exploit against processes on the host. Docker’s default seccomp profile does not block pidfd_getfd. Kubernetes nodes running shared untrusted workloads carry the same exposure.
The short version: any environment where untrusted code runs on Linux is a live risk right now.
Patch It Now
The fix shipped in seven stable kernel branches. The patched versions are 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, and 5.10.256. All major distributions have updates available.
# Ubuntu/Debian
sudo apt update && sudo apt upgrade linux-image-generic && sudo reboot
# RHEL / AlmaLinux / Fedora
sudo dnf upgrade kernel && sudo reboot
# Verify after reboot
uname -rIf a reboot is not possible right now, raise the Yama ptrace scope as a temporary block:
sudo sysctl -w kernel.yama.ptrace_scope=2Set it to 2, not 3. Level 3 disables ptrace entirely for all users including root. Level 2 still breaks strace and gdb for non-root users, so CI jobs that use debuggers will fail. That is a trade-off, not a solution. Update the kernel and reboot as soon as you can — the interim setting blocks the public exploit paths but does not eliminate the vulnerability.
Why Nine Years?
The race condition entered mainline Linux in November 2016, part of a refactor to the process exit path in v4.10-rc1. The code was subtle enough that no one caught it as a security issue. Then in 2020, Linux 5.6 shipped pidfd_getfd(2) — a syscall designed to safely clone file descriptors across process boundaries. Combined with the nine-year-old race window, it became a reliable exploit primitive. The bug existed before its own exploit tool was invented.
Qualys reported it privately on May 11. Linus committed the fix on May 14. Public disclosure came on May 20 alongside distribution patches. That is a fast turnaround — faster than the Copy Fail (CVE-2026-31431) and Dirty Frag (CVE-2026-43284/43500) disclosures earlier this year. The Hacker News has a solid writeup on the full timeline if you want the details.
This is the third serious local privilege escalation in the Linux kernel in 2026. The pattern holds: bugs introduced years ago, dormant until a newer syscall or technique makes them exploitable. The full Qualys advisory includes the four exploitation primitives and their exact exploitation paths — worth reading if you want to understand the blast radius before you brief your team.
Update your runners. Check your Kubernetes node kernels. If you are on Ubuntu, Debian, RHEL, AlmaLinux, or Fedora, patches are available right now. Do not wait for your cloud provider to push the update automatically — Ubuntu’s security tracker and Red Hat’s advisory both confirm active exploitation in the wild.
