· 10 min read

Researchers Just Disclosed a 9-Year-Old Linux Kernel Root Flaw (CVE-2026-46333). If You Run a VPS, You Patch This Weekend.

Stack Tools Lessons

Researchers Just Disclosed a 9-Year-Old Linux Kernel Root Flaw (CVE-2026-46333). If You Run a VPS, You Patch This Weekend.

Qualys disclosed CVE-2026-46333 on May 20, 2026: a logic flaw in the Linux kernel's ptrace path that was introduced in November 2016 and has been sitting in every mainline kernel ever since. The proof-of-concept exploit is named ssh-keysign-pwn. It lets an unprivileged local user read /etc/shadow, dump host SSH private keys, and execute arbitrary commands as root on default installations of Debian, Fedora, and Ubuntu.

Working exploits are circulating publicly. The patch landed in upstream Linux on May 14, 2026, and most distribution kernel packages have rolled it out within the last 72 hours. If you SSH into a $5/month VPS to ship your indie product, you patch this weekend. Here's exactly what to do and why a different version of this story is going to land every six weeks for the rest of 2026.

What the bug actually is

The flaw lives in __ptrace_may_access(), the kernel function that decides whether one process can attach to another. Specifically, between the moment a task's memory descriptor (mm_struct) is detached and the moment its file descriptor table is closed, the kernel's ptrace access check skips the dumpable safeguard, because the memory descriptor is already NULL, the safeguard's prerequisite no longer evaluates.

That tiny window is the bug. During it, an unprivileged process can call pidfd_getfd(2) (the file descriptor cloning interface introduced in Linux 5.6) and copy open file descriptors out of the exiting privileged process. The CVSS score is 5.5, which is low for a flaw that ends in root. CVSS does not weight publicly available exploits, and four are circulating.

The four exploits target different setuid binaries that briefly hold privileged file descriptors during their exit path: chage, ssh-keysign, pkexec, and accounts-daemon. ssh-keysign-pwn is the most reliable on default installations because ssh-keysign is shipped setuid on the major distros and it opens host keys during its exit sequence. Open /etc/ssh/ssh_host_ed25519_key at the right moment, clone the file descriptor out via pidfd_getfd, and an unprivileged user reads the host private key.

The "execute arbitrary commands as root" part of the disclosure works through accounts-daemon, which holds open D-Bus connections to system services during its exit. Clone those out and you can hand-craft messages to systemd as the privileged process.

Disclosure timeline

The timeline is worth understanding because it's slightly better than the average kernel CVE this year:

  • 2026-05-11: Qualys privately reported the issue to the upstream Linux kernel security contact, with proof-of-concept code attached.
  • 2026-05-14: Patch committed to mainline Linux after review by the kernel security team.
  • 2026-05-20: Qualys published the advisory; distribution updates began rolling out.
  • 2026-05-21 onward: Working exploits are circulating publicly. Multiple security researchers and red-team operators have confirmed the PoC works on default Ubuntu 22.04 and 24.04 installations.

Nine days from private disclosure to public patch is the kernel community functioning well. The fact that the bug sat in the kernel for nine years before anyone noticed is the part that should keep you up at night, not the patch cycle.

The exact patch commands for your VPS

If your VPS is running Ubuntu, Debian, or Fedora (which covers most of the indie hosting ecosystem) the patch is one update and a reboot away.

For Ubuntu 22.04 and 24.04:

sudo apt update
sudo apt install --only-upgrade linux-image-generic linux-headers-generic
sudo reboot

For Debian 12 (bookworm):

sudo apt update
sudo apt install --only-upgrade linux-image-amd64
sudo reboot

For Fedora 39 and 40:

sudo dnf update kernel kernel-core kernel-modules
sudo reboot

After reboot, confirm the kernel version includes the fix. Ubuntu fixed versions are at the security tracker: check uname -r against the advisory for your specific release. Upstream stable kernels with the fix are 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, and 5.10.256, all dated May 14–15, 2026. Distribution backports use different package version strings, so cross-check against your distro's advisory rather than the upstream number.

If you cannot patch immediately (and the only reason not to patch immediately is if you have applications that depend on a specific kernel version) there's a mitigation. You can temporarily restrict pidfd_getfd to root only with a kernel module load setting, or you can disable the setuid bits on the affected binaries:

sudo chmod u-s /usr/lib/openssh/ssh-keysign
sudo chmod u-s /usr/bin/chage
sudo chmod u-s /usr/bin/pkexec
sudo chmod u-s /usr/libexec/accounts-daemon

This breaks legitimate uses of these binaries. chage -l will fail for unprivileged users. pkexec for desktop privilege escalation will break. accounts-daemon will not function correctly for GUI session management. These mitigations are stop-gaps, not permanent fixes. Patch the kernel and put the setuid bits back.

Confirming you're not already compromised

Public PoCs have been circulating since May 21. If your VPS has a publicly exposed SSH service and any local user accounts beyond root, you should also check for compromise indicators, not just patch.

Three quick checks. First, look at the file access time on /etc/shadow:

stat /etc/shadow

If the access time is recent and you don't have a reason for it to be (no recent useradd, no recent passwd operations) that's suspicious. Note that noatime mount options will make this check unreliable.

Second, check for unusual processes that called pidfd_getfd:

sudo grep -i pidfd /var/log/auth.log /var/log/secure 2>/dev/null
sudo journalctl --since "2026-05-20" | grep -i pidfd

Third, rotate host SSH keys if you have any reason to suspect compromise:

sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh

This will change your host key fingerprint and trip warnings on any client that connects. That's the point.

The broader question this raises

Nine years. The flaw was introduced in November 2016, in a kernel patch related to ptrace path handling. It sat undetected through Linux 4.x, all of Linux 5.x, and into Linux 6.x. Qualys found it by reading the relevant ptrace code with fresh eyes and noticing the race condition between mm detachment and fd table closure.

The honest read for a solo operator is that this kind of bug will keep coming. Linux kernel code is reviewed by thousands of eyes, but the eyes are reviewing patches as they go in, not re-reading 9-year-old code that everyone assumes is correct. Qualys reads kernel code as a security research practice. The xz-utils backdoor in 2024 was the same shape of story: code nobody had reread in years. CVE-2026-46333 is not the last of these.

What you can do about it as a one-person shop is not "audit the Linux kernel." It's "have a patch posture that doesn't depend on you reading kernel CVE feeds." The two things that actually help are: enable unattended security updates so kernel patches apply automatically, and run your services in containers so the host kernel isn't directly exposed to your application code.

For Ubuntu and Debian:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

For container isolation, every indie product running on a VPS should be running its application code in Docker or Podman, not as a host-level process. If a hostile local user can't get a shell on your VPS, ssh-keysign-pwn doesn't apply to your threat model.

What I'd actually do this weekend

I run three Hetzner Cloud VPSes. Here's the order I'm patching them in.

The blog VPS is patched first because it has the largest attack surface: multiple Astro builds, public webhooks, and a couple of Cloudflare tunnel daemons. Patch, reboot, confirm kernel version, check /etc/shadow access time. Total time: 8 minutes.

The internal tools VPS is patched second because it has the smallest impact: if something breaks, I notice within an hour and I'm the only affected user. Same procedure.

The customer-facing API VPS is patched last because the downtime window matters. I do it on Sunday morning. Same procedure plus a 5-minute warmup on the health check after reboot.

If you've never set up unattended security updates, do that this weekend too. The version of you that gets the next kernel CVE patched within 12 hours of release is a different person than the version of you that reads about it on Hacker News two weeks later. Set it up once.

The honest counter-take

The risk of CVE-2026-46333 to a specific solo operator's specific VPS depends on whether you have any other local users. If you're the only person with shell access, and you don't run anything that gives untrusted code execution at the unprivileged level (no public Jupyter notebook, no MCP server exposed to outside callers, no agentic AI process with shell access), the local-only attack surface is small. The bug requires local code execution to exploit. It does not give a remote unauthenticated attacker root.

That said, "I'm the only user" is more fragile than it sounds. The web server you forgot to update last quarter, the AI agent you're testing that has Bash tool access, the npm postinstall script you ran an hour ago: any of these can become the local-user the bug needs. The honest read is that a 9-year root flaw matters even when the immediate threat model looks contained.

Patch the kernel. Enable unattended upgrades. Move the application into containers. Then move on to building something.

Author

Lukas

Sources

More Stack articles →

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts