Skip to content

Commit f71b427

Browse files
advisory-database[bot]advisory-database[bot]
committed
Publish Advisories
GHSA-c72g-53hw-82q7 GHSA-9q7c-qmhm-jv86 GHSA-56mx-8g9f-5crf GHSA-282g-fhmx-xf54 GHSA-4j3x-hhg2-fm2x GHSA-6g7g-w4f8-9c9x GHSA-h9q6-hc68-35rp GHSA-jqcq-xjh3-6g23 GHSA-m59h-42jf-cphr
1 parent a78cc35 commit f71b427

9 files changed

Lines changed: 55 additions & 60 deletions

File tree

‎advisories/github-reviewed/2025/05/GHSA-c72g-53hw-82q7/GHSA-c72g-53hw-82q7.json‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-c72g-53hw-82q7",
4-
"modified": "2025-06-10T20:33:34Z",
4+
"modified": "2026-03-30T13:56:21Z",
55
"published": "2025-05-23T18:41:38Z",
66
"aliases": [
77
"CVE-2025-48371"
88
],
99
"summary": "OpenFGA Authorization Bypass",
10-
"details": "### Overview\nOpenFGA v1.8.0 to v1.8.12 ( openfga-0.2.16 <= Helm chart <= openfga-0.2.31, v1.8.0 <= docker <= v.1.8.12) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.\n\n\n### Am I Affected?\nIf you are using OpenFGA v1.8.0 to v1.8.12, specifically under the following conditions, you are affected by this authorization bypass vulnerability:\n- Calling Check API or ListObjects with an [authorization model](https://openfga.dev/docs/concepts#what-is-an-authorization-model) that has a relationship directly assignable by both [type bound public access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) and [userset](https://openfga.dev/docs/modeling/building-blocks/usersets), and\n- There are check or list object queries with [contextual tuples](https://openfga.dev/docs/interacting/contextual-tuples) for the relationship that can be directly assignable by both [type bound public access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) and [userset](https://openfga.dev/docs/modeling/building-blocks/usersets), and\n- Those contextual tuples’s user field is an userset, and\n- Type bound public access tuples are not assigned to the relationship\n\n### Fix\nUpgrade to v1.8.13. This upgrade is backwards compatible.\n\n### Acknowledgments\nOkta would like to thank @udyvish for discovering this vulnerability.",
10+
"details": "### Overview\nOpenFGA v1.8.0 to v1.8.12 ( openfga-0.2.16 <= Helm chart <= openfga-0.2.31, v1.8.0 <= docker <= v.1.8.12) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.\n\n\n### Am I Affected?\nIf you are using OpenFGA v1.8.0 to v1.8.12, specifically under the following conditions, you are affected by this authorization bypass vulnerability:\n- Calling Check API or ListObjects with an [authorization model](https://openfga.dev/docs/concepts#what-is-an-authorization-model) that has a relationship directly assignable by both [type bound public access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) and [userset](https://openfga.dev/docs/modeling/building-blocks/usersets), and\n- There are check or list object queries with [contextual tuples](https://openfga.dev/docs/interacting/contextual-tuples) for the relationship that can be directly assignable by both [type bound public access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) and [userset](https://openfga.dev/docs/modeling/building-blocks/usersets), and\n- Those contextual tuples’s user field is an userset, and\n- Type bound public access tuples are not assigned to the relationship\n\n### Fix\nUpgrade to v1.8.13. This upgrade is backwards compatible.\n\n### Acknowledgments\nOpenFGA would like to thank @udyvish for discovering this vulnerability.",
1111
"severity": [
1212
{
1313
"type": "CVSS_V4",

‎advisories/github-reviewed/2025/06/GHSA-9q7c-qmhm-jv86/GHSA-9q7c-qmhm-jv86.json‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-9q7c-qmhm-jv86",
4-
"modified": "2026-01-15T17:47:34Z",
4+
"modified": "2026-03-30T13:54:35Z",
55
"published": "2025-06-26T21:11:09Z",
66
"aliases": [
77
"CVE-2025-52889"
@@ -25,7 +25,7 @@
2525
"type": "ECOSYSTEM",
2626
"events": [
2727
{
28-
"introduced": "6.12.0"
28+
"introduced": "0"
2929
},
3030
{
3131
"fixed": "6.14.0"

‎advisories/github-reviewed/2025/11/GHSA-56mx-8g9f-5crf/GHSA-56mx-8g9f-5crf.json‎

Lines changed: 7 additions & 42 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-56mx-8g9f-5crf",
4-
"modified": "2025-11-13T16:04:55Z",
4+
"modified": "2026-03-30T13:54:58Z",
55
"published": "2025-11-13T16:04:55Z",
66
"aliases": [
77
"CVE-2025-64507"
88
],
99
"summary": "Incus vulnerable to local privilege escalation through custom storage volumes",
10-
"details": "### Impact\nThis affects any Incus user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user.\n\nThe most common case for this would be systems using `incus-user` with the less privileged `incus` group to provide unprivileged users with an isolated restricted access to Incus. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unpriivleged user on the host to gain root privileges.\n\n### Patches\nA patch for this issue is available here: https://github.com/lxc/incus/pull/2642\n\nThe first commit changes the permissions for any new storage pool, the second commit applies it on startup to all existing storage pools.\n\n### Workarounds\nPermissions can be manually restricted until a patched version of Incus is deployed.\n\nThis is done with:\n\n```\nchmod 0700 /var/lib/incus/storage-pools/*/*\nchmod 0711 /var/lib/incus/storage-pools/*/buckets*\nchmod 0711 /var/lib/incus/storage-pools/*/container*\n```\n\nThose are the same permissions which will be applied by the patched Incus for both new and existing storage pools.\n\n### References\nThis was reported publicly on Github: https://github.com/lxc/incus/issues/2641",
10+
"details": "### Impact\nThis affects any Incus user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user.\n\nThe most common case for this would be systems using `incus-user` with the less privileged `incus` group to provide unprivileged users with an isolated restricted access to Incus. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unpriivleged user on the host to gain root privileges.\n\n### Patches\nA patch for this issue is available here: https://github.com/lxc/incus/pull/2642\n\nThe first commit changes the permissions for any new storage pool, the second commit applies it on startup to all existing storage pools.\n\n### Workarounds\nPermissions can be manually restricted until a patched version of Incus is deployed.\n\nThis is done with:\n\n```\nchmod 0700 /var/lib/incus/storage-pools/*/*\nchmod 0711 /var/lib/incus/storage-pools/*/buckets*\nchmod 0711 /var/lib/incus/storage-pools/*/container*\n```\n\nThose are the same permissions which will be applied by the patched Incus for both new and existing storage pools.\n\n### References\nThis was reported publicly on Github by here: https://github.com/lxc/incus/issues/2641",
1111
"severity": [
1212
{
1313
"type": "CVSS_V4",
@@ -20,44 +20,6 @@
2020
"ecosystem": "Go",
2121
"name": "github.com/lxc/incus/v6"
2222
},
23-
"ranges": [
24-
{
25-
"type": "ECOSYSTEM",
26-
"events": [
27-
{
28-
"introduced": "6.1.0"
29-
},
30-
{
31-
"last_affected": "6.18.0"
32-
}
33-
]
34-
}
35-
]
36-
},
37-
{
38-
"package": {
39-
"ecosystem": "Go",
40-
"name": "github.com/lxc/incus/v6"
41-
},
42-
"ranges": [
43-
{
44-
"type": "ECOSYSTEM",
45-
"events": [
46-
{
47-
"introduced": "0"
48-
},
49-
{
50-
"last_affected": "6.0.6"
51-
}
52-
]
53-
}
54-
]
55-
},
56-
{
57-
"package": {
58-
"ecosystem": "Go",
59-
"name": "github.com/lxc/incus"
60-
},
6123
"ranges": [
6224
{
6325
"type": "ECOSYSTEM",
@@ -66,11 +28,14 @@
6628
"introduced": "0"
6729
},
6830
{
69-
"last_affected": "0.7.0"
31+
"fixed": "6.19.0"
7032
}
7133
]
7234
}
73-
]
35+
],
36+
"database_specific": {
37+
"last_known_affected_version_range": "<= 6.18.0"
38+
}
7439
}
7540
],
7641
"references": [

‎advisories/github-reviewed/2026/02/GHSA-282g-fhmx-xf54/GHSA-282g-fhmx-xf54.json‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-282g-fhmx-xf54",
4-
"modified": "2026-02-27T21:26:46Z",
4+
"modified": "2026-03-30T13:55:37Z",
55
"published": "2026-02-27T21:26:46Z",
66
"aliases": [
77
"CVE-2026-27946"
88
],
99
"summary": "ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API",
10-
"details": "### Summary\n\nA vulnerability in ZITADEL's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.\n\n### Impact\n\nZITADEL provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.\n\nDue to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user.\nThis allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.\n\nNote that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n- **4.x**: `4.0.0` through `4.11.0` (including RC versions)\n- **3.x**: `3.0.0` through `3.4.6` (including RC versions)\n- **2.x**: `2.43.0` through `2.71.19`\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.\n\n4.x: Upgrade to >=[4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1)\n3.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)\n2.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)\n\n### Workarounds\n\nThe recommended solution is to upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.\n\n### Questions\n\nIf there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)",
10+
"details": "### Summary\n\nA vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.\n\n### Impact\n\nZitadel provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.\n\nDue to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user.\nThis allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.\n\nNote that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n- **4.x**: `4.0.0` through `4.11.0` (including RC versions)\n- **3.x**: `3.0.0` through `3.4.6` (including RC versions)\n- **2.x**: `2.43.0` through `2.71.19`\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.\n\n4.x: Upgrade to >=[4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1)\n3.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)\n2.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)\n\n### Workarounds\n\nThe recommended solution is to upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.\n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n\n### Credits\n\nThis vulnerability was identified by [Oliver Maicher](https://olivermaicher.eu/) during a security audit of a system utilizing Zitadel.",
1111
"severity": [
1212
{
1313
"type": "CVSS_V4",

‎advisories/github-reviewed/2026/03/GHSA-4j3x-hhg2-fm2x/GHSA-4j3x-hhg2-fm2x.json‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-4j3x-hhg2-fm2x",
4-
"modified": "2026-03-16T22:00:21Z",
4+
"modified": "2026-03-30T13:56:39Z",
55
"published": "2026-03-13T20:56:47Z",
66
"aliases": [
77
"CVE-2026-32704"

‎advisories/github-reviewed/2026/03/GHSA-6g7g-w4f8-9c9x/GHSA-6g7g-w4f8-9c9x.json‎

Lines changed: 13 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-6g7g-w4f8-9c9x",
4-
"modified": "2026-03-19T18:38:45Z",
4+
"modified": "2026-03-30T13:57:14Z",
55
"published": "2026-03-18T13:00:19Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-32285"
8+
],
79
"summary": "Denial of service in github.com/buger/jsonparser",
810
"details": "The Delete function fails to properly validate offsets when processing malformed JSON input. This can lead to a negative slice index and a runtime panic, allowing a denial of service attack.",
911
"severity": [
@@ -37,6 +39,10 @@
3739
}
3840
],
3941
"references": [
42+
{
43+
"type": "ADVISORY",
44+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32285"
45+
},
4046
{
4147
"type": "WEB",
4248
"url": "https://github.com/buger/jsonparser/issues/275"
@@ -64,6 +70,10 @@
6470
{
6571
"type": "WEB",
6672
"url": "https://github.com/buger/jsonparser/releases/tag/v1.1.2"
73+
},
74+
{
75+
"type": "WEB",
76+
"url": "https://pkg.go.dev/vuln/GO-2026-4514"
6777
}
6878
],
6979
"database_specific": {
@@ -73,6 +83,6 @@
7383
"severity": "HIGH",
7484
"github_reviewed": true,
7585
"github_reviewed_at": "2026-03-18T13:00:19Z",
76-
"nvd_published_at": null
86+
"nvd_published_at": "2026-03-26T20:16:12Z"
7787
}
7888
}

‎advisories/github-reviewed/2026/03/GHSA-h9q6-hc68-35rp/GHSA-h9q6-hc68-35rp.json‎

Lines changed: 13 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-h9q6-hc68-35rp",
4-
"modified": "2026-03-18T12:59:54Z",
4+
"modified": "2026-03-30T13:57:05Z",
55
"published": "2026-03-18T12:59:54Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-32284"
8+
],
79
"summary": "Denial of service in github.com/shamaton/msgpack",
810
"details": "The msgpack decoder fails to properly validate the input buffer length when processing truncated fixext data (format codes 0xd4-0xd8). This can lead to an out-of-bounds read and a runtime panic, allowing a denial of service attack.",
911
"severity": [
@@ -53,6 +55,10 @@
5355
}
5456
],
5557
"references": [
58+
{
59+
"type": "ADVISORY",
60+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32284"
61+
},
5662
{
5763
"type": "WEB",
5864
"url": "https://github.com/golang/vulndb/issues/4513"
@@ -65,6 +71,10 @@
6571
"type": "PACKAGE",
6672
"url": "https://github.com/shamaton/msgpack"
6773
},
74+
{
75+
"type": "WEB",
76+
"url": "https://pkg.go.dev/vuln/GO-2026-4513"
77+
},
6878
{
6979
"type": "WEB",
7080
"url": "https://securityinfinity.com/research/shamaton-msgpack-oob-panic-fixext-dos-2026"
@@ -77,6 +87,6 @@
7787
"severity": "HIGH",
7888
"github_reviewed": true,
7989
"github_reviewed_at": "2026-03-18T12:59:54Z",
80-
"nvd_published_at": null
90+
"nvd_published_at": "2026-03-26T20:16:12Z"
8191
}
8292
}

‎advisories/github-reviewed/2026/03/GHSA-jqcq-xjh3-6g23/GHSA-jqcq-xjh3-6g23.json‎

Lines changed: 13 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-jqcq-xjh3-6g23",
4-
"modified": "2026-03-18T13:00:31Z",
4+
"modified": "2026-03-30T13:57:25Z",
55
"published": "2026-03-18T13:00:31Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-32286"
8+
],
79
"summary": "Denial of service in github.com/jackc/pgproto3/v2",
810
"details": "The DataRow.Decode function fails to properly validate field lengths. A malicious or compromised PostgreSQL server can send a DataRow message with a negative field length, causing a slice bounds out of range panic.",
911
"severity": [
@@ -34,6 +36,10 @@
3436
}
3537
],
3638
"references": [
39+
{
40+
"type": "ADVISORY",
41+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32286"
42+
},
3743
{
3844
"type": "WEB",
3945
"url": "https://github.com/golang/vulndb/issues/4518"
@@ -46,6 +52,10 @@
4652
"type": "PACKAGE",
4753
"url": "https://github.com/jackc/pgproto3"
4854
},
55+
{
56+
"type": "WEB",
57+
"url": "https://pkg.go.dev/vuln/GO-2026-4518"
58+
},
4959
{
5060
"type": "WEB",
5161
"url": "https://securityinfinity.com/research/memory-safety-vulnerabilities-in-go-postgresql-wire-protocol-parsers-pgproto3-pgx"
@@ -58,6 +68,6 @@
5868
"severity": "HIGH",
5969
"github_reviewed": true,
6070
"github_reviewed_at": "2026-03-18T13:00:31Z",
61-
"nvd_published_at": null
71+
"nvd_published_at": "2026-03-26T20:16:12Z"
6272
}
6373
}

‎advisories/github-reviewed/2026/03/GHSA-m59h-42jf-cphr/GHSA-m59h-42jf-cphr.json‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-m59h-42jf-cphr",
4-
"modified": "2026-03-25T19:59:21Z",
4+
"modified": "2026-03-30T13:55:55Z",
55
"published": "2026-03-23T20:25:37Z",
66
"aliases": [
77
"CVE-2026-27131"
88
],
99
"summary": "Sprig Plugin for Craft CMS potentially discloses sensitive information via Sprig Playground",
10-
"details": "Admin users, and users with explicit permission to access the Sprig Playground, could potentially expose the security key, credentials, and other sensitive configuration data, in addition to running the `hashData()` signing function.\n\nThis issue was mitigated in versions 3.15.2 and 2.15.2 by disabling access to the Sprig Playground entirely when `devMode` is disabled, by default. It is possible to override this behaviour using a new `enablePlaygroundWhenDevModeDisabled` that defaults to `false`.",
10+
"details": "Admin users, and users with explicit permission to access the Sprig Playground, could potentially expose the security key, credentials, and other sensitive configuration data, in addition to running the `hashData()` signing function.\n\nThis issue was mitigated in versions 3.7.2 and 2.15.2 by disabling access to the Sprig Playground entirely when `devMode` is disabled, by default. It is possible to override this behaviour using a new `enablePlaygroundWhenDevModeDisabled` that defaults to `false`.\n\nReferences:\n\n- https://github.com/putyourlightson/craft-sprig/commit/db18c46f6dc5603828aa321a3a615adbd677d475\n- https://github.com/putyourlightson/craft-sprig/commit/09c9da2ffb45a8857829f3390ae2578e26cfe03b",
1111
"severity": [
1212
{
1313
"type": "CVSS_V3",

0 commit comments

Comments
 (0)