Table of contents of the article:
CVE-2026-23111 It is a Linux kernel vulnerability in the subsystem Netfilter / nf_tables which allows, under certain conditions, an unprivileged local user to gain root privileges. This is not a remote vulnerability that can be exploited directly over a network, but rather a Local Privilege Escalation, that is, a vulnerability that is useful to an attacker who has already gained limited access to the system, a user shell, code execution via a compromised web application, or a foothold within a container.
The story is interesting because the bug arises from an inverted logical condition: a single character, the symbol !, changes the expected behavior of the code and opens the way to a use-after-free in the kernel. In practical terms, the problem affects Linux systems that simultaneously expose nf_tables e user namespaces, a fairly common combination on many modern distributions.
If you are a hosting provider, Linux system administrator, or anyone managing multi-tenant servers, container hosts, CI/CD environments, Kubernetes nodes, VPS, or shell user servers, this CVE deserves immediate attention. The risk is not so much that of a direct attack from the outside, but rather the possibility that a relatively limited initial compromise could be transformed into complete control of the system.
What is nf_tables and why is it involved?
nf_tables is the modern Linux kernel framework used by nftables, successor to iptables, ip6tables, arptables, and ebtables. It is the component that allows you to define filtering, NAT, mangling, and network traffic classification rules. Even when the administrator doesn't directly use the command nft, the subsystem may be present and used indirectly by firewall managers, container runtimes, orchestrators, or system tools.
The CVE-2026-23111 vulnerability affects a specific function, nft_map_catchall_activate(), involved in managing the “catchall” elements of nftables maps during transaction abort. nftables works with a transactional model: rule changes are prepared and then applied or rolled back. When something goes wrong, the kernel must properly restore the elements that were temporarily deactivated.
The problem is that in this case the logic was reversed. The function should have skipped the already active elements and reactivated the inactive ones. Instead, due to an incorrect negation, it did the opposite: it skipped the inactive elements and processed the active ones. The upstream fix is conceptually minimal:
- if (!nft_set_elem_active(ext, genmask))
+ if (nft_set_elem_active(ext, genmask))
continue;
This is a classic example where a seemingly trivial change in the kernel source code has very serious security consequences. The vulnerable code can lead to incorrect handling of internal references to chain nftables; by repeating certain operations, the reference count can be incorrectly decremented until a still-referenced structure can be freed. This is where the use-after-free, one of the most dangerous classes of bugs in the kernel.
Use-after-free in the kernel: why it's serious
A use-after-free attack occurs when software continues to use an area of memory after freeing it. In user space, this can already be a significant problem; in the kernel, it's much more serious, because the kernel is the operating system's most privileged component. If an attacker manages to influence the reuse of that memory, they can corrupt internal structures, hijack the flow of execution, or manipulate credentials and privileges.
In the case of CVE-2026-23111, the bug becomes exploitable when an unprivileged user can reach the vulnerable code through the combination of user namespaces e nftablesUser namespaces allow an unprivileged process to appear as root within an isolated namespace. This feature is useful for rootless containers, sandboxes, isolated builds, and some desktop technologies, but it also increases the kernel's attack surface.
The key point is this: even if the user isn't root on the host, within a namespace they can gain sufficient capabilities to interact with parts of the kernel that would normally be inaccessible. If one of these parts contains a vulnerability, isolation can become a bridge to escalation.
It's not a remote RCE, but it shouldn't be underestimated
It's important to avoid false alarmism: CVE-2026-23111 is not a remote code execution attack exposed directly to the Internet. A server isn't compromised simply because it has an open port. However, in Linux security, local vulnerabilities are often crucial in the post-intrusion phase.
An attacker can initially gain limited access through a vulnerable web application, a compromised WordPress plugin, weak SSH credentials, a stolen key, a containerized process, or a service running with reduced privileges. Local Privilege Escalation then allows the attacker to move from a limited user to root, making it much more difficult to contain the incident.
For this reason, the vulnerability should be considered particularly relevant in the following scenarios:
- shared hosting server with multiple local users;
- servers with SSH access granted to customers, developers or vendors;
- container host Docker, Podman, LXC or Kubernetes;
- CI/CD runners that compile or test code that is not fully trusted;
- multi-tenant environments;
- web servers where an application compromise could provide a limited shell;
- systems with user namespaces enabled for non-privileged users.
On a traditional server, without untrusted local users and rootless containers, the urgency may be less, but the kernel still needs to be updated. In a professional context, it's not advisable to leave a known kernel vulnerability with public technical details waiting indefinitely.
Affected distributions and patch status
The vulnerability has been fixed upstream in the Linux kernel and publicly tracked as CVE-2026-23111 in the National Vulnerability DatabaseUbuntu classifies it as a high-priority vulnerability, explicitly describing the possibility of local escalation via user namespaces and nftables. Debian tracks it in its Security Tracker, with correct versions for supported branches.
For the Enterprise Linux world, AlmaLinux has included CVE in kernel updates. In particular, for Alma Linux 9 the vulnerability is present in the advisory ALSA-2026:6570, while for Alma Linux 10 is present in the advisory ALSA-2026:18134Rocky Linux and RHEL-derived distributions also track the fix in kernel package updates.
The operational advice is simple: do not attempt to manually patch the kernel source on production servers. You should install the correct kernel provided by the distribution vendor and reboot the system into the new kernel.
How to quickly check your system
The first check is the version of the kernel currently running:
uname -r
This command displays the actual booted kernel, not simply the latest installed kernel. This is a crucial distinction: after a kernel package update, the system remains vulnerable until it reboots into the correct kernel.
To check if nftables modules are present or loaded:
lsmod | grep -E 'nf_tables|nft'
To check kernel configuration options:
zgrep -E 'CONFIG_USER_NS|CONFIG_NF_TABLES' /proc/config.gz 2>/dev/null || \
grep -E 'CONFIG_USER_NS|CONFIG_NF_TABLES' /boot/config-$(uname -r)
If the system exposes both CONFIG_USER_NS is CONFIG_NF_TABLES, the machine should be considered potentially exposed, unless the vendor has already provided an applied patch and the server has been rebooted into the correct kernel.
On AlmaLinux, Rocky Linux, RHEL and derivatives it is also useful to check the value of user.max_user_namespaces:
sysctl user.max_user_namespaces
A value greater than zero indicates that the system allows the creation of user namespaces up to the configured limit. A value of zero effectively disables the creation of user namespaces.
How to patch on AlmaLinux, Rocky Linux and RHEL-like
On AlmaLinux and compatible Enterprise Linux systems, the recommended procedure is to update kernel packages via dnf:
dnf clean all
dnf update -y 'kernel*'
reboot
After rebooting, check the running kernel again:
uname -r
rpm -q kernel kernel-core kernel-modules
To determine if a reboot is still required after the update, you can use:
dnf install -y yum-utils
needs-restarting -r
If the command indicates that the system needs to be rebooted, the updated kernel isn't running yet. In a server context, especially hosting or container hosting, this step shouldn't be skipped: updating RPMs without rebooting doesn't eliminate the risk.
Temporary mitigation: Disable user namespaces
When immediate reboot is not possible, an effective mitigation is to disable the creation of user namespaces by unprivileged users. On AlmaLinux, Rocky Linux, and RHEL-like systems, the correct path is to use the parameter user.max_user_namespaces:
cat > /etc/sysctl.d/99-disable-userns.conf <<'EOF'
user.max_user_namespaces = 0
EOF
sysctl --system
The verification is performed with:
sysctl user.max_user_namespaces
The expected output is:
user.max_user_namespaces = 0
This mitigation reduces the attack surface by preventing unprivileged users from creating user namespaces. However, it's not a patch. It simply buys time until a reboot into the correct kernel.
Side effects must also be considered. Disabling user namespaces can break rootless containers, rootless Podman, rootless Buildah, some build environments, sandboxes, and tools that depend on this feature. On a traditional hosting server with a web stack, database, mail, and dashboards like Plesk or cPanel, this mitigation is often acceptable. However, on a container node or advanced development environments, it should be considered more carefully.
Debian and Ubuntu: operational differences
On Debian and Ubuntu the patch is normally applied by updating the kernel packages:
apt update
apt full-upgrade -y
reboot
After reboot:
uname -r
dpkg -l 'linux-image*' | grep '^ii'
On these distributions the following parameter may also be present:
kernel.unprivileged_userns_clone
For a temporary mitigation on Debian/Ubuntu it is therefore common to see:
sysctl -w kernel.unprivileged_userns_clone=0
printf 'kernel.unprivileged_userns_clone = 0\n' > /etc/sysctl.d/99-disable-unpriv-userns.conf
sysctl --system
This parameter should not be taken for granted on AlmaLinux or RHEL-like systems. In those contexts the most correct parameter to use is user.max_user_namespaces.
Priority intervention for those who manage Linux hosting and servers
In a real-world infrastructure, not all systems have the same priority. The practical ranking might be as follows.
Top priority for hosts running containers, Kubernetes environments, multi-tenant servers, user-shelled machines, CI/CD systems, and servers running client or developer code that is not fully trusted.
High priority For web servers exposed to the Internet, even if they don't allow direct shells. An application vulnerability in WordPress, Magento, PrestaShop, Joomla, or a plugin can provide initial local access, and such a kernel CVE can turn that limited access into complete compromise.
Ordinary but necessary priority For isolated servers, without local users and without containers. Patches are still required in this case, but the maintenance window can be scheduled less urgently than in a multi-tenant environment.
Why Kernel Patching Requires Discipline
Local kernel vulnerabilities are sometimes overlooked because they don't directly expose a network service. This is a mistake. In a modern attack chain, the hardest part isn't always gaining initial access: it's often maintaining it, elevating it, and moving laterally. Reliable local privilege escalation is precisely what allows an attacker to turn a limited incident into an infrastructure problem.
In the case of CVE-2026-23111, the risk is increased by the publication of technical details and independent reproductions. This doesn't mean every system is automatically compromised, but it does mean that the window between public disclosure and actual exploitation is narrowing. When a kernel bug becomes understandable, reproducible, and documented, time is on the attackers' side.
Conclusion
CVE-2026-23111 is a technically elegant and operationally dangerous vulnerability: a single incorrect character in the code of nf_tables It can lead to a use-after-free exploit that can be exploited for local escalation to root. This is not a direct remote vulnerability, but it is highly relevant in any environment where an unprivileged user, container, or compromised process can interact with the kernel through user namespaces and nftables.
The recommendation is clear: update the kernel from your distribution's official repository and rebootWhile waiting for the reboot, on AlmaLinux and RHEL-like distributions it is possible to temporarily mitigate this by setting user.max_user_namespaces = 0, but evaluating the impact on rootless containers and sandboxes.
For those managing hosting infrastructure, Linux servers, and multi-tenant environments, this CVE reminds us of a fundamental principle: security isn't limited to patching web applications. The kernel, namespaces, firewalling, and seemingly "low-level" features are an integral part of the attack surface. An updated system, rebooted with the correct kernel, and configured with a minimal surface area remains the strongest foundation for reducing operational risk.
