Implication pour la chaîne d'attaque : l'exécution de code « dans un sandbox » [1] signifie qu'un attaquant prend le contrôle d'un processus sandboxé (le plus vraisemblablement le processus GPU). Une prise de contrôle complète du navigateur nécessiterait en outre une évasion de sandbox distincte qui ne fait pas partie de cette CVE.

2. Stratégie et hypothèse (évaluation propre de l'analyste — à considérer comme non confirmée)

Ce qui suit est une déduction fondée sur les informations publiques, et non des faits confirmés :

• ANGLE est le moteur que Chrome utilise pour traduire le GLSL de WebGL vers les API graphiques de la plateforme — sur macOS, vers Metal. Une « page HTML spécialement conçue » [1] qui atteint ANGLE signifie presque certainement du contenu WebGL — c'est-à-dire des shaders contrôlés par l'attaquant et/ou un état WebGL géré par le backend Metal.
• CWE-269 (Gestion inappropriée des privilèges) [1], combinée à un impact contenu dans le sandbox, suggère que la couche ANGLE/GPU ne parvient pas à correctement contraindre un élément contrôlé par l'attaquant lors de la traduction de shaders ou de la validation d'état.
• Historiquement, ce composant a produit des bugs de sécurité mémoire via des cas limites dans le traducteur GLSL (indexation constante hors limites, dimensionnement de tableaux par dépassement d'entier, interactions swizzle/discard, blocs uniform surdimensionnés, explosions de déroulage de boucles).

Le harnais exerce donc exactement ces motifs, puis mute le GLSL à grande échelle pour traquer un crash côté moteur de rendu (contexte WebGL perdu = crash du processus GPU ou mise à mort par le watchdog).

3. Contenu du dépôt

4. Prérequis

• Une machine macOS ou une VM compatible Metal que vous êtes autorisé à faire crasher délibérément. La CVE est spécifique à macOS [1] ; les tests sous Windows/Linux n'exerceront pas le backend ANGLE Metal vulnérable.
• Un build de Chrome < 148.0.7778.216 [1] (voir §5).
• GPU matériel / prise en charge de Metal. Sans cela, Chrome retombe sur SwiftShader (rendu logiciel) et le chemin vulnérable n'est jamais atteint — voir la vérification en §5.4.
• Python 3 (facultatif, uniquement pour l'outil de recherche de version en §5.1 et un serveur HTTP local).

5. Configuration de l'environnement

5.1 Méthode A — Chrome for Testing (recommandée)

L'archive Chrome for Testing de Google fournit des builds épinglés à une version qui ne se mettent pas à jour automatiquement. Trouvez le build vulnérable le plus récent (toutes les versions inférieures à 148.0.7778.216 sont concernées [1]) :

Téléchargez pour votre architecture (uname -m) :

Décompressez dans un dossier de laboratoire (par ex. ~/lab/, pas /Applications) puis lancez à partir de là.

5.2 Méthode B — Instantanés Chromium

Si un build précis manque dans Chrome for Testing, utilisez l'archive d'instantanés Chromium (commondatastorage.googleapis.com/chromium-browser-snapshots/Mac/ pour Intel, .../Mac_Arm/ pour Apple Silicon), indexée par position de commit — faites correspondre la version vulnérable à une position de branche via chromium-history, puis récupérez l'instantané le plus proche. Les instantanés ne se mettent pas non plus à jour automatiquement.

5.3 Bloquer les mises à jour automatiques (uniquement si vous utilisez un build estampillé provenant d'une autre source)

Tuez les agents de mise à jour Keystone et bloquez googleupdate.googleapis.com, sinon le build de test se corrigera silencieusement tout seul pendant la nuit. Inutile pour les builds Chrome for Testing.

5.4 Vérifier que vous êtes sur le backend Metal (critique)

Sans Metal, Chrome rend le WebGL par logiciel (SwiftShader) et le backend ANGLE Metal n'est jamais sollicité. Dans la console de la page PoC, exécutez :

Vous pouvez aussi le confirmer sur chrome://gpu. Les invités Parallels/VMware Fusion avec virtualisation GPU fonctionnent généralement ; les configurations minimales QEMU/UTM retombent souvent sur SwiftShader.

6. Étapes de reproduction

1. Isolez la cible. Instantané de VM ou compte macOS dédié. Ne vous connectez jamais et n'activez jamais la synchronisation dans le build vulnérable ; considérez-le comme compromis par conception. (L'impact de la CVE est une exécution de code dans un sandbox obtenue simplement en visitant une page web [1].)
2. Installez le build vulnérable conformément à §5 et vérifiez que §5.4 est satisfait.
3. Servez le PoC (ouvrez le fichier directement ou bien) :
   root@kitploit:~

   cd <repo dir>
   python3 -m http.server 8000
   # then browse to http://localhost:8000/cve-2026-9999-poc.html
   

4. Vérifiez la ligne d'empreinte affichée au chargement. Elle doit indiquer que le build est inférieur à 148.0.7778.216 et donc potentiellement vulnérable [1]. Sur les builds corrigés, le harnais affiche un avertissement pour vous éviter de perdre du temps.
5. Cliquez sur 1) Run curated triggers. Huit shaders stressent les motifs du traducteur décrits en §2 (indexation constante hors limites, dimensionnement de tableaux par dépassement d'entier, indexation dynamique de matrices, stress de déroulage de boucles, tableaux de tableaux, discard/swizzle, cas limites du préprocesseur, UBO surdimensionnés). Surveillez les résultats [!!] et les événements de perte de contexte.
6. Cliquez sur 2) Fuzz. Des shaders GLSL mutés sont compilés, liés, utilisés pour le rendu puis relus en boucle. Surveillez le journal pour CONTEXT LOST.
7. En cas de crash, le shader fautif est persisté dans localStorage. Récupérez-le :
   root@kitploit:~

   localStorage.getItem("cve20269999_poc_fs");      // crashing fragment shader
   localStorage.getItem("cve20269999_crashes");     // crash event log
   

8. Minimisez et retestez le shader qui crashe, en isolation (5+ exécutions consécutives), pour confirmer le déterminisme.
9. Confirmez la cause racine avec un build ASAN avant d'attribuer quoi que ce soit à CVE-2026-9999 — voir §8.

Un instantané en direct d'une exécution suspecte est également visible sur chrome://gpu et dans la Console macOS (rapports de crash du processus GPU).

7. Interprétation des résultats / faux positifs connus

• WEBGL_context_lost ≠ vulnérabilité. Le watchdog GPU de Chrome tue les shaders à exécution longue (le déclencheur loop-unroll-dos et les itérations de fuzz avec d'énormes compteurs de boucles sont conçus pour être lents). Réduisez le bruit : diminuez SH_ITER, ou confirmez que tout crash candidat se reproduit rapidement (< 1 s par itération).
• Un véritable crash de sécurité mémoire devrait se reproduire de manière déterministe à partir du shader minimisé et présenter une signature de crash distincte dans la Console (par ex., EXC_BAD_ACCESS) plutôt qu'une terminaison par le watchdog.
• Seul un rapport ASAN qui pointe précisément le backend ANGLE Metal est une preuve solide que vous avez trouvé ce bug, par opposition à un dysfonctionnement de pilote sans rapport.

8. Confirmation de la cause racine : build ASAN (facultatif mais fortement recommandé)

Compilez une révision vulnérable de Chromium avec AddressSanitizer :

Exécutez ensuite le shader minimisé qui crashe avec la validation de l'API Metal activée :

La trace ASAN nommera la fonction ANGLE/Metal exacte et confirmera si le crash correspond au composant de la CVE [1]. (En aval : une fois que le commit de correction pour 148.0.7778.216 est visible, faites un diff de third_party/angle/src/libANGLE/renderer/metal/ pour identifier la véritable cause racine et remplacez l'approche de fuzzing par un déclencheur déterministe.)

9. Limitations

• Aucune cause racine ni PoC public n'existe. Le ticket Chromium est restreint (« Permissions Required ») [1] ; ce harnais est guidé par des hypothèses.
• Aucune exploitation connue dans la nature. L'enrichissement SSVC de la CISA (2026-05-29) enregistre exploitation: none [1].
• Impact contenu dans le sandbox uniquement [1] — ce PoC, même s'il produit une exécution de code, ne couvre que l'étape du processus sandboxé d'une véritable chaîne d'attaque.
• Cible macOS uniquement [1] ; ne tirez pas de conclusions des exécutions sur d'autres plateformes.

10. Sécurité et aspects légaux

Testez uniquement sur des machines que vous possédez ou que vous êtes explicitement autorisé à tester. Le harnais compile intentionnellement des shaders hostiles pour faire crasher un processus graphique — attendez-vous à des terminaisons du processus GPU. Tenez le build de navigateur vulnérable à l'écart des réseaux de production.

11. Références

[1] NVD — CVE-2026-9999 : https://nvd.nist.gov/vuln/detail/CVE-2026-9999 * Avis de l'éditeur (blog Chrome Releases, mise à jour du canal stable) : https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_0877304591.html * Ticket Chromium 513364480 (accès restreint) : https://issues.chromium.org/issues/513364480