Chaque cloud possède un mur qu'il jure porteur. Sur un hôte virtualisé, ce mur s'appelle l'hyperviseur : la fine couche de code qui persuade chaque client que sa part de machine n'appartient qu'à lui. Le 3 novembre, le projet Xen a annoncé au monde qu'un mur qu'il entretient depuis 2016 comporte une porte, et que cette porte a été trouvée par une IA.
L'avis est XSA-523. Les deux CVE sont CVE-2026-102703 et CVE-2026-102704. L'impact, dans la formulation prudente du projet : « Un invité malveillant peut lire et écrire de la mémoire arbitraire appartenant à d'autres domaines, y compris Dom0. »
Relisez-le. Ce n'est pas « un invité peut faire tomber son voisin ». Ce n'est pas « un invité fuite quelques octets ». Un invité peut atteindre la mémoire d'un autre client et celle de Dom0, le domaine de contrôle qui pilote l'hôte. XCP-ng, la plateforme open source bâtie sur Xen, le dit plus frontalement dans ses notes : « un seul invité compromis peut sortir de son isolation et prendre le contrôle de tout l'hôte ».
Et il n'y a pas de mitigation. Seulement des patches, et un redémarrage.
Ce qui a cassé, exactement
La grant table de Xen est le mécanisme qui permet aux machines virtuelles de partager de la mémoire sans se faire confiance. Un invité déclare « ces pages peuvent être lues par cette VM », et Xen fait respecter la promesse. L'hypercall GNTTABOP_copy exécute ces copies par lots, et comme les éléments voisins d'un lot touchent souvent de la mémoire voisine dans la même page, Xen met en cache la description validée de l'élément précédent et la réutilise quand le suivant semble équivalent.
C'est dans ce cache que le mur a fissuré.
La première faille, CVE-2026-102703, est un contrôle de validité qui confond deux types d'identifiants. Quand le nouvel élément copie par numéro de trame machine, Xen compare ce numéro à l'entrée en cache sans vérifier d'abord que l'entrée en cache était bien une trame. Une référence de grant issue d'un élément précédent peut être prise pour un numéro de trame physique, et le tampon en cache est réutilisé pour de la mémoire que l'invité n'a pas le droit de toucher.
La seconde, CVE-2026-102704, est un contrôle de permission placé au mauvais endroit. Copier par numéro de trame plutôt que par référence de grant n'est légal que lorsque l'invité travaille sur sa propre mémoire, et Xen le vérifie dans une fonction appelée au moment de reverrouiller les domaines concernés. Si l'élément suivant nomme les mêmes domaines que le précédent, cette fonction est entièrement court-circuitée et la règle « ta mémoire uniquement » n'est jamais appliquée.
Aucune des deux voies n'exige de configuration spéciale, de root dans l'invité, ni de chaîne d'exploitation publique. Les deux exigent une seule chose : une grant table fonctionnelle. Toutes les versions de Xen depuis la 4.6 sont vulnérables. Cela représente une décennie d'hyperviseur, et c'est pourquoi le sujet dépasse largement la liste de diffusion de Xen.
La partie qui devrait changer votre façon de recruter en sécurité
Le projet Xen attribue la découverte à Anthropic, via Claude. Stephan Lipp, d'Ada Logics, a validé le résultat. L'équipe de recherche CodeAnt a rapporté le même problème de façon indépendante.
Retenez cette séquence. Un modèle a trouvé une erreur de logique mémoire dans la grant table d'un hyperviseur lu pendant dix ans par des experts humains. Un cabinet humain de validation a confirmé que la trouvaille était réelle. Une seconde équipe de recherche IA, sans lien, est arrivée au même défaut d'elle-même.
C'est la même semaine où le groupe renseignement menaces de Google a décrit des opérations de LLMjacking siphonnant plus d'un million de dollars d'usage IA cloud volé, et où Wiz a compté plus de neuf plateformes de développement IA compromises en octobre. Deux courbes se croisent : les attaquants automatisent la découverte et la monétisation avec l'IA, et les défenseurs disposent désormais d'IA qui trouvent de vrais bugs dans la couche la plus profonde de la pile.
La lecture pratique pour un CTO est inconfortable : votre cadence de patch ne se cale plus sur des chercheurs humains. Elle se cale sur des machines qui lisent du code noyau toute la nuit.
Qui est exposé, et qui ne l'est pas
Si vous louez une VM à un hyperscaler, le patch lui appartient et votre exposition dépend de sa fenêtre de maintenance. Demandez-le. Dans un cloud géré, la vision de l'invité peut être en retard sur l'état réel de l'hôte ; seule une réponse écrite du fournisseur compte.
Si vous exploitez votre propre parc Xen ou XCP-ng, ce qui est courant chez les hébergeurs, les agences qui gèrent l'infrastructure de leurs clients et tous ceux qui virtualisent on-premise, l'horloge est la vôtre.
- Xen unstable jusqu'à 4.19.x : appliquez xsa523-1.patch et xsa523-2.patch.
- Xen 4.18.x à 4.17.x : appliquez xsa523-4.18-1.patch et xsa523-4.18-2.patch.
- Xen 4.6.x à 4.16.x : aucun patch upstream. Ces branches sont en fin de vie. Si vous êtes ici, c'est un moment de migration, pas de patch.
- XCP-ng 8.3 LTS : installez xen-4.17.7-4.2.xcpng8.3 et redémarrez l'hôte. Vates qualifie l'impact de critique.
- Qubes OS 4.3 : paquets Xen 4.19.6-3 en dom0, redémarrage de dom0 requis. Si vous utilisez Anti Evil Maid, rescellez votre passphrase, car les nouveaux binaires Xen modifient PCR18 et PCR19.
Deux vérités opérationnelles des précédentes alertes hyperviseur s'appliquent encore. Premièrement, les patches sont préparés contre les branches stables : montez d'abord en tête de branche, sinon une archive de release vous résistera. Deuxièmement, patcher arrête les attaques futures, mais ne dit pas si une attaque a déjà eu lieu. Un invité qui lit la mémoire de son voisin ne laisse aucune trace dans les logs du voisin. Si vous hébergez des locataires non fiables, le patch ouvre la revue d'incident, il ne la ferme pas.
Ce que nous faisons, et ce que nous ferions pour vous
Chez aratech, un patch d'hyperviseur est un changement de classe un : fenêtre de redémarrage planifiée, information des locataires, snapshot avant redémarrage, puis relecture du changelog du paquet pour prouver que la branche porte bien le numéro XSA au lieu de le supposer. Les clients sur infrastructure virtualisée partagée obtiennent une réponse écrite : quel hyperviseur, quelle version, quel état de patch.
La version courte de ce qu'il faut faire cette semaine.
- Inventoriez l'hyperviseur, pas seulement la VM. Sur un hôte Xen,
xl info | grep '^xen_version', et dans l'invitécat /sys/hypervisor/type. La plupart des équipes connaissent leurs versions d'OS et ignorent ce qui se trouve dessous. - Demandez à chaque fournisseur l'état XSA-523 par écrit, avec la branche et la date de redémarrage. « Nous sommes patchés » sans numéro de version est une supposition.
- Patchez, redémarrez, vérifiez. Un patch d'hyperviseur qui ne redémarre jamais est une note dans un ticket, pas un correctif.
- Si vous exploitez des branches en fin de vie, traitez XSA-523 comme le déclencheur d'un plan de migration. Aucun patch n'arrivera pour 4.6 à 4.16.
- Partez du principe que la découverte va désormais à vitesse machine. Réduisez le délai entre « avis publié » et « hôte redémarré » à quelques heures, et écrivez le runbook avant d'en avoir besoin.
Le mur tient, si vous le reconstruisez
Le mur de l'hyperviseur reste le meilleur que nous ayons. Il a tenu une décennie face à des chercheurs humains, et il a tenu parce que les contrôles étaient presque justes. « Presque » est désormais tout ce qu'il faut à un auditeur IA pour vous trouver.
La porte dans Xen est patchée. Savoir si la porte de votre parc est fermée tient à une question ennuyeuse : savez-vous, aujourd'hui, sur quelle version d'hyperviseur tournent vos charges de production ?
Si la réponse honnête est « il faudrait que je demande », c'est la conclusion qui mérite votre attention avant le prochain avis.