# GHSA-gcjh-h69q-9w9g: cel-go: JSON Private Fields Exposed via NativeTypes and ParseStructTag > The cel-go library exposes private struct fields tagged with json:"-" to user-submitted expressions, allowing unauthorized data disclosure. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 24 Jul 2026 - **Also known as:** GO-2026-6094 ## What is GHSA-gcjh-h69q-9w9g? GHSA-gcjh-h69q-9w9g is a vulnerability in github.com/google/cel-go, published on 24 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official description The function `ext.NativeTypes(ParseStructTag("json"))` does not honour the `encoding/json` skip directive `json:"-"`. Fields tagged `json:"-"` are registered in the CEL type system under the literal name `"-"` and are readable from any user-submitted CEL expression via `dyn(obj)["-"]`. Additionally, `newNativeTypes` silently registers every nested struct reachable from the type passed to `NativeTypes`, including types from third-party dependencies the developer never examined. ## Root cause In `fieldNameByTag`, the helper used by `ParseStructTag("json")` to translate Go struct tags into CEL field names. See at `ext/native.go:146`: ```go func fieldNameByTag(structTagToParse string) func(field reflect.StructField) string { return func(field reflect.StructField) string { tag, found := field.Tag.Lookup(structTagToParse) if found { splits := strings.Split(tag, ",") if len(splits) > 0 { // We make the assumption that the leftmost entry in the tag is the name. // This seems to be true for most tags that have the concept of a name/key, such as: // https://pkg.go.dev/encoding/xml#Marshal // https://pkg.go.dev/encoding/json#Marshal // https://pkg.go.dev/go.mongodb.org/mongo-driver/bson#hdr-Structs // https://pkg.go.dev/go.yaml.in/yaml/v3#Marshal name := splits[0] return name } } return field.Name } } ``` For a field tagged `json:"-"`, this code splits the tag into `[]string{"-"}` and returns `"-"` as the CEL field name. It never checks whether `"-"` is the JSON skip sentinel. This contradicts the `encoding/json` rule that the source comment explicitly points readers to: ```text As a special case, if the field tag is "-", the field is always omitted. Note that a field with name "-" can still be generated using the tag "-,". ``` The public option also documents JSON-style parsing as the intended behavior. See at `ext/native.go:190`: ```go // ParseStructTag configures the struct tag to parse. The 0th item in the tag is used as the name of the CEL field. // For example: // If the tag to parse is "cel" and the struct field has tag cel:"foo", the CEL struct field will be "foo". // If the tag to parse is "json" and the struct field has tag json:"foo,omitempty", the CEL struct field will be "foo". func ParseStructTag(tag string) NativeTypesOption { return func(ntp *nativeTypeOptions) error { ntp.fieldNameHandler = fieldNameByTag(tag) return nil } } ``` A developer using `ParseStructTag("json")` is therefore led to expect `encoding/json` field-name semantics. Instead, `json:"-"` is treated as a real field name. The bad name is accepted during native type construction. `newNativeType` checks for duplicate field names, but it does not reject or skip empty names or skip sentinels. See at `ext/native.go:663`: ```go if fieldNameHandler != nil { fieldNames := make(map[string]struct{}) for idx := 0; idx < refType.NumField(); idx++ { field := refType.Field(idx) fieldName := toFieldName(fieldNameHandler, field) if _, found := fieldNames[fieldName]; found { return nil, fmt.Errorf("invalid field name `%s` in struct `%s`: %w", fieldName, refType.Name(), errDuplicatedFieldName) } else { fieldNames[fieldName] = struct{}{} } } } ``` Once accepted, the field becomes part of CEL's view of the type. Field enumeration reports it as a normal field name. See at `ext/native.go:286`: ```go func (tp *nativeTypeProvider) FindStructFieldNames(typeName string) ([]string, bool) { if t, found := tp.nativeTypes[typeName]; found { fieldCount := t.refType.NumField() fields := make([]string, fieldCount) for i := 0; i < fieldCount; i++ { fields[i] = toFieldName(tp.options.fieldNameHandler, t.refType.Field(i)) } return fields, true } if celTypeFields, found := tp.baseProvider.FindStructFieldNames(typeName); found { return celTypeFields, true } return tp.baseProvider.FindStructFieldNames(typeName) } ``` Field lookup also treats the name as valid and returns the underlying Go field value. See at `ext/native.go:303`: ```go func (tp *nativeTypeProvider) FindStructFieldType(typeName, fieldName string) (*types.FieldType, bool) { t, found := tp.nativeTypes[typeName] if !found { return tp.baseProvider.FindStructFieldType(typeName, fieldName) } refField, isDefined := t.hasField(fieldName) if !found || !isDefined { return nil, false } return &types.FieldType{ IsSet: func(obj any) bool { refVal := reflect.Indirect(reflect.ValueOf(obj)) refField := refVal.FieldByName(refField.Name) return !refField.IsZero() }, GetFrom: func(obj any) (any, error) { refVal := reflect.Indirect(reflect.ValueOf(obj)) refField := refVal.FieldByName(refField.Name) return getFieldValue(refField), nil }, }, true } ``` At runtime, native objects advertise index access. See at `ext/native.go:37`: ```go var ( nativeObjTraitMask = traits.FieldTesterType | traits.IndexerType ) ``` Because `traits.IndexerType` is present, a user expression can bypass ordinary field syntax and read the registered `"-"` field with bracket access: ```cel dyn(req.auth)["-"] ``` The same mistaken name is also used when converting native objects to JSON-like CEL values. `ConvertToNative(jsonStructType)` iterates all Go struct fields, computes the CEL field name, and inserts it into the output map without applying the JSON skip rule. See at `ext/native.go:501`: ```go case jsonStructType: refVal := reflect.Indirect(o.refValue) refType := refVal.Type() fields := make(map[string]*structpb.Value, refVal.NumField()) for i := 0; i < refVal.NumField(); i++ { fieldType := refType.Field(i) fieldValue := refVal.Field(i) if !fieldValue.IsValid() || fieldValue.IsZero() { continue } fieldName := toFieldName(o.valType.fieldNameHandler, fieldType) fieldCELVal := o.NativeToValue(fieldValue.Interface()) fieldJSONVal, err := fieldCELVal.ConvertToNative(jsonValueType) if err != nil { return nil, err } fields[fieldName] = fieldJSONVal.(*structpb.Value) } return &structpb.Struct{Fields: fields}, nil ``` This means a `json:"-"` secret is exposed in two ways: it can be read directly through CEL indexing as `dyn(obj)["-"]`, and it can appear under the key `"-"` in JSON struct conversion output. The blast radius is widened by `newNativeTypes`, which registers not only the type explicitly passed to `NativeTypes`, but also every nested struct reachable from its fields. See at `ext/native.go:609`: ```go func newNativeTypes(fieldNameHandler NativeTypesFieldNameHandler, rawType reflect.Type) ([]*nativeType, error) { nt, err := newNativeType(fieldNameHandler, rawType) if err != nil { return nil, err } result := []*nativeType{nt} var iterateStructMembers func(reflect.Type) iterateStructMembers = func(t reflect.Type) { if k := t.Kind(); k == reflect.Pointer || k == reflect.Slice || k == reflect.Array || k == reflect.Map { iterateStructMembers(t.Elem()) return } if t.Kind() != reflect.Struct { return } nt, ntErr := newNativeType(fieldNameHandler, t) if ntErr != nil { err = ntErr return } result = append(result, nt) for idx := 0; idx < t.NumField(); idx++ { iterateStructMembers(t.Field(idx).Type) } } iterateStructMembers(rawType) return result, err } ``` As a result, a developer can register one apparently safe req ## Which versions are affected by GHSA-gcjh-h69q-9w9g? 3 open source packages ship an affected version, including github.com/google/cel-go. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `github.com/google/cel-go` | Go | From 0.22.0 | 0.29.0 | | `github.com/google/cel-go` | Go | From 0.22.0 | 0.29.0 | | `github.com/google/cel-go` | Go | From 0.22.0 | 0.30.0 | ## How do I fix GHSA-gcjh-h69q-9w9g? Upgrade github.com/google/cel-go to a fixed version for your release line: 0.29.0 or 0.30.0. ## Is GHSA-gcjh-h69q-9w9g being exploited? There is no known exploitation of GHSA-gcjh-h69q-9w9g in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-gcjh-h69q-9w9g and fix it if it is affected. What it is: GHSA-gcjh-h69q-9w9g is a vulnerability in github.com/google/cel-go, published on 24 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. Exploitation: There is no known exploitation of GHSA-gcjh-h69q-9w9g in the wild and no public exploit code. Affected packages and fixed versions: - github.com/google/cel-go (Go): affected from 0.22.0; fixed in 0.29.0 - github.com/google/cel-go (Go): affected from 0.22.0; fixed in 0.29.0 - github.com/google/cel-go (Go): affected from 0.22.0; fixed in 0.30.0 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-gcjh-h69q-9w9g/ (Markdown: https://insights.sbomify.com/GHSA-gcjh-h69q-9w9g/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-gcjh-h69q-9w9g --- From sbomify Insights: https://insights.sbomify.com/GHSA-gcjh-h69q-9w9g/ Summaries are generated and may contain mistakes; the official description above is the record.