GitHub : les champs privés sont exposés via NativeTypes de CEL
Une fonction spécifique, ext.NativeTypes(ParseStructTag("json")), ne respecte pas la directive d’omission json:"-" dans les structures Go, selon l’avis de sécurité GHSA-gcjh-h69q-9w9g publié par github.com. Ce mécanisme permet, en théorie, à n’importe quel utilisateur soumettant une expression CEL de lire des champs qui étaient pourtant marqués pour être ignorés lors de la sérialisation JSON.
Le problème réside dans l’implémentation de fieldNameByTag, l’aide utilisée par ParseStructTag("json") pour traduire les balises de structure Go en noms de champs CEL. Pour un champ balisé json:"-", ce code interprète simplement "-" comme un nom de champ valide, au lieu de reconnaître le sentinel d’omission de encoding/json. Conséquence directe : ce champ devient lisible via dyn(obj)["-"].
Ce défaut est aggravé par le fait que la fonction newNativeTypes enregistre silencieusement chaque structure imbriquée accessible à partir du type passé en argument. Le développeur n’est pas limité aux champs qu’il a explicitement examinés, ce qui élargit considérablement la surface d’exposition. Les champs deviennent alors partie de la vue du type pour CEL, permettant une énumération et une récupération par lookup standard.
Impact sur les développements et la gestion des dépendances
Ce comportement contredit l’intention documentée de ParseStructTag("json"), qui est de se comporter selon les sémantiques de encoding/json. Le système accepte le nom de champ erroné, et une fois accepté, il est traité comme un champ normal par le fournisseur de types natifs de CEL. L’accès aux valeurs sous-jacentes est alors possible via FindStructFieldType.
On note que la conversion de ces objets natifs en valeurs de type JSON-like CEL itère sur tous les champs de la structure Go, sans appliquer la règle d’omission JSON. C’est un angle mort qui appelle une attention particulière des équipes de développement.
Parallèlement, la cybersécurité continue de pointer du doigt des failles dans les outils d’infrastructure. Des avis de sécurité récents concernant containerd signalent des problèmes d’escalade de privilèges locaux dus à des permissions par défaut trop larges sur des répertoires critiques, comme /var/lib/containerd (GHSA-pwhc-rpq9-4c8w). Ces incidents confirment la nécessité d’une vigilance accrue sur la manière dont les systèmes génèrent et gèrent les droits d’accès, que ce soit au niveau des structures de données logicielles ou des systèmes d’exploitation sous-jacents.
Les enjeux des mises à jour et des environnements conteneurisés
L’écosystème des conteneurs n’est pas exempt de surprises. Si l’on regarde du côté des systèmes d’orchestration, les mises à jour de plateformes comme Apigee Edge for Private Cloud 4.54.00 imposent des changements majeurs. Cette version passe à Java 21 LTS, ce qui entraîne la suppression de modules Java EE et CORBA, affectant les politiques JavaCallout personnalisées. Les développeurs doivent impérativement vérifier la compatibilité de leurs JARs et de leurs politiques, sous peine de NoClassDefFoundError.
Ce besoin de vérification exhaustive est d’ailleurs illustré ailleurs. Dans le secteur du cloud, Google Cloud a récemment corrigé plusieurs vulnérabilités logicielles, incluant des fixes pour CVE-2025-31133 dans runc, un outil de conteneur, et des mises à jour pour divers composants comme docker et containerd afin de patcher des failles de sécurité critiques. Ces corrections, comme celles concernant des problèmes d’autorisation ou des accès non désirés, rappellent que le maintien des systèmes à jour est une course constante contre l’obscurité des failles.
Il faut surveiller attentivement les prochaines versions de ces outils, car la simple dépendance à un json:
Fiche technique
| CVE | Produit | Gravité | Exploitée activement | Versions corrigées |
|---|---|---|---|---|
| CVE-2024-25621 | github.com/containerd/containerd (go), github.com/containerd/containerd/v2 (go) | Élevée (CVSS 7,3) | Non signalée | github.com/containerd/containerd 1.7.29, github.com/containerd/containerd/v2 2.0.7, github.com/containerd/containerd/v2 |
| CVE-2024-41110 | github.com/docker/docker (go), github.com/docker/docker (go) | Critique (CVSS 9,9) | Non signalée | github.com/docker/docker 25.0.6, github.com/docker/docker 23.0.15, github.com/docker/docker 26.1.5, github.com/docker/do |
| CVE-2025-31133 | github.com/opencontainers/runc (go), github.com/opencontainers/runc (go) | Élevée (CVSS 7,3) | Non signalée | github.com/opencontainers/runc 1.2.8, github.com/opencontainers/runc 1.3.3, github.com/opencontainers/runc 1.4.0-rc.3 |
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 07, 2026, Google Cloud, 7 novembre 2026
- Wednesday, November 11, 2026 Security Releases, Node.js, 3 novembre 2026 (contenu sous licence CC BY 4.0)
- Announcing new builds for 6 November 2026, Windows, 6 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-v23v-6jw2-98fq : Authz zero length regression, GitHub Advisory Database (CC BY 4.0)
- CVE-2024-41110, 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)
