Une vulnérabilité a été identifiée dans l’implémentation de CEL (Common Expression Language) de GitHub, permettant à des expressions arbitraires de lire des champs de structures Go qui devraient être ignorés lors de la sérialisation JSON. Selon l’alerte GHSA-gcjh-h69q-9w9g publiée par github.com, la fonction ext.NativeTypes(ParseStructTag("json")) ne respecte pas la directive json:"-".

En clair, si un développeur utilise ParseStructTag("json"), il s’attend à ce que les champs marqués json:"-" soient omis, conformément aux règles standard de l’encodage JSON. Or, le code interprète cette balise comme un nom de champ valide, le traduisant en "-" dans le système de types CEL. Ce champ devient ainsi lisible par n’importe quelle expression CEL soumise par un utilisateur, via une syntaxe d’accès par crochets comme dyn(obj)["-"].

Ce problème ne se limite pas à l’omission ; le système enregistre également silencieusement toutes les structures imbriquées accessibles depuis le type fourni à NativeTypes, y compris celles issues de dépendances tierces que le développeur n’a pas examinées. C’est un risque d’énorme portée en termes de surface d’attaque potentielle.

Conséquences techniques du défaut

Le cœur du dysfonctionnement réside dans fieldNameByTag, l’aide utilisée par ParseStructTag("json") pour convertir les balises de structure Go en noms de champs CEL. Au lieu de vérifier si le tag est le sentinelle d’omission JSON, le code procède à une division du tag, attribuant ainsi "-" comme nom de champ. Une fois ce champ accepté lors de la construction du type natif, il est exposé via les méthodes de recherche de champ de CEL.

D’ailleurs, lors de la conversion de ces objets natifs vers des valeurs de type JSON, cette même erreur de nommage persiste, car ConvertToNative(jsonStructType) itère sur tous les champs de la structure Go sans appliquer la règle d’omission JSON. On constate que même si le système de construction de types natifs vérifie les noms dupliqués, il n’exclut pas les noms vides ou les sentinelles d’omission, ouvrant la porte à cette lecture non désirée.

La vigilance face aux mises à jour de systèmes complexes

Si cette faille est une affaire de langage de programmation spécifique, elle rappelle la nécessité de vigilance accrue lorsque l’on intègre des systèmes complexes, où les conventions de sérialisation peuvent être mal interprétées par les moteurs d’exécution. Cela fait écho à d’autres mises à jour logicielles importantes qui imposent des changements radicaux dans les environnements d’exécution.

Par exemple, Apigee Edge for Private Cloud 4.54.00, bien qu’il apporte des améliorations de posture de sécurité, retire le support de certaines fonctionnalités de la version précédente, comme l’installation sur des environnements GDC isolés ou l’utilisation de certains systèmes HSM. De même, la migration vers Java 21 LTS dans Apigee 4.54.00 entraîne la suppression permanente de modules Java EE et CORBA, forçant les développeurs à réévaluer profondément leurs politiques de JavaCallout.

Pour les projets qui utilisent CEL ou des systèmes basés sur la sérialisation JSON, il faut impérativement vérifier comment les directives d’omission sont traitées par le moteur de type.

Il faudra surveiller les correctifs de GitHub pour cette vulnérabilité afin de s’assurer que les expressions CEL ne permettent plus un accès non autorisé aux données internes des structures Go.

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 01, 2026, Google Cloud, 1 novembre 2026