CVE-2026-23111: The `nf_tables` UAF Nightmare & Container Escape
Just caught the Exodus Intelligence write-up on CVE-2026-23111. It’s wild that a single character omission in the Linux kernel's nf_tables code leads to a full local privilege escalation (LPE) and container breakout.
This use-after-free (UAF) vulnerability sits in the packet-filtering framework and was patched upstream back in February, but the full exploit dropped recently. If you have unprivileged local access—perhaps inside a container—you can potentially hit this to break out and gain root on the host.
Technical Summary:
- CVE: CVE-2026-23111
- Component: Netfilter
nf_tables - Impact: LPE, Container Escape
- Patch Date: Feb 5, 2026
Since this leverages nf_tables, the first step in triage is checking if your systems are actually loading the module and checking kernel versions against the patch releases.
You can quickly audit your fleet with this one-liner to see if nf_tables is active:
lsmod | grep nf_tables
And verify your kernel version against your distro's security advisory. If you are running kernels older than the Feb 5 patch and use nftables, you are in the danger zone.
Detection:
While exploiting UAFs is generally subtle, successful exploitation might trigger kernel oops logs or crashes before the attacker stabilizes the shell. Watch /var/log/kern.log for generic page faults or general protection faults in nf_tables context.
For those running multi-tenant Kubernetes clusters, this is critical. How are you handling the patch rollout for nodes that can't be rebooted immediately? Are you relying on Seccomp profiles to block the netlink syscalls required to trigger this, or just crossing your fingers?
The scary part here is the reliability. Usually, UAF exploits are touchy, but the report suggests this is very stable. For my pentests, I'm checking if nft is available immediately.
If you can't patch right now, restricting access to the netlink family via Seccomp or AppArmor is your best bet. You can block the specific netlink messages used to manipulate nf_tables.
Here is a basic auditd rule to watch for suspicious nft commands:
-w /sbin/nft -p x -k nft_changes
This is a nightmare for our legacy RHEL-based systems that are stuck on older kernels. We don't even use nftables internally (we stick to iptables), but the module is often auto-loaded by dependencies or systemd.
I've pushed a cron job across the fleet to blacklist the module immediately as a stopgap:
echo "install nf_tables /bin/true" >> /etc/modprobe.d/disable-nf_tables.conf
It's a hammer, but it works until we can schedule maintenance windows.
From a SOC perspective, detecting the exploit attempt before root is gained is tough. However, if you have eBPF monitoring enabled, you might catch the allocation patterns or the specific syscalls being made in rapid succession.
I'd recommend checking for unexpected children processes spawning from your container runtimes (like runc) or users suddenly switching to UID 0 without a corresponding sudo log entry in /var/log/secure.
That’s a valid concern, SA_Admin_Staff. For systems that can't reboot yet, verify if the vulnerable module is actually active in memory despite not using it explicitly. You can quickly check loaded kernel modules with:
lsmod | grep nf_tables
If it returns nothing, you might be safe from this specific vector, provided it doesn't get auto-loaded by a subsequent trigger. If it is loaded and you aren't using nftables, unloading it immediately might serve as a temporary stopgap until the patch cycle finishes.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access