> ## 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) : une écriture noyau hors limites, exploitée dans la nature

> Une faille du pare-feu de pont ebtables permet d'écrire dans le cache de pages du noyau. Au catalogue KEV de la CISA depuis le 18 septembre. Périmètre, mitigation.

*Publié le 24 septembre 2026*

<Warning>
  **CVE-2026-53266, dans la cible SNAT d'ebtables.** Ajoutée au catalogue KEV de la CISA le 18 septembre 2026 : elle est exploitée dans la nature. Le correctif est disponible sur Debian, RHEL 8 et 9, AlmaLinux et Ubuntu 26.04 — mais pas encore sur Ubuntu 22.04 ni 24.04. Sur ces deux versions, appliquez la mitigation maintenant.
</Warning>

## Le problème en deux phrases

La cible `snat` d'ebtables, le pare-feu des ponts réseau Linux, peut réécrire l'adresse matérielle de l'expéditeur dans les paquets ARP. Le module `ebt_snat` effectue cette écriture via `skb_store_bits()` sans vérifier au préalable que la zone mémoire visée est modifiable.

Quand cette zone est une page de fichier importée par `splice()`, le noyau écrit directement dans le cache de pages. La NVD classe la faille en écriture hors limites (CWE-787), avec un score CVSS de 8,8.

## Pourquoi celle-ci compte

Sur le papier, la faille exige une configuration rare : une règle ebtables SNAT avec réécriture ARP (`--snat-arp`) sur un pont. Red Hat la décrit d'ailleurs comme dépendante de « configurations netfilter de pont spécifiques ». C'est vrai, mais incomplet.

**L'attaquant peut créer lui-même cette configuration.** Il lui faut la capacité `CAP_NET_ADMIN` dans l'espace de noms réseau qui porte le pont. Là où les espaces de noms utilisateur non privilégiés sont autorisés, un simple compte l'obtient avec `unshare -Urn`, dans son propre espace de noms, sans rien toucher à la configuration de l'hôte.

**Le module se charge tout seul.** `ebt_snat` est chargé automatiquement dès qu'une règle le réclame. Qu'il soit absent de `lsmod` aujourd'hui ne vous protège pas.

**L'écriture vise le cache de pages.** Six octets contrôlés écrits dans une page de fichier suffisent à modifier en mémoire un fichier lisible mais non modifiable par l'attaquant, un binaire setuid par exemple.

Ces trois points viennent du [suivi public de la faille](https://github.com/suominen/CVE-2026-53266), pas des avis des distributions, qui ne détaillent pas le chemin d'attaque. La CISA ne dit pas non plus comment l'exploitation qu'elle a constatée a été menée.

## Évaluer son exposition

La question est double : **qui peut exécuter du code sur la machine, et peut-il obtenir `CAP_NET_ADMIN` ?**

| Profil                                                                                        | Exposition             | Action                                                                                  |
| --------------------------------------------------------------------------------------------- | ---------------------- | --------------------------------------------------------------------------------------- |
| VPS mono-locataire, votre code seul, aucun compte shell tiers                                 | Modérée                | Corriger et redémarrer. Sur Ubuntu 22.04 ou 24.04, appliquer la mitigation en attendant |
| VPS avec plusieurs comptes shell, des clients, ou un runner CI non audité                     | **Critique**           | Mitiger immédiatement, puis corriger dès que le noyau est disponible                    |
| Nœud Docker ou Kubernetes dont des conteneurs tournent avec `NET_ADMIN` ou en mode privilégié | **Critique**           | Mitiger sur tous les nœuds, retirer `NET_ADMIN` là où il n'est pas indispensable        |
| Hôte de virtualisation qui utilise des règles ebtables SNAT avec `--snat-arp` sur ses ponts   | **Critique**           | Corriger le noyau. Ne pas bloquer le module sans avoir mesuré l'impact sur ces règles   |
| Hébergement mutualisé où vous ne gérez pas le noyau                                           | Traité par l'hébergeur | Rien à faire de votre côté                                                              |

Comme toujours avec ce type de faille, il faut un point d'appui local. Elle n'est pas exploitable à distance en elle-même, mais transforme une application web compromise ou un compte peu privilégié en contrôle de la machine.

Pour savoir si un compte non privilégié peut créer son propre espace de noms réseau :

```bash theme={null}
# À lancer avec un utilisateur normal, pas root
unshare -Urn true && echo "espaces de noms utilisateur disponibles"

# Sur les noyaux Debian et Ubuntu : 1 = autorisé, 0 = interdit
sysctl kernel.unprivileged_userns_clone
```

## Appliquer le correctif

Le correctif amont a été intégré à Linux 7.1-rc7. Il rend la zone de l'adresse ARP modifiable avant de la lire puis de la réécrire.

### Debian, Ubuntu et dérivées

```bash theme={null}
# Mettre à jour le noyau
sudo apt update
sudo apt full-upgrade

# Le nouveau noyau n'est actif qu'après redémarrage
sudo reboot
```

État au 24 septembre 2026, d'après les trackers [Debian](https://security-tracker.debian.org/tracker/CVE-2026-53266) et [Ubuntu](https://ubuntu.com/security/CVE-2026-53266) :

| Version                   | Paquet noyau corrigé                                                        |
| ------------------------- | --------------------------------------------------------------------------- |
| 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          | **Pas encore de correctif** — mitigation nécessaire                         |
| Ubuntu 22.04 LTS          | **Pas encore de correctif** — mitigation nécessaire                         |
| Ubuntu 20.04 LTS          | Vulnérable, pas de correctif annoncé                                        |
| Ubuntu 18.04 LTS          | Non affectée                                                                |

### AlmaLinux, Rocky Linux et RHEL

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

| Version            | Noyau corrigé                    | Bulletin                                |
| ------------------ | -------------------------------- | --------------------------------------- |
| 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, publié le 24 septembre |

Red Hat publie aussi `kernel-rt-4.18.0-553.143.1.rt7.484.el8_10` pour le noyau temps réel de RHEL 8 (RHSA-2026:39082). Toute version ultérieure à celles du tableau contient le correctif.

## Mitigation immédiate

À appliquer si votre noyau corrigé n'est pas encore disponible, ou tant que vous n'avez pas pu redémarrer.

### Bloquer le module `ebt_snat`

Sans le module, la cible SNAT d'ebtables n'existe plus, et le chemin vulnérable avec elle.

```bash theme={null}
# Empêche tout chargement ultérieur du module
printf 'install ebt_snat /bin/false\n' | sudo tee /etc/modprobe.d/cve-2026-53266.conf

# Décharge le module s'il est déjà en mémoire
sudo modprobe -r ebt_snat
```

<Note>
  Si vous administrez un hôte qui s'appuie sur des règles ebtables SNAT, ce blocage les casse. Red Hat propose dans ce cas une autre voie : retirer l'option de réécriture ARP de ces règles, ou supprimer les règles SNAT qui portent sur le trafic ARP. Listez-les avec `sudo ebtables -t nat -L`.
</Note>

### Couper les espaces de noms utilisateur non privilégiés (Debian et Ubuntu)

Deuxième barrière : empêcher un compte ordinaire d'obtenir `CAP_NET_ADMIN` dans son propre espace de noms. Ce paramètre existe sur les noyaux Debian et Ubuntu.

```bash theme={null}
# Effet immédiat
sudo sysctl -w kernel.unprivileged_userns_clone=0

# Persistance au redémarrage
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cve-2026-53266.conf
```

Ce réglage casse ce qui repose sur ces espaces de noms, les conteneurs rootless notamment. Vérifiez vos usages avant de l'appliquer en production.

### Sur un cluster Kubernetes

Propagez le blocage du module sur tous les nœuds avec un DaemonSet privilégié. Le conteneur `pause` évite que le DaemonSet redémarre en boucle après l'`initContainer`.

```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
```

## Vérifier la mitigation

```bash theme={null}
# Le module ne doit pas apparaître
lsmod | grep ebt_snat

# Toute tentative de chargement doit échouer
sudo modprobe ebt_snat

# Sur Debian et Ubuntu, si vous avez coupé les espaces de noms : doit afficher 0
sysctl kernel.unprivileged_userns_clone
```

Après la mise à jour du noyau, vérifiez que c'est bien lui qui tourne :

```bash theme={null}
# Doit afficher la version corrigée
uname -r
```

Un paquet installé sans redémarrage ne protège de rien : la machine exécute toujours l'ancien noyau.

## Annuler la mitigation

Une fois le noyau corrigé démarré, vous pouvez revenir en arrière :

```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
```

## Et après ?

La faille a été rendue publique le 25 juin, corrigée par Red Hat dès le 8 juillet, mais n'est entrée au catalogue KEV que le 18 septembre. Autrement dit, les correctifs existaient depuis plus de deux mois quand l'exploitation a été confirmée. Si vos serveurs n'ont pas redémarré sur un noyau à jour depuis juillet, considérez la fenêtre comme ouverte.

En cas de doute sur une machine, ne la nettoyez pas sur place : reconstruisez-la depuis un état sain grâce à vos [snapshots](https://help.onetsolutions.net/fr/vps/snapshot) et [sauvegardes](https://help.onetsolutions.net/fr/vps/backup), puis faites tourner les secrets qu'elle détenait.

Besoin d'un avis sur votre parc ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.