Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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.

5636 vulnerabilities reference this CWE, most recent first.

GHSA-QCCJ-J742-WW2R

Vulnerability from github – Published: 2023-07-13 03:30 – Updated: 2024-04-04 06:06
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 15.3 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1, which allows an attacker to merge arbitrary code into protected branches.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-3444"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-74",
      "CWE-863",
      "CWE-99"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T03:15:10Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 15.3 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1, which allows an attacker to merge arbitrary code into protected branches.",
  "id": "GHSA-qccj-j742-ww2r",
  "modified": "2024-04-04T06:06:33Z",
  "published": "2023-07-13T03:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3444"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1928709"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/406803"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QCHV-QQP6-V795

Vulnerability from github – Published: 2025-04-18 15:31 – Updated: 2025-04-18 15:31
VLAI
Details

IBM Sterling Connect:Direct Web Services 6.1.0, 6.2.0, and 6.3.0 could allow an authenticated user to spoof the identity of another user due to improper authorization which could allow the user to bypass access restrictions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49808"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-18T11:15:45Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling Connect:Direct Web Services 6.1.0, 6.2.0, and 6.3.0 could allow an authenticated user to spoof the identity of another user due to improper authorization which could allow the user to bypass access restrictions.",
  "id": "GHSA-qchv-qqp6-v795",
  "modified": "2025-04-18T15:31:38Z",
  "published": "2025-04-18T15:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49808"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7231180"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QCJ3-WPGM-QPXH

Vulnerability from github – Published: 2024-06-24 18:00 – Updated: 2024-06-24 21:27
VLAI
Summary
XWiki programming rights may be inherited by inclusion
Details

Impact

The content of a document included using {{include reference="targetdocument"/}} is executed with the right of the includer and not with the right of its author.

This means that any user able to modify the target document can impersonate the author of the content which used the include macro.

Patches

This has been patched in XWiki 15.0 RC1 by making the default behavior safe.

Workarounds

Make sure to protect any included document to make sure only allowed users can modify it.

A workaround have been provided in 14.10.2 to allow forcing to execute the included content with the target content author instead of the default behavior. See https://extensions.xwiki.org/xwiki/bin/view/Extension/Include%20Macro#HAuthor for more details.

References

https://jira.xwiki.org/browse/XWIKI-5027 https://jira.xwiki.org/browse/XWIKI-20471

For more information

If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-rendering-macro-include"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "15.0-rc-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-38369"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-24T18:00:16Z",
    "nvd_published_at": "2024-06-24T17:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nThe content of a document included using `{{include reference=\"targetdocument\"/}}` is executed with the right of the includer and not with the right of its author.\n\nThis means that any user able to modify the target document can impersonate the author of the content which used the `include` macro.\n\n### Patches\n\nThis has been patched in XWiki 15.0 RC1 by making the default behavior safe.\n\n### Workarounds\n\nMake sure to protect any included document to make sure only allowed users can modify it.\n\nA workaround have been provided in 14.10.2 to allow forcing to execute the included content with the target content author instead of the default behavior. See https://extensions.xwiki.org/xwiki/bin/view/Extension/Include%20Macro#HAuthor for more details.\n\n### References\n\nhttps://jira.xwiki.org/browse/XWIKI-5027\nhttps://jira.xwiki.org/browse/XWIKI-20471\n\n### For more information\nIf you have any questions or comments about this advisory:\n*    Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n*    Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
  "id": "GHSA-qcj3-wpgm-qpxh",
  "modified": "2024-06-24T21:27:57Z",
  "published": "2024-06-24T18:00:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-qcj3-wpgm-qpxh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38369"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/0a4f9b026ba9931516b4e9b3019da8da838c7ac6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/b48116a3ebe9ce928c401b5d068d4db7e7239575"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/c1fb14402ce2ee569c5a8e3f1f8e64ae45dfbfb0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/d1a84a3eea38305ff8e10ba411910c0675ac157c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/f627abe2dc39b07ff75fe68398cc8a1bbc743ef7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-20471"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-5027"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "XWiki programming rights may be inherited by inclusion"
}

GHSA-QCQW-JWXC-2HQG

Vulnerability from github – Published: 2026-06-25 18:48 – Updated: 2026-06-25 18:48
VLAI
Summary
Lemur has an authorization bypass in StrictRolePermission / AuthorityCreatorPermission
Details

Summary

StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flask_principal.Permission.__init__() with zero Needs when their config flags are unset. Both flags defaulted to False in code prior to the fix, so this was the state of any Lemur install that hadn't explicitly opted in.

Flask-Principal's Permission.allows() returns True whenever self.needs is empty. The .can() gate therefore passes for every authenticated identity, including the lowest-privilege role Lemur ships (read-only).

A user holding only read-only can create root Certificate Authorities, create and edit notifications (an SSRF sink), create domain entries, and upload arbitrary certificates. These classes are the sole authorization check on those endpoints.

Root Cause

# lemur/auth/permissions.py
class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", False)
        if requires_admin:
            super().__init__(RoleNeed("admin"))
        else:
            super().__init__()              # empty Need set

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", False)
        if strict_role_enforcement:
            needs = [RoleNeed("admin"), RoleNeed("operator")]
            super().__init__(*needs)
        else:
            super().__init__()              # empty Need set

flask_principal.Permission.allows() (upstream, v0.4.0):

def allows(self, identity):
    if self.needs and not self.needs.intersection(identity.provides):
        return False
    ...
    return True

When self.needs == set(), the first guard is falsy and is skipped. excludes is also empty, so allows() returns True for any identity. AuthenticatedResource (the parent class for these views) sets method_decorators = [login_required], which checks authentication only, no role. So the permission .can() is the only authorization layer in front of these endpoints.

Affected Endpoints

Views whose only authorization check is StrictRolePermission().can() or AuthorityCreatorPermission().can():

Method Path Source
POST /api/1/authorities lemur/authorities/views.py:231
POST /api/1/certificates/upload lemur/certificates/views.py:651
POST /api/1/pending_certificates/\/upload lemur/pending_certificates/views.py:545
POST /api/1/notifications lemur/notifications/views.py:227
PUT/DEL /api/1/notifications/\ lemur/notifications/views.py:370,384
POST /api/1/domains lemur/domains/views.py:131

POST /api/1/authorities is gated by AuthorityCreatorPermission().can() and StrictRolePermission().can(); both have empty Needs by default. The other rows are gated by StrictRolePermission().can() alone.

Note on scope: PUT /api/1/authorities/<id> also references StrictRolePermission, but its gate is AuthorityPermission(...).can() and StrictRolePermission().can(). AuthorityPermission is constructed with non-empty Needs (RoleNeed("admin") plus authority-scoped needs), so that endpoint is not bypassable by a read-only user and is excluded from this report.

Impact

A user holding only the read-only role can:

  1. Create root Certificate Authorities. CA cert and private key are persisted in Lemur's DB with the attacker as owner. Any internal trust store that pins Lemur-managed roots can now be signed against by the attacker.
  2. Upload arbitrary certificates via /certificates/upload, including attacker-supplied keys with destinations such as AWS push.
  3. Create or modify notifications, which reach an SSRF sink (see related finding F3, Slack notification webhook).
  4. Mark arbitrary domains as sensitive, manipulating Lemur's domain registry and the cert-issuance approval path.

Combined with any low-privilege credential leak (phished employee, leaked SSO token) or insider access, this is a pivot from "any authenticated identity" to control of the PKI issuance plane.

Remediation

The config flag defaults for ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT were changed from False to True. Restrictive role enforcement is now active on all default installs without requiring explicit configuration.

class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", True)
        ...

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", True)
        ...

Note: The opt-out branches (empty Needs) remain in the code. Operators who explicitly set ADMIN_ONLY_AUTHORITY_CREATION = False or LEMUR_STRICT_ROLE_ENFORCEMENT = False in their config will reintroduce the bypass. These flags should be left unset or set to True.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.9.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48508"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T18:48:39Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`StrictRolePermission` and `AuthorityCreatorPermission` in `lemur/auth/permissions.py` call `flask_principal.Permission.__init__()` with zero `Need`s when their config flags are unset. Both flags defaulted to `False` in code prior to the fix, so this was the state of any Lemur install that hadn\u0027t explicitly opted in.\n\nFlask-Principal\u0027s `Permission.allows()` returns `True` whenever `self.needs` is empty. The `.can()` gate therefore passes for every authenticated identity, including the lowest-privilege role Lemur ships (`read-only`).\n\nA user holding only `read-only` can create root Certificate Authorities, create and edit notifications (an SSRF sink), create domain entries, and upload arbitrary certificates. These classes are the sole authorization check on those endpoints.\n\n## Root Cause\n\n```python\n# lemur/auth/permissions.py\nclass AuthorityCreatorPermission(Permission):\n    def __init__(self):\n        requires_admin = current_app.config.get(\"ADMIN_ONLY_AUTHORITY_CREATION\", False)\n        if requires_admin:\n            super().__init__(RoleNeed(\"admin\"))\n        else:\n            super().__init__()              # empty Need set\n\nclass StrictRolePermission(Permission):\n    def __init__(self):\n        strict_role_enforcement = current_app.config.get(\"LEMUR_STRICT_ROLE_ENFORCEMENT\", False)\n        if strict_role_enforcement:\n            needs = [RoleNeed(\"admin\"), RoleNeed(\"operator\")]\n            super().__init__(*needs)\n        else:\n            super().__init__()              # empty Need set\n```\n\n`flask_principal.Permission.allows()` (upstream, v0.4.0):\n\n```python\ndef allows(self, identity):\n    if self.needs and not self.needs.intersection(identity.provides):\n        return False\n    ...\n    return True\n```\n\nWhen `self.needs == set()`, the first guard is falsy and is skipped. `excludes` is also empty, so `allows()` returns `True` for any identity. `AuthenticatedResource` (the parent class for these views) sets `method_decorators = [login_required]`, which checks authentication only, no role. So the permission `.can()` is the only authorization layer in front of these endpoints.\n\n## Affected Endpoints\n\nViews whose only authorization check is `StrictRolePermission().can()` or `AuthorityCreatorPermission().can()`:\n\n| Method   | Path                                      | Source                                  |\n|----------|-------------------------------------------|-----------------------------------------|\n| POST     | /api/1/authorities                        | lemur/authorities/views.py:231          |\n| POST     | /api/1/certificates/upload                | lemur/certificates/views.py:651         |\n| POST     | /api/1/pending_certificates/\\\u003cid\u003e/upload  | lemur/pending_certificates/views.py:545 |\n| POST     | /api/1/notifications                      | lemur/notifications/views.py:227        |\n| PUT/DEL  | /api/1/notifications/\\\u003cid\u003e                | lemur/notifications/views.py:370,384    |\n| POST     | /api/1/domains                            | lemur/domains/views.py:131              |\n\n`POST /api/1/authorities` is gated by `AuthorityCreatorPermission().can() and StrictRolePermission().can()`; both have empty Needs by default. The other rows are gated by `StrictRolePermission().can()` alone.\n\nNote on scope: `PUT /api/1/authorities/\u003cid\u003e` also references `StrictRolePermission`, but its gate is `AuthorityPermission(...).can() and StrictRolePermission().can()`. `AuthorityPermission` is constructed with non-empty Needs (`RoleNeed(\"admin\")` plus authority-scoped needs), so that endpoint is not bypassable by a `read-only` user and is excluded from this report.\n\n## Impact\n\nA user holding only the `read-only` role can:\n\n1. Create root Certificate Authorities. CA cert and private key are persisted in Lemur\u0027s DB with the attacker as owner. Any internal trust store that pins Lemur-managed roots can now be signed against by the attacker.\n2. Upload arbitrary certificates via `/certificates/upload`, including attacker-supplied keys with destinations such as AWS push.\n3. Create or modify notifications, which reach an SSRF sink (see related finding F3, Slack notification webhook).\n4. Mark arbitrary domains as `sensitive`, manipulating Lemur\u0027s domain registry and the cert-issuance approval path.\n\nCombined with any low-privilege credential leak (phished employee, leaked SSO token) or insider access, this is a pivot from \"any authenticated identity\" to control of the PKI issuance plane.\n\n## Remediation\n\nThe config flag defaults for `ADMIN_ONLY_AUTHORITY_CREATION` and `LEMUR_STRICT_ROLE_ENFORCEMENT` were changed from `False` to `True`. Restrictive role enforcement is now active on all default installs without requiring explicit configuration.\n\n```python\nclass AuthorityCreatorPermission(Permission):\n    def __init__(self):\n        requires_admin = current_app.config.get(\"ADMIN_ONLY_AUTHORITY_CREATION\", True)\n        ...\n\nclass StrictRolePermission(Permission):\n    def __init__(self):\n        strict_role_enforcement = current_app.config.get(\"LEMUR_STRICT_ROLE_ENFORCEMENT\", True)\n        ...\n```\n\n**Note:** The opt-out branches (empty Needs) remain in the code. Operators who explicitly set `ADMIN_ONLY_AUTHORITY_CREATION = False` or `LEMUR_STRICT_ROLE_ENFORCEMENT = False` in their config will reintroduce the bypass. These flags should be left unset or set to `True`.",
  "id": "GHSA-qcqw-jwxc-2hqg",
  "modified": "2026-06-25T18:48:39Z",
  "published": "2026-06-25T18:48:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-qcqw-jwxc-2hqg"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Netflix/lemur"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur has an authorization bypass in StrictRolePermission / AuthorityCreatorPermission"
}

GHSA-QCX4-X6Q7-8HC3

Vulnerability from github – Published: 2023-02-13 12:30 – Updated: 2023-02-24 09:30
VLAI
Details

Dell Unisphere for PowerMax vApp, VASA Provider vApp, and Solution Enabler vApp version 10.0.0.5 and below contains an authorization bypass vulnerability, allowing users to perform actions in which they are not authorized.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-34397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-13T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dell Unisphere for PowerMax vApp, VASA Provider vApp, and Solution Enabler vApp version 10.0.0.5 and below contains an authorization bypass vulnerability, allowing users to perform actions in which they are not authorized.",
  "id": "GHSA-qcx4-x6q7-8hc3",
  "modified": "2023-02-24T09:30:29Z",
  "published": "2023-02-13T12:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34397"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000207177/dsa-2022-340-dell-unisphere-for-powermax-dell-unisphere-for-powermax-vapp-dell-solutions-enabler-vapp-dell-unisphere-360-dell-vasa-provider-vapp-and-dell-powermax-emb-mgmt-security-update-for-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QCXW-QQMJ-C5FP

Vulnerability from github – Published: 2021-12-10 00:00 – Updated: 2021-12-15 00:01
VLAI
Details

IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 9.7, 10.1, 10.5, 11.1, and 11.5 could allow a user with DBADM authority to access other databases and read or modify files. IBM X-Force ID: 199914.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-29678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-09T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 9.7, 10.1, 10.5, 11.1, and 11.5 could allow a user with DBADM authority to access other databases and read or modify files. IBM X-Force ID: 199914.",
  "id": "GHSA-qcxw-qqmj-c5fp",
  "modified": "2021-12-15T00:01:40Z",
  "published": "2021-12-10T00:00:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29678"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/199914"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220114-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6523806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QF2F-QH6P-7V89

Vulnerability from github – Published: 2026-07-21 20:13 – Updated: 2026-07-21 20:13
VLAI
Summary
Gitea CVE-2026-20800 sibling endpoints not covered: revoked user still reads private repo objects via `/api/v1/user/starred` and private issue titles via `/api/v1/user/times`
Details

Summary

CVE-2026-20800 fixed private-info leakage to revoked users only for the notification endpoint. Two sibling endpoints that return data keyed on the caller's own relationship still do not re-check repo access at output time: - GET /api/v1/user/starredgetStarredRepos() computes a per-repo permission but still lists every starred repo (no filtering), so the full repo object (full_name, private, clone_url, ssh_url) of a now-inaccessible private repo is returned. - GET /api/v1/user/timesListMyTrackedTimes() queries by UserID only and LoadAttributes brings in the issue (title, state), leaking private issue titles after revocation.

Steps to reproduce

Using the provided reproduction materials, as a revoked user: 1. Control: GET /api/v1/repos/admin/starred-test404. 2. GET /api/v1/user/starred → leaks admin/starred-test, private:true, clone_url. 3. GET /api/v1/user/times → leaks issue.title = "SECRET: …", state.

(Runtime-confirmed on gitea/gitea:1.25.4. Oracle = planted sentinel title; no real secret exfiltrated.)

Impact

A former collaborator can enumerate private repos they starred and read private issue titles they logged time on, indefinitely after access revocation. Metadata only (no repo content / comment bodies). Low.

Suggested remediation

  1. getStarredRepos: drop (or minimally redact) repos where permission.HasAnyUnitAccessOrPublicAccess() is false for the caller.
  2. ListMyTrackedTimes: filter tracked-time entries by current repo access.
  3. Optionally clear a user's stars / time entries for a private repo on revocation.

Credit

Reported as part of an incomplete-patch measurement study (responsible disclosure).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59766"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:13:03Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nCVE-2026-20800 fixed private-info leakage to revoked users only for the notification endpoint. Two\nsibling endpoints that return data keyed on the caller\u0027s own relationship still do not re-check repo\naccess at output time:\n- `GET /api/v1/user/starred` \u2014 `getStarredRepos()` computes a per-repo permission but still lists every\n  starred repo (no filtering), so the full repo object (`full_name`, `private`, `clone_url`, `ssh_url`)\n  of a now-inaccessible private repo is returned.\n- `GET /api/v1/user/times` \u2014 `ListMyTrackedTimes()` queries by `UserID` only and `LoadAttributes` brings\n  in the issue (`title`, `state`), leaking private issue titles after revocation.\n\n## Steps to reproduce\nUsing the provided reproduction materials, as a revoked user:\n1. Control: `GET /api/v1/repos/admin/starred-test` \u2192 **404**.\n2. `GET /api/v1/user/starred` \u2192 leaks `admin/starred-test`, `private:true`, `clone_url`.\n3. `GET /api/v1/user/times` \u2192 leaks `issue.title = \"SECRET: \u2026\"`, `state`.\n\n(Runtime-confirmed on `gitea/gitea:1.25.4`. Oracle = planted sentinel title; no real secret exfiltrated.)\n\n## Impact\nA former collaborator can enumerate private repos they starred and read private issue titles they logged\ntime on, indefinitely after access revocation. Metadata only (no repo content / comment bodies). Low.\n\n## Suggested remediation\n1. `getStarredRepos`: drop (or minimally redact) repos where `permission.HasAnyUnitAccessOrPublicAccess()`\n   is false for the caller.\n2. `ListMyTrackedTimes`: filter tracked-time entries by current repo access.\n3. Optionally clear a user\u0027s stars / time entries for a private repo on revocation.\n\n## Credit\nReported as part of an incomplete-patch measurement study (responsible disclosure).",
  "id": "GHSA-qf2f-qh6p-7v89",
  "modified": "2026-07-21T20:13:03Z",
  "published": "2026-07-21T20:13:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-qf2f-qh6p-7v89"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea CVE-2026-20800 sibling endpoints not covered: revoked user still reads private repo objects via `/api/v1/user/starred` and private issue titles via `/api/v1/user/times`"
}

GHSA-QF48-QFV4-JJM9

Vulnerability from github – Published: 2026-03-31 23:53 – Updated: 2026-05-08 15:36
VLAI
Summary
OpenClaw: Feishu extension resolveUploadInput bypasses file-system sandbox and allows arbitrary file reads via upload_image
Details

Summary

Feishu upload path resolution could read files outside the configured localRoots sandbox before handing them to the upload path.

Impact

A tool caller constrained to workspace or localRoots paths could exfiltrate arbitrary host files through Feishu upload actions.

Affected Component

extensions/feishu/src/docx.ts

Fixed Versions

  • Affected: >= 2026.2.6, <= 2026.3.24
  • Patched: >= 2026.3.28
  • Latest stable 2026.3.28 contains the fix.

Fix

Fixed by commit 764394c78b (fix: enforce localRoots sandbox on Feishu docx upload file reads).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.2.6"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-31T23:53:00Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nFeishu upload path resolution could read files outside the configured localRoots sandbox before handing them to the upload path.\n\n## Impact\n\nA tool caller constrained to workspace or localRoots paths could exfiltrate arbitrary host files through Feishu upload actions.\n\n## Affected Component\n\n`extensions/feishu/src/docx.ts`\n\n## Fixed Versions\n\n- Affected: `\u003e= 2026.2.6, \u003c= 2026.3.24`\n- Patched: `\u003e= 2026.3.28`\n- Latest stable `2026.3.28` contains the fix.\n\n## Fix\n\nFixed by commit `764394c78b` (`fix: enforce localRoots sandbox on Feishu docx upload file reads`).",
  "id": "GHSA-qf48-qfv4-jjm9",
  "modified": "2026-05-08T15:36:30Z",
  "published": "2026-03-31T23:53:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qf48-qfv4-jjm9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41363"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/764394c78b6c22c5b53c3cd132d27ff36340bf45"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-arbitrary-file-read-via-feishu-upload-image-parameter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Feishu extension resolveUploadInput bypasses file-system sandbox and allows arbitrary file reads via upload_image"
}

GHSA-QF5C-HFC7-449F

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

Intent redirection vulnerability in Samsung Health prior to version 6.16 allows attacker to execute privileged action.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25401"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-11T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Intent redirection vulnerability in Samsung Health prior to version 6.16 allows attacker to execute privileged action.",
  "id": "GHSA-qf5c-hfc7-449f",
  "modified": "2022-07-31T00:00:57Z",
  "published": "2022-05-24T19:05:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25401"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QF6R-242X-WPG6

Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-12-03 18:31
VLAI
Details

python_book V1.0 is vulnerable to Incorrect Access Control, which allows attackers to obtain sensitive information of users with different IDs by modifying the ID parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50650"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-15T16:15:36Z",
    "severity": "HIGH"
  },
  "details": "python_book V1.0 is vulnerable to Incorrect Access Control, which allows attackers to obtain sensitive information of users with different IDs by modifying the ID parameter.",
  "id": "GHSA-qf6r-242x-wpg6",
  "modified": "2024-12-03T18:31:02Z",
  "published": "2024-11-15T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50650"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yllxx03/CVE/blob/main/python_book/BrokenAccessControl.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yllxx03/CVE/tree/main/CVE-2024-50650"
    }
  ],
  "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"
    }
  ]
}

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.