TL;DR — A memory-safety flaw in the Linux kernel’s bridge netfilter ebtables SNAT target, CVE-2026-53266, is now being exploited in the wild and was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog on 18 September 2026 with a federal patch deadline of 21 September 2026. The scoring is split: the Linux kernel CNA rates it CVSS 8.8 (High) with a scope-changing AV:L vector, while Red Hat rates it 7.5 (Important) — the demonstrated bug is an out-of-bounds write (CWE-787) in the ebtables ARP source-address rewrite that a local attacker holding CAP_NET_ADMIN (including inside an unprivileged user namespace) can turn into kernel memory corruption and privilege escalation. It only bites hosts that actually use bridge netfilter with an ebtables SNAT rule. The fix shipped upstream in June 2026; the news now is that attackers have started using it against unpatched kernels.

HIGHCVE-2026-53266Linux kernel ebtables SNAT out-of-bounds write (local EoP)CVSS 3.18.8 Linux CNA · 7.5 Red Hat (Important)VECTORCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HWEAKNESSCWE-787 Out-of-Bounds Write (netfilter bridge SNAT)AFFECTEDLinux kernels with bridge netfilter + an ebtables SNAT ruleATTACK VECTORLocal – needs CAP_NET_ADMIN (native or user namespace)FIXED IN5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36 (+ backports)EXPLOITEDYes – CISA confirms exploitation (no public details)CISA KEVListed – added 18 Sep 2026 (deadline 21 Sep 2026)
At-a-glance threat summary for the Linux kernel ebtables SNAT out-of-bounds write (CVE-2026-53266). The Linux CNA and Red Hat scores differ — see the impact section below.

What Is the Linux Kernel ebtables SNAT Flaw (CVE-2026-53266)?

ebtables is the Ethernet-bridge equivalent of iptables: it filters and mangles frames as they cross a Linux software bridge, and it lives inside the kernel’s bridge netfilter layer. One of its targets, SNAT, can rewrite the source MAC address of a frame — and, optionally, rewrite the sender hardware address inside an ARP payload to keep ARP consistent with the new MAC. That optional ARP rewrite is where CVE-2026-53266 lives. Bridges and ebtables are the plumbing behind virtual machine networking, container bridges and any host that stitches interfaces together at layer 2, so the vulnerable code is compiled into a great many production kernels.

The bug is an out-of-bounds write (CWE-787). The SNAT target performs the Ethernet source-address rewrite behind a skb_ensure_writable() call, which guarantees the bytes it is about to touch are safe to modify. The ARP sender-hardware-address rewrite did not get the same guarantee: on a nonlinear socket buffer — one whose data lives in paged fragments rather than the linear header, for example a fragment backed by a splice-imported file page — the rewrite could write directly into that fragment before the relevant range had been made writable. The result is a controlled write landing outside the intended bounds, corrupting adjacent kernel memory.

CVE-2026-53266 was published on 25 June 2026 and fixed the same day upstream in the netfilter bridge code (the change makes the ebtables SNAT ARP rewrite go through the writable path). It went largely unremarked for three months — until CISA flagged it, together with two other Linux kernel flaws, as actively exploited in September 2026.

How the CVE-2026-53266 Exploit Works

In plain terms: an attacker who can install a bridge firewall rule can craft a situation where the kernel writes a rewritten ARP address a few bytes past where it should, landing in memory it does not own. With careful heap grooming, that stray write becomes the primitive for corrupting a neighbouring kernel object and, from there, escalating privileges.

The mechanism, per the upstream advisory: the ebtables SNAT target rewrites the Ethernet source address only after skb_ensure_writable(skb, 0) has made the head writable. When the target is also asked to rewrite the ARP sender hardware address, it reaches into the ARP payload and writes the new address there — but on a nonlinear skb that payload can sit in a paged fragment that has not been made writable, in some cases a fragment backed by a splice-imported file page. The write therefore lands in an unintended, out-of-bounds location. The precondition that matters most for real-world risk: installing an ebtables SNAT rule requires CAP_NET_ADMIN. That is a privileged capability — but on kernels that allow unprivileged user namespaces, an ordinary local user can obtain CAP_NET_ADMIN inside their own namespace and reach this code path, which is the bridge from “local user” to “kernel memory corruption.”

The demonstrated impact is local privilege escalation. This is not a remote “send a packet, get a shell” bug — the attacker needs local access and the ability to configure a bridge SNAT rule. ZeroDayHub is not publishing a working exploit; the upstream commit documents the root cause and the fix for defenders. The responsible action is to patch and to watch for the signals below.

# Signals to hunt on Linux hosts that use bridge netfilter / ebtables
- KASAN / kernel oops reports flagging an out-of-bounds write in
  the netfilter bridge / ebtables SNAT path (nf_bridge, ebt_snat)
- Unprivileged processes creating user namespaces then bridges +
  ebtables rules (unshare -Urn ... ebtables -t nat -A ...)
- Unexpected ebtables SNAT rules that rewrite ARP sender addresses
- Root-owned processes spawned from unprivileged parents
- Crashes clustered on bridged / container-networking workloads

Impact Nuance: Why the Scores Disagree (8.8 vs 7.5)

This one rewards a careful read rather than a scary round number. The Linux kernel CNA scores CVE-2026-53266 at CVSS 8.8 (High) using the vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — a local attack with low privileges, but a changed scope (the kernel is compromised beyond the attacker’s original boundary), which pushes the number up. Red Hat rates the same flaw 7.5 (Important), reflecting its view that meaningful exploitation needs a specific configuration — bridge netfilter in use and the ability to install an ebtables SNAT rule that rewrites ARP.

The gap matters for prioritisation. Two things narrow the real-world blast radius: the host must actually use bridge netfilter with an ebtables SNAT rule, and the attacker must hold CAP_NET_ADMIN. The sting in the tail is unprivileged user namespaces: where they are enabled (many desktop and container-friendly distributions ship them on), a plain local user can grant themselves CAP_NET_ADMIN inside a private namespace and reach the vulnerable path anyway. So the honest reading is “High-severity local privilege escalation, gated by a capability that user namespaces can hand out” — serious on multi-tenant and container hosts, less pressing on a locked-down box with user namespaces disabled and no untrusted local users. Where ZeroDayHub can only pick one accent, we’ve gone with High, and shown both scores on the card so you can judge for yourself.

The write is only a few bytes out of place. On a shared or containerised host, a few bytes in the wrong part of kernel memory is the whole distance from ordinary user to root.

ATTACK CHAIN1Gain a local foothold and obtain CAP_NET_ADMINNatively, or via an unprivileged user namespace on kernels that allow them.2Install an ebtables SNAT rule that rewrites the ARP addressAttach a bridge and add the SNAT target with ARP sender-hardware-address rewrite.3Drive crafted traffic through the SNAT target on a nonlinear skbForce the ARP payload into a paged fragment that has not been made writable.4ARP rewrite writes past the fragment → out-of-bounds writeThe sender-hardware-address write lands outside the intended bounds (CWE-787).5Groom kernel memory and escalate to rootCorrupt an adjacent kernel object to gain code execution / full privileges.
How a local user turns an ebtables ARP rewrite into an out-of-bounds write and root on an unpatched kernel (CVE-2026-53266).

Active Exploitation of CVE-2026-53266

The exploitation is what pushed this three-month-old patch back into the headlines. On 18 September 2026, CISA added CVE-2026-53266 to its Known Exploited Vulnerabilities catalog — part of a batch of three Linux kernel flaws flagged as exploited in the wild, the others being CVE-2025-39682 (a kTLS receive-path use-after-free) and CVE-2025-39964 (an AF_ALG race condition). CISA set a federal civilian remediation deadline of 21 September 2026 under its Binding Operational Directive — an unusually tight three-day window.

As is normal for KEV entries, CISA has not published exploitation details: no named threat actor, victim population or exploit chain, and no public proof-of-concept had been released at the time of writing. Distribution vendors updated their kernel advisories as the exploitation was confirmed. As always with local privilege escalation, treat this as the second stage of an intrusion, not the first: it is the primitive an attacker reaches for once they already hold a shell, to go from a compromised service account or container to full control of the host — which is exactly why the netfilter/ebtables path, reachable through user namespaces, is attractive.

DISCLOSURE TIMELINE25 Jun 2026CVE-2026-53266 published; fix merged upstream (netfilter bridge)Jul–Sep 2026Fix backported to stable trees (5.15.210, 6.1.176, 6.6.143, 6.12.94…)18 Sep 2026CISA adds the flaw to the KEV catalog (with 2 other kernel bugs)19 Sep 2026Distributions update kernel advisories as exploitation is confirmed21 Sep 2026CISA federal remediation deadline
From a June 2026 upstream fix to a September 2026 exploitation wave and a three-day federal patch deadline (CVE-2026-53266).

Remediation & Mitigation: Patching the ebtables SNAT Out-of-Bounds Write

Update the kernel. The flaw was fixed upstream in June 2026, so the fix is already in current stable trees. Upgrade to at least one of the fixed maintenance releases — and, in practice, take whatever your distribution ships, because vendors backport the fix to their own kernel builds:

  • 5.10.x → 5.10.259 or later
  • 5.15.x → 5.15.210 or later
  • 6.1.x → 6.1.176 or later
  • 6.6.x → 6.6.143 or later
  • 6.12.x → 6.12.94 or later
  • 6.18.x → 6.18.36 or later (and 7.0.13 / 7.1+ contain the fix)

For enterprise distributions, apply the vendor kernel update rather than tracking upstream version numbers — a backport can fix an older-looking release. Remember a kernel patch requires a reboot (or a live-patch service) to take effect: an installed-but-not-booted kernel is still vulnerable. Reduce exposure while you schedule that reboot:

  • Disable unprivileged user namespaces where you don’t need them. Setting kernel.unprivileged_userns_clone=0 (or the equivalent user.max_user_namespaces=0) stops ordinary users from minting their own CAP_NET_ADMIN and reaching this path — the single most effective interim control on multi-user hosts. Confirm your container runtime doesn’t rely on them first.
  • Restrict who holds CAP_NET_ADMIN. Audit which service accounts and containers are granted it, and drop it from workloads that don’t configure networking.
  • Review bridge netfilter usage. If ebtables/bridge SNAT is not needed on a given host, don’t load it; monitor for unexpected ebtables SNAT rules that rewrite ARP.

If you find evidence of exploitation, treat it as a full host compromise. Privilege escalation to root (or a container escape to the host) means the attacker can install persistence, tamper with logs and pivot. Hunt for KASAN/kernel-oops reports in the netfilter bridge path, unexpected root processes descended from unprivileged accounts or containers, and new persistence mechanisms; rotate credentials and secrets stored on or reachable from the host; and rebuild from a trusted image where root compromise is confirmed.

Related ZeroDayHub Coverage

CVE-2026-53266 was one of three Linux kernel flaws CISA flagged together on 18 September 2026. We covered its sibling in the same batch — the Linux kernel kTLS receive-path use-after-free (CVE-2025-39682), another local privilege-escalation bug with a similarly split score. For the wider pattern of “only High severity” local escalation turning a foothold into ownership, see the Windows ALPC elevation-of-privilege flaw (CVE-2026-85880). The recurring lesson: attackers pair a modest initial access with a kernel privilege-escalation primitive, and multi-tenant and container hosts are where that pairing hurts most.

Sources & Further Reading

ZeroDayHub reports on vulnerabilities for defensive purposes only. This article summarises the publicly-documented root cause but deliberately omits a working exploit while patching is in progress.

Leave a Reply

Trending

Discover more from Zerodayhub

Subscribe now to keep reading and get access to the full archive.

Continue reading