CVE-2026-23111, the nf_tables Bug Behind a One-Character Root Privesc

CVE-2026-23111 is a Linux kernel local privilege escalation bug in nf_tables, the kernel subsystem behind nftables. It is not a remote firewall bypass. It does not let an attacker scan the internet, hit an exposed port, and instantly own a server. The real risk is different and often more useful to attackers: a local, low-privileged foothold can become root when the vulnerable kernel path is reachable through user namespaces and nftables.

The root cause is small enough to look harmless in a patch diff. In nft_map_catchall_activate(), the Linux kernel used the wrong sense of an activity check while aborting a failed nf_tables transaction. The fix changes a condition from “not active” to “active,” but that one inverted check affects reference accounting for catchall verdict map elements. When the affected element uses an NFT_GOTO verdict, a chain reference can fail to be restored during abort. Repeating the abort path can drop a chain’s use counter to zero, allow the chain to be deleted, and leave other nf_tables state holding a stale reference. That is the use-after-free. The NVD entry describes the flaw as a use-after-free in Linux kernel netfilter nf_tables, assigns CWE-416, and gives it a CVSS 3.1 base score of 7.8 High with local attack vector and high confidentiality, integrity, and availability impact. (NVD)

The upstream patch is also unusually clear. The Linux kernel commit titled “netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()” says the function is called from the abort path to reactivate catchall map elements deactivated by a failed transaction, and that it should skip already active elements while processing inactive ones. The diff changes one line in net/netfilter/nf_tables_api.c, replacing if (!nft_set_elem_active(ext, genmask)) と if (nft_set_elem_active(ext, genmask)). (ギットハブ)

That is why CVE-2026-23111 deserves more attention than its “local” label suggests. Many real intrusions already start with local code execution: a web shell running as wwwデータ, a compromised CI job, a malicious package script, an untrusted build task, a low-privileged SSH account, a browser exploit landing in a sandbox, or code running inside a container. On systems where unprivileged user namespaces expose enough kernel attack surface, a kernel local privilege escalation can become the step that turns a limited foothold into full host control.

Quick facts for defenders

Area	What matters
CVE	CVE-2026-23111
コンポーネント	Linux kernel netfilter nf_tables
Bug class	Use-after-free, CWE-416
根本原因	Inverted generation-mask activity check in nft_map_catchall_activate() during nf_tables transaction abort
Main impact	Local privilege escalation, potentially from low-privileged user to root
CVSS	NVD CVSS 3.1 score 7.8 High, vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Common exposure condition	Vulnerable kernel plus reachable nftables path, often through unprivileged user namespaces and network namespaces
What it is not	A standalone unauthenticated remote exploit
Primary fix	Install the fixed vendor kernel package and reboot into it
Temporary risk reduction	Restrict unprivileged user namespaces where operationally safe, harden container workloads, remove unnecessary namespace and network capabilities
Validation priority	Highest on multi-user Linux hosts, container hosts, Kubernetes nodes, CI runners, developer workstations, bastion hosts, and systems running untrusted workloads

Ubuntu rates the issue High and states that a local unprivileged user may use the vulnerability to gain root privileges through a use-after-free. Its advisory page lists fixed kernel package versions for multiple supported Ubuntu lines, including Ubuntu 25.10, Ubuntu 24.04 LTS, and Ubuntu 22.04 LTS. (Ubuntu) Debian’s tracker also records fixed source package versions for several branches and shows why distro-specific package state matters more than upstream version strings alone. (security-tracker.debian.org)

What nf_tables is doing in the kernel

Netfilter is the packet filtering and network hook framework inside the Linux kernel. nftables is the newer userspace interface and in-kernel ruleset model that replaced the older iptables, ip6tables, arptables, and ebtables tooling in many distributions. The nft command configures tables, chains, rules, expressions, and sets in the kernel’s nf_tables subsystem. Netfilter’s own documentation describes nftables as a packet classification framework that reuses the existing netfilter hooks, connection tracking, NAT, queueing, and logging infrastructure. (netfilter.org)

A simplified nftables ruleset has several layers.

対象	Plain-English meaning	Why it matters for CVE-2026-23111
Table	A namespace for nftables objects	Holds chains, sets, maps, and rules
Chain	A sequence of rules, often attached to a netfilter hook or called from another chain	The vulnerable path can leave a stale reference to a chain after its use counter is mishandled
Rule	A set of expressions and actions	Rules can reference maps and verdicts
Expression	Matching or action logic inside a rule	Expressions drive evaluation and can use sets or maps
セット	A collection of elements used for matching	Some sets can behave as maps
Verdict map	A map whose values are verdicts such as jump, goto, accept, drop, or continue	CVE-2026-23111 is tied to catchall map elements with verdict behavior
Catchall element	A fallback element used when no more specific element matches	The vulnerable function handles catchall map elements during transaction abort
Generation mask	A mechanism used to distinguish active and inactive state across current and next generations	The inverted check misclassifies what should be skipped or reactivated

The dangerous part is not packet filtering in the data plane. The dangerous part is the control plane: the kernel code that accepts nftables configuration changes, stages them as transactions, commits them, or rolls them back. That distinction matters because defenders often assume firewall vulnerabilities require remote traffic hitting a rule. In this case, the attacker interacts with the nf_tables configuration machinery locally.

nftables supports verdict maps. The nftables wiki describes verdict maps as maps that can return verdicts directly, internally using the generic set infrastructure. (wiki.nftables.org) A verdict map can point evaluation toward another chain. A catchall element can act as a fallback verdict when no specific key matches. That is useful functionality, but it also means the kernel must manage object lifetimes carefully. If a map element refers to a chain, the chain’s reference count has to stay correct across normal updates, deletes, failed transactions, and abort cleanup.

CVE-2026-23111 is a failure in that cleanup logic.

The transaction model that makes the bug possible

nf_tables updates are transactional. Userspace sends a batch of operations to the kernel. The kernel prepares the changes, checks constraints, and then either commits them or aborts them. This model is necessary because firewall state must not end up half-applied. A batch can include multiple operations, and later operations may fail after earlier operations have already staged changes.

A simplified transaction flow looks like this:

userspace nft request
        |
        v
nf_tables batch begins
        |
        v
prepare staged updates
        |
        +--------------------+
        |                    |
        v                    v
all checks pass        one operation fails
        |                    |
        v                    v
commit changes         abort transaction
                             |
                             v
                     restore objects that were
                     deactivated or modified

Generation masks help nf_tables represent object activity across transaction generations. A set element can be active in one generation and inactive in another. When a transaction is aborted, objects that were deactivated during the failed transaction often need to be reactivated so the ruleset remains consistent with the pre-transaction state.

The vulnerable function, nft_map_catchall_activate(), is responsible for catchall map elements in that abort path. The intended logic is simple: skip catchall elements that are already active in the relevant generation, and process catchall elements that are inactive and need to be restored.

The patch shows the bug directly:

/* Vulnerable logic */
if (!nft_set_elem_active(ext, genmask))
        continue;

/* Fixed logic */
if (nft_set_elem_active(ext, genmask))
        continue;

The vulnerable condition skips the wrong elements. Instead of skipping already active catchall elements, it skips inactive ones. For the CVE-2026-23111 path, that means the abort cleanup fails to properly reactivate a catchall verdict element that had been deactivated by the failed transaction.

The upstream commit explains the consequence: for NFT_GOTO verdict elements, nft_data_hold() is not called to restore chain->use, so each abort can permanently decrement the chain’s use counter. Eventually, a chain can be deleted while a catchall verdict element still refers to it. (ギットハブ)

That is the shape of the vulnerability: a reference count and object lifetime mismatch triggered through transaction rollback.

Why the bug becomes a use-after-free

A use-after-free occurs when code continues using memory after the object that owned that memory has been freed. In kernel space, this is especially dangerous because freed memory can later be reused for another object. If an attacker can influence what occupies that memory, a stale pointer can become a primitive for leaking kernel memory, corrupting kernel data, or changing control flow.

For CVE-2026-23111, the important object is a chain referenced by a catchall verdict map element. The high-level sequence is:

1. A verdict map contains a catchall element that references a chain.
2. A transaction deactivates that catchall element.
3. A later operation in the same batch fails.
4. nf_tables abort handling should reactivate the catchall element.
5. The inverted genmask check skips the element that needed reactivation.
6. For NFT_GOTO, the chain use counter is not restored.
7. Repeating the path can drive chain->use down incorrectly.
8. The chain can be deleted even though a stale reference remains.
9. Later nf_tables evaluation or validation can touch freed chain memory.

Security researchers have published technical exploitation analyses showing how this can be turned into local privilege escalation. Exodus Intelligence wrote that it found the bug in early 2025, that it was patched upstream on February 5, 2026, and that it demonstrated local unprivileged root exploits on Debian Bookworm, Debian Trixie, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. (エクソダス・インテリジェンス) FuzzingLabs independently reproduced CVE-2026-23111 on a Red Hat Enterprise Linux 10 kernel and described the bug as an inverted condition in the catchall abort path that can be used to trigger a use-after-free. (FuzzingLabs)

Those public writeups matter for defense because they move the issue from “theoretical local kernel bug” to “documented exploitation path.” They do not change the primary remediation: update the kernel and reboot. They do change the urgency for systems where attackers might already run low-privileged code.

The exposure condition most teams miss

A local kernel privilege escalation has two parts: a vulnerable kernel path and a way for the attacker to reach that path. For CVE-2026-23111, user namespaces are central to that reachability on many systems.

User namespaces let a process have namespace-local privileges that do not map to full host root. They are important for container runtimes, application sandboxing, build isolation, and rootless workflows. Ubuntu’s security team has noted that unprivileged user namespaces can replace many setuid and setgid use cases and allow applications to create more secure sandboxes, while also exposing kernel interfaces that are normally restricted to privileged processes. (Ubuntu)

That tradeoff is the heart of the risk. User namespaces are not “bad.” They support real security architecture. But when a kernel bug sits behind a namespace-reachable subsystem, unprivileged namespace creation can turn a local user into a kernel attacker.

A defender should think about CVE-2026-23111 exposure in layers:

レイヤー	Question	なぜそれが重要なのか
Kernel code	Is the running kernel vulnerable, or has the distro backported the fix	Package state determines whether the bug exists
Runtime state	Has the system rebooted into the fixed kernel	Installing a kernel package without rebooting often leaves the old kernel running
Namespace policy	Can an unprivileged user create user and network namespaces	This often determines whether a low-privileged user can reach nf_tables paths
Workload model	Do untrusted users, CI jobs, build scripts, containers, or plugins run on the host	Local-only bugs matter most where local code is expected
Container boundary	Can containerized workloads access enough namespace and netfilter functionality	Shared-kernel environments can turn container footholds into host risk
モニタリング	Can the team see unexpected namespace creation and nftables activity	Detection is mostly host-based, not network-based

The systems most exposed are not necessarily internet-facing web servers. They are systems that run code from many sources: developer workstations, build runners, Kubernetes nodes, shared Linux bastions, multi-tenant research boxes, security testing labs, container hosts, and servers where compromised service accounts can execute local commands.

Why “local only” is not low priority

Security teams sometimes downgrade local privilege escalation because the attacker already needs a foothold. That can be a mistake. Modern intrusion chains often look like this:

phishing, exposed service, stolen token, vulnerable app, malicious package
        |
        v
low-privileged code execution
        |
        v
local privilege escalation
        |
        v
credential theft, kernel tampering, container escape, persistence
        |
        v
lateral movement or data access

CVE-2026-23111 fits the second step. It is not the initial access bug. It is the bug that can make initial access much worse.

A low-privileged web process that cannot read /root, dump other users’ processes, load kernel modules, modify firewall state, or access host secrets is still constrained. Root on the host changes that. Root can read service credentials, inspect memory, modify binaries, interfere with logging, access mounted secrets, tamper with containers, and pivot into adjacent infrastructure.

The same logic applies to containers. A container is not a VM. Most containers share the host kernel. If an attacker can trigger a kernel use-after-free from inside a container or a namespace reachable from the container, the security boundary can collapse. The exact exploitability depends on runtime configuration, capabilities, seccomp, AppArmor or SELinux policy, kernel version, and namespace access. But the architectural point is simple: kernel local privilege escalation bugs matter more on shared-kernel platforms than their CVSS wording often conveys.

Affected versions and vendor state

The NVD entry lists multiple affected Linux kernel version ranges, including older long-term lines and newer release candidates. It also records the upstream fix references and the CVSS 3.1 score. (NVD) Treat those upstream ranges as vulnerability intelligence, not as the only patch decision. Linux distributions routinely backport security fixes without changing to the exact upstream fixed version. A Debian, Ubuntu, SUSE, Red Hat, or Amazon Linux kernel may be fixed even if its version string looks older than an upstream release. The reverse can also happen in custom kernels.

A practical vendor-state summary looks like this:

Vendor or source	What the public advisory data shows	How to use it
Upstream Linux kernel	The fix is a one-line correction in nft_map_catchall_activate() removing the inverted check	Useful for understanding root cause and custom kernel patching
NVD	CVE-2026-23111 is a Linux kernel nf_tables use-after-free, CVSS 7.8 High, CWE-416	Useful for inventory, scoring, and vulnerability management records
Ubuntu	Rated High, with fixed package versions listed for supported Ubuntu kernel packages	Compare installed and running kernel package against Ubuntu’s advisory
Debian	Tracker lists fixed versions across Debian branches and security tracks	Check exact source package and branch, not only uname -r
SUSE	Advisory page marks the issue resolved, rates it important, and repeats the user-namespace plus nftables local privilege escalation condition	Use SUSE’s package guidance for SUSE systems
Amazon Linux	Public advisory data lists affected package tracks and security advisory identifiers for fixed Amazon Linux 2023 kernel lines	Check the current Amazon Linux advisory and installed package state

SUSE describes the flaw as a vulnerability in which an unprivileged user can escalate privileges via user namespaces and nftables, and rates the issue Important with a CVSS 3.1 score of 7.8. (suse.com) Amazon Linux advisory data lists CVE-2026-23111 as Important and associates fixes with Amazon Linux 2023 kernel advisories for affected tracks. (explore.alas.aws.amazon.com)

The safest rule is:

Do not decide CVE-2026-23111 exposure from upstream kernel version alone.
Decide it from the vendor advisory, installed package version, and running kernel.

A second rule is just as important:

Installing a fixed kernel is not enough if the host is still running the old kernel.

Linux kernel updates usually require rebooting into the new kernel. Some live patch systems can reduce exposure for certain kernel vulnerabilities, but a team still needs vendor confirmation that a live patch covers this specific flaw and that the running kernel state is actually patched.

Safe exposure checks

The following checks are defensive. They do not attempt to trigger the vulnerability. They help answer five questions:

1. What kernel is running?
2. What distribution and package track is this host using?
3. Is nf_tables present?
4. Are unprivileged namespaces available?
5. Is a fixed kernel installed and active?

Start with the OS and running kernel:

uname -a
uname -r
cat /etc/os-release

Check whether the kernel config exposes the relevant features. Not every system keeps the config in the same place, so try both common locations:

grep -E 'CONFIG_NF_TABLES|CONFIG_USER_NS' /boot/config-$(uname -r) 2>/dev/null || true
zgrep -E 'CONFIG_NF_TABLES|CONFIG_USER_NS' /proc/config.gz 2>/dev/null || true

Typical output might look like this:

CONFIG_NF_TABLES=m
CONFIG_USER_NS=y

CONFIG_NF_TABLES=m means nf_tables is available as a module. CONFIG_USER_NS=y means user namespaces are compiled into the kernel. These values do not prove exploitability by themselves. They tell you whether key pieces of the attack surface exist.

Check namespace policy:

sysctl kernel.unprivileged_userns_clone 2>/dev/null || true
sysctl user.max_user_namespaces 2>/dev/null || true
sysctl kernel.apparmor_restrict_unprivileged_userns 2>/dev/null || true

Interpretation needs distro context:

Setting	意味	Caveat
kernel.unprivileged_userns_clone	Common Debian and Ubuntu-style control for unprivileged user namespace creation	Not present on every distro
user.max_user_namespaces	Limits the number of user namespaces	Setting it too low can break rootless containers, browsers, build tools, and sandboxes
kernel.apparmor_restrict_unprivileged_userns	Ubuntu AppArmor-based restriction for unprivileged user namespaces	Ubuntu-specific behavior, not a universal Linux control

Qualys has documented Ubuntu’s AppArmor-based unprivileged user namespace restriction model, including that Ubuntu 24.04 enabled such restrictions by default while also discussing bypass considerations in specific contexts. (クオリス) The operational takeaway is not “Ubuntu is immune.” It is that namespace policy is now a real part of Linux kernel exposure management and must be checked alongside kernel package state.

Check nftables tooling and current ruleset:

command -v nft && nft --version
sudo nft list ruleset 2>/dev/null | head -n 80
lsmod | grep -E '^nf_tables|^nft_' || true

The presence of nft is not required for exploitation if an attacker can use netlink directly or bring their own tooling, but it is useful for inventory. The loaded module list can show whether nf_tables-related modules are active. A module not currently loaded does not always mean the attack surface is impossible; autoloading and kernel configuration matter.

For Debian and Ubuntu package checks:

dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'
apt-cache policy linux-image-generic 2>/dev/null || true
apt list --upgradable 2>/dev/null | grep -E '^linux-(image|generic|headers)' || true

On Ubuntu, compare the installed package to Ubuntu’s fixed versions for your release. Ubuntu’s page lists, for example, fixed versions including 6.8.0-107.107 for Ubuntu 24.04 LTS and 5.15.0-174.184 for Ubuntu 22.04 LTS in the main linux package track. (Ubuntu)

For Red Hat-family, Fedora, and Amazon Linux systems, package and advisory tooling varies by release, but the shape is similar:

rpm -q kernel
dnf updateinfo list --cve CVE-2026-23111 2>/dev/null || true
yum updateinfo list --cve CVE-2026-23111 2>/dev/null || true
needs-restarting -r 2>/dev/null || true

もし needs-restarting -r reports that a reboot is required, treat the host as not fully remediated even if the fixed package is installed.

A small triage script can collect evidence without touching exploit paths:

#!/usr/bin/env bash
set -euo pipefail

echo "== Host =="
hostname
date -Is
cat /etc/os-release 2>/dev/null | sed -n 's/^PRETTY_NAME=//p'
echo "Running kernel: $(uname -r)"

echo
echo "== Kernel config signals =="
grep -E 'CONFIG_NF_TABLES|CONFIG_USER_NS' "/boot/config-$(uname -r)" 2>/dev/null \
  || zgrep -E 'CONFIG_NF_TABLES|CONFIG_USER_NS' /proc/config.gz 2>/dev/null \
  || echo "Kernel config not readable from common locations"

echo
echo "== Namespace policy =="
for key in \
  kernel.unprivileged_userns_clone \
  user.max_user_namespaces \
  kernel.apparmor_restrict_unprivileged_userns
do
  sysctl "$key" 2>/dev/null || true
done

echo
echo "== nftables signals =="
if command -v nft >/dev/null 2>&1; then
  nft --version
else
  echo "nft command not found in PATH"
fi
lsmod 2>/dev/null | grep -E '^nf_tables|^nft_' || echo "No nf_tables modules visible in lsmod output"

echo
echo "== Debian or Ubuntu kernel packages =="
if command -v dpkg >/dev/null 2>&1; then
  dpkg -l 'linux-image*' 2>/dev/null | awk '/^ii/ {print $2, $3}' || true
fi

echo
echo "== RPM kernel packages =="
if command -v rpm >/dev/null 2>&1; then
  rpm -q kernel 2>/dev/null || true
fi

echo
echo "== Reboot check hints =="
if command -v needs-restarting >/dev/null 2>&1; then
  needs-restarting -r || true
elif [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required
else
  echo "No distro reboot indicator found in common locations"
fi

This script is safe for production triage because it reads system state. It does not create nftables transactions. It does not create user namespaces. It does not exercise the vulnerable abort path.

What exploitation looks like at a defensive level

A defender does not need to reproduce a public exploit to understand the risk. The important properties are:

Property	Defensive meaning
Local entry point	Watch hosts where attackers can already run code
Namespace dependence	Harden unprivileged user and network namespace creation where possible
nf_tables transaction abuse	Look for suspicious nftables configuration activity by unexpected users
Kernel memory corruption	Expect weak traditional IOCs and focus on patch state plus behavioral telemetry
Root outcome	Treat successful exploitation as full host compromise
Container relevance	Container boundaries may not protect the host if the kernel is exploitable

Public exploitation writeups describe kernel-base leakage, heap shaping, and control-flow techniques. Those details are useful for exploit developers and kernel security researchers, but production defenders should not need to run an exploit to prioritize remediation. Exodus Intelligence’s public analysis states that the exploit was demonstrated on multiple Debian and Ubuntu releases, while FuzzingLabs described a reproduction on RHEL 10. (エクソダス・インテリジェンス) The Hacker News reported on June 8, 2026 that working exploit details were public, that the issue had no remote vector by itself, and that there were no public reports of in-the-wild exploitation at that time. (ハッカーニュース)

That last sentence should not be read as comfort. Public exploit details for local kernel bugs often matter because attackers can combine them with unrelated initial-access bugs. A remote web vulnerability, exposed SSH credential, malicious dependency, or compromised build token can provide the local execution needed to use a kernel LPE.

Detection and hunting

There is no reliable network signature for CVE-2026-23111. A remote IDS looking at packets will usually not see “CVE-2026-23111 exploitation.” The activity happens through local kernel interfaces. Detection has to come from host telemetry, kernel logs, process execution, audit events, and workload context.

Useful signals include:

信号	Why it may matter	Common false positives
Unexpected unshare, cloneあるいは clone3 activity by low-privileged users	Attackers may create user and network namespaces to reach kernel attack surface	Rootless containers, browser sandboxes, build tools
Unexpected nft 執行	Simple exploit setups may use nftables tooling or helper commands	Admin firewall changes, container networking, security tools
Netlink activity modifying nf_tables from unusual processes	The vulnerable path is reached through nf_tables control operations	Legitimate network managers and firewall controllers
Rapid create/delete batches involving nftables sets, maps, or chains	Transaction abuse can involve repeated abort-like patterns	Firewall reload loops, orchestration bugs
Kernel oops, general protection faults, slab warnings	Failed exploitation or unstable memory corruption may crash or warn	Hardware issues, unrelated kernel bugs
Sudden privilege jump from service user to root behavior	Successful LPE changes post-exploitation behavior	Legitimate sudo, automation, admin scripts

Auditd can help capture namespace creation attempts. This is not a complete exploit detector, but it gives defenders a starting point:

sudo auditctl -a always,exit -F arch=b64 -S unshare -S clone -S clone3 \
  -F auid>=1000 -F auid!=4294967295 \
  -k userns_activity

Search recent events:

sudo ausearch -k userns_activity -ts recent
sudo aureport -x --summary | head -n 30

You can add process execution monitoring for nftables tooling:

sudo auditctl -w /usr/sbin/nft -p x -k nft_exec
sudo auditctl -w /sbin/nft -p x -k nft_exec 2>/dev/null || true
sudo ausearch -k nft_exec -ts recent

This catches execution of the nft binary, not direct netlink use. An attacker can avoid the binary. Still, it is useful in many environments because commodity post-exploitation tooling often uses standard tools first.

Kernel logs are also worth reviewing:

journalctl -k --since "24 hours ago" \
  | grep -Ei 'nf_tables|nft_|oops|general protection|use-after-free|BUG:|slab|KASAN|refcount'

On production kernels without sanitizers, a successful exploit may leave little obvious trace. A failed exploit may crash the host or produce a noisy kernel warning. The absence of such logs does not prove safety.

For higher-value servers, use endpoint telemetry to connect events:

low-privileged service account
        |
        +-- creates user namespace
        +-- creates network namespace
        +-- performs nftables operations
        +-- spawns unexpected root process
        +-- reads secrets or modifies persistence paths

The most useful detections are usually correlation rules, not single-event signatures.

Patch and reboot are the real fix

The primary remediation is to install a kernel package that contains the CVE-2026-23111 fix and reboot into it.

A minimal Debian or Ubuntu remediation flow:

sudo apt update
sudo apt install --only-upgrade 'linux-image-*' 'linux-modules-*' 'linux-generic' 2>/dev/null || sudo apt upgrade
sudo reboot

After reboot:

uname -r
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'

A minimal Red Hat-family flow:

sudo dnf update kernel
sudo reboot

After reboot:

uname -r
rpm -q kernel
needs-restarting -r 2>/dev/null || true

For Amazon Linux 2 or older yum-based systems:

sudo yum update kernel
sudo reboot

After reboot:

uname -r
rpm -q kernel

For SUSE-family systems:

sudo zypper refresh
sudo zypper patch
sudo reboot

After reboot:

uname -r
rpm -q kernel-default 2>/dev/null || rpm -q kernel

Patch validation should record:

エビデンス	なぜそれが重要なのか
OS release	Determines the correct vendor advisory
Installed kernel package version	Shows whether the fixed package is installed
Running kernel version	Shows whether the host actually booted into the fixed kernel
Reboot timestamp	Confirms the update took effect
Namespace policy	Shows whether temporary hardening remains in place
Workload smoke test	Confirms firewall, container, and application networking still work
Change ticket or report artifact	Makes remediation auditable

Do not treat apt upgrade または dnf update output as final proof. The running kernel is what matters.

Temporary mitigations when patching is delayed

Temporary mitigations are not replacements for the kernel fix. They reduce the chance that an unprivileged attacker can reach the vulnerable path or turn it into root. They can also break legitimate workloads.

Restrict unprivileged user namespaces where safe

On Debian and Ubuntu systems that support kernel.unprivileged_userns_clone, a blunt temporary control is:

sudo sysctl -w kernel.unprivileged_userns_clone=0

To persist it:

echo 'kernel.unprivileged_userns_clone=0' \
  | sudo tee /etc/sysctl.d/99-disable-unprivileged-userns.conf
sudo sysctl --system

On systems where user.max_user_namespaces is the available control, a restrictive setting can look like this:

sudo sysctl -w user.max_user_namespaces=0

To persist:

echo 'user.max_user_namespaces=0' \
  | sudo tee /etc/sysctl.d/99-limit-userns.conf
sudo sysctl --system

This can break rootless containers, Chromium-style browser sandboxes, Flatpak, build tools, CI isolation, package builders, and developer workflows. Test before broad rollout. If you run shared production infrastructure, the tradeoff may still be worth it until all nodes are patched and rebooted.

On Ubuntu systems with AppArmor-based restrictions, check:

sysctl kernel.apparmor_restrict_unprivileged_userns

If your Ubuntu release and policy support it, enforce the vendor-supported restriction rather than inventing a local control. AppArmor’s documentation describes policy controls for unprivileged user namespaces, including selectively allowing or denying namespace creation per application profile. (Ubuntu Community Hub)

Harden containers and Kubernetes nodes

For container environments, focus on reducing kernel attack surface available to untrusted workloads:

apiVersion: v1
kind: Pod
metadata:
  name: restricted-example
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: example/app:latest
      securityContext:
        allowPrivilegeEscalation: false
        privileged: false
        capabilities:
          drop:
            - ALL

Avoid these unless there is a documented need:

securityContext:
  privileged: true
hostNetwork: true
hostPID: true
hostIPC: true

Also avoid granting CAP_NET_ADMIN to workloads that do not need it. CAP_NET_ADMIN can expose networking controls that should not be available to ordinary application containers. Even if CVE-2026-23111 can be reached through namespace behavior rather than a simple capability check on every host, reducing network-control privileges remains good hardening.

For Kubernetes, prioritize:

コントロール	Why it helps
Pod Security Standards restricted profile	Prevents many dangerous defaults
RuntimeDefault seccomp	Blocks broad syscall surface compared with unconfined profiles
AppArmor or SELinux profiles	Adds policy enforcement around namespace and file access behavior
No privileged containers	Prevents direct host-level control
Drop all Linux capabilities by default	Reduces attack surface exposed to containers
Separate untrusted workloads onto dedicated nodes	Limits blast radius if a kernel bug is exploited
Fast node rotation after kernel patch	Ensures all pods run on fixed kernels

A container image scan will not detect CVE-2026-23111 because the vulnerable code is in the host kernel, not the image filesystem. Node-level vulnerability management is required.

Be careful with “disable nftables” advice

Some advisories for nf_tables bugs discuss blacklisting or disabling nf_tables in narrow circumstances. For CVE-2026-23111, that should not be a casual recommendation.

Modern Linux systems often use nftables directly or indirectly for host firewalling, container networking, NAT, orchestration, and network policy. Removing nf_tables support can break security controls as well as applications. If a vendor provides a supported mitigation for your distribution and workload, follow that. Otherwise, treat nf_tables disablement as a controlled emergency measure for systems where:

- the kernel cannot be patched quickly,
- nftables is not required for host firewalling or container networking,
- the change has been tested,
- rollback is documented,
- and compensating network controls exist.

For most teams, the safer temporary control is namespace restriction plus rapid patching.

Verification without unsafe production exploitation

A mature remediation process does not require running a public exploit on production servers. It requires evidence that the vulnerable condition no longer exists or is no longer reachable.

A safe post-fix checklist:

1. Confirm the vendor advisory says your installed package version is fixed.
2. Confirm the host rebooted into the fixed kernel.
3. Confirm unprivileged namespace policy is intentionally configured.
4. Confirm nftables and container networking still behave as expected.
5. Confirm no unexpected kernel errors appeared after reboot.
6. Confirm vulnerable nodes were drained, rebooted, and returned to service.
7. Record evidence in a ticket, report, or change system.

For a single Ubuntu host, a compact evidence sequence might look like this:

cat /etc/os-release | grep PRETTY_NAME
uname -r
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'
sysctl kernel.unprivileged_userns_clone 2>/dev/null || true
sysctl user.max_user_namespaces 2>/dev/null || true
journalctl -k -b --no-pager | grep -Ei 'nf_tables|oops|BUG:' || true

For a Kubernetes node pool, the process should be node-oriented:

- identify vulnerable node images or kernel packages
- cordon and drain one node
- patch and reboot
- confirm running kernel
- run workload smoke tests
- rotate remaining nodes
- remove temporary mitigations only after the fleet is fixed

For teams using authorized AI-assisted validation workflows, the useful role is not “run an exploit everywhere.” It is collecting exact host evidence, matching package state to advisories, preserving command output, separating affected from not affected systems, and generating a remediation record that can be reviewed. Penligent’s public material describes AI-powered penetration testing and CVE validation workflows that connect tool execution, multi-agent task handling, evidence capture, and reporting; the relevant pages are the Penligent homepage at https://penligent.ai/ and its automated penetration testing overview at https://www.penligent.ai/resources/blog/overview-of-penligentais-automated-penetration-testing-tool. The same safety rule still applies: use such workflows only on authorized systems, and use them to structure validation evidence rather than to justify unsafe exploit attempts on production hosts.

Common mistakes that lead to bad risk decisions

Mistake one, relying only on uname -r

uname -r tells you the running kernel release string. It does not tell you whether your distribution backported the fix into that release. It also does not tell you whether a newer fixed kernel is installed but not yet running. Use uname -r, package manager output, and the vendor advisory together.

Mistake two, assuming containers solve it

Containers share the host kernel. A container boundary can reduce attack surface, but it does not remove kernel bugs. If an untrusted container can reach the vulnerable kernel path, the host may be at risk. Treat kernel CVEs as node issues, not image issues.

Mistake three, disabling the nft binary and calling it fixed

Removing or restricting /usr/sbin/nft can reduce casual misuse, but nf_tables is a kernel interface. Attackers can use other binaries, netlink libraries, custom code, or shipped tools. Do not treat the absence of the nft command as a complete mitigation.

Mistake four, installing the fixed package without rebooting

Kernel package installation and kernel execution are different states. If the host still runs the vulnerable kernel, the host is still exposed. Reboot or verify live-patch coverage with the vendor.

Mistake five, treating CVSS 7.8 as moderate operational risk

A CVSS 7.8 local privilege escalation can be urgent on systems where local code execution is common. CI runners, developer workstations, multi-user hosts, bastions, and Kubernetes nodes are often more exposed than a single-purpose locked-down appliance.

Mistake six, using public exploits as production scanners

A public kernel exploit is not a scanner. Running it on production can crash systems, corrupt memory, alter host state, or create legal and operational risk. Use vendor package checks, safe configuration checks, and controlled lab validation.

Related CVEs that explain the pattern

CVE-2026-23111 is part of a broader pattern: Linux kernel local privilege escalation bugs become more dangerous when unprivileged namespaces expose complex kernel subsystems to low-privileged users.

CVE	コンポーネント	What happened	Why it is relevant	Main defensive lesson
CVE-2024-1086	Linux kernel netfilter nf_tables	A use-after-free in nf_tables could be exploited for local privilege escalation; NVD describes the issue in nft_verdict_init() and recommends upgrading past the fixing commit	Same subsystem family, same local privilege escalation theme, same importance of kernel patching	nf_tables bugs can become high-value post-exploitation primitives
CVE-2023-32233	Linux kernel Netfilter nf_tables	A use-after-free while processing batch requests allowed arbitrary read and write of kernel memory; unprivileged local users could obtain root privileges because anonymous sets were mishandled	Shows that nf_tables transaction and set handling have been a repeated source of serious kernel bugs	Batch-processing paths and object lifetime rules deserve extra scrutiny
CVE-2022-0185	Linux kernel filesystem context	A heap-based buffer overflow in legacy_parse_param() could let an unprivileged local user escalate privileges when unprivileged user namespaces were enabled, or when the attacker had namespaced CAP_SYS_ADMIN	Not nf_tables, but highly relevant to the namespace exposure model	User namespaces can expose kernel code paths that were historically less reachable to unprivileged users

NVD describes CVE-2024-1086 as a Linux kernel nf_tables use-after-free that can achieve local privilege escalation. (NVD) NVD describes CVE-2023-32233 as a use-after-free in Netfilter nf_tables batch processing through Linux kernel 6.3.1 that unprivileged local users could abuse to obtain root privileges. (NVD) NVD describes CVE-2022-0185 as a heap-based buffer overflow in the Linux kernel filesystem context code, reachable by an unprivileged local user when unprivileged user namespaces are enabled, or otherwise by a user with namespaced CAP_SYS_ADMIN. (NVD)

The shared lesson is not “disable every Linux feature that has ever had a CVE.” The lesson is to manage feature exposure based on workload trust. A single-user laptop, a locked-down appliance, a rootless container build host, and a shared CI worker have different tolerance for unprivileged namespace access. Kernel hardening should reflect that.

Prioritization by environment

A useful remediation priority model for CVE-2026-23111 is based on who can run code and how valuable the host is.

Environment	優先順位	Reason
Kubernetes worker nodes running untrusted or internet-facing workloads	Critical operational priority	Containers share the host kernel, and node compromise can affect many workloads
CI/CD runners	Critical operational priority	Build jobs often execute third-party code, dependency scripts, tests, and generated artifacts
Multi-user Linux servers	Critical operational priority	Low-privileged users may be legitimate but untrusted
Developer workstations	High priority	Browsers, package managers, local containers, and dev tools run large amounts of code
Bastion hosts and VPN jump boxes	High priority	Root compromise can expose credentials and lateral movement paths
Internet-facing app servers	High priority if app compromise is plausible	Web app RCE plus local kernel LPE is a common escalation pattern
Single-purpose servers with no untrusted local code	Medium to high depending on compensating controls	Still patch, but exploit reachability may be lower
Offline lab systems	Context-dependent	Patch before connecting to shared networks or running untrusted samples

This model is more useful than sorting only by CVSS. CVSS tells you intrinsic severity. Environment tells you how likely the vulnerable path is to matter in your estate.

Practical hardening profiles

Different organizations need different tradeoffs. The following profiles are starting points.

Shared CI runner profile

- Patch and reboot runner hosts quickly.
- Prefer ephemeral runners for untrusted projects.
- Disable unprivileged user namespaces if builds do not require them.
- Use VM isolation for high-risk third-party builds.
- Prevent privileged containers in build jobs.
- Drop CAP_NET_ADMIN unless explicitly required.
- Monitor namespace creation and nftables activity by build users.
- Rotate runner images after kernel patching.

CI runners deserve special attention because they intentionally execute code that may not be fully trusted. A malicious dependency script can be local code execution. CVE-2026-23111 can then become the escalation step.

Kubernetes node profile

- Patch node images or host kernels.
- Cordon, drain, reboot, and verify nodes.
- Enforce restricted pod security defaults.
- Deny privileged pods by default.
- Drop Linux capabilities by default.
- Use RuntimeDefault seccomp.
- Use AppArmor or SELinux profiles where supported.
- Separate untrusted workloads from sensitive workloads.
- Treat node compromise as cluster incident scope.

Do not rely on container image scanners to solve kernel CVEs. The node owns the kernel.

Developer workstation profile

- Patch through the OS vendor and reboot.
- Keep browser and sandbox policies intact.
- Review local container tooling that depends on user namespaces.
- Avoid running untrusted PoCs outside disposable VMs.
- Use VM-based isolation for exploit research.
- Monitor suspicious root processes and persistence paths.

Developers often run package install scripts, containers, local test servers, browser sessions, and experimental code. That makes local privilege escalation bugs more relevant than they look on paper.

Production server profile

- Patch during the next emergency or high-priority maintenance window.
- Reboot into the fixed kernel.
- Confirm service health after reboot.
- Keep temporary namespace restrictions if they do not break workloads.
- Review whether service users can execute shell commands.
- Monitor web shells, suspicious child processes, and unexpected nft activity.

If an internet-facing application has any realistic path to command execution, file upload execution, template injection, deserialization, or plugin abuse, local kernel LPE should be treated as part of the same risk chain.

よくあるご質問

Is CVE-2026-23111 remotely exploitable?

• Not by itself. CVE-2026-23111 is a local privilege escalation in the Linux kernel nf_tables subsystem.
• An attacker usually needs local code execution first, such as a shell, compromised service account, malicious CI job, or code running in a container.
• It can still matter in remote intrusions because many attacks first gain low-privileged code execution and then use a kernel LPE to become root.
• Defenders should prioritize it on systems where untrusted or semi-trusted local code runs.

How do I know whether my Linux system is affected?

• Check your distribution’s security advisory for CVE-2026-23111.
• Compare the installed kernel package version to the vendor’s fixed package version.
• Confirm the running kernel with uname -r.
• Confirm the system rebooted into the fixed kernel after the update.
• Do not rely only on upstream kernel version strings, because distributions often backport fixes.

Does this affect containers?

• It can, depending on the host kernel and container restrictions.
• Containers share the host kernel, so a kernel use-after-free can threaten the host if the vulnerable path is reachable.
• Risk is higher for privileged containers, containers with broad capabilities, untrusted workloads, weak seccomp policy, or permissive namespace settings.
• Patch the node or host kernel. Scanning only container images is not enough.

Should I disable unprivileged user namespaces?

• Disable or restrict them temporarily if your workloads do not require them and patching is delayed.
• Test first, because rootless containers, browsers, build tools, Flatpak, sandboxes, and CI jobs may depend on user namespaces.
• On Debian or Ubuntu-style systems, kernel.unprivileged_userns_clone=0 may be available.
• On other systems, user.max_user_namespaces may be the practical control.
• On Ubuntu releases with AppArmor namespace restrictions, prefer the vendor-supported policy model.

Can I mitigate CVE-2026-23111 by disabling nftables?

• Sometimes, but it is not a safe general recommendation.
• nftables may be required for firewalling, NAT, container networking, orchestration, and network policy.
• Removing the nft command is not enough because nf_tables is a kernel interface.
• Only consider disabling nf_tables when the vendor recommends it or when you have tested the impact and have compensating controls.
• The reliable fix is a patched kernel and reboot.

What should I monitor for exploitation attempts?

• Unexpected user namespace or network namespace creation by low-privileged users.
• Unexpected nft execution or nf_tables netlink activity by service accounts.
• Rapid nftables create/delete activity involving sets, maps, chains, or failed batches.
• Kernel warnings, oops messages, slab allocator errors, or general protection faults.
• Sudden privilege changes followed by credential access, persistence, or lateral movement behavior.
• Expect false positives from rootless containers, browsers, CI systems, and legitimate firewall tools.

Is it safe to run a public CVE-2026-23111 exploit to confirm exposure?

• Do not run public kernel exploits on production systems.
• Kernel exploits can crash hosts, corrupt memory, bypass controls, or leave the system in an unknown state.
• Use vendor advisory checks, package version checks, running-kernel verification, and namespace policy review.
• If exploit validation is required, use a disposable lab system that matches the target kernel and is explicitly authorized for testing.
• Production validation should prove patch state, not exploitability.

What evidence should I keep after remediation?

• OS release and kernel package version before and after patching.
• Running kernel version after reboot.
• Vendor advisory or package changelog showing the fixed version.
• Namespace policy settings.
• Reboot evidence or maintenance record.
• Node rotation evidence for Kubernetes or container hosts.
• A short statement of residual risk, including any temporary mitigations left in place.

CVE-2026-23111 is easy to underestimate because it is local, because the patch is one line, and because nf_tables sounds like firewall plumbing. That is the wrong mental model. The issue sits in kernel transaction cleanup, affects object lifetime, and can turn reachable local code execution into root on systems where namespace and nftables exposure line up.

The right response is practical: identify systems where untrusted local code runs, patch and reboot, verify the running kernel, restrict unprivileged namespace exposure where the business can tolerate it, harden container workloads, and preserve evidence that remediation actually happened. For shared Linux infrastructure, CI runners, Kubernetes nodes, bastions, and developer machines, “local only” is not a reason to wait.