Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-RHX5-H5P6-9G65

Vulnerability from github – Published: 2024-03-07 03:30 – Updated: 2024-03-07 03:30
VLAI
Details

An authorization bypass vulnerability was discovered in GitLab affecting versions 11.3 prior to 16.7.7, 16.7.6 prior to 16.8.4, and 16.8.3 prior to 16.9.2. An attacker could bypass CODEOWNERS by utilizing a crafted payload in an old feature branch to perform malicious actions.

Severity
7.7 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-0199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-07T01:15:52Z",
    "severity": "HIGH"
  },
  "details": "An authorization bypass vulnerability was discovered in GitLab affecting versions 11.3 prior to 16.7.7, 16.7.6 prior to 16.8.4, and 16.8.3 prior to 16.9.2. An attacker could bypass CODEOWNERS by utilizing a crafted payload in an old feature branch to perform malicious actions.",
  "id": "GHSA-rhx5-h5p6-9g65",
  "modified": "2024-03-07T03:30:40Z",
  "published": "2024-03-07T03:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0199"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2295423"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2024/03/06/security-release-gitlab-16-9-2-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/436977"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RHXJ-H3H6-HJ2G

Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-28 00:31
VLAI
Details

Incorrect authorization in Network in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-79262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T21:18:20Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in Network in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-rhxj-h3h6-hj2g",
  "modified": "2026-08-28T00:31:58Z",
  "published": "2026-08-25T21:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79262"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0256176589.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/497338168"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RJ9J-8772-4H6C

Vulnerability from github – Published: 2026-10-09 20:42 – Updated: 2026-10-09 20:42
VLAI
Summary
Vikunja: Link-share token reads any tenant's kanban buckets and enumerates usernames/IDs instance-wide (BOLA)
Details

Summary

The task-collection endpoint GET /api/v1/projects/{project}/views/{view}/tasks loads the requested project view straight from the URL path without verifying the caller is authorized for it. For a link-share token, the task query is correctly pinned to the share's own project, but the view is taken from the attacker-controlled path and never re-validated against the share. A holder of a share link to any project can therefore point the endpoint at any other tenant's kanban view and receive that view's bucket records — bucket titles plus the full created_by user object (username, name, id) — for every view in the instance. The same missing pre-authorization view load also yields a project/view-ID existence oracle (404 vs. non-404) usable by link shares and ordinary authenticated users alike.

Details

Root cause is in TaskCollection.ReadAll (pkg/models/task_collection.go).

  1. The view is resolved from the URL params before any permission check:
// pkg/models/task_collection.go  (ReadAll)
if tf.ProjectViewID != 0 {
    view, err = GetProjectViewByIDAndProject(s, tf.ProjectViewID, tf.ProjectID) // (URL params)
    ...
}

GetProjectViewByIDAndProject (pkg/models/project_view.go) filters only on WHERE id = ? AND project_id = ? — it performs no authorization. A valid (project, view) pair returns the view; an invalid pair returns ErrProjectViewDoesNotExist (HTTP 404).

  1. For a link-share caller, the code pins the task scope to the token's own project but reuses the attacker-supplied view:
shareAuth, is := a.(*LinkSharing)
if is {
    project, err := GetProjectSimpleByID(s, shareAuth.ProjectID)   // token's project
    ...
    return getTaskOrTasksInBuckets(s, a, []*Project{project}, view, opts, filteringForBucket, tf.forceFlatTasks)
    // `view` is the foreign, attacker-controlled view — never validated against shareAuth.ProjectID
}
  1. getTaskOrTasksInBuckets → GetTasksInBucketsForView (pkg/models/kanban.go) reads the buckets of that foreign view directly:
err = s.Where("project_view_id = ?", view.ID).OrderBy("position").Find(&buckets)
...
users, err := getUsersOrLinkSharesFromIDs(s, userIDs) // resolves each bucket's created_by

Each returned Bucket serializes CreatedBy *user.User as json:"created_by" (pkg/models/kanban.go), exposing the creating user's username, name, and id.

The normal (non-share) path is protected because it runs getRelevantProjectsFromCollection, which calls project.CanRead on the URL project and returns 403 before any bucket data is produced. Only the LinkSharing branch skips that gate, which is why the bucket disclosure is link-share-specific. ReadAllWeb (pkg/web/handler/read_all.go) performs no permission check of its own, so all authorization for this endpoint lives inside ReadAll.

Scope of the leak (verified against fixtures): the tasks returned inside the buckets are still constrained to the share's own project (getRawTasksForProjects filters tasks.project_id IN opts.projectIDs, derived from the share's project). So victim task contents do not leak; what leaks is the foreign view's bucket structure and, critically, the created_by user identities of arbitrary buckets instance-wide.

Introduced in v0.24.0 by the per-view kanban feature (feat(views)!: return tasks in buckets by view), which added the views/{view}/tasks endpoint and the foreign-view bucket load. The link-share branch predates it, but the two only combine into this bug from v0.24.0 onward.

Impact

A holder of a link-share token to any single project (link shares are designed to be handed out, often semi-publicly) can:

  • Enumerate all project and view IDs instance-wide. IDs are sequential auto-increment integers; an invalid (project, view) pair returns 404 while a valid one returns 200, giving a reliable existence oracle across all tenants.
  • Disclose the created_by user of any kanban view's buckets — username, display name, and user id. Because Vikunja auto-creates a default project with a Kanban view for every user, iterating view IDs enumerates usernames and user IDs for essentially every account on the instance.
  • Disclose bucket titles of every kanban view in the instance.

This is a cross-tenant broken-object-level-authorization bypass. It does not disclose victim task contents through this path, but instance-wide username/user-id enumeration plus kanban structure disclosure is a meaningful PII and reconnaissance exposure that defeats the tenant isolation the permission model is meant to enforce. The ID-enumeration oracle additionally works for any ordinary authenticated user (invalid combo → 404 vs. inaccessible combo → 403), because the view is loaded before the CanRead check.

Proof of Concept

Prerequisites: link sharing enabled (default), a share link to any project (call it project A), and any second project B (e.g. another tenant's) with a kanban view V_B.

  1. Authenticate the share link to obtain a share JWT: POST /api/v1/shares/{shareHash}/auth
  2. Using that token, request a foreign kanban view's tasks: GET /api/v1/projects/{B}/views/{V_B}/tasks
  3. The 200 response is a list of Bucket objects belonging to view V_B — each with title and a populated created_by (username, name, id) — even though the token has no relationship to project B.
  4. Iterate {B}/{V_B} over sequential integers: valid pairs return bucket lists (harvest usernames/ids), invalid pairs return 404.

Verified locally against the model fixtures: a LinkSharing{ProjectID: 1} (project 1 owned by user 1) calling TaskCollection{ProjectID: 2, ProjectViewID: 8}.ReadAll (project 2 owned by user 3) returns project 2's buckets ("testbucket4 - other project", "testbucket40") with their created_by user objects populated, and no error — while a nonexistent view id returns ErrProjectViewDoesNotExist.

Recommended Fix

In TaskCollection.ReadAll, before the view is loaded, pin the requested project to the link share's own project so any foreign view resolves to a 404 instead of leaking:

if shareAuth, is := a.(*LinkSharing); is {
    tf.ProjectID = shareAuth.ProjectID
}

This is consistent with the existing behavior that already forces the task query to shareAuth.ProjectID, and it closes both the bucket disclosure and the share-token half of the enumeration oracle. As defence-in-depth, resolve the view's authorization against the authenticated caller for every auth type (not just link shares), so the endpoint never loads a view the caller cannot read — closing the 404-vs-403 existence oracle for ordinary users as well.

Severity
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.24.0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-68582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:42:33Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe task-collection endpoint `GET /api/v1/projects/{project}/views/{view}/tasks` loads the requested project view straight from the URL path without verifying the caller is authorized for it. For a **link-share token**, the task query is correctly pinned to the share\u0027s own project, but the *view* is taken from the attacker-controlled path and never re-validated against the share. A holder of a share link to **any** project can therefore point the endpoint at any other tenant\u0027s kanban view and receive that view\u0027s bucket records \u2014 bucket titles plus the full `created_by` user object (username, name, id) \u2014 for every view in the instance. The same missing pre-authorization view load also yields a project/view-ID existence oracle (404 vs. non-404) usable by link shares and ordinary authenticated users alike.\n\n## Details\n\nRoot cause is in `TaskCollection.ReadAll` (`pkg/models/task_collection.go`).\n\n1. The view is resolved from the URL params before any permission check:\n\n```go\n// pkg/models/task_collection.go  (ReadAll)\nif tf.ProjectViewID != 0 {\n    view, err = GetProjectViewByIDAndProject(s, tf.ProjectViewID, tf.ProjectID) // (URL params)\n    ...\n}\n```\n\n`GetProjectViewByIDAndProject` (`pkg/models/project_view.go`) filters only on `WHERE id = ? AND project_id = ?` \u2014 it performs no authorization. A valid `(project, view)` pair returns the view; an invalid pair returns `ErrProjectViewDoesNotExist` (HTTP 404).\n\n2. For a link-share caller, the code pins the *task* scope to the token\u0027s own project but reuses the attacker-supplied `view`:\n\n```go\nshareAuth, is := a.(*LinkSharing)\nif is {\n    project, err := GetProjectSimpleByID(s, shareAuth.ProjectID)   // token\u0027s project\n    ...\n    return getTaskOrTasksInBuckets(s, a, []*Project{project}, view, opts, filteringForBucket, tf.forceFlatTasks)\n    // `view` is the foreign, attacker-controlled view \u2014 never validated against shareAuth.ProjectID\n}\n```\n\n3. `getTaskOrTasksInBuckets` \u2192 `GetTasksInBucketsForView` (`pkg/models/kanban.go`) reads the buckets of that foreign view directly:\n\n```go\nerr = s.Where(\"project_view_id = ?\", view.ID).OrderBy(\"position\").Find(\u0026buckets)\n...\nusers, err := getUsersOrLinkSharesFromIDs(s, userIDs) // resolves each bucket\u0027s created_by\n```\n\nEach returned `Bucket` serializes `CreatedBy *user.User` as `json:\"created_by\"` (`pkg/models/kanban.go`), exposing the creating user\u0027s username, name, and id.\n\nThe normal (non-share) path is protected because it runs `getRelevantProjectsFromCollection`, which calls `project.CanRead` on the URL project and returns 403 before any bucket data is produced. Only the `LinkSharing` branch skips that gate, which is why the bucket disclosure is link-share-specific. `ReadAllWeb` (`pkg/web/handler/read_all.go`) performs no permission check of its own, so all authorization for this endpoint lives inside `ReadAll`.\n\nScope of the leak (verified against fixtures): the *tasks* returned inside the buckets are still constrained to the share\u0027s own project (`getRawTasksForProjects` filters `tasks.project_id IN opts.projectIDs`, derived from the share\u0027s project). So victim task **contents do not leak**; what leaks is the foreign view\u0027s bucket structure and, critically, the `created_by` user identities of arbitrary buckets instance-wide.\n\nIntroduced in v0.24.0 by the per-view kanban feature (`feat(views)!: return tasks in buckets by view`), which added the `views/{view}/tasks` endpoint and the foreign-view bucket load. The link-share branch predates it, but the two only combine into this bug from v0.24.0 onward.\n\n## Impact\n\nA holder of a link-share token to any single project (link shares are designed to be handed out, often semi-publicly) can:\n\n- **Enumerate all project and view IDs instance-wide.** IDs are sequential auto-increment integers; an invalid `(project, view)` pair returns 404 while a valid one returns 200, giving a reliable existence oracle across all tenants.\n- **Disclose the `created_by` user of any kanban view\u0027s buckets** \u2014 username, display name, and user id. Because Vikunja auto-creates a default project with a Kanban view for every user, iterating view IDs enumerates usernames and user IDs for essentially every account on the instance.\n- **Disclose bucket titles** of every kanban view in the instance.\n\nThis is a cross-tenant broken-object-level-authorization bypass. It does not disclose victim task contents through this path, but instance-wide username/user-id enumeration plus kanban structure disclosure is a meaningful PII and reconnaissance exposure that defeats the tenant isolation the permission model is meant to enforce. The ID-enumeration oracle additionally works for any ordinary authenticated user (invalid combo \u2192 404 vs. inaccessible combo \u2192 403), because the view is loaded before the `CanRead` check.\n\n## Proof of Concept\n\nPrerequisites: link sharing enabled (default), a share link to any project (call it project A), and any second project B (e.g. another tenant\u0027s) with a kanban view V_B.\n\n1. Authenticate the share link to obtain a share JWT:\n   `POST /api/v1/shares/{shareHash}/auth`\n2. Using that token, request a foreign kanban view\u0027s tasks:\n   `GET /api/v1/projects/{B}/views/{V_B}/tasks`\n3. The 200 response is a list of `Bucket` objects belonging to view `V_B` \u2014 each with `title` and a populated `created_by` (username, name, id) \u2014 even though the token has no relationship to project B.\n4. Iterate `{B}`/`{V_B}` over sequential integers: valid pairs return bucket lists (harvest usernames/ids), invalid pairs return 404.\n\nVerified locally against the model fixtures: a `LinkSharing{ProjectID: 1}` (project 1 owned by user 1) calling `TaskCollection{ProjectID: 2, ProjectViewID: 8}.ReadAll` (project 2 owned by user 3) returns project 2\u0027s buckets (`\"testbucket4 - other project\"`, `\"testbucket40\"`) with their `created_by` user objects populated, and no error \u2014 while a nonexistent view id returns `ErrProjectViewDoesNotExist`.\n\n## Recommended Fix\n\nIn `TaskCollection.ReadAll`, before the view is loaded, pin the requested project to the link share\u0027s own project so any foreign view resolves to a 404 instead of leaking:\n\n```go\nif shareAuth, is := a.(*LinkSharing); is {\n    tf.ProjectID = shareAuth.ProjectID\n}\n```\n\nThis is consistent with the existing behavior that already forces the task query to `shareAuth.ProjectID`, and it closes both the bucket disclosure and the share-token half of the enumeration oracle. As defence-in-depth, resolve the view\u0027s authorization against the authenticated caller for every auth type (not just link shares), so the endpoint never loads a view the caller cannot read \u2014 closing the 404-vs-403 existence oracle for ordinary users as well.",
  "id": "GHSA-rj9j-8772-4h6c",
  "modified": "2026-10-09T20:42:33Z",
  "published": "2026-10-09T20:42:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-rj9j-8772-4h6c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68582"
    },
    {
      "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-broken-object-level-authorization-via-link-share-token"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vikunja: Link-share token reads any tenant\u0027s kanban buckets and enumerates usernames/IDs instance-wide (BOLA)"
}

GHSA-RJFC-FV4G-M58Q

Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-07-09 00:00
VLAI
Details

A side effect of an integrated chipset option may be able to be used by an attacker to bypass SPI ROM protections, allowing unauthorized SPI ROM modification.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-12954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-16T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A side effect of an integrated chipset option may be able to be used by an attacker to bypass SPI ROM protections, allowing unauthorized SPI ROM modification.",
  "id": "GHSA-rjfc-fv4g-m58q",
  "modified": "2022-07-09T00:00:22Z",
  "published": "2022-05-24T19:20:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12954"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RJJC-GG9M-VHV8

Vulnerability from github – Published: 2023-12-21 15:30 – Updated: 2024-10-29 18:30
VLAI
Details

Inadequate validation of permissions when employing remote tools and macros via the context menu within Devolutions Remote Desktop Manager versions 2023.3.31 and earlier permits a user to initiate a connection without proper execution rights via the remote tools feature. This affects only SQL data sources.

Severity
4.4 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-7047"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-21T15:15:14Z",
    "severity": "MODERATE"
  },
  "details": "\nInadequate validation of permissions when employing remote tools and \nmacros via the context menu within Devolutions Remote Desktop Manager versions 2023.3.31 and \nearlier permits a user to initiate a connection without proper execution\n rights via the remote tools feature. This affects only SQL data sources.\n",
  "id": "GHSA-rjjc-gg9m-vhv8",
  "modified": "2024-10-29T18:30:33Z",
  "published": "2023-12-21T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7047"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2023-0024"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RJJR-7VQ7-W4MX

Vulnerability from github – Published: 2022-12-19 15:30 – Updated: 2022-12-23 21:30
VLAI
Details

A vulnerability was found in Click Studios Passwordstate and Passwordstate Browser Extension Chrome and classified as critical. This issue affects some unknown processing of the component Browser Extension Provisioning. The manipulation leads to improper authorization. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-216275.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-4613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-19T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Click Studios Passwordstate and Passwordstate Browser Extension Chrome and classified as critical. This issue affects some unknown processing of the component Browser Extension Provisioning. The manipulation leads to improper authorization. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-216275.",
  "id": "GHSA-rjjr-7vq7-w4mx",
  "modified": "2022-12-23T21:30:17Z",
  "published": "2022-12-19T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4613"
    },
    {
      "type": "WEB",
      "url": "https://modzero.com/modlog/archives/2022/12/19/better_make_sure_your_password_manager_is_secure/index.html"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.216275"
    },
    {
      "type": "WEB",
      "url": "https://www.modzero.com/static/MZ-22-03_Passwordstate_Security_Disclosure_Report-v1.0.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RJMQ-6V55-4RJV

Vulnerability from github – Published: 2022-03-15 19:02 – Updated: 2022-03-15 19:02
VLAI
Summary
Improper Authorization in org.cometd.oort
Details

Impact

Internal usage of Oort and Seti channels is improperly authorized, so any remote user could subscribe and publish to those channels. By subscribing to those channels, a remote user may be able to watch cluster-internal traffic that contains other user's (possibly sensitive) data. By publishing to those channels, a remote user may be able to create/modify/delete other user's data and modify the cluster structure. The issue impacts any version up to 5.0.10, 6.0.5 and 7.0.5.

Patches

The issue has been fixed in 5.0.11, 6.0.6 and 7.0.6.

Workarounds

The workaround is to install a custom SecurityPolicy that forbids subscription and publishing to remote, non-Oort, sessions on Oort and Seti channels. This workaround could be implemented in any affected version.

References

cometd/cometd#1146

For more information

If you have any questions or comments about this advisory: * Email us at security@webtide.com

Credits

https://www.redteam-pentesting.de/

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.cometd.java:cometd-java-oort"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.cometd.java:cometd-java-oort"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.cometd.java:cometd-java-oort"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-24721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-15T19:02:36Z",
    "nvd_published_at": "2022-03-15T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nInternal usage of Oort and Seti channels is improperly authorized, so any remote user could subscribe and publish to those channels.\nBy subscribing to those channels, a remote user may be able to watch cluster-internal traffic that contains other user\u0027s (possibly sensitive) data.\nBy publishing to those channels, a remote user may be able to create/modify/delete other user\u0027s data and modify the cluster structure.\nThe issue impacts any version up to 5.0.10, 6.0.5 and 7.0.5.\n\n### Patches\nThe issue has been fixed in 5.0.11, 6.0.6 and 7.0.6.\n\n### Workarounds\nThe workaround is to install a custom `SecurityPolicy` that forbids subscription and publishing to remote, non-Oort, sessions on Oort and Seti channels.\nThis workaround could be implemented in any affected version.\n\n### References\ncometd/cometd#1146\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [security@webtide.com](mailto:security@webtide.com)\n\n### Credits\nhttps://www.redteam-pentesting.de/",
  "id": "GHSA-rjmq-6v55-4rjv",
  "modified": "2022-03-15T19:02:36Z",
  "published": "2022-03-15T19:02:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cometd/cometd/security/advisories/GHSA-rjmq-6v55-4rjv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24721"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cometd/cometd/issues/1146"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cometd/cometd/commit/bb445a143fbf320f17c62e340455cd74acfb5929"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cometd/cometd"
    }
  ],
  "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": "Improper Authorization in org.cometd.oort"
}

GHSA-RJVX-X5H2-6PX5

Vulnerability from github – Published: 2026-07-21 20:26 – Updated: 2026-07-21 20:26
VLAI
Summary
Gitea: API Fork Endpoint Authorization Bypass Allows Organization Members to Bypass Repository Creation Restrictions
Details

Summary

The API endpoint used to fork repositories into organizations performs a weaker authorization check than the corresponding web UI and other repository creation endpoints.

When a repository is forked into an organization through the API, the endpoint only verifies that the user is an organization member (IsOrgMember()), but does not verify whether the user is allowed to create repositories in that organization (CanCreateOrgRepo()).

As a result, organization members belonging to teams with can_create_org_repo=false can still create repositories inside the organization by using the fork API.

Details

Affected endpoint:

POST /api/v1/repos/{owner}/{repo}/forks

In routers/api/v1/repo/fork.go, the endpoint performs the following authorization check:

if !ctx.Doer.IsAdmin {
    isMember, err := org.IsOrgMember(ctx, ctx.Doer.ID)
    if !isMember {
        ctx.APIError(http.StatusForbidden, ...)
        return
    }
}

The equivalent web UI implementation uses the stronger permission check:

isAllowedToFork, err := organization.OrgFromUser(ctxUser).
    CanCreateOrgRepo(ctx, ctx.Doer.ID)

The same CanCreateOrgRepo() authorization check is also used by:

  • CreateOrgRepo API endpoint
  • GenerateRepository API endpoint

The fork endpoint appears to be the only repository creation path that relies solely on organization membership.

Proof of Concept

Tested on Gitea 1.23.7.

  1. Create an organization.
  2. Create a team with can_create_org_repo=false.
  3. Add a test user to that team.
  4. Verify that normal repository creation is denied:
POST /api/v1/orgs/target-org/repos

Result:

403 Forbidden
  1. Fork a repository into the organization:
POST /api/v1/repos/admin/public-repo/forks
Content-Type: application/json

{
  "organization": "target-org"
}

Result:

202 Accepted

The repository is successfully created despite repository creation permissions being disabled.

Impact

Users who are organization members but are intentionally prevented from creating repositories can bypass that restriction through the API.

This allows unauthorized repository creation inside the organization and may expose additional attack surface depending on the organization's Actions, runner, and workflow configuration.

The vulnerability represents an authorization bypass because API behavior is less restrictive than both the web UI and other repository creation endpoints.

Severity
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:26:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe API endpoint used to fork repositories into organizations performs a weaker authorization check than the corresponding web UI and other repository creation endpoints.\n\nWhen a repository is forked into an organization through the API, the endpoint only verifies that the user is an organization member (`IsOrgMember()`), but does not verify whether the user is allowed to create repositories in that organization (`CanCreateOrgRepo()`).\n\nAs a result, organization members belonging to teams with `can_create_org_repo=false` can still create repositories inside the organization by using the fork API.\n\n### Details\n\nAffected endpoint:\n\n```\nPOST /api/v1/repos/{owner}/{repo}/forks\n```\n\nIn `routers/api/v1/repo/fork.go`, the endpoint performs the following authorization check:\n\n```go\nif !ctx.Doer.IsAdmin {\n    isMember, err := org.IsOrgMember(ctx, ctx.Doer.ID)\n    if !isMember {\n        ctx.APIError(http.StatusForbidden, ...)\n        return\n    }\n}\n```\n\nThe equivalent web UI implementation uses the stronger permission check:\n\n```go\nisAllowedToFork, err := organization.OrgFromUser(ctxUser).\n    CanCreateOrgRepo(ctx, ctx.Doer.ID)\n```\n\nThe same `CanCreateOrgRepo()` authorization check is also used by:\n\n* CreateOrgRepo API endpoint\n* GenerateRepository API endpoint\n\nThe fork endpoint appears to be the only repository creation path that relies solely on organization membership.\n\n### Proof of Concept\n\nTested on Gitea 1.23.7.\n\n1. Create an organization.\n2. Create a team with `can_create_org_repo=false`.\n3. Add a test user to that team.\n4. Verify that normal repository creation is denied:\n\n```http\nPOST /api/v1/orgs/target-org/repos\n```\n\nResult:\n\n```http\n403 Forbidden\n```\n\n5. Fork a repository into the organization:\n\n```http\nPOST /api/v1/repos/admin/public-repo/forks\nContent-Type: application/json\n\n{\n  \"organization\": \"target-org\"\n}\n```\n\nResult:\n\n```http\n202 Accepted\n```\n\nThe repository is successfully created despite repository creation permissions being disabled.\n\n### Impact\n\nUsers who are organization members but are intentionally prevented from creating repositories can bypass that restriction through the API.\n\nThis allows unauthorized repository creation inside the organization and may expose additional attack surface depending on the organization\u0027s Actions, runner, and workflow configuration.\n\nThe vulnerability represents an authorization bypass because API behavior is less restrictive than both the web UI and other repository creation endpoints.",
  "id": "GHSA-rjvx-x5h2-6px5",
  "modified": "2026-07-21T20:26:37Z",
  "published": "2026-07-21T20:26:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-rjvx-x5h2-6px5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/36950"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/686d10b7f0c26baf91171124b382cbcdfa7bf025"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.0"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gitea: API Fork Endpoint Authorization Bypass Allows Organization Members to Bypass Repository Creation Restrictions"
}

GHSA-RJX3-H5W4-7663

Vulnerability from github – Published: 2022-07-24 00:00 – Updated: 2022-07-28 00:00
VLAI
Details

Inappropriate implementation in Virtual Keyboard in Google Chrome on Chrome OS prior to 100.0.4896.60 allowed a local attacker to bypass navigation restrictions via physical access to the device.

Severity
6.1 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-1132"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-23T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Inappropriate implementation in Virtual Keyboard in Google Chrome on Chrome OS prior to 100.0.4896.60 allowed a local attacker to bypass navigation restrictions via physical access to the device.",
  "id": "GHSA-rjx3-h5w4-7663",
  "modified": "2022-07-28T00:00:48Z",
  "published": "2022-07-24T00:00:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1132"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2022/03/stable-channel-update-for-desktop_29.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1303410"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-25"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RJXG-RPG3-9R89

Vulnerability from github – Published: 2023-10-24 02:21 – Updated: 2023-11-02 16:38
VLAI
Summary
Fides Information Disclosure Vulnerability in Config API Endpoint
Details

Impact

The Fides webserver API allows users to retrieve its configuration using the GET api/v1/config endpoint. The configuration data is filtered to suppress most sensitive configuration information before it is returned to the user, but even the filtered data contains information about the internals and the backend infrastructure, such as various settings, servers’ addresses and ports and database username. This information is useful for administrative users as well as attackers, thus it should not be revealed to low-privileged users.

This vulnerability allows Admin UI users with roles lower than the owner role e.g. the viewer role to retrieve the config information using the API.

Patches

The vulnerability has been patched in Fides version 2.22.1. Users are advised to upgrade to this version or later to secure their systems against this threat.

Workarounds

There are no workarounds.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ethyca-fides"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.22.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46125"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-24T02:21:34Z",
    "nvd_published_at": "2023-10-25T18:17:36Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe Fides webserver API allows users to retrieve its configuration using the `GET api/v1/config` endpoint. The configuration data is filtered to suppress most sensitive configuration information before it is returned to the user, but even the filtered data contains information about the internals and the backend infrastructure, such as various settings, servers\u2019 addresses and ports and database username. This information is useful for administrative users as well as attackers, thus it should not be revealed to low-privileged users.\n\nThis vulnerability allows Admin UI users with roles lower than the owner role e.g. the viewer role to retrieve the config information using the API. \n\n### Patches\nThe vulnerability has been patched in Fides version `2.22.1`. Users are advised to upgrade to this version or later to secure their systems against this threat.\n\n### Workarounds\nThere are no workarounds.\n",
  "id": "GHSA-rjxg-rpg3-9r89",
  "modified": "2023-11-02T16:38:02Z",
  "published": "2023-10-24T02:21:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ethyca/fides/security/advisories/GHSA-rjxg-rpg3-9r89"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46125"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethyca/fides/commit/c9f3a620a4b4c1916e0941cb5624dcd636f06d06"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ethyca/fides"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethyca/fides/releases/tag/2.22.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fides Information Disclosure Vulnerability in Config API Endpoint"
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list