> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# ebtables SNAT (CVE-2026-53266): an Out-of-Bounds Kernel Write, Exploited in the Wild

> A flaw in the ebtables bridge firewall lets an attacker write into the kernel page cache. In CISA's KEV catalog since September 18. Scope and mitigation.

*Published on September 24, 2026*

<Warning>
  **CVE-2026-53266, in the ebtables SNAT target.** Added to CISA's KEV catalog on September 18, 2026: it is being exploited in the wild. Fixes have shipped for Debian, RHEL 8 and 9, AlmaLinux and Ubuntu 26.04 — but not yet for Ubuntu 22.04 or 24.04. On those two releases, apply the mitigation now.
</Warning>

## The problem in two sentences

The `snat` target of ebtables, the Linux bridge firewall, can rewrite the sender hardware address in ARP packets. The `ebt_snat` module performs that write through `skb_store_bits()` without first making sure the target memory range is writable.

When that range is a file page imported with `splice()`, the kernel writes straight into the page cache. NVD classifies the flaw as an out-of-bounds write (CWE-787), with a CVSS score of 8.8.

## Why this one matters

On paper, the flaw needs an unusual setup: an ebtables SNAT rule with ARP rewriting (`--snat-arp`) on a bridge. Red Hat describes it as requiring "specific bridge netfilter configurations". That is true, but incomplete.

**The attacker can build that setup themselves.** All it takes is `CAP_NET_ADMIN` in the network namespace that owns the bridge. Where unprivileged user namespaces are allowed, any ordinary account gets it with `unshare -Urn`, inside its own namespace, without touching the host configuration.

**The module loads itself.** `ebt_snat` is loaded automatically as soon as a rule needs it. Its absence from `lsmod` today protects you from nothing.

**The write lands in the page cache.** Six controlled bytes written into a file page are enough to modify, in memory, a file the attacker can read but not write — a setuid binary, for instance.

These three points come from the [public tracker for the flaw](https://github.com/suominen/CVE-2026-53266), not from the distribution advisories, which do not describe the attack path. CISA does not say how the exploitation it observed was carried out either.

## Sizing your exposure

There are two questions: **who can run code on the machine, and can they obtain `CAP_NET_ADMIN`?**

| Profile                                                                               | Exposure                | Action                                                                        |
| ------------------------------------------------------------------------------------- | ----------------------- | ----------------------------------------------------------------------------- |
| Single-tenant VPS, your code only, no third-party shell accounts                      | Moderate                | Patch and reboot. On Ubuntu 22.04 or 24.04, mitigate in the meantime          |
| VPS with several shell accounts, customers, or an unaudited CI runner                 | **Critical**            | Mitigate now, patch as soon as the kernel is available                        |
| Docker or Kubernetes node where containers run with `NET_ADMIN` or in privileged mode | **Critical**            | Mitigate on every node, drop `NET_ADMIN` wherever it is not strictly required |
| Virtualisation host using ebtables SNAT rules with `--snat-arp` on its bridges        | **Critical**            | Patch the kernel. Do not block the module before checking what it breaks      |
| Shared hosting where you do not manage the kernel                                     | Handled by the provider | Nothing to do on your side                                                    |

As usual with this class of bug, a local foothold is required. The flaw is not remotely exploitable on its own, but it turns a compromised web application or a low-privilege account into control of the machine.

To check whether an unprivileged account can create its own network namespace:

```bash theme={null}
# Run as a regular user, not root
unshare -Urn true && echo "user namespaces available"

# On Debian and Ubuntu kernels: 1 = allowed, 0 = forbidden
sysctl kernel.unprivileged_userns_clone
```

## Applying the fix

The upstream fix landed in Linux 7.1-rc7. It makes the ARP address range writable before reading and rewriting it.

### Debian, Ubuntu and derivatives

```bash theme={null}
# Upgrade the kernel
sudo apt update
sudo apt full-upgrade

# The new kernel only runs after a reboot
sudo reboot
```

Status as of September 24, 2026, per the [Debian](https://security-tracker.debian.org/tracker/CVE-2026-53266) and [Ubuntu](https://ubuntu.com/security/CVE-2026-53266) trackers:

| Release                   | Fixed kernel package                                                        |
| ------------------------- | --------------------------------------------------------------------------- |
| Debian 11 (bullseye, LTS) | `linux 5.10.259-1` (DLA-4664-1), `linux-6.1 6.1.176-1~deb11u1` (DLA-4671-1) |
| Debian 12 (bookworm)      | `linux 6.1.176-1`                                                           |
| Debian 13 (trixie)        | `linux 6.12.94-1`                                                           |
| Ubuntu 26.04 LTS          | `linux 7.0.0-31.31`                                                         |
| Ubuntu 24.04 LTS          | **No fix yet** — mitigation required                                        |
| Ubuntu 22.04 LTS          | **No fix yet** — mitigation required                                        |
| Ubuntu 20.04 LTS          | Vulnerable, no fix announced                                                |
| Ubuntu 18.04 LTS          | Not affected                                                                |

### AlmaLinux, Rocky Linux and RHEL

```bash theme={null}
sudo dnf clean metadata && sudo dnf upgrade
sudo reboot
```

| Release            | Fixed kernel                     | Advisory                               |
| ------------------ | -------------------------------- | -------------------------------------- |
| RHEL / AlmaLinux 8 | `kernel-4.18.0-553.143.1.el8_10` | RHSA-2026:39083, ALSA-2026:39083       |
| RHEL / AlmaLinux 9 | `kernel-5.14.0-687.23.1.el9_8`   | RHSA-2026:36645, ALSA-2026:36645       |
| AlmaLinux 10       | `kernel-6.12.0-211.59.1.el10_2`  | ALSA-2026:71233, released September 24 |

Red Hat also ships `kernel-rt-4.18.0-553.143.1.rt7.484.el8_10` for the RHEL 8 real-time kernel (RHSA-2026:39082). Any later version than those listed includes the fix.

## Immediate mitigation

Apply this if your fixed kernel is not out yet, or until you are able to reboot.

### Block the `ebt_snat` module

Without the module, the ebtables SNAT target no longer exists — and neither does the vulnerable path.

```bash theme={null}
# Prevent any further loading of the module
printf 'install ebt_snat /bin/false\n' | sudo tee /etc/modprobe.d/cve-2026-53266.conf

# Unload it if it is already in memory
sudo modprobe -r ebt_snat
```

<Note>
  If you run a host that relies on ebtables SNAT rules, this block breaks them. Red Hat offers another route for that case: remove the ARP rewrite option from those rules, or delete the SNAT rules that apply to ARP traffic. List them with `sudo ebtables -t nat -L`.
</Note>

### Disable unprivileged user namespaces (Debian and Ubuntu)

A second barrier: stop an ordinary account from obtaining `CAP_NET_ADMIN` in a namespace of its own. This setting exists on Debian and Ubuntu kernels.

```bash theme={null}
# Takes effect immediately
sudo sysctl -w kernel.unprivileged_userns_clone=0

# Persist across reboots
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cve-2026-53266.conf
```

This breaks anything that depends on those namespaces, rootless containers in particular. Check what you run before applying it in production.

### On a Kubernetes cluster

Roll the module block out to every node with a privileged DaemonSet. The `pause` container keeps the DaemonSet from restart-looping once the `initContainer` finishes.

```yaml theme={null}
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: disable-ebt-snat
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: disable-ebt-snat
  template:
    metadata:
      labels:
        app: disable-ebt-snat
    spec:
      hostPID: true
      tolerations:
        - operator: Exists
          effect: NoSchedule
        - operator: Exists
          effect: NoExecute
      initContainers:
        - name: disable-ebt-snat
          image: alpine:3.23
          securityContext:
            privileged: true
          command:
            - /bin/sh
            - -c
            - |
              printf 'install ebt_snat /bin/false\n' > /etc/modprobe.d/cve-2026-53266.conf
              rmmod ebt_snat 2>/dev/null || true
          volumeMounts:
            - name: modprobe-d
              mountPath: /etc/modprobe.d
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.10
          resources:
            limits:
              cpu: 1m
              memory: 8Mi
      volumes:
        - name: modprobe-d
          hostPath:
            path: /etc/modprobe.d
```

## Verifying the mitigation

```bash theme={null}
# The module must not be listed
lsmod | grep ebt_snat

# Any attempt to load it must fail
sudo modprobe ebt_snat

# On Debian and Ubuntu, if you disabled user namespaces: must print 0
sysctl kernel.unprivileged_userns_clone
```

After the kernel upgrade, confirm it is the one actually running:

```bash theme={null}
# Must show the fixed version
uname -r
```

A package installed without a reboot protects nothing: the machine is still running the old kernel.

## Rolling back the mitigation

Once the fixed kernel is booted, you can revert:

```bash theme={null}
sudo rm /etc/modprobe.d/cve-2026-53266.conf
sudo rm /etc/sysctl.d/99-cve-2026-53266.conf
sudo sysctl -w kernel.unprivileged_userns_clone=1
```

## What next?

The flaw was disclosed on June 25 and fixed by Red Hat as early as July 8, but only entered the KEV catalog on September 18. Put differently, fixes had been available for more than two months when exploitation was confirmed. If your servers have not rebooted onto an updated kernel since July, treat the window as open.

If you have doubts about a machine, do not clean it in place: rebuild it from a known-good state using your [snapshots](https://help.onetsolutions.net/vps/snapshot) and [backups](https://help.onetsolutions.net/vps/backup), then rotate every secret it held.

Want a second opinion on your fleet? [Our team is available](https://help.onetsolutions.net/console/support) from your customer area.