Chrome XSLT use-after-free exploité dans la nature (CVE-2026-125350)

En bref

• Un use-after-free dans le traitement XML et XSLT de Chrome permet à une page piégée de corrompre la mémoire du moteur de rendu. Google classe CVE-2026-125350 High et affirme qu'un exploit existe dans la nature.
• Toutes les versions de Chrome de bureau antérieures à 157.0.8103.50 sont concernées. Statcounter place Chrome à 66,98 % de part de marché des navigateurs de bureau dans le monde en octobre 2026.
• CVE-2026-125350 ne figure pas au catalogue Known Exploited Vulnerabilities (KEV) de la CISA au 10 novembre 2026.
• La faille se trouve dans le cache de correspondance directe de motifs de libxslt, que Chrome embarque. Le même correctif ferme CVE-2026-125346, signalée séparément le 12 octobre 2026.
• Mettez Chrome à jour vers 157.0.8103.50 ou 157.0.8103.51, puis redémarrez le navigateur. Les navigateurs basés sur Chromium ont besoin de la mise à jour de leur éditeur. Voir « Comment corriger ? ».

Suis-je concerné ?

Vous êtes exposé lorsque toutes ces conditions sont réunies :

• Vous utilisez Google Chrome de bureau antérieur à 157.0.8103.50 sous Windows, macOS ou Linux.
• Vous ouvrez une page contrôlée par l'attaquant, ou une page qui charge du XML et du XSLT contrôlés par l'attaquant. Aucune autre interaction n'est nécessaire pour que l'analyseur vulnérable s'exécute.
• La version ne contient pas déjà le correctif libxslt. Google l'a livré dans les versions de bureau 157.0.8103.50 et 157.0.8103.51 le 9 novembre 2026.

L'avis couvre Chrome de bureau. Les navigateurs basés sur Chromium partagent le moteur, mais chaque éditeur livre sa propre version et son propre calendrier de correction. Vérifiez auprès de l'éditeur avant de considérer un navigateur Chromium comme corrigé.

Vérifiez la version installée depuis le navigateur :

# Open this URL in Chrome and read the version line
chrome://version

Depuis un terminal, le gestionnaire de paquets indique la version installée :

# Debian and Ubuntu
dpkg-query -W -f='${Version}\n' google-chrome-stable

# Fedora and RHEL
rpm -q google-chrome-stable

# macOS
defaults read "/Applications/Google Chrome.app/Contents/Info.plist" CFBundleShortVersionString

Comparez le résultat avec 157.0.8103.50. Une version antérieure à ce numéro est concernée.

Comment corriger ?

1. Mettez Chrome à jour vers 157.0.8103.50 ou ultérieur. Sous Windows et macOS, ouvrez le menu à trois points, choisissez Aide, puis À propos de Google Chrome, et laissez la mise à jour s'installer. Sous Linux, mettez à jour le paquet : sudo apt update && sudo apt install --only-upgrade google-chrome-stable
2. Redémarrez le navigateur. Une mise à jour téléchargée mais non appliquée laisse l'ancien moteur de rendu en cours d'exécution.
3. Si vous gérez Chrome par une stratégie d'entreprise, vérifiez que la mise à jour est autorisée et que le rapport de version indique 157.0.8103.50 ou ultérieur sur chaque poste.
4. Si vous utilisez un navigateur basé sur Chromium, consultez son avis et son canal de mise à jour. Ne supposez pas que le numéro de version de Chrome s'applique.
5. Si vous ne pouvez pas mettre à jour immédiatement, limitez la navigation aux sites de confiance et bloquez le contenu XML et XSLT non fiable au proxy. Cela réduit l'exposition ; ce n'est pas un correctif.

Aucun commutateur de configuration ne désactive le cache de motifs vulnérable tout en gardant XSLT fonctionnel. La version de Google est le correctif.

Quelle est la cause racine ?

La faille est un défaut de réentrance dans xsltTestCompMatchDirect() dans le moteur de motifs de libxslt. La fonction met en cache l'ensemble de nœuds produit par une évaluation directe de motif dans les extras d'exécution du contexte de transformation, et elle lit le pointeur mis en cache avant d'évaluer le motif.

Le cache existe pour que les tests de motif directs répétés sur le même document réutilisent un seul ensemble de nœuds au lieu de réévaluer le XPath pour chaque nœud. Il est indexé sur les extras d'exécution de la première étape : un pointeur de liste, le document pour lequel la liste a été construite et un index. Cette conception suppose que l'évaluation ne modifie pas le cache. XSLT autorise l'évaluation paresseuse, donc une variable globale ou un paramètre de modèle peut exécuter une instruction de transformation imbriquée pendant que l'évaluation externe est encore sur la pile. Le xsl:number imbriqué peut amorcer ou remplacer le même emplacement de cache, ce qui casse l'hypothèse.

Voici le code vulnérable dans third_party/libxslt/src/libxslt/pattern.c, dans l'arbre Chromium avant le correctif :

list = (xmlXPathObjectPtr)
    XSLT_RUNTIME_EXTRA_LST(ctxt, sel->lenExtra);

if ((list == NULL) || (prevdoc != doc)) {
    ...
    newlist = xmlXPathEval(comp->pattern, ctxt->xpathCtxt);
    ...
    if (nocache == 0) {
        if (list != NULL)
            xmlXPathFreeObject(list);
        list = newlist;

        XSLT_RUNTIME_EXTRA_LST(ctxt, sel->lenExtra) =
            (void *) list;
        ...
    } else
        list = newlist;
}

La fonction lit list depuis le cache avant xmlXPathEval. L'évaluation peut réentrer dans xsltTestCompMatchDirect() pour le même emplacement de cache, par exemple par une variable globale évaluée paresseusement dont la valeur exécute xsl:number. L'appel imbriqué libère ou remplace l'objet mis en cache. L'appel externe libère alors le pointeur list devenu obsolète, ce qui est une double libération et laisse le cache pointer vers une mémoire libérée.

Le commit de correction de Chromium décrit la même séquence. L'ensemble de nœuds mis en cache est lu avant l'évaluation, l'appel imbriqué peut le libérer et le remplacer, et l'appel externe le libère ensuite de nouveau.

Comment la faille est-elle exploitée ?

L'attaquant a besoin d'un document que Chrome analyse comme du XML avec une feuille de style XSLT. La feuille de style pousse le moteur de motifs dans le chemin de cache réentrant.

1. La victime ouvre une page qui charge un document XML contrôlé par l'attaquant avec une instruction de traitement xml-stylesheet, ou une feuille de style XSLT contrôlée par l'attaquant.
2. Un motif de modèle ou xsl:number utilise une construction évaluée paresseusement, par exemple une variable globale dont la valeur exécute xsl:number.
3. Le cache de correspondance directe de motifs est amorcé pour le motif, puis xmlXPathEval réentre dans xsltTestCompMatchDirect() pour le même emplacement de cache.
4. L'appel imbriqué libère ou remplace l'ensemble de nœuds mis en cache. L'appel externe libère le pointeur obsolète et stocke newlist à sa place.
5. La transformation continue avec une entrée de cache qui pointe vers une mémoire libérée, ce qui donne un use-after-free dans le moteur de rendu.

Google affirme qu'un exploit de CVE-2026-125350 existe dans la nature. L'entreprise n'a pas publié l'exploit, la chaîne d'attaque, les sites concernés ni l'identité des attaquants. Le dossier CVE n'était pas dans la base publique au moment de la rédaction, et Google restreint les détails pendant que les utilisateurs se mettent à jour.

Le même correctif ferme CVE-2026-125346, un use-after-free dans XML signalé par Arni Hardarson de Neonix Security le 12 octobre 2026. Google n'a pas dit que celle-ci est exploitée. Les deux signalements exercent la même faille de cache.

Comment se déroule l'attaque ?

Un document XML et XSLT piégé pousse une évaluation réentrante du cache de motifs ; l'appel imbriqué libère l'ensemble de nœuds mis en cache et l'appel externe le libère de nouveau, laissant le moteur de rendu avec un use-after-free.

Que peut faire un attaquant ?

Un attaquant qui déclenche la faille corrompt la mémoire du moteur de rendu de Chrome. Google classe la faille High et affirme qu'un exploit existe dans la nature. L'entreprise n'a pas dit si l'exploit s'échappe du bac à sable du moteur de rendu, quel processus il cible ni ce qu'il fait après l'exécution de code.

Les conditions font partie de l'impact :

• L'attaquant doit amener la victime à charger du XML ou du XSLT qu'il contrôle. Une visite de page normale suffit.
• Le code vulnérable s'exécute dans le moteur de rendu. L'exécution de code y est limitée par le bac à sable de Chrome jusqu'à ce qu'une seconde faille ou une évasion de bac à sable soit enchaînée. Chrome isole le moteur de rendu sur chaque plateforme de bureau. L'exploit signalé par Google peut s'arrêter au moteur de rendu ou faire partie d'une chaîne plus large, et le dossier public ne dit pas lequel. Une primitive de corruption mémoire dans le moteur de rendu est la première étape de la plupart des chaînes d'exploitation de navigateur, donc la mise à jour est urgente dans les deux cas.
• Aucun code d'exploit public n'est disponible. L'exploit dans la nature est connu par la déclaration de Google, pas par un échantillon publié.

Ne lisez pas « exploité dans la nature » comme « compromission complète de l'appareil ». Google n'a pas publié cette chaîne, et le bac à sable du moteur de rendu est une frontière distincte.

Pourquoi le correctif fonctionne-t-il ?

Le correctif relit l'emplacement de cache après xmlXPathEval, donc l'appel externe libère l'objet actuellement dans le cache, et non le pointeur lu avant l'appel imbriqué. Voici le code ajouté par le commit Chromium 61cab3f77203 :

@@ -581,6 +581,15 @@ xsltTestCompMatchDirect(xsltTransformContextPtr ctxt, xsltCompMatchPtr comp,
        nocache = 1;

    if (nocache == 0) {
+       /*
+        * xmlXPathEval can re-enter this function for the same cache
+        * slot, e.g. through a lazily evaluated global variable whose
+        * value runs xsl:number. The nested call may free or replace
+        * the cached object, so re-read it instead of using the value
+        * read before the evaluation.
+        */
+       list = (xmlXPathObjectPtr)
+       XSLT_RUNTIME_EXTRA_LST(ctxt, sel->lenExtra);
        if (list != NULL)
        xmlXPathFreeObject(list);
        list = newlist;

Le correctif est complet pour la copie de Chromium. Il ferme CVE-2026-125350 et CVE-2026-125346, et le commit ajoute un test de régression qui charge la feuille XSLT piégée dans une iframe.

Le projet libxslt en amont n'a pas pris le changement. Le fichier libxslt/pattern.c de la branche master amont lit encore list avant xmlXPathEval et le libère après l'appel. Chromium porte le correctif comme un patch dans third_party/libxslt/chromium. Les logiciels qui embarquent libxslt, notamment les pipelines XML côté serveur et d'autres navigateurs, doivent demander à leur éditeur si cette copie est corrigée.

Comment vérifier si j'ai été compromis ?

Google n'a publié aucun indicateur de compromission pour CVE-2026-125350. Un exploit de navigateur laisse peu de traces sur le disque, donc la vérification fiable consiste à confirmer la version du navigateur et à considérer toute période sur une version concernée comme une exposition.

• Confirmez que chaque installation de Chrome de bureau exécute 157.0.8103.50 ou ultérieur. Utilisez chrome://version en local et votre inventaire de gestion des postes pour le reste.
• Examinez les rapports de plantage du navigateur de la période concernée pour des plantages du moteur de rendu sur des pages qui chargent du XML ou du XSLT. Un plantage est une piste, pas une preuve d'exploitation.
• Examinez les journaux du proxy et du DNS pour du contenu XML ou XSLT provenant d'hôtes que vos utilisateurs ne visitent pas habituellement. Google n'a publié aucun domaine ni hachage.
• Si vous suspectez une exploitation, conservez le profil du navigateur, les vidages de plantage et les journaux du proxy avant d'effacer la machine, puis reconstruisez-la.

Un exploit qui réussit peut ne laisser ni plantage ni fichier. L'absence de plantage ne prouve pas qu'un poste n'a pas été exposé.

Chronologie

• 2026-10-12 : Arni Hardarson de Neonix Security signale CVE-2026-125346, un use-after-free dans XML.
• 2026-11-06 : un chercheur anonyme signale CVE-2026-125350, un use-after-free dans XML que Google déclarera ensuite exploité dans la nature.
• 2026-11-07 : Chromium intègre le commit 61cab3f77203, qui corrige les deux failles dans le cache de correspondance directe de motifs de libxslt.
• 2026-11-09 : Google publie Chrome 157.0.8103.50/.51 pour Windows et macOS et 157.0.8103.50 pour Linux.

FAQ

CVE-2026-125350 est-elle exploitée dans la nature ?

Oui. Le billet du canal stable de Google indique qu'un exploit de CVE-2026-125350 existe dans la nature. Google n'a pas dit qui l'utilise, quels sites le servent ni s'il s'échappe du bac à sable du moteur de rendu.

Existe-t-il un exploit public ?

Non. Google n'a pas publié de code d'exploit, et le dossier CVE n'était pas public au moment de la rédaction. L'exploit dans la nature est connu par la déclaration de Google, pas par un échantillon.

Cela concerne-t-il Chrome sous Android ?

L'avis de Google couvre le canal stable de bureau. Il ne liste pas Chrome pour Android. Traitez Android comme non confirmé plutôt que comme sûr, et maintenez-le à jour via le Play Store.

Les autres navigateurs Chromium sont-ils concernés ?

Probablement, jusqu'à ce que leurs éditeurs livrent le même correctif libxslt. Le numéro de version de Chrome ne s'applique pas à Edge, Brave, Opera ou Vivaldi. Consultez l'avis et le canal de mise à jour de chaque éditeur.

Qu'est-ce que le cache de correspondance directe de motifs ?

C'est un cache par transformation dans libxslt qui stocke l'ensemble de nœuds produit par une évaluation directe de motif XPath. Il évite de réévaluer le même motif pour chaque nœud. Comme le cache vit dans le contexte de transformation, une évaluation imbriquée peut atteindre le même emplacement et remplacer l'objet stocké.

libxslt est-il corrigé ?

Non. La branche master amont de libxslt contient encore la lecture vulnérable, et Chromium porte le correctif comme un patch local. Les applications qui embarquent libxslt doivent suivre le projet amont et leur éditeur.

Quelle est l'urgence de la mise à jour ?

Mettez à jour maintenant. La faille est atteignable par une visite de page normale, Chrome est le navigateur de bureau majoritaire et Google affirme qu'un exploit existe. La mise à jour demande un redémarrage.

Références

• Chrome Releases, « Stable Channel Update for Desktop », 9 novembre 2026, les versions corrigées, les neuf correctifs de sécurité, CVE-2026-125350, CVE-2026-125346 et la déclaration d'exploitation dans la nature : https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop_018223192.html (vérifié le 10 novembre 2026)
• Commit Chromium 61cab3f77203671e09402e68738aa217632aed8d, « Fix use-after-free in libxslt direct pattern match cache », le correctif et le test de régression : https://github.com/chromium/chromium/commit/61cab3f77203671e09402e68738aa217632aed8d (vérifié le 10 novembre 2026)
• La fonction vulnérable xsltTestCompMatchDirect() dans third_party/libxslt/src/libxslt/pattern.c avant le correctif : https://github.com/chromium/chromium/blob/6eade082d6e5/third_party/libxslt/src/libxslt/pattern.c (vérifié le 10 novembre 2026)
• Le fichier libxslt/pattern.c de la branche master amont de libxslt, qui contient encore la séquence d'avant le correctif : https://github.com/GNOME/libxslt/blob/master/libxslt/pattern.c (vérifié le 10 novembre 2026)
• Statcounter Global Stats, part de marché des navigateurs de bureau dans le monde, octobre 2026 : https://gs.statcounter.com/browser-market-share/desktop/worldwide (vérifié le 10 novembre 2026)
• Flux JSON du catalogue Known Exploited Vulnerabilities de la CISA, vérifié pour CVE-2026-125350 le 10 novembre 2026 (non listée) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 10 novembre 2026)