Kernel Exploits: When the OS Itself Is the Bug
Every privesc so far has been a misconfiguration, someone set a permission or a sudo rule wrong. A kernel exploit is different: the bug is in the Linux kernel itself, the code that runs everything. Because the kernel runs as the most privileged thing on the machine, a flaw in it can take any user straight to root, no misconfiguration required. The catch: it depends entirely on the kernel being outdated and unpatched, and running one is riskier than the tricks you've already learned.
That risk is why order matters. Exhaust the quiet, safe misconfiguration checks first; the kernel exploit is the last thing you reach for:
Misconfigs are quiet and safe. A kernel exploit is loud and can panic the machine — reach for it only when nothing else works.
Step 1: fingerprint the kernel
A kernel exploit only works against specific versions, so first you find out exactly what you're on:
uname -a # kernel version + architecture (e.g. 5.15.0-105-generic x86_64)
uname -r # just the kernel release
cat /etc/os-release # the distribution and release (Ubuntu 22.04, etc.)
That version string is the input to everything that follows.
Step 2: match it to a known exploit
Search the kernel version against exploit databases:
searchsploit linux kernel 5.15 # local exploit-db copy
# then filter for lines that say "Local Privilege Escalation"
Also search Google / exploit-db / GitHub for "<kernel version> local privilege escalation" and check your distro's security advisories (Ubuntu USN, Red Hat RHSA) to see if the box is missing a patch.
The 2026 headline kernel privescs
New kernel privesc CVEs land regularly, and 2026 has been a busy year. A few that made noise (all give an unprivileged local user root, and all have public exploits):
| CVE | Nickname | Abuses |
|---|---|---|
| CVE-2026-31431 | "Copy Fail" | a crypto + "no-copy" file-transfer trick to write attacker bytes into protected files; actively exploited in the wild (on CISA's KEV list) |
| CVE-2026-46333 | ptrace flaw | a logic bug in __ptrace_may_access() (present since 2016) that leaks files and runs commands as root |
| CVE-2026-43284 / 43500 | "Dirty Frag" | two chained page-cache write bugs (xfrm-ESP + RxRPC); single-command root on kernel 4.10+ |
| CVE-2026-23111 | nftables UAF | a use-after-free in the nftables subsystem, reliable root |
These follow the same lineage as the classics you'll still see on old boxes: DirtyCow (CVE-2016-5195), DirtyPipe (CVE-2022-0847), PwnKit (CVE-2021-4034, a SUID pkexec bug), and Looney Tunables (CVE-2023-4911). The pattern never changes: a memory or logic bug in privileged kernel/system code, triggerable by any local user.
You don't memorise CVEs. You fingerprint the kernel, search for a matching public exploit, and read its write-up.
The risk you must weigh
Kernel exploits are the loudest and most dangerous privesc:
- They can panic the kernel, crashing the whole box (a denial of service you didn't intend, and a very bad look on a client's production server).
- A half-working PoC can corrupt data or leave the system unstable.
- On a real engagement, you try misconfiguration privescs first (SUID, sudo, cron, capabilities, writable files), and reach for a kernel exploit last, only when you understand the PoC and can accept the risk.
Always read the exploit code before running it, prefer PoCs from reputable sources, and test in a snapshot/VM when you can.
Common questions
"How do I know if the kernel is actually vulnerable, or just old-looking?"
A version number alone doesn't prove it. Take the exact uname -r string, search exploit-db/GitHub for a matching local privilege escalation PoC, then confirm the box is missing the patch via the distro's advisories (Ubuntu USN, Red Hat RHSA). Distros backport fixes, so a "5.15" kernel may already be patched against a 5.15 bug.
"The exploit compiled but did nothing (or crashed). Why?" Kernel PoCs are fragile, they target a specific kernel build, config, and sometimes a specific distro. A tiny mismatch means it silently fails or panics. Read the PoC's notes for the exact versions it supports, and never fire a half-working one at a production box.
"Do I need to memorise these CVEs?" No. Nobody memorises kernel CVEs. The skill is the workflow: fingerprint → search → read the write-up → decide if the risk is acceptable. The 2026 names in the table are just examples of what "an outdated kernel is dangerous" looks like this year.
"If it's this risky, why learn it at all?" Because sometimes it's the only door left, a box patched everywhere else may still run a stale kernel. And from the defender's side, knowing this vector is exactly why "patch the kernel promptly" is such high-value advice.
Why this matters
When a box is locked down everywhere else, a forgotten kernel from three years ago is the way in. Recognising an outdated kernel, matching it to a real CVE, and understanding the trade-off of firing a kernel exploit is a core privilege-escalation skill, and it's why patching the kernel promptly is one of the highest-value things a defender does.