If you have been following our coverage of this month's Linux privilege escalation wave, you know the cadence: Copy Fail, then Dirty Frag, then Fragnesia. This article covers two more disclosures that arrived in the week of May 15 and that have been causing some understandable confusion in coverage: DirtyDecrypt and ssh-keysign-pwn. Before going too much further, let's address that confusion directly, because it matters for how you respond.
A note on the CVE mix-up
Several publications and advisories have been inconsistent about which CVE corresponds to which vulnerability, so here is the definitive breakdown.
DirtyDecrypt (also called DirtyCBC) is tracked as CVE-2026-31635. It is a page-cache write primitive in the Linux kernel's rxgk subsystem, discovered and reported by researchers at Zellic and the V12 security team. A public proof-of-concept was released by the researchers on May 19, 2026. It affects only Linux distributions that ship with CONFIG_RXGK enabled.
ssh-keysign-pwn is tracked as CVE-2026-46333. It is an entirely separate vulnerability: a nine-year-old logic flaw in the kernel's __ptrace_may_access() function, discovered by Qualys's Threat Research Unit. It affects virtually all major Linux distributions by default, regardless of kernel configuration.
The two bugs were disclosed within days of each other and both carry working public exploits - that proximity is why coverage has conflated them. They are distinct vulnerabilities, with different root causes, different affected surfaces, and different mitigations. We're going to cover both.
DirtyDecrypt (CVE-2026-31635)
What is it?
DirtyDecrypt is a Local Privilege Escalation (LPE) vulnerability in the Linux kernel's rxgk (RxGK is a Kerberos 5 security layer for AFS/RxRPC) subsystem. It is a variant in the same page-cache write primitive family as Copy Fail, Dirty Frag, and Fragnesia before it.
The vulnerability was discovered and reported by Zellic co-founder Luna Tong (also known online as cts and gf_256) and the V12 security team on May 9, 2026. When reported, the kernel maintainers informed the team that it was a duplicate of a vulnerability that had already been quietly patched in the mainline - meaning the fix existed before the independent discovery, but the community was unaware of the security implications.
The NVD record for CVE-2026-31635 carries a CNA-assigned CVSS score of 7.5.
How does it work?
The flaw sits in rxgk_decrypt_skb(), the function responsible for decrypting an incoming socket buffer (sk_buff) on the receive side of the rxgk code path. As described by a researcher from Moselwal in their technical write-up:
"In this code path the kernel handles memory pages that are partly shared with the page cache of other processes – a normal Linux optimisation protected by copy-on-write: as soon as a write to a shared page happens, a private copy is made beforehand so that the write doesn't bleed into another process's data." [^1]
[^1] DirtyDecrypt: Linux kernel LPE in the RxGK subsystem (CVE-2026-31635) with public PoC, Kai Ole Hartwig, Moselwal
The copy-on-write guard is missing from rxgk_decrypt_skb. Without it, decryption writes can bleed into the page cache of privileged files, including /etc/shadow, /etc/sudoers, or SUID binaries, without those files being modified on disk. This is the same category of primitive used in every major Linux LPE of the past month: a page-cache write that bypasses on-disk integrity checks.
The specific technical trigger is an inverted bounds check in rxgk_verify_response(), which is supposed to verify that an authenticator length field fits within the remaining packet payload. Because that check is inverted, oversized RESPONSE authenticators pass through and reach rxgk_decrypt_skb(), where the missing COW guard then permits the page-cache write.
Who is affected?
DirtyDecrypt affects only Linux distributions built with CONFIG_RXGK enabled. That configuration is not universal. Distributions known to ship with it enabled include Fedora, Arch Linux, and openSUSE Tumbleweed.
Ubuntu, Debian, RHEL, and most enterprise-oriented distributions do not enable CONFIG_RXGK by default and are not affected by DirtyDecrypt specifically.
In containerized environments, worker nodes running a vulnerable kernel could provide an attacker with a path to escape a pod, in addition to the straightforward local privilege escalation path. [^2]
[^2] DirtyDecrypt PoC Released for Linux Kernel CVE-2026-31635 LPE Vulnerability Ravie Lakshamanan, The Hacker News
How does DirtyDecrypt relate to the earlier LPEs?
It is in the same family. Zellic's disclosure describes it as a variant of Copy Fail (CVE-2026-31431), Dirty Frag (CVE-2026-43284 and CVE-2026-43500), and Fragnesia (CVE-2026-46300): all four produce a page-cache write primitive that grants root access by modifying the in-memory representation of privileged files without touching the disk. Each has a different trigger mechanism and lives in a different kernel subsystem. DirtyDecrypt lives in the rxgk path; its predecessors lived in algif_aead, the XFRM ESP stack, and the ESP-in-TCP ULP respectively.
The practical consequence of being a variant rather than a fully independent class of bug is important: the same detection blind spot applies. File integrity monitoring will see nothing. On-disk hashes remain clean. Detection requires monitoring at the syscall level.
ssh-keysign-pwn (CVE-2026-46333)
What is it?
ssh-keysign-pwn is a nine-year-old improper privilege management flaw in the Linux kernel's ptrace subsystem, tracked as CVE-2026-46333. It was discovered by the Qualys Threat Research Unit (TRU), reported to the upstream Linux kernel security team on May 11, 2026, patched publicly on May 14, and publicly disclosed on May 15. The name derives from the proof-of-concept exploit released by researcher 0xdeadbeefnetwork, which demonstrates reading OpenSSH server host private keys via the ssh-keysign SUID binary.
CVE-2026-46333 carries a CVSS 3.1 score of 5.5, assigned by CISA as Medium severity. Ubuntu has assigned an internal priority of High, noting that the disclosure of sensitive local information to unprivileged users warrants the elevated assessment even at the lower CVSS score.
The flaw has been present in mainline Linux since v4.10-rc1, introduced in November 2016. That is nine years of exposure across enterprise fleets, cloud images, and container hosts.
How does it work?
The root cause is a logic flaw in __ptrace_may_access(), the kernel function that controls whether one process is allowed to inspect another via ptrace. The function uses a dumpable flag to gate access: a process that has dropped privileges is supposed to close the ptrace inspection path by setting this flag appropriately.
The bug creates a narrow window during which a privileged process that is dropping its credentials remains reachable through ptrace-family operations even though the dumpable flag should have blocked that path. An attacker who pairs this window with the pidfd_getfd() syscall (available since kernel v5.6-rc1, January 2020) can capture open file descriptors and authenticated inter-process channels from a dying privileged process and re-use them under their own UID.
Qualys developed four working exploits for CVE-2026-46333, each targeting a different privileged binary:
- chage (set-gid-shadow): discloses
/etc/shadow, exposing hashed local user passwords. - ssh-keysign (set-uid-root): discloses OpenSSH server host private keys from
/etc/ssh/*_key. These keys are used to prove server identity to clients; their disclosure enables on-path attacks against SSH connections. - pkexec (set-uid-root): executes arbitrary commands as root. This path is usable by a remote attacker logged in via SSH, provided an active console session exists.
- accounts-daemon (root daemon): executes arbitrary commands as root via hijacked dbus connections to systemd.
As Saeed Abbasi, Senior Manager of Qualys's Threat Research Unit, noted in the full disclosure: "The primitive is reliable and turns any local shell into a path to root or to sensitive credential material." [^3] Qualys is careful to note that the four exploits above were drawn from prior research and do not represent an exhaustive survey; other SUID, SGID, file-capability binaries, and root daemons may be reachable through the same mechanism.
[^3] CVE-2026-46333: Local Root Privilege Escalation and Credential Disclosure in the Linux Kernel ptrace Path Saeed Abbasi, Qualys
Who is affected?
CVE-2026-46333 affects virtually all major Linux distributions across all releases from Ubuntu 14.04 LTS through Ubuntu 26.04 LTS, Debian, Fedora, AlmaLinux, CloudLinux, Red Hat Enterprise Linux, and SUSE, among others. Distribution security advisories have been issued by AlmaLinux, Amazon Linux, CloudLinux, Debian, Fedora, Gentoo, Red Hat, SUSE, and Ubuntu.
Unlike DirtyDecrypt, there is no special kernel build configuration that restricts exposure. If the kernel is a version introduced after November 2016, it is affected.
In container deployments, Ubuntu notes that the information accessible via exploitation is limited to the confines of the container itself and is generally unlikely to be useful to an attacker, though this should be evaluated against the specific workloads running in any given container.
The disclosure: an embargo that didn't hold
Qualys followed coordinated disclosure. After reporting to the upstream kernel security team on May 11, a fix was committed publicly on May 14. Qualys then engaged the linux-distros mailing list to coordinate downstream patching. Shortly thereafter, an independent researcher derived an exploit from the public kernel commit, ending the effectiveness of the embargo.
The linux-distros list maintainers asked Qualys to move the discussion public, and Qualys published a minimal notice at that point while distributions finished their patching work. The complete advisory was published on May 20 once vendor patches were broadly available.
This is the second time in this month's LPE series that a public kernel commit was identified as security-relevant by an independent researcher and led to early public disclosure; the same pattern forced Hyunwoo Kim's early disclosure of Dirty Frag. The Linux kernel's public development model means that security fixes, once committed, are visible to anyone who reads them. This is a feature of the development process, but it creates a short window between fix and fully distributed patch where exploit writers have an advantage over defenders.
The broader context: five LPEs in a month
Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt, and ssh-keysign-pwn: five Linux kernel privilege escalation disclosures within approximately four weeks. This is an unusual concentration, and it is worth saying plainly what it means and what it does not mean.
It does not mean Linux is uniquely insecure or that the kernel development process is broken. What it reflects is a research community that has been following the page-cache write primitive established by Dirty Pipe in 2022, combined with independent researchers examining the ptrace access control path. When a class of vulnerability proves productive, multiple teams working independently tend to find related bugs in the same neighborhood at roughly the same time.
CVE-2026-46333 is also qualitatively different from the page-cache write series. It is not a novel research direction finding - it is a nine-year-old logic flaw that survived in the kernel because the affected code path is subtle and the security implications of the dumpable flag interaction were not obvious. Its discovery says less about current research momentum and more about the ordinary difficulty of auditing a codebase as large and complex as the Linux kernel.
What the pattern does mean practically is that patch cadence, detection coverage, and live-patching infrastructure are worth reviewing. Five emergency kernel updates in four weeks is not a sustainable operational pace for teams relying on scheduled maintenance windows.
The same detection problem
DirtyDecrypt operates via the page cache, like Copy Fail, Dirty Frag, and Fragnesia before it. File integrity monitoring does not detect it. On-disk hashes remain correct. Detection requires syscall-level monitoring.
CVE-2026-46333 presents a different detection challenge: it involves ptrace and pidfd_getfd() system calls against SUID/SGID processes during a narrow exit window. Detection rules need to look for unprivileged use of pidfd_getfd() against processes with elevated credentials, particularly against binaries known to be exploitable targets (chage, ssh-keysign, pkexec, accounts-daemon).
What should you do?
DirtyDecrypt (CVE-2026-31635)
Step 1: Determine if you are affected. Check whether your kernel was built with CONFIG_RXGK:
grep CONFIG_RXGK /boot/config-$(uname -r)
If the output is CONFIG_RXGK=y or CONFIG_RXGK=m, your kernel is potentially affected. If the key is absent or set to # CONFIG_RXGK is not set, you are not affected by DirtyDecrypt.
Step 2: Patch. If you are running Fedora, Arch Linux, or openSUSE Tumbleweed, apply available kernel updates:
| Distribution | Update command |
|---|---|
| Fedora | sudo dnf update kernel |
| Arch Linux | sudo pacman -Syu |
| openSUSE Tumbleweed | sudo zypper dup |
Step 3: Drop the page cache after patching if there is any possibility the system was exposed prior to the patch:
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
Step 4: Review detection coverage. If your environment has existing detection rules for the earlier page-cache LPE series, review whether they cover the rxgk syscall chain used by DirtyDecrypt, which differs from the XFRM/ESP paths monitored for Dirty Frag and Fragnesia.
ssh-keysign-pwn (CVE-2026-46333)
Step 1: Apply the interim mitigation. Raise kernel.yama.ptrace_scope to 2. This blocks the public exploit path, since pidfd_getfd() is gated by __ptrace_may_access(), and at scope level 2, unprivileged users require CAP_SYS_PTRACE to proceed, which is a capability they do not have.
echo kernel.yama.ptrace_scope=2 | sudo tee /etc/sysctl.d/99-CVE-2026-46333.conf
sudo sysctl -p /etc/sysctl.d/99-CVE-2026-46333.conf
Be aware that raising ptrace_scope to 2 will prevent unprivileged users from attaching debuggers (gdb, strace) to processes they did not launch. Setting it to 3 disables ptrace for all users including root and cannot be reversed without a reboot. Setting to 2 is generally sufficient.
Step 2: Patch. Kernel updates are available from all major distributions. Apply and reboot:
| Distribution | Update command |
|---|---|
| Ubuntu / Debian | sudo apt-get update && sudo apt-get upgrade |
| RHEL / Rocky / AlmaLinux | sudo dnf update kernel |
| Fedora | sudo dnf update kernel |
| SUSE / openSUSE | sudo zypper update kernel-default |
| Amazon Linux | sudo dnf update kernel |
After updating, verify the running kernel version:
uname -r
Step 3: Remove the mitigation after patching. Once the patched kernel is confirmed running:
sudo rm /etc/sysctl.d/99-CVE-2026-46333.conf
sudo sysctl kernel.yama.ptrace_scope=1
Do not set ptrace_scope to 0 after removing the mitigation, as this disables all ptrace protections.
Step 4: Rotate credentials on exposed systems. If any systems ran with untrusted local users during the exposure window, treat SSH host keys and locally cached credentials as potentially compromised. Qualys advises rotating host keys and reviewing any administrative material that lived in the memory of SUID processes. For SSH host key rotation:
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo systemctl restart sshd
Rotating host keys will cause SSH clients to receive a host key mismatch warning on their next connection. Communicate this to your users in advance if possible, or push the updated known_hosts fingerprint through your configuration management tooling.
Summary
| DirtyDecrypt | ssh-keysign-pwn | |
|---|---|---|
| CVE | CVE-2026-31635 | CVE-2026-46333 |
| CVSS Score | 7.5 | 5.5 (CISA) / High (Ubuntu priority) |
| Type | LPE via page-cache write (rxgk COW bypass) | LPE + credential disclosure via ptrace race |
| Researchers | Zellic / V12 security team (Luna Tong et al.) | Qualys Threat Research Unit |
| Introduced | N/A (config-dependent; rxgk subsystem) | November 2016 (Linux v4.10-rc1) |
| Affected distributions | Fedora, Arch Linux, openSUSE Tumbleweed (CONFIG_RXGK only) | All major distributions across all LTS releases |
| Working PoC? | Yes — public as of May 19 | Yes — public as of May 15 |
| Fragnesia mitigation covers this? | No — separate subsystem, separate mitigation | N/A — different vulnerability class |
| Interim mitigation | Verify CONFIG_RXGK; page cache flush | Raise kernel.yama.ptrace_scope to 2 |
| Full fix | Kernel update from your distribution | Kernel update from your distribution |
| Patch available? | Yes, for affected distributions | Yes, from all major distributions |
If you need help assessing your exposure across both vulnerabilities, reviewing your detection coverage for the full LPE series, or managing credential rotation on systems that were exposed before patching, get in touch. The month of May 2026 will be a notable case study in Linux kernel security research for some time - and making sure your environment is clean and hardened on the other side of it is the right priority right now.