Un advisory récent de github.com met en lumière un problème dans l’implémentation du système CEL, permettant l’exposition de champs privés lors de l’utilisation de NativeTypes avec ParseStructTag("json").

Ce défaut, documenté sous la référence GHSA-gcjh-h69q-9w9g, signifie que même lorsque le tag json:"-" est utilisé pour ignorer un champ lors de la sérialisation JSON, ce champ est en réalité enregistré dans le système de types CEL sous le nom littéral "-". Il devient ainsi accessible à n’importe quelle expression CEL soumise par un utilisateur, par exemple via dyn(obj)"-".

L’analyse du code révèle que la fonction fieldNameByTag, utilisée par ParseStructTag("json"), traite "-" comme un nom de champ valide au lieu de le reconnaître comme un marqueur d’omission JSON, contredisant ainsi les conventions attendues des bibliothèques Go. De surcroît, le mécanisme de newNativeTypes enregistre silencieusement tous les types imbriqués atteignables, même ceux provenant de dépendances tierces que le développeur n’a pas examinées. On dirait que l’on construit des systèmes d’auto-description complexes en laissant passer des informations sensibles.

Pression sur la sécurité des runtimes conteneurs

En parallèle de cette faille logicielle dans l’écosystème Go, les enjeux de sécurité au niveau des systèmes d’exécution des conteneurs restent particulièrement élevés. Des failles de privilège ont été confirmées dans containerd. L’avis de sécurité GHSA-pwhc-rpq9-4c8w signale que des permissions par défaut trop larges sur des répertoires clés, tels que /var/lib/containerd (créé en 0o711 au lieu de 0o700), peuvent permettre à un utilisateur local d’accéder au magasin de métadonnées.

Ces problèmes de permissions, qui ont engendré le CVE-2024-25621, sont corrigés dans les versions 1.7.29, 2.0.7, 2.1.5 et 2.2.0 de containerd. Les administrateurs sont invités à appliquer ces correctifs ou, à défaut, à prendre des mesures manuelles en appliquant chmod 700 sur les chemins concernés, ou encore à opérer en mode rootless.

Les failles de bas niveau persistent

L’arsenal des menaces ne s’arrête pas au niveau des outils d’orchestration. runc, le CLI pour l’exécution des conteneurs selon la spécification OCI, présente des failles de contournement de sécurité. Les CVE-2025-31133 et CVE-2025-52565, par exemple, pointent des faiblesses liées à la vérification des bind-mounts. Une mauvaise gestion de l’inode source pour /dev/null ou des vérifications insuffisantes lors du montage de /dev/pts/$n vers /dev/console peuvent mener, selon les analyses, à une divulgation d’informations sur l’hôte ou à une évasion de conteneur.

Ces vulnérabilités, également corrigées dans les versions 1.2.8, 1.3.3 et 1.4.0-rc.3 de runc, rappellent que la sécurité doit être traitée couche par couche, depuis le langage de programmation jusqu’au noyau. Il faut donc s’assurer que les mises à jour, qu’elles viennent de GitHub ou d’ailleurs, sont appliquées dans un calendrier serré.

Fiche technique

Données : NVD (NIST) et GitHub Advisory Database (CC BY 4.0, données adaptées).

Sources

• GHSA-gcjh-h69q-9w9g – GitHub Advisory Database, github.com
• Changes in Edge for Private Cloud 4.54.00 | Edge for Private Cloud v4.54.00 | Apigee Docs, docs.apigee.com
• November 09, 2026, Google Cloud, 9 novembre 2026
• Avis de sécurité (github.com), github.com, 6 novembre 2025
• GHSA-pwhc-rpq9-4c8w : containerd affected by a local privilege escalation via wide permissions on CRI directory, GitHub Advisory Database (CC BY 4.0)
• CVE-2024-25621, NVD (NIST)
• GHSA-9493-h29p-rfm2 : runc container escape via « masked path » abuse due to mount race conditions, GitHub Advisory Database (CC BY 4.0)
• CVE-2025-31133, NVD (NIST)
• GHSA-qw9x-cqr3-wc7r : runc container escape with malicious config due to /dev/console mount and related races, GitHub Advisory Database (CC BY 4.0)
• CVE-2025-52565, NVD (NIST)