Accueil Blog Music Vinyles Computhèque À propos

TL;DR pour ceux qui courent

Une faille dans le kernel Linux permet à n'importe quel utilisateur local d'escalader ses droits jusqu'à root. Elle traîne depuis août 2017. Elle affecte tous les kernels Linux mainstream construits entre 2017 et début avril 2026. C'est Theori (équipe sécu offensive, 9 victoires DEF CON CTF) qui l'a trouvée — plus précisément leur outil IA Xint Code, en une heure de scan, un seul prompt. Il faut patcher. Oui, c'est sérieux. Non, ce n'est pas une bombe à retardement façon Heartbleed : il faut déjà être connecté sur la machine pour exploiter.

L'histoire : quand l'IA trouve ce que 9 ans d'humains ont raté

La timeline réelle

  • Août 2017 : commit 72548b093ee3 introduit une "optimisation in-place" dans le subsystème crypto du kernel. Idée séduisante : éviter une copie mémoire. Effet de bord : des pages du page cache peuvent finir là où elles ne devraient pas.
  • 1er avril 2026 (oui, vraiment) : commit a664bf3d603d est mergé en mainline. Il reverte l'optimisation de 2017. Au passage, le commit atterrit dans 7.0-rc7 (le 7.0 stable n'est pas encore sorti, c'est encore en RC).
  • 22 avril 2026 : CVE-2026-31431 est assigné.
  • 29 avril 2026 : disclosure publique. PoC sur GitHub. Le site copy.fail apparaît.
  • 1er mai 2026 : AlmaLinux push ses kernels patchés en prod. Ubuntu a déjà publié sa mitigation kmod. Microsoft ajoute Copy Fail au catalogue CISA KEV.
  • 2 mai 2026 (aujourd'hui) : tu lis cet article. Et tu te demandes si tu vas devoir bosser ce weekend.

Theori, pas "une boîte appelée Xint Code"

Petit point parce que je l'ai vu mal écrit partout : Theori est l'équipe qui a fait la découverte. C'est une boîte sérieuse — anciens MMM (avec PPP de CMU et Maple Bacon de UBC), 9 victoires en DEF CON CTF, troisième de la finale du DARPA AI Cyber Challenge. Xint Code est leur système IA, l'outil qu'ils ont construit. Quand Theori dit "un prompt, une heure, pas de harness", c'est crédible.

C'est le moment où on réalise qu'un outil IA ciblé peut fouiller le subsystème crypto du kernel le plus audité du monde et sortir en 60 minutes un bug qui dort depuis 2017. Avant de se rassurer en disant "Linux a juste eu un coup de chance avec un scan IA", la vraie question c'est : qu'est-ce qui dort dans macOS, Windows, ESXi, Hyper-V que personne n'a encore scanné ?

C'est quoi, techniquement ?

Le bug en deux paragraphes

Le bug n'est pas dans tout algif_aead. Il est précisément dans le template authencesn(hmac(sha256),cbc(aes)), et seulement quand on l'utilise via la combo AF_ALG + splice() avec l'optimisation in-place de 2017.

Concrètement : authencesn écrit 4 bytes "scratch" à l'offset assoclen + cryptlen pour réorganiser le numéro de séquence étendu (ESN). Avec l'optimisation in-place, le scatterlist de sortie chaîne des pages du page cache du fichier qu'on a splicé dedans. Résultat : ces 4 bytes contrôlés finissent dans le page cache d'un fichier qu'on n'est pas censé pouvoir écrire. Le HMAC échoue, recvmsg() retourne une erreur, mais l'écriture, elle, est passée. Aucun autre algo AEAD du kernel ne fait ce write. GCM, CCM, authenc classique : tous propres. Seul authencesn salit.

Trois primitives chaînées

Le PoC fait 732 bytes de Python (stdlib uniquement : os, socket, zlib, et Python 3.10+ pour os.splice). Il chaîne :

  1. Un socket AF_ALG SOCK_SEQPACKET bindé sur authencesn(hmac(sha256),cbc(aes))
  2. Un splice() qui injecte le page cache d'un fichier setuid (/usr/bin/su par défaut)
  3. L'opération AEAD qui écrit 4 bytes contrôlés dans ce page cache

Puis on appelle su. Le kernel charge le code depuis le page cache corrompu (pas depuis le disque). L'utilitaire devient une porte ouverte vers root. Le fichier sur disque n'est jamais touché — ce qui rend la chose furtive face à un forensic disque classique. Reboot ou pression mémoire et le page cache se recharge depuis l'original. Cool, sauf qu'à ce stade tu es déjà root.

⚠️ Comment l'exploit fonctionne (pour la science, pas pour nuire)

DISCLAIMER ÉTHIQUE : La section qui suit explique précisément comment fonctionne l'exploitation de Copy Fail. Pourquoi ? Parce que tu es en veille sécu, que tu bosses en IT, ou que tu cherches à comprendre comment défendre tes systèmes. Je te fais confiance pour ne pas utiliser cette connaissance à mauvaise escient. Si tu as un lab à disposition (VirtualBox, Proxmox sandbox, machine AWS à détruire après test), tester ça sur du code que tu contrôles est une excellente pratique de sécu. Sur des systèmes en prod qu'on ne possède pas ? C'est juste du crime. On est d'accord ? Go.

L'exploitation en 4 étapes

L'exploit est un script Python de 732 bytes utilisant uniquement os, socket, zlib et Python 3.10+ pour os.splice() :

Étape 1 : Créer un socket AF_ALG SEQPACKET

python
sock = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET)
sock.bind(("authencesn(hmac(sha256),cbc(aes))", 0))

C'est un socket qui demande au kernel un service AEAD spécifique. C'est légitime pour du chiffrement applicatif. Aucun antivirus ne lève les sourcils. Les EDR ciblés regardent juste qui l'ouvre — hors des binaires crypto autorisés, ça devient bruyant.

Étape 2 : Pointer vers un binaire setuid

python
with open("/usr/bin/su", "rb") as f:
    target_fd = f.fileno()

On ouvre /usr/bin/su (ou un autre binaire setuid). C'est un fichier qu'on peut lire en tant qu'user lambda. Le kernel va charger son code dans le page cache.

Étape 3 : Injecter le page cache via splice()

python
os.splice(target_fd, 0, sock, os.SPLICE_F_MOVE, size)

Le splice() envoie le contenu du binaire directement au socket AF_ALG. Le binaire finit dans le page cache partagé que l'opération AEAD va voir. C'est là que la vulnérabilité se crée.

Étape 4 : L'opération AEAD écrit 4 bytes de contrôle dans le page cache du binaire

Quand authencesn traite les données, il écrit 4 bytes scratch pour le numéro de séquence étendu (ESN). Avec la faille, ces 4 bytes atterrissent directement dans le page cache du binaire qu'on vient d'injecter. Les 4 bytes peuvent suffire à transformer su en un utilitaire qui s'ouvre sans mot de passe, ou qui spawn un shell root.

Résultat immédiat :

bash
$ /usr/bin/su
# (tu es root)
# id
uid=0(root) gid=1002(user) groups=1002(user)

Le binaire sur disque reste inchangé. Le file de /usr/bin/su est silencieux. Seule la mémoire a été modifiée. Un reboot ou une pression mémoire et le page cache se recharge du disque — corruption disparaît. Stealth remarquable.

Pas de race condition. Pas d'offset dépendant de la distro. Pas de spray mémoire fragile. Le même script fonctionne sur Ubuntu, Amazon Linux, RHEL, SUSE, Debian, Arch — sans modification, sans recompilation.

Tester en sandbox

Si tu veux vraiment tester (et bravo de vouloir comprendre), tu dois absolument :

  • ✅ Utiliser une VM ou container jetable que tu vas détruire après
  • ✅ Utiliser une machine hors réseau ou dans un lab privé
  • ✅ Documenter ton test pour la veille sécu de ton équipe
  • ❌ NE JAMAIS tester sur un système partagé ou de prod, même vide
  • ❌ NE JAMAIS utiliser ce PoC sur un système qui ne t'appartient pas, même "juste pour vérifier"

Le repo GitHub theori-io/copy-fail-CVE-2026-31431 a le PoC complet. C'est légal et légitime de le compiler et tester sur du matériel qu'on contrôle. C'est une forme de sécurité offensive responsable.

🚨 ACTION IMMÉDIATE : PATCHER, C'EST FACILE ET C'EST MAINTENANT

Bon. Maintenant qu'on a parlé du "comment ça marche", parlons du "comment on se protège". Et c'est vraiment simple.

Les 3 étapes du salut

Étape 1 : Identifier ce que tu tournes

bash
# Tu es sur quelle distro ?
lsb_release -a
# ou
cat /etc/os-release

# Tu as des LXC ou des VMs ?
# (Si tu es sur Proxmox)
pct list
qm list

Étape 2 : Appliquer le patch approprié à ta distro

Debian / Ubuntu / Proxmox (la majorité) :

bash
sudo apt update
sudo apt full-upgrade
sudo reboot

C'est tout. Sérieusement.

AlmaLinux / Rocky / RHEL :

bash
sudo dnf clean metadata
sudo dnf upgrade
sudo reboot

Idem.

Fedora :

bash
sudo dnf upgrade
sudo reboot

Étape 3 : Vérifier après reboot

bash
uname -r
# doit afficher un kernel **neuf**
# (le kernel avant était X.Y.Z, maintenant X.Y.(Z+1) ou plus)

# Optionnel mais rassurant :
# dmesg | head -20
# (pas d'erreurs évidentes ?)

# Si tu as des services critiques
systemctl status postfix    # mail
systemctl status nginx      # web
# etc.

Priorité : les hyperviseurs d'abord

Si tu as des Proxmox, KVM, ou tout autre hyperviseur Linux :

C'est TA priorité numéro un. Reboot un hyperviseur dimanche 3am, c'est acceptable. Te faire comprometter ton hyperviseur en prod ? C'est la fin de ton infrastructure.

Patche Jungle. Patche PARIS. Patche tes KVM standalone. Après, tu fais les VMs/LXC individuellement si besoin (si c'est des LXC, t'as rien à faire, ils sont déjà patchés avec l'hyperviseur).

Combien de temps ça prend ?

  • Debian/Ubuntu/Proxmox : 5 minutes (update + reboot). Downtime : 3-4 min.
  • RHEL/Rocky/AlmaLinux : idem.
  • Les VMs KVM après : 10 min par VM (update + reboot).
  • Les LXC : 0 min (ils se font tout seul avec l'hyperviseur).

Total pour un homelab avec 2 hyperviseurs + quelques VMs : 30 min samedi 3am. C'est l'heure d'un café.

Et si tu ne peux PAS rebooter tout de suite ?

(Situation rare, mais ça arrive en prod.)

Mitigation temporaire — Debian-likes :

bash
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true

Vérification :

bash
grep -qE '^algif_aead ' /proc/modules && echo "Pas efficace" || echo "OK"

Mitigation temporaire — RHEL-likes (NE FAIS PAS la commande modprobe ci-dessus, elle ne marche pas) :

bash
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

(Oui, même la mitigation RHEL demande un reboot. C'est pour passer le paramètre kernel.)

Ces mitigations ne remplacent pas le vrai patch, mais ça ferme l'attack surface en attendant. À utiliser que si tu as vraiment un contraint de downtime (spoiler : tu n'en as probablement pas).

⚠️ Important : c'est une LPE, pas une RCE

LPE = Local Privilege Escalation : tu dois déjà être connecté sur la machine.
RCE = Remote Code Execution : ça part du réseau tout seul.

Copy Fail est une LPE. Donc avant de paniquer : est-ce qu'il existe une autre façon d'accéder à ta machine en tant qu'utilisateur ?

  • Une appli web vulnérable qui expose un shell ?
  • Un container avec du code untrusted ?
  • Un CI/CD runner qui exécute des PR de n'importe qui ?
  • Un système multi-tenant avec plusieurs users ?

Si oui, Copy Fail est la deuxième étape d'une attaque réussie : la chaîne RCE-app → escalade kernel → root → game over hyperviseur. Si non — si tu es seul user sur ton laptop bien tenu — c'est juste une vuln à patcher tranquillement.

Le vrai danger est dans les environnements partagés : Kubernetes multi-tenant, runners GitLab/GitHub Actions, plateformes PaaS, hébergement mutualisé. C'est là que la CVE prend toute sa gravité. À noter qu'AWS Lambda, Fargate (Firecracker), Cloudflare Workers (V8 isolates) et gVisor ne sont pas concernés : ils n'utilisent pas le kernel Linux comme frontière de tenant.

Qu'est-ce qui est affecté ?

Tous les kernels Linux mainstream entre 4.14 (juillet 2017) et le patch d'avril 2026. Soit :

  • ✅ Toutes les Ubuntu avant 26.04 (Resolute) — Canonical confirme que 26.04+ shippe un kernel non vulnérable
  • ✅ Debian 11, 12, 13 (avant patch)
  • ✅ Rocky / Alma / RHEL 8, 9, 10
  • ✅ Fedora (toutes versions actives avant patch)
  • ✅ Amazon Linux 2, 2023
  • ✅ SUSE 15, 16
  • ✅ Proxmox (puisque kernel Debian-based avec patches Proxmox)
  • ✅ Arch, Gentoo, openSUSE, etc.

C'est-à-dire : à peu près tout ce qui tourne en prod aujourd'hui.

Mon infra : 2 hyperviseurs, LXC et VMs, et pourquoi ce mix

Voilà ma situation concrète, parce que c'est plus parlant qu'une matrice abstraite.

J'ai deux hyperviseurs Proxmox :

  • Jungle : ma baie physique perso, Debian 13 (trixie), kernel pve
  • PARIS : ma baie cloud chez Scaleway, Debian 13 (trixie), kernel pve

Et là-dessus tournent un mix LXC + VMs : Homer (mail) et Bart (web) en VMs KVM, GoriTalk/Matrix en LXC, mqtt/zigbee2mqtt/pihole en LXC.

Pourquoi ce mix ?

Honnêtement ? Les LXC c'est meilleur. Plus léger, plus rapide à démarrer, plus facile à patcher, consommation mémoire infiniment inférieure aux VMs. J'ai migré progressivement mes services en LXC au fil des années — et je félicite ce choix chaque jour.

Mais les VMs restent nécessaires quand :

  • Tu besoin d'un kernel spécifique (une Ubuntu 16.04 LTS pour un logiciel propriétaire qui ne peut pas être mis à jour)
  • Tu tournes un OS différent (Windows Server, FreeBSD, etc.)
  • Tu as besoin d'une isolation réseau ou hardware poussée (accès direct à un périphérique, VLAN isolé, etc.)
  • Un legacy system qui refuse de bouger (mainframe-style)

Pour la majorité des services modernes (mail, web, API, monitoring, IoT), LXC suffit et gagne sur tous les fronts.

Le truc important avec les LXC vs VMs pour le patching

Les LXC partagent le kernel de leur hyperviseur. Donc :

  • uname -r dans un LXC renvoie le même kernel que Jungle
  • Patcher Jungle = patcher automatiquement tous les LXC dessus, en un seul reboot

Les VMs ont chacune leur propre kernel. Donc :

  • Homer (VM) a son kernel Debian/Ubuntu indépendant
  • Bart (VM) a son kernel indépendant
  • Reboot de Jungle pause/migre/redémarre les VMs, mais ne patche rien dedans — faut entrer dans chaque VM et faire son apt full-upgrade && reboot

Pour vérifier ce que tu as :

bash
# Sur ton hyperviseur
pct list   # liste les LXC (containers) → patchés avec l'hyperviseur
qm list    # liste les VMs (KVM) → patching indépendant requis

La bonne nouvelle : même avec un mix, le patching n'est pas catastrophique. Les LXC se font tout seul, les VMs c'est un apt par machine.

L'angle que personne ne traite : les hyperviseurs

Pendant que tout le monde recommande de "patcher vos serveurs", il y a un éléphant dans la salle : les hyperviseurs eux-mêmes tournent un kernel Linux.

Proxmox, KVM, Hyper-V (sur ses parties Linux), XCP-ng. Tous concernés. Si un attaquant chope une RCE dans une appli hébergée sur une de tes VMs/LXC, et que de là il exploite Copy Fail sur le kernel du host, il a :

  • Accès aux disques de toutes les VMs
  • La capacité de pivoter latéralement vers d'autres VMs
  • Une chaîne de confiance brisée jusqu'au plus bas niveau
  • Potentiellement la capacité de rootkitter le host sans que tu le saches

C'est pire qu'une RCE sur une VM. Une VM, ça se réinstalle en deux heures. Un hyperviseur compromis, c'est ta chaîne de confiance entière qui se casse — et pour un homelab, c'est la fin de la sérénité.

Et pourtant : aucun article officiel des distros principales ne met l'accent là-dessus. Proxmox VE n'a pas (encore) émis de communication dédiée à Copy Fail au moment où j'écris ces lignes. Le patching arrivera via Debian, sans grand bruit. C'est dommage parce que pour les sysadmins de homelabs et d'infra petites/moyennes, c'est l'angle qui devrait dicter la priorité.

État des patchs au 2 mai 2026

✅ Distributions qui ont déjà patché ou shippent une mitigation

AlmaLinux : kernels patchés en production depuis le 1er mai 21:07 UTC. Ils n'ont pas attendu Red Hat — leur core team a buildé un kernel sur le commit upstream a664bf3d603d. Respect.

bash
sudo dnf clean metadata && sudo dnf upgrade && sudo reboot

Ubuntu : mitigation kmod publiée (désactive le module via package update), patches kernel en cours de déploiement sur tous les supports stables. Ubuntu 26.04 (Resolute) n'est pas affecté — leur kernel embarque déjà le fix.

bash
sudo apt update && sudo apt full-upgrade && sudo reboot

Debian : security tracker actif, patches kernel en distribution sur les branches supportées. Le tracker pointe explicitement le commit a664bf3d603d comme fix de référence.

Proxmox VE : suit Debian, donc patches arrivant via les repos Proxmox dans les jours qui viennent (déjà disponibles sur certains streams au moment d'écrire).

bash
apt update && apt full-upgrade && reboot

CloudLinux : kernels patchés en cours de rollout (6-24h selon le produit). KernelCare livepatch dispo en alternative — patch sans reboot, ce qui change la donne pour les hébergeurs.

⏳ Distributions à la traîne

Red Hat / RHEL / CentOS Stream / Oracle Linux : Bugzilla 2460538 actif, mais pas de kernel patché shippé en officiel au moment où AlmaLinux a sorti le sien (1er mai). C'est précisément la raison pour laquelle AlmaLinux a buildé son propre patch indépendamment.

C'est là que ça pique. Red Hat vante sa sécurité "Enterprise" et son SLA. Sur Copy Fail, AlmaLinux et Debian ont été plus rapides que IBM. La distro communautaire et la distro gratuite bénévole ont publié avant la solution payante. Pour ceux qui paient un support RHEL, vous avez le droit d'être un peu énervés.

Fedora : suit le rythme RHEL, donc en attente.

Amazon Linux 2023 : kernel patché annoncé, en cours de propagation.

Et CISA KEV ?

C'est officiel : CVE-2026-31431 est dans le catalogue Known Exploited Vulnerabilities de CISA. Pour les organismes US sous mandat fédéral, ça devient un patch obligatoire avec deadline. Pour le reste du monde, c'est un signal fort que l'exploitation active est anticipée à court terme.

Mitigation temporaire : attention au piège

C'est ici que beaucoup d'articles se plantent et donnent un faux sentiment de sécurité. Il y a deux familles de mitigations selon ta distro, et elles ne sont pas interchangeables.

Famille Debian/Ubuntu/Proxmox : module chargeable

Sur Debian-likes, algif_aead est compilé en module chargeable. Tu peux le bloquer :

bash
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true

Ça empêche le module de se charger au boot et le retire s'il est en mémoire. Vérification :

bash
grep -qE '^algif_aead ' /proc/modules && echo "Encore chargé" || echo "OK, déchargé"

Cette mitigation n'affecte pas dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, SSH ni le crypto kernel utilisé en interne. Tout ça utilise l'API crypto directement, pas l'interface AF_ALG userspace.

Famille RHEL/Rocky/AlmaLinux/Fedora : module BUILT-IN

ICI ATTENTION : sur la famille RHEL, algif_aead est compilé en built-in (CONFIG_CRYPTO_USER_API_AEAD=y). Conséquence directe :

Les règles modprobe.d ne peuvent pas bloquer son chargement. rmmod ne peut pas le retirer. Les commandes ci-dessus s'exécutent sans erreur mais ne changent rien. Tu obtiens un faux sentiment de protection.

C'est documenté noir sur blanc par CloudLinux. Et c'est exactement le genre de gaffe sécu qui peut coûter cher. Sur la famille RHEL, la vraie mitigation provisoire est de blacklister l'initcall via la ligne de commande kernel :

bash
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Après reboot :

bash
cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

Si la ligne contient bien le paramètre, l'interface AEAD AF_ALG n'est plus enregistrée au boot. Attaque-surface fermée jusqu'au vrai patch kernel.

Vérification d'exposition

Sur n'importe quelle distro, tu peux vérifier qui utilise actuellement AF_ALG :

bash
sudo lsof | grep AF_ALG

Sur 99% des systèmes : rien ou seulement des binaires de la chaîne disk-encryption (cryptsetup, systemd-cryptsetup, kcapi-*). Mitiger sans risque.

Mon plan : 30 minutes sur un weekend

Vu mon infra (deux Proxmox, LXC + VMs), voilà le réaliste :

Samedi 03h00 — Jungle (avec LXC qui se patchent auto)

Je SSH, je fais apt update && apt full-upgrade && reboot. Durée : 5 min. Downtime : 3-4 min. Les LXC Homer et les autres petits services (mqtt, zigbee2mqtt, pihole) repartent tous seuls, Postfix/nginx/Synapse aussi via systemd.

Pour mes deux VMs (Homer et Bart en KVM, pas LXC), elles sont juste en pause pendant le reboot du host. Après, je SSH dedans individuellement et apt full-upgrade && reboot. C'est 10 min par VM, donc 20 min au total pour les deux. Mais c'est après le patching du host, c'est pas critique.

Dimanche 03h00 — PARIS (même routine)

Je répète samedi pour PARIS, dimanche pour étaler les reboots. Si le nouveau kernel a un bug surprenant, je veux pas tous mes services down en même temps.

Vérification post-patch :

bash
uname -r                      # kernel neuf ?
systemctl --failed            # rien en rouge ?
pct list                      # LXC all green ?

Si un truc déraille, rollback kernel via GRUB au reboot suivant. C'est la beauté de Proxmox : tu peux choisir l'ancien kernel du menu de boot.

Note VMs : Homer et Bart en KVM, elles se font patcher indépendamment de Jungle. Reboot du host ne les touche pas au level kernel. Il faut entrer dans chaque VM et apt full-upgrade && reboot.

Et l'EDR là-dedans ?

Quelques mots vite fait, parce que dans un contexte pro la question se pose. Si ton infra a un EDR (Endpoint Detection and Response) — Microsoft Defender for Endpoint, CrowdStrike, SentinelOne, Sophos — il devrait détecter le pattern d'exploitation : création d'un socket AF_ALG SEQPACKET par un processus en dehors de la toolchain crypto connue (cryptsetup, kcapi-*, systemd-cryptsetup). Sysdig a publié une règle Falco prête à l'emploi qui couvre exactement ça.

Ça ne remplace pas le patch. Mais en attendant le patch, ça ajoute une couche de détection. Pour un homelab solo, c'est overkill. Pour une infra pro avec des couches multi-tenant, c'est non négociable.

Conclusion : Copy Fail dit quelque chose de plus large

Une faille de logique simple, dans le subsystème crypto le plus audité du kernel, qui dort 9 ans sans qu'aucun reviewer humain ne la voie. Une IA ciblée la trouve en 1 heure avec un seul prompt.

On peut tirer trois leçons.

Un, AlmaLinux et Debian ont publié leurs patches plus vite que Red Hat. La sécurité réactive n'est plus l'apanage du payant — c'est devenu l'apanage du communautaire bien organisé. IBM, si vous lisez ça : votre clientèle paie pour un SLA, donnez-leur un SLA.

Deux, l'angle hyperviseur reste sous-traité. Tous les articles vous disent "patchez vos serveurs". Très peu vous disent "votre Proxmox host est le serveur le plus critique de votre infra et doit être patché en premier". Si tu as un homelab ou une PME avec virtualisation, c'est ta priorité numéro un.

Trois, l'IA va trouver d'autres bugs. Theori a indiqué que Xint Code a sorti d'autres findings du kernel encore en disclosure coordonnée. Mythos d'Anthropic, et les outils similaires qui vont arriver, vont scanner des subsystems entiers à des vitesses incompatibles avec le rythme des reviewers humains. C'est une bonne nouvelle pour les défenseurs si ces outils sont utilisés en upstream pour patcher avant disclosure. C'est une catastrophe si les attaquants prennent l'avance — et il est naïf de croire que ce n'est pas en train de se faire en parallèle, dans des labos qui ne publient pas.

La période 2026-2028 va probablement être marquée par une vague de CVE critiques découvertes par IA dans des subsystems centraux — kernel, libc, crypto libs, runtimes web, bases de données. Préparez vos process de patching maintenant. Apprenez à patcher vite et sans drame. C'est la nouvelle baseline.

Pour aller plus vite

  • Tu es sur Debian/Ubuntu/Proxmox : apt full-upgrade && reboot cette semaine. C'est tout.
  • Tu es sur AlmaLinux/Rocky : dnf clean metadata && dnf upgrade && reboot. AlmaLinux a déjà patché, Rocky a probablement suivi.
  • Tu es sur RHEL : appelle ton support, en attendant fais le grubby initcall_blacklist.
  • Tu es sur Kubernetes multi-tenant ou CI/CD avec workloads untrusted : c'est ta priorité du jour, pas du weekend.
  • Tu as un hyperviseur (Proxmox, KVM standalone, etc.) : patche-le. C'est plus important que tes VMs.

Pour moi, deux reboots ce weekend. Merci aux mainteneurs Debian et Proxmox d'avoir poussé les patches vite. Merci à Theori d'avoir disclosé proprement. Merci à Xint Code d'exister, parce que je préfère que l'IA trouve les bugs avant les attaquants — du moins tant qu'elle est entre les bonnes mains.

Sources & lectures

#Sécu #Linux #DevOps #Rant
Commentaires 0
Laisser un commentaire