GHSA-2464-8j7c-4cjm

Summary

Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.

Details

OpenBao (and presumably HashiCorp Vault) have surfaced error messages from mapstructure as follows:

https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L43-L50

            _, _, err := d.getPrimitive(field, schema)
            if err != nil {
                return fmt.Errorf("error converting input for field %q: %w", field, err)
            }

where this calls mapstructure.WeakDecode(...): https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L181-L193

func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) {
    raw, ok := d.Raw[k]
    if !ok {
        return nil, false, nil
    }

    switch t := schema.Type; t {
    case TypeBool:
        var result bool
        if err := mapstructure.WeakDecode(raw, &result); err != nil {
            return nil, false, err
        }
        return result, true, nil

Notably, WeakDecode(...) eventually calls one of the decode helpers, which surfaces the original value via strconv helpers:

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L720-L727

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L791-L798

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/decode_hooks.go#L180

& more. These are different code paths than are fixed in the previous iteration at https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h.

PoC

To reproduce with OpenBao:

$ podman run --pull=always -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300

and in a new tab:

$ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass
Success! Enabled userpass auth method at: userpass/
$ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"ttl":"asdf"}' "http://localhost:8200/v1/auth/userpass/users/asdf"

--> server logs:

2025-06-25T21:32:25.101-0500 [ERROR] core: failed to run existence check: error="error converting input for field \"ttl\": time: invalid duration \"asdf\""

Impact

This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at '' expected a map, got 'string' -- when the field type is string and a map is provided, we see the above information leak -- the previous example had a map type field with a string value provided).

This was rated 4.5 Medium by HashiCorp in the past iteration.