GHSA-2464-8j7c-4cjm
MEDIUMgo-viper's mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/go-viper/mapstructure/v2Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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:
_, _, 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:
& 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/go-viper/mapstructure/v2 | all versions | 2.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/go-viper/mapstructure/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/go-viper/mapstructure/v2 to 2.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2464-8j7c-4cjm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2464-8j7c-4cjm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2464-8j7c-4cjm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2464-8j7c-4cjm in your dependencies?
O3 detects GHSA-2464-8j7c-4cjm across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.