{"id":"CVE-2026-54766","aliases":["EUVD-2026-67830","GHSA-f27p-pw2p-9pr4","GO-2026-6311","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"Vikunja: Project duplication bypasses write-permission check on the target parent project","description":"Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.","severity":{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00427,"percentile":0.37428,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-285","CWE-863"],"published":"2026-08-28T16:36:57Z","modified":"2026-10-28T02:30:27Z","fixes":[{"ecosystem":"Go","package":"code.vikunja.io/api","fixed_in":["2.4.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"code.vikunja.io/api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.21.0"},{"last_affected":"2.3.0"},{"fixed":"2.4.0"}]}]},{"source":"osv","ecosystem":"Go","package":"code.vikunja.io/api","ranges":[{"type":"SEMVER","events":[{"introduced":"0.21.0"},{"fixed":"2.4.0"}]}]},{"source":"osv","ecosystem":"Go","package":"code.vikunja.io/api","ranges":[{"type":"SEMVER","events":[{"introduced":"0.21.0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39}],"products":[{"vendor":"go-vikunja","product":"vikunja"}],"references":[{"url":"https://github.com/go-vikunja/vikunja/security/advisories/GHSA-f27p-pw2p-9pr4","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/go-vikunja/vikunja/pull/3239","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/go-vikunja/vikunja/commit/d911caaa11c748c3abc6b98b3189afea2677bcb0","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-f27p-pw2p-9pr4"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/54xxx/CVE-2026-54766.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-54766","tags":["advisory"]},{"url":"https://github.com/go-vikunja/vikunja","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623692-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-20909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-22547","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24690","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25712","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25718","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26232","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26247","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26307","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27657","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27878","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28705","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54746","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54754","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54755","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55064","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55065","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55066","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55067","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55108","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55484","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55621","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55761","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55763","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55764","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55784","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55785","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55873","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55874","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56854","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78662","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623712-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-54766","title":"Vikunja: Project duplication bypasses write-permission check on the target parent project","description":"Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T16:36:57.857Z","modified":"2026-08-28T19:59:25.82Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-285","CWE-863"],"updated_at":"2026-11-02T13:38:09.774038Z"}],"euvd":[{"id":"EUVD-2026-67830","description":"Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T16:36:57Z","modified":"2026-08-28T19:59:25Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N","level":"medium"}],"updated_at":"2026-11-02T18:01:22.342607Z"}],"ghsa":[{"id":"GHSA-f27p-pw2p-9pr4","title":"Vikunja has a project duplication bypasses write-permission check on the target parent project","description":"## Summary\n\nThe project-duplication endpoint fails to enforce write access to the target parent project. Any authenticated (non-link-share) user can duplicate a project they can read into **any** parent project on the instance, regardless of whether they have write access to that parent — injecting an attacker-owned project into another user's or team's project hierarchy.\n\n## Details\n\n`ProjectDuplicate.CanCreate` (`pkg/models/project_duplicate.go`) is meant to require write access to the parent the duplicate is placed under — its own comment says \"Parent project exists + user has write access\". The implementation does neither correctly:\n\n```go\nfunc (pd *ProjectDuplicate) CanCreate(s *xorm.Session, a web.Auth) (canCreate bool, err error) {\n    pd.Project = \u0026Project{ID: pd.ProjectID}\n    canRead, _, err := pd.Project.CanRead(s, a)\n    if err != nil || !canRead {\n        return canRead, err\n    }\n    if pd.ParentProjectID == 0 {\n        return canRead, err\n    }\n    // Parent project exists + user has write access to is (-\u003e can create new projects)\n    parent := \u0026Project{ID: pd.ParentProjectID}\n    return parent.CanCreate(s, a)   // \u003c-- bug\n}\n```\n\nTwo defects compound here:\n\n1. **Wrong permission method.** It calls `parent.CanCreate` (\"may I create *this* project?\") instead of `parent.CanWrite` (\"may I create children *inside* this project?\"). The latter is what the normal create path uses — `POST /projects` with a `parent_project_id` enforces `parent.CanWrite` via `Project.CanCreate` (`pkg/models/project_permissions.go:196-199`).\n\n2. **Unhydrated struct.** `parent` is constructed as `\u0026Project{ID: pd.ParentProjectID}` and never loaded from the database, so its in-memory `ParentProjectID` is always `0`. Inside `Project.CanCreate` the only branch that performs any permission check is `if p.ParentProjectID != 0 { return parent.CanWrite(...) }` — which therefore never executes. Control falls through to the link-share check and then `return true, nil`. The result is `true` for any authenticated non-link-share user, for any `ParentProjectID`.\n\nNothing downstream re-checks: `ProjectDuplicate.Create` → `CreateProject` → `checkProjectBeforeUpdateOrDelete` (`pkg/models/project.go:954`) validates only that the parent exists, is not a pseudo-project, and introduces no cycle — no authorization.\n\n## Impact\n\nAn authenticated user can:\n\n- Duplicate any project they can read (including their own) and attach the copy as a child of **any** parent project ID on the instance, with no write access to that parent.\n- Inject an attacker-owned project into other users'/teams' project trees. The duplicate is owned by the attacker but appears inside the victim's hierarchy; members of the victim parent see it, and because Vikunja propagates parent access down the tree, they may inherit access to the injected project — enabling content injection / spam / phishing inside another tenant's workspace.\n\nThis is a bypass of the same parent-write guard that the ordinary create path enforces, so the duplicate route is an authorization hole for an operation that is otherwise correctly gated. The endpoint requires authentication; it does not expose or modify the victim's existing project data (the source is attacker-readable), so the impact is an integrity / access-control violation rather than confidentiality.\n\n## Proof of Concept\n\n1. As user A, create or have read access to any project `S` (e.g. id 100).\n2. Identify a parent project `P` (e.g. id 5) owned by user B, to which A has **no** access.\n3. Call `PUT /api/v1/projects/100/duplicate` with body `{\"parent_project_id\": 5}`.\n4. The request succeeds (201). A new project owned by A is created as a child of B's project 5, despite A having no write access to it. The equivalent `POST /api/v1/projects` with `parent_project_id: 5` would be correctly rejected with 403.\n\n## Affected versions\n\nIntroduced with the namespace→project migration (commit `fef253312`, first released in v0.21.0) and present through the latest release (v2.3.0). The shared model also backs the new `/api/v2` duplication route under review, so any v2 release would inherit the same flaw unless fixed in the model.\n\n## Recommended Fix\n\nIn `ProjectDuplicate.CanCreate`, check write access to the parent directly:\n\n```go\nparent := \u0026Project{ID: pd.ParentProjectID}\nreturn parent.CanWrite(s, a)\n```\n\n`Project.CanWrite` loads the project from the database and evaluates real permissions, fixing both the wrong-method and the unhydrated-struct defects at once and matching the documented contract. (It also rejects archived parents, which is desirable.)","status":"published","published":"2026-08-28T16:37:26Z","modified":"2026-08-28T16:37:27Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N","level":"medium"}],"cwes":["CWE-285","CWE-863"],"updated_at":"2026-11-02T14:41:07.031507Z"}],"nvd":[{"id":"CVE-2026-54766","description":"Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T20:18:17.803Z","modified":"2026-09-09T21:09:13.08Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-285","CWE-863"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"CVE-2026-54766","title":"Vikunja: Project duplication bypasses write-permission check on the target parent project","description":"Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T16:36:57.857Z","modified":"2026-10-28T02:30:27.449634563Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N","level":"medium"}],"cwes":["CWE-285","CWE-863"],"updated_at":"2026-11-02T15:45:10.818486Z"},{"id":"GHSA-f27p-pw2p-9pr4","title":"Vikunja has a project duplication bypasses write-permission check on the target parent project","description":"## Summary\n\nThe project-duplication endpoint fails to enforce write access to the target parent project. Any authenticated (non-link-share) user can duplicate a project they can read into **any** parent project on the instance, regardless of whether they have write access to that parent — injecting an attacker-owned project into another user's or team's project hierarchy.\n\n## Details\n\n`ProjectDuplicate.CanCreate` (`pkg/models/project_duplicate.go`) is meant to require write access to the parent the duplicate is placed under — its own comment says \"Parent project exists + user has write access\". The implementation does neither correctly:\n\n```go\nfunc (pd *ProjectDuplicate) CanCreate(s *xorm.Session, a web.Auth) (canCreate bool, err error) {\n    pd.Project = \u0026Project{ID: pd.ProjectID}\n    canRead, _, err := pd.Project.CanRead(s, a)\n    if err != nil || !canRead {\n        return canRead, err\n    }\n    if pd.ParentProjectID == 0 {\n        return canRead, err\n    }\n    // Parent project exists + user has write access to is (-\u003e can create new projects)\n    parent := \u0026Project{ID: pd.ParentProjectID}\n    return parent.CanCreate(s, a)   // \u003c-- bug\n}\n```\n\nTwo defects compound here:\n\n1. **Wrong permission method.** It calls `parent.CanCreate` (\"may I create *this* project?\") instead of `parent.CanWrite` (\"may I create children *inside* this project?\"). The latter is what the normal create path uses — `POST /projects` with a `parent_project_id` enforces `parent.CanWrite` via `Project.CanCreate` (`pkg/models/project_permissions.go:196-199`).\n\n2. **Unhydrated struct.** `parent` is constructed as `\u0026Project{ID: pd.ParentProjectID}` and never loaded from the database, so its in-memory `ParentProjectID` is always `0`. Inside `Project.CanCreate` the only branch that performs any permission check is `if p.ParentProjectID != 0 { return parent.CanWrite(...) }` — which therefore never executes. Control falls through to the link-share check and then `return true, nil`. The result is `true` for any authenticated non-link-share user, for any `ParentProjectID`.\n\nNothing downstream re-checks: `ProjectDuplicate.Create` → `CreateProject` → `checkProjectBeforeUpdateOrDelete` (`pkg/models/project.go:954`) validates only that the parent exists, is not a pseudo-project, and introduces no cycle — no authorization.\n\n## Impact\n\nAn authenticated user can:\n\n- Duplicate any project they can read (including their own) and attach the copy as a child of **any** parent project ID on the instance, with no write access to that parent.\n- Inject an attacker-owned project into other users'/teams' project trees. The duplicate is owned by the attacker but appears inside the victim's hierarchy; members of the victim parent see it, and because Vikunja propagates parent access down the tree, they may inherit access to the injected project — enabling content injection / spam / phishing inside another tenant's workspace.\n\nThis is a bypass of the same parent-write guard that the ordinary create path enforces, so the duplicate route is an authorization hole for an operation that is otherwise correctly gated. The endpoint requires authentication; it does not expose or modify the victim's existing project data (the source is attacker-readable), so the impact is an integrity / access-control violation rather than confidentiality.\n\n## Proof of Concept\n\n1. As user A, create or have read access to any project `S` (e.g. id 100).\n2. Identify a parent project `P` (e.g. id 5) owned by user B, to which A has **no** access.\n3. Call `PUT /api/v1/projects/100/duplicate` with body `{\"parent_project_id\": 5}`.\n4. The request succeeds (201). A new project owned by A is created as a child of B's project 5, despite A having no write access to it. The equivalent `POST /api/v1/projects` with `parent_project_id: 5` would be correctly rejected with 403.\n\n## Affected versions\n\nIntroduced with the namespace→project migration (commit `fef253312`, first released in v0.21.0) and present through the latest release (v2.3.0). The shared model also backs the new `/api/v2` duplication route under review, so any v2 release would inherit the same flaw unless fixed in the model.\n\n## Recommended Fix\n\nIn `ProjectDuplicate.CanCreate`, check write access to the parent directly:\n\n```go\nparent := \u0026Project{ID: pd.ParentProjectID}\nreturn parent.CanWrite(s, a)\n```\n\n`Project.CanWrite` loads the project from the database and evaluates real permissions, fixing both the wrong-method and the unhydrated-struct defects at once and matching the documented contract. (It also rejects archived parents, which is desirable.)","status":"published","published":"2026-08-28T16:37:26Z","modified":"2026-09-02T19:55:46.453854844Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N","level":"medium"}],"cwes":["CWE-285","CWE-863"],"updated_at":"2026-11-02T15:46:45.639885Z"},{"id":"GO-2026-6311","title":"Vikunja has a project duplication bypasses write-permission check on the target parent project in code.vikunja.io/api","description":"Vikunja has a project duplication bypasses write-permission check on the target parent project in code.vikunja.io/api.\n\nNOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.\n\n(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)\n\nThe additional affected modules and versions are: code.vikunja.io/api before v2.4.0.","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:45:14.02904885Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"openSUSE-SU-2026:21812-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:52:09Z","modified":"2026-09-10T18:23:18.964541257Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:23692-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.31116925Z","updated_at":"2026-11-02T15:54:03.991985Z"},{"id":"SUSE-SU-2026:23712-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.805639295Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}