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.

5548 vulnerabilities reference this CWE, most recent first.

GHSA-Q9XQ-P65J-27M8

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

Improper component protection vulnerability in Samsung Internet prior to version 14.0.1.62 allows untrusted applications to execute arbitrary activity in specific condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-11T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper component protection vulnerability in Samsung Internet prior to version 14.0.1.62 allows untrusted applications to execute arbitrary activity in specific condition.",
  "id": "GHSA-q9xq-p65j-27m8",
  "modified": "2022-05-24T19:05:07Z",
  "published": "2022-05-24T19:05:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25418"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QC36-X95H-7J53

Vulnerability from github – Published: 2026-03-13 15:48 – Updated: 2026-04-06 22:35
VLAI
Summary
OpenClaw: Unrecognized script runners could bypass `system.run` approval integrity
Details

Summary

In affected versions of openclaw, node-host system.run approvals did not bind a mutable file operand for some script runners, including forms such as tsx and jiti. An attacker could obtain approval for a benign script-runner command, rewrite the referenced script on disk, and have the modified code execute under the already approved run context.

Impact

Deployments that rely on node-host system.run approvals for script integrity could execute rewritten local code after operator approval. This can lead to unintended local code execution as the OpenClaw runtime user.

Affected Packages and Versions

  • Package: openclaw (npm)
  • Affected versions: < 2026.3.11
  • Fixed in: 2026.3.11

Technical Details

The approval planner only tracked mutable script operands for a hardcoded set of interpreters and runtime forms. Commands such as tsx ./run.ts and jiti ./run.ts fell through without a bound file snapshot, so the final pre-execution revalidation step was skipped.

Fix

OpenClaw now fails closed for approval-backed interpreter and runtime commands unless it can bind exactly one concrete local file operand, and it extends direct-file binding coverage for additional runtime forms. The fix shipped in openclaw@2026.3.11.

Workarounds

Upgrade to 2026.3.11 or later.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32978"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T15:48:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nIn affected versions of `openclaw`, node-host `system.run` approvals did not bind a mutable file operand for some script runners, including forms such as `tsx` and `jiti`. An attacker could obtain approval for a benign script-runner command, rewrite the referenced script on disk, and have the modified code execute under the already approved run context.\n\n## Impact\nDeployments that rely on node-host `system.run` approvals for script integrity could execute rewritten local code after operator approval. This can lead to unintended local code execution as the OpenClaw runtime user.\n\n## Affected Packages and Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c 2026.3.11`\n- Fixed in: `2026.3.11`\n\n## Technical Details\nThe approval planner only tracked mutable script operands for a hardcoded set of interpreters and runtime forms. Commands such as `tsx ./run.ts` and `jiti ./run.ts` fell through without a bound file snapshot, so the final pre-execution revalidation step was skipped.\n\n## Fix\nOpenClaw now fails closed for approval-backed interpreter and runtime commands unless it can bind exactly one concrete local file operand, and it extends direct-file binding coverage for additional runtime forms. The fix shipped in `openclaw@2026.3.11`.\n\n## Workarounds\nUpgrade to `2026.3.11` or later.",
  "id": "GHSA-qc36-x95h-7j53",
  "modified": "2026-04-06T22:35:57Z",
  "published": "2026-03-13T15:48:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qc36-x95h-7j53"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32978"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-approval-bypass-via-unrecognized-script-runners"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Unrecognized script runners could bypass `system.run` approval integrity"
}

GHSA-QC88-643M-WHJM

Vulnerability from github – Published: 2024-10-28 21:30 – Updated: 2026-04-02 21:31
VLAI
Details

The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.1, macOS Sequoia 15, macOS Sonoma 14.7.1. A sandboxed app may be able to access sensitive user data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-40855"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-28T21:15:04Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.1, macOS Sequoia 15, macOS Sonoma 14.7.1. A sandboxed app may be able to access sensitive user data.",
  "id": "GHSA-qc88-643m-whjm",
  "modified": "2026-04-02T21:31:56Z",
  "published": "2024-10-28T21:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40855"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121238"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121249"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121568"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121570"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Oct/12"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Oct/13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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-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"
}

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.