DirtyDecrypt PoC Drop: CVE-2026-31635 LPE Analysis
Just saw that the PoC for DirtyDecrypt (CVE-2026-31635) has officially dropped. For those who missed the initial report back in May, this is a Linux Kernel Local Privilege Escalation (LPE) vulnerability discovered by the Zellic and V12 teams.
Interestingly, when they reported it on May 9, the maintainers marked it as a duplicate of an internal finding. Regardless of the history, the exploit is now public (dubbed DirtyCBC as well), and it targets the kernel's handling of decryption contexts.
If you are running standard Linux distributions, you need to verify your kernel version against the latest patches immediately. Since this is an LPE, the primary risk is if an attacker already has a foothold (via a web shell or compromised user account). They can leverage this to gain root access.
You can quickly check your current kernel version with:
uname -r
For detection, keep an eye out for suspicious prctl operations or unauthorized attempts to load kernel modules, although the PoC is somewhat subtle in its execution.
Given the recent spate of 'Dirty' vulnerabilities (Pipe, Cred, Cow), how is everyone handling the patch cycle? Are you relying on live-patching solutions like KernelCare, or are you scheduling downtime for kernel updates immediately?
We're strictly using live-patching for our production fleets. With the frequency of these kernel LPEs, scheduling reboots every other week just isn't feasible for our SLAs. We deployed the KernelCare patch for this specific CVE within hours of the PoC dropping. It’s a bit pricey, but the uptime is worth it.
I've been testing the PoC in a lab environment. It's fairly reliable against default Ubuntu 22.04 installs running the generic kernel prior to the May patches. The race condition window is tight, but the script retries effectively. If you have strict seccomp profiles or SELinux in enforcing mode, it might fail, but don't rely on that.
Detection-wise, I've updated our Falco rules to catch the specific sequence of syscalls used during the exploit's setup phase. It's noisy if you aren't filtering, but catching the memfd_create combined with specific ioctl calls on unprivileged processes is a strong indicator. Here is the basic filter logic we are testing:
- rule: DirtyDecrypt Suspicious Activity
desc: Detect potential DirtyDecrypt exploit usage
condition: >
spawn and proc.name = bash and
fd.type in (memfd, unknown)
output: "Potential DirtyDecrypt exploit (user=%user.name command=%proc.cmdline)"
priority: WARNING
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access