Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

3341 vulnerabilities reference this CWE, most recent first.

GHSA-F78Q-MW55-HMG4

Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-27 18:32
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in Mikado-Themes Innovio innovio allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Innovio: from n/a through <= 1.7.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-22404"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T17:16:33Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Mikado-Themes Innovio innovio allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Innovio: from n/a through \u003c= 1.7.",
  "id": "GHSA-f78q-mw55-hmg4",
  "modified": "2026-01-27T18:32:12Z",
  "published": "2026-01-22T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22404"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/innovio/vulnerability/wordpress-innovio-theme-1-7-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F7H9-HRG7-94FG

Vulnerability from github – Published: 2024-10-01 15:32 – Updated: 2024-11-16 00:31
VLAI
Details

Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-37577"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-01T15:15:06Z",
    "severity": "MODERATE"
  },
  "details": "Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.",
  "id": "GHSA-f7h9-hrg7-94fg",
  "modified": "2024-11-16T00:31:49Z",
  "published": "2024-10-01T15:32:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37577"
    },
    {
      "type": "WEB",
      "url": "https://bluetooth.com"
    },
    {
      "type": "WEB",
      "url": "https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/passkey-impersonation"
    },
    {
      "type": "WEB",
      "url": "https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/reporting-security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F8CV-RHQG-3X6W

Vulnerability from github – Published: 2022-08-06 00:00 – Updated: 2022-08-11 00:00
VLAI
Details

Authenticated IDOR vulnerability in StoreApps Affiliate For WooCommerce premium plugin <= 4.7.0 at WordPress allows an attacker to change the PayPal email. WooCommerce PayPal Payments plugin (free) should be at least installed to get the extra input field on the user profile page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-36284"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-05T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Authenticated IDOR vulnerability in StoreApps Affiliate For WooCommerce premium plugin \u003c= 4.7.0 at WordPress allows an attacker to change the PayPal email. WooCommerce PayPal Payments plugin (free) should be at least installed to get the extra input field on the user profile page.",
  "id": "GHSA-f8cv-rhqg-3x6w",
  "modified": "2022-08-11T00:00:33Z",
  "published": "2022-08-06T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36284"
    },
    {
      "type": "WEB",
      "url": "https://dzv365zjfbd8v.cloudfront.net/changelogs/affiliate-for-woocommerce/changelog.txt"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/affiliate-for-woocommerce/wordpress-affiliate-for-woocommerce-premium-plugin-4-7-0-authenticated-idor-vulnerability-leading-to-paypal-email-change"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F8J3-R9JJ-4QXR

Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31
VLAI
Details

ServiceNow has addressed a Broken Access Control vulnerability that was identified in the ServiceNow AI Platform. This vulnerability could allow a low privileged user to bypass access controls and perform a limited set of actions typically reserved for higher privileged users, potentially leading to unauthorized data modifications. This issue is addressed in the listed patches and family releases, which have been made available to hosted and self-hosted customers, as well as partners.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-3089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T16:15:27Z",
    "severity": "MODERATE"
  },
  "details": "ServiceNow has addressed a Broken Access Control vulnerability that was identified in the ServiceNow AI Platform. This vulnerability could allow a low privileged user to bypass access controls and perform a limited set of actions typically reserved for higher privileged users, potentially leading to unauthorized data modifications.\u00a0This issue is addressed in the listed patches and family releases, which have been made available to hosted and self-hosted customers, as well as partners.",
  "id": "GHSA-f8j3-r9jj-4qxr",
  "modified": "2025-08-12T18:31:25Z",
  "published": "2025-08-12T18:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3089"
    },
    {
      "type": "WEB",
      "url": "https://support.servicenow.com/kb?id=kb_article_view\u0026sysparm_article=KB2264930"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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"
    }
  ]
}

GHSA-F8MV-JPHX-3R7G

Vulnerability from github – Published: 2024-06-06 21:30 – Updated: 2024-06-06 21:30
VLAI
Details

An Incorrect Authorization vulnerability exists in lunary-ai/lunary versions up to and including 1.2.2, which allows unauthenticated users to delete any dataset. The vulnerability is due to the lack of proper authorization checks in the dataset deletion endpoint. Specifically, the endpoint does not verify if the provided project ID belongs to the current user, thereby allowing any dataset to be deleted without proper authentication. This issue was fixed in version 1.2.8.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-5130"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-06T19:16:04Z",
    "severity": "HIGH"
  },
  "details": "An Incorrect Authorization vulnerability exists in lunary-ai/lunary versions up to and including 1.2.2, which allows unauthenticated users to delete any dataset. The vulnerability is due to the lack of proper authorization checks in the dataset deletion endpoint. Specifically, the endpoint does not verify if the provided project ID belongs to the current user, thereby allowing any dataset to be deleted without proper authentication. This issue was fixed in version 1.2.8.",
  "id": "GHSA-f8mv-jphx-3r7g",
  "modified": "2024-06-06T21:30:37Z",
  "published": "2024-06-06T21:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5130"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lunary-ai/lunary/commit/14078c1d2b8766075bf655f187ece24c7a787776"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/e81a9871-308d-4628-9726-af66643a16fe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F8V3-8WM7-H9QR

Vulnerability from github – Published: 2026-04-30 21:30 – Updated: 2026-04-30 21:30
VLAI
Details

IBM Langflow Desktop 1.0.0 through 1.8.4 Langflow could allow an unauthenticated user to view other users' images due to an indirect object reference through a user-controlled key.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T21:16:33Z",
    "severity": "HIGH"
  },
  "details": "IBM Langflow Desktop 1.0.0 through 1.8.4 Langflow could allow an unauthenticated user to view other users\u0027 images due to an indirect object reference through a user-controlled key.",
  "id": "GHSA-f8v3-8wm7-h9qr",
  "modified": "2026-04-30T21:30:39Z",
  "published": "2026-04-30T21:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4503"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7271099"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F924-8J9Q-7FPQ

Vulnerability from github – Published: 2025-10-14 12:31 – Updated: 2025-10-14 12:31
VLAI
Details

A vulnerability has been identified in SiPass integrated (All versions < V3.0). Affected server applications contains a broken access control vulnerability. The authorization mechanism lacks sufficient server-side checks, allowing an attacker to execute a specific API request.

Successful exploitation allows an attacker to potentially manipulate data belonging to other users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-40773"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T10:15:38Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SiPass integrated (All versions \u003c V3.0). Affected server applications contains a broken access control vulnerability. The authorization mechanism lacks sufficient server-side checks, allowing an attacker to execute a specific API request.\n\nSuccessful exploitation allows an attacker to potentially manipulate data belonging to other users.",
  "id": "GHSA-f924-8j9q-7fpq",
  "modified": "2025-10-14T12:31:31Z",
  "published": "2025-10-14T12:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40773"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-599451.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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"
    }
  ]
}

GHSA-F93W-PCJ3-RGGC

Vulnerability from github – Published: 2026-03-05 20:57 – Updated: 2026-03-09 20:46
VLAI
Summary
Pingora vulnerable to cache poisoning via insecure-by-default cache key
Details

Impact

Pingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users.

This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.

Patches

We strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation.

Workarounds

Do not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method.

References

See CVE-2026-2836 and the Cloudflare blog post for more details.

Credits

Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.7.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "pingora-cache"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-2836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T20:57:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nPingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users.\n\nThis vulnerability affects users of Pingora\u0027s alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries.\n\nNote: Cloudflare customers and Cloudflare\u0027s CDN infrastructure were not affected by this vulnerability, as Cloudflare\u0027s default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.\n\n### Patches\nWe strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation.\n\n### Workarounds\nDo not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. \n\n### References\nSee [CVE-2026-2836](https://cve.org/CVERecord?id=CVE-2026-2836) and the [Cloudflare blog post](https://blog.cloudflare.com/pingora-oss-smuggling-vulnerabilities/) for more details.\n\n### Credits\nDisclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare [Bug Bounty Program](https://www.cloudflare.com/disclosure/).",
  "id": "GHSA-f93w-pcj3-rggc",
  "modified": "2026-03-09T20:46:06Z",
  "published": "2026-03-05T20:57:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/pingora/security/advisories/GHSA-f93w-pcj3-rggc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2836"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudflare/pingora"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0035.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pingora vulnerable to cache poisoning via insecure-by-default cache key"
}

GHSA-F95F-77JX-FCJC

Vulnerability from github – Published: 2026-03-25 21:21 – Updated: 2026-03-25 21:21
VLAI
Summary
Vikunja has a Link Share Delete IDOR — Missing Project Ownership Check Allows Cross-Project Link Share Deletion
Details

Summary

The DELETE /api/v1/projects/:project/shares/:share endpoint does not verify that the link share belongs to the project specified in the URL. An attacker with admin access to any project can delete link shares from other projects by providing their own project ID combined with the target share ID.

Details

The permission check in canDoLinkShare (pkg/models/link_sharing_permissions.go:53-70) validates admin access on the project from the :project URL parameter. However, the Delete method at pkg/models/link_sharing.go:305 queries only WHERE id = ? using the share ID, without verifying it belongs to the URL-specified project:

func (share *LinkSharing) Delete(s *xorm.Session, _ web.Auth) (err error) {
    _, err = s.Where("id = ?", share.ID).Delete(share)
    return
}

This is the same vulnerability class as GHSA-jfmm-mjcp-8wq2 (task attachment IDOR) and the fixed GHSA-mr3j-p26x-72x4 (task comment IDOR).

Additionally, ReadOne at line 203 has the same pattern (WHERE id = ? only), though it is not currently exploitable because CanRead fails first due to an unrelated issue with the hash parameter binding.

Impact

An authenticated user with admin access to any project can: - Delete link shares belonging to any other project in the system - Disrupt collaboration by removing shared access links - Link share IDs are sequential integers, making enumeration trivial

Reproduction

  1. User A creates Project A and a link share on it (share ID = X)
  2. User B creates Project B (gaining admin access)
  3. User B calls DELETE /api/v1/projects/{projectB_id}/shares/{X}
  4. The permission check passes (User B is admin on Project B)
  5. The delete executes WHERE id = X — deleting User A's link share

Recommended Fix

Change Delete at pkg/models/link_sharing.go:305 to:

_, err = s.Where("id = ? AND project_id = ?", share.ID, share.ProjectID).Delete(share)

Also fix ReadOne at line 203 as defense in depth.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33700"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T21:21:20Z",
    "nvd_published_at": "2026-03-24T16:16:35Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `DELETE /api/v1/projects/:project/shares/:share` endpoint does not verify that the link share belongs to the project specified in the URL. An attacker with admin access to any project can delete link shares from other projects by providing their own project ID combined with the target share ID.\n\n## Details\n\nThe permission check in `canDoLinkShare` (`pkg/models/link_sharing_permissions.go:53-70`) validates admin access on the project from the `:project` URL parameter. However, the `Delete` method at `pkg/models/link_sharing.go:305` queries only `WHERE id = ?` using the share ID, without verifying it belongs to the URL-specified project:\n\n```go\nfunc (share *LinkSharing) Delete(s *xorm.Session, _ web.Auth) (err error) {\n    _, err = s.Where(\"id = ?\", share.ID).Delete(share)\n    return\n}\n```\n\nThis is the same vulnerability class as GHSA-jfmm-mjcp-8wq2 (task attachment IDOR) and the fixed GHSA-mr3j-p26x-72x4 (task comment IDOR).\n\nAdditionally, `ReadOne` at line 203 has the same pattern (`WHERE id = ?` only), though it is not currently exploitable because `CanRead` fails first due to an unrelated issue with the hash parameter binding.\n\n## Impact\n\nAn authenticated user with admin access to any project can:\n- Delete link shares belonging to any other project in the system\n- Disrupt collaboration by removing shared access links\n- Link share IDs are sequential integers, making enumeration trivial\n\n## Reproduction\n\n1. User A creates Project A and a link share on it (share ID = X)\n2. User B creates Project B (gaining admin access)\n3. User B calls `DELETE /api/v1/projects/{projectB_id}/shares/{X}`\n4. The permission check passes (User B is admin on Project B)\n5. The delete executes `WHERE id = X` \u2014 deleting User A\u0027s link share\n\n## Recommended Fix\n\nChange `Delete` at `pkg/models/link_sharing.go:305` to:\n\n```go\n_, err = s.Where(\"id = ? AND project_id = ?\", share.ID, share.ProjectID).Delete(share)\n```\n\nAlso fix `ReadOne` at line 203 as defense in depth.",
  "id": "GHSA-f95f-77jx-fcjc",
  "modified": "2026-03-25T21:21:20Z",
  "published": "2026-03-25T21:21:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-f95f-77jx-fcjc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33700"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.2.2-was-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vikunja has a Link Share Delete IDOR \u2014 Missing Project Ownership Check Allows Cross-Project Link Share Deletion"
}

GHSA-F95X-R3PV-JH63

Vulnerability from github – Published: 2026-07-15 18:31 – Updated: 2026-07-15 18:31
VLAI
Details

Kanboard through 1.2.52, fixed in commit 564cc30, BoardAjaxController save() method (used by the kanban board drag-and-drop endpoint) validates the caller's role on the attacker-supplied project_id but never verifies that the supplied task_id actually belongs to that project. Because task identifiers are sequential integers shared across the entire instance, any authenticated user who is a member of at least one project can enumerate and move (corrupt/hide) tasks belonging to any other project on the same instance, including private projects they have no membership or role on.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-58660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-15T18:16:48Z",
    "severity": "HIGH"
  },
  "details": "Kanboard through 1.2.52, fixed in commit 564cc30, BoardAjaxController save() method (used by the kanban board drag-and-drop endpoint) validates the caller\u0027s role on the attacker-supplied project_id but never verifies that the supplied task_id actually belongs to that project. Because task identifiers are sequential integers shared across the entire instance, any authenticated user who is a member of at least one project can enumerate and move (corrupt/hide) tasks belonging to any other project on the same instance, including private projects they have no membership or role on.",
  "id": "GHSA-f95x-r3pv-jh63",
  "modified": "2026-07-15T18:31:58Z",
  "published": "2026-07-15T18:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58660"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanboard/kanboard/issues/5852"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanboard/kanboard/pull/5853"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanboard/kanboard/commit/564cc30e1e360959572e01e158734d9475c05903"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/kanboard-boardajaxcontroller-missing-ownership-check-via-drag-and-drop"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/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"
    }
  ]
}

Mitigation
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.