Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-07-30 07:10
Modified
2026-07-30 09:39
Summary
Security fixes in opentofu-fips 1.10.7-r1
Details
Package opentofu-fips version 1.10.7-r1 fixes 6 vulnerabilities: ghsa-6v2p-p543-phr9, ghsa-wjrx-6529-hcj3, ghsa-2464-8j7c-4cjm, ghsa-fv92-fjc5-jj9h, ghsa-jc7w-c686-c4v9...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "opentofu-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.7-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.10.7-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package opentofu-fips version 1.10.7-r1 fixes 6 vulnerabilities: ghsa-6v2p-p543-phr9, ghsa-wjrx-6529-hcj3, ghsa-2464-8j7c-4cjm, ghsa-fv92-fjc5-jj9h, ghsa-jc7w-c686-c4v9...",
"id": "CLEANSTART-2026-SH34049",
"modified": "2026-07-30T09:39:01Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://opentofu.org"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in opentofu-fips 1.10.7-r1",
"upstream": [
"ghsa-6v2p-p543-phr9",
"ghsa-wjrx-6529-hcj3",
"ghsa-2464-8j7c-4cjm",
"ghsa-fv92-fjc5-jj9h",
"ghsa-jc7w-c686-c4v9",
"ghsa-2x5j-vhc8-9cwm"
]
}
GHSA-2464-8J7C-4CJM
Vulnerability from github – Published: 2025-08-21 14:37 – Updated: 2026-01-27 21:01
VLAI
Summary
go-viper's mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data
Details
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.
Severity
5.3 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-viper/mapstructure/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-11065"
],
"database_specific": {
"cwe_ids": [
"CWE-117"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-21T14:37:19Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nUse of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.\n\n### Details\n\nOpenBao (and presumably HashiCorp Vault) have surfaced error messages from `mapstructure` as follows:\n\nhttps://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L43-L50\n\n```go\n\t\t\t_, _, err := d.getPrimitive(field, schema)\n\t\t\tif err != nil {\n\t\t\t\treturn fmt.Errorf(\"error converting input for field %q: %w\", field, err)\n\t\t\t}\n```\n\nwhere this calls `mapstructure.WeakDecode(...)`: https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L181-L193\n\n```go\n\nfunc (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) {\n\traw, ok := d.Raw[k]\n\tif !ok {\n\t\treturn nil, false, nil\n\t}\n\n\tswitch t := schema.Type; t {\n\tcase TypeBool:\n\t\tvar result bool\n\t\tif err := mapstructure.WeakDecode(raw, \u0026result); err != nil {\n\t\t\treturn nil, false, err\n\t\t}\n\t\treturn result, true, nil\n```\n\nNotably, `WeakDecode(...)` eventually calls one of the decode helpers, which surfaces the original value via `strconv` helpers:\n\nhttps://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L720-L727\n\nhttps://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L791-L798\n\nhttps://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/decode_hooks.go#L180\n\n\u0026 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.\n\n### PoC\n\nTo reproduce with OpenBao:\n\n```\n$ 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\n```\n\nand in a new tab:\n\n```\n$ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass\nSuccess! Enabled userpass auth method at: userpass/\n$ curl -X PUT -H \"X-Vault-Request: true\" -H \"X-Vault-Token: root\" -d \u0027{\"ttl\":\"asdf\"}\u0027 \"http://localhost:8200/v1/auth/userpass/users/asdf\"\n\n--\u003e server logs:\n\n2025-06-25T21:32:25.101-0500 [ERROR] core: failed to run existence check: error=\"error converting input for field \\\"ttl\\\": time: invalid duration \\\"asdf\\\"\"\n```\n\n### Impact\n\nThis 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 `\u0027\u0027 expected a map, got \u0027string\u0027` -- 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).\n\nThis was rated 4.5 Medium by HashiCorp in the past iteration.",
"id": "GHSA-2464-8j7c-4cjm",
"modified": "2026-01-27T21:01:22Z",
"published": "2025-08-21T14:37:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-viper/mapstructure/security/advisories/GHSA-2464-8j7c-4cjm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11065"
},
{
"type": "WEB",
"url": "https://github.com/go-viper/mapstructure/commit/742921c9ba2854d27baa64272487fc5075d2c39c"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-11065"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2391829"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-viper/mapstructure"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3900"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "go-viper\u0027s mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data"
}
GHSA-2X5J-VHC8-9CWM
Vulnerability from github – Published: 2025-06-10 21:18 – Updated: 2025-10-23 17:36
VLAI
Summary
CIRCL-Fourq: Missing and wrong validation can lead to incorrect results
Details
Impact
The CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security.
Moreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve.
Patches
Version 1.6.1 (https://github.com/cloudflare/circl/tree/v1.6.1) mitigates the identified issues.
We acknowledge Alon Livne (Botanica Software Labs) for the reported findings.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudflare/circl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-8556"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-10T21:18:33Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nThe CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security.\n\nMoreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve.\n\n\n### Patches\nVersion 1.6.1 (https://github.com/cloudflare/circl/tree/v1.6.1) mitigates the identified issues.\n\nWe acknowledge Alon Livne (Botanica Software Labs) for the reported findings.",
"id": "GHSA-2x5j-vhc8-9cwm",
"modified": "2025-10-23T17:36:51Z",
"published": "2025-06-10T21:18:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudflare/circl/security/advisories/GHSA-2x5j-vhc8-9cwm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8556"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-8556"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2371624"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudflare/circl"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/circl/tree/v1.6.1"
},
{
"type": "WEB",
"url": "https://news.ycombinator.com/item?id=45669593"
},
{
"type": "WEB",
"url": "https://www.botanica.software/blog/cryptographic-issues-in-cloudflares-circl-fourq-implementation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "CIRCL-Fourq: Missing and wrong validation can lead to incorrect results"
}
GHSA-6V2P-P543-PHR9
Vulnerability from github – Published: 2025-07-18 17:27 – Updated: 2025-07-18 17:27
VLAI
Summary
golang.org/x/oauth2 Improper Validation of Syntactic Correctness of Input vulnerability
Details
An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "golang.org/x/oauth2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-22868"
],
"database_specific": {
"cwe_ids": [
"CWE-1286"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-18T17:27:22Z",
"nvd_published_at": "2025-02-26T08:14:24Z",
"severity": "HIGH"
},
"details": "An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.",
"id": "GHSA-6v2p-p543-phr9",
"modified": "2025-07-18T17:27:22Z",
"published": "2025-07-18T17:27:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22868"
},
{
"type": "WEB",
"url": "https://go.dev/cl/652155"
},
{
"type": "WEB",
"url": "https://go.dev/issue/71490"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3488"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "golang.org/x/oauth2 Improper Validation of Syntactic Correctness of Input vulnerability"
}
GHSA-FV92-FJC5-JJ9H
Vulnerability from github – Published: 2025-06-27 16:24 – Updated: 2025-06-27 16:24
VLAI
Summary
mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data
Details
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:
https://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L679-L686
https://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L726-L730
https://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L783-L787
& more.
PoC
To reproduce with OpenBao:
$ podman run -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 '{"password":{"asdf":"my-sensitive-value"}}' "http://localhost:8300/v1/auth/userpass/users/adsf"
{"errors":["error converting input for field \"password\": '' expected type 'string', got unconvertible type 'map[string]interface {}', value: 'map[asdf:my-sensitive-value]'"]}
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.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-viper/mapstructure/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-27T16:24:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nUse of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.\n\n### Details\n\nOpenBao (and presumably HashiCorp Vault) have surfaced error messages from `mapstructure` as follows:\n\nhttps://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L43-L50\n\n```go\n\t\t\t_, _, err := d.getPrimitive(field, schema)\n\t\t\tif err != nil {\n\t\t\t\treturn fmt.Errorf(\"error converting input for field %q: %w\", field, err)\n\t\t\t}\n```\n\nwhere this calls `mapstructure.WeakDecode(...)`: https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L181-L193\n\n```go\n\nfunc (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) {\n\traw, ok := d.Raw[k]\n\tif !ok {\n\t\treturn nil, false, nil\n\t}\n\n\tswitch t := schema.Type; t {\n\tcase TypeBool:\n\t\tvar result bool\n\t\tif err := mapstructure.WeakDecode(raw, \u0026result); err != nil {\n\t\t\treturn nil, false, err\n\t\t}\n\t\treturn result, true, nil\n```\n\nNotably, `WeakDecode(...)` eventually calls one of the decode helpers, which surfaces the original value:\n\nhttps://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L679-L686\n\nhttps://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L726-L730\n\nhttps://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L783-L787\n\n\u0026 more.\n\n### PoC\n\nTo reproduce with OpenBao:\n\n```\n$ podman run -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300\n```\n\nand in a new tab:\n\n```\n$ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass\nSuccess! Enabled userpass auth method at: userpass/\n$ curl -X PUT -H \"X-Vault-Request: true\" -H \"X-Vault-Token: root\" -d \u0027{\"password\":{\"asdf\":\"my-sensitive-value\"}}\u0027 \"http://localhost:8300/v1/auth/userpass/users/adsf\"\n{\"errors\":[\"error converting input for field \\\"password\\\": \u0027\u0027 expected type \u0027string\u0027, got unconvertible type \u0027map[string]interface {}\u0027, value: \u0027map[asdf:my-sensitive-value]\u0027\"]}\n```\n\n### Impact\n\nThis 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 `\u0027\u0027 expected a map, got \u0027string\u0027` -- 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).\n\nThis was rated 4.5 Medium by HashiCorp in the past iteration.",
"id": "GHSA-fv92-fjc5-jj9h",
"modified": "2025-06-27T16:24:59Z",
"published": "2025-06-27T16:24:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-viper/mapstructure"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data"
}
GHSA-JC7W-C686-C4V9
Vulnerability from github – Published: 2025-08-28 19:36 – Updated: 2025-08-29 20:25
VLAI
Summary
github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives
Details
Summary
It is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification.
Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done.
Mitigations
The release v0.5.15 includes following mitigations:
- The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size.
- The default is 2 Gigabytes - 1 byte (2^31-1 bytes).
- Users can check with the [Reader.Header] method what the actual values are in their LZMA files and set a smaller limit using ReaderConfig.
- The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary.
- The code supports stream sizes only up to a pebibyte (1024^5).
Note that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15.
Methods affected
Only software that uses lzma.NewReader or lzma.ReaderConfig.NewReader is affected. There is no issue for software using the xz functionality.
I thank @GregoryBuligin for his report, which is provided below.
Summary
When unpacking a large number of LZMA archives, even in a single goroutine, if the first byte of the archive file is 0 (a zero byte added to the beginning), an error writeMatch: distance out of range occurs. Memory consumption spikes sharply, and the GC clearly cannot handle this situation.
Details
Judging by the error writeMatch: distance out of range, the problems occur in the code around this function. https://github.com/ulikunitz/xz/blob/c8314b8f21e9c5e25b52da07544cac14db277e89/lzma/decoderdict.go#L81
PoC
Run a function similar to this one in 1 or several goroutines on a multitude of LZMA archives that have a 0 (a zero byte) added to the beginning.
const ProjectLocalPath = "some/path"
const TmpDir = "tmp"
func UnpackLZMA(lzmaFile string) error {
file, err := os.Open(lzmaFile)
if err != nil {
return err
}
defer file.Close()
reader, err := lzma.NewReader(bufio.NewReader(file))
if err != nil {
return err
}
tmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix)
if err != nil {
return err
}
defer func() {
tmpFile.Close()
_ = os.Remove(tmpFile.Name())
}()
sha256Hasher := sha256.New()
multiWriter := io.MultiWriter(tmpFile, sha256Hasher)
if _, err = io.Copy(multiWriter, reader); err != nil {
return err
}
unpackHash := hex.EncodeToString(sha256Hasher.Sum(nil))
unpackDir := filepath.Join(
ProjectLocalPath, unpackHash[:2],
)
_ = os.MkdirAll(unpackDir, DirPerm)
unpackPath := filepath.Join(unpackDir, unpackHash)
return os.Rename(tmpFile.Name(), unpackPath)
}
Impact
Servers with a small amount of RAM that download and unpack a large number of unverified LZMA archives
Severity
5.3 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.13"
},
"package": {
"ecosystem": "Go",
"name": "github.com/ulikunitz/xz"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58058"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-28T19:36:22Z",
"nvd_published_at": "2025-08-28T22:15:32Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nIt is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn\u0027t include a magic number or has a checksum to detect such an issue according to the [specification](https://github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt).\n\nNote that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done.\n\n### Mitigations\n\nThe release v0.5.15 includes following mitigations:\n\n- The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size.\n- The default is 2 Gigabytes - 1 byte (2^31-1 bytes).\n- Users can check with the [Reader.Header] method what the actual values are in their LZMA files and set a smaller limit using ReaderConfig.\n- The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary.\n- The code supports stream sizes only up to a pebibyte (1024^5).\n\nNote that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15.\n\n### Methods affected\n\nOnly software that uses [lzma.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#NewReader) or [lzma.ReaderConfig.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#ReaderConfig.NewReader) is affected. There is no issue for software using the xz functionality.\n\nI thank @GregoryBuligin for his report, which is provided below.\n\n### Summary\nWhen unpacking a large number of LZMA archives, even in a single goroutine, if the first byte of the archive file is 0 (a zero byte added to the beginning), an error __writeMatch: distance out of range__ occurs. Memory consumption spikes sharply, and the GC clearly cannot handle this situation.\n\n### Details\nJudging by the error __writeMatch: distance out of range__, the problems occur in the code around this function.\nhttps://github.com/ulikunitz/xz/blob/c8314b8f21e9c5e25b52da07544cac14db277e89/lzma/decoderdict.go#L81\n\n### PoC\nRun a function similar to this one in 1 or several goroutines on a multitude of LZMA archives that have a 0 (a zero byte) added to the beginning.\n```\nconst ProjectLocalPath = \"some/path\"\nconst TmpDir = \"tmp\"\n\nfunc UnpackLZMA(lzmaFile string) error {\n\tfile, err := os.Open(lzmaFile)\n\tif err != nil {\n\t\treturn err\n\t}\n\tdefer file.Close()\n\n\treader, err := lzma.NewReader(bufio.NewReader(file))\n\tif err != nil {\n\t\treturn err\n\t}\n\n\ttmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix)\n\tif err != nil {\n\t\treturn err\n\t}\n\tdefer func() {\n\t\ttmpFile.Close()\n\t\t_ = os.Remove(tmpFile.Name())\n\t}()\n\n\tsha256Hasher := sha256.New()\n\tmultiWriter := io.MultiWriter(tmpFile, sha256Hasher)\n\n\tif _, err = io.Copy(multiWriter, reader); err != nil {\n\t\treturn err\n\t}\n\n\tunpackHash := hex.EncodeToString(sha256Hasher.Sum(nil))\n\tunpackDir := filepath.Join(\n\t\tProjectLocalPath, unpackHash[:2],\n\t)\n\t_ = os.MkdirAll(unpackDir, DirPerm)\n\n\tunpackPath := filepath.Join(unpackDir, unpackHash)\n\n\treturn os.Rename(tmpFile.Name(), unpackPath)\n}\n```\n\n\n\n### Impact\nServers with a small amount of RAM that download and unpack a large number of unverified LZMA archives",
"id": "GHSA-jc7w-c686-c4v9",
"modified": "2025-08-29T20:25:38Z",
"published": "2025-08-28T19:36:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58058"
},
{
"type": "WEB",
"url": "https://github.com/ulikunitz/xz/commit/88ddf1d0d98d688db65de034f48960b2760d2ae2"
},
{
"type": "PACKAGE",
"url": "https://github.com/ulikunitz/xz"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives"
}
GHSA-WJRX-6529-HCJ3
Vulnerability from github – Published: 2025-08-15 21:31 – Updated: 2025-08-29 20:36
VLAI
Summary
HashiCorp go-getter Vulnerable to Symlink Attacks
Details
HashiCorp's go-getter library subdirectory download feature is vulnerable to symlink attacks leading to unauthorized read access beyond the designated directory boundaries. This vulnerability, identified as CVE-2025-8959, is fixed in go-getter 1.7.9.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/go-getter"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-8959"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-18T15:10:29Z",
"nvd_published_at": "2025-08-15T21:15:37Z",
"severity": "HIGH"
},
"details": "HashiCorp\u0027s go-getter library subdirectory download feature is vulnerable to symlink attacks leading to unauthorized read access beyond the designated directory boundaries. This vulnerability, identified as CVE-2025-8959, is fixed in go-getter 1.7.9.",
"id": "GHSA-wjrx-6529-hcj3",
"modified": "2025-08-29T20:36:28Z",
"published": "2025-08-15T21:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8959"
},
{
"type": "WEB",
"url": "https://github.com/hashicorp/go-getter/commit/87541b2501c00df5eaedea6acc61a2a4a4efa5b7"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2025-23-hashicorp-go-getter-vulnerable-to-arbitrary-read-through-symlink-attack/76242"
},
{
"type": "PACKAGE",
"url": "https://github.com/hashicorp/go-getter"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3892"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "HashiCorp go-getter Vulnerable to Symlink Attacks"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…