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.

7155 vulnerabilities reference this CWE, most recent first.

GHSA-H55P-3MG5-547M

Vulnerability from github – Published: 2023-03-31 18:30 – Updated: 2025-02-18 18:33
VLAI
Details

An authentication bypass vulnerability in the Password Reset component of Gladinet CentreStack before 13.5.9808 allows remote attackers to set a new password for any valid user account, without needing the previous known password, resulting in a full authentication bypass.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-26829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-31T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An authentication bypass vulnerability in the Password Reset component of Gladinet CentreStack before 13.5.9808 allows remote attackers to set a new password for any valid user account, without needing the previous known password, resulting in a full authentication bypass.",
  "id": "GHSA-h55p-3mg5-547m",
  "modified": "2025-02-18T18:33:03Z",
  "published": "2023-03-31T18:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26829"
    },
    {
      "type": "WEB",
      "url": "https://www.whiteoaksecurity.com/blog/centrestack-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H56G-4QW7-2MXG

Vulnerability from github – Published: 2026-07-21 21:50 – Updated: 2026-07-21 21:50
VLAI
Summary
Gitea: Public-only API token restriction is not enforced on team API routes
Details

Summary

Gitea's /api/v1/teams/{id} API routes do not correctly enforce the public-only access token restriction.

A public-only token is intended to limit API access to public repositories and public organizations. However, several team API routes continue to return private team repository metadata and private team activity feed entries when called with a public-only token.

Details

The /api/v1/teams/{teamid} route group uses:

orgAssignment(false, true)

This loads ctx.Org.Team, but does not load ctx.Org.Organization.

The checkTokenPublicOnly middleware checks organization visibility through ctx.Org.Organization. When ctx.Org.Organization is nil, the organization visibility check silently passes.

In addition, the team repository handlers return repositories without applying repository-level public-only filtering:

repo_model.GetTeamRepositories(...)
convert.ToRepo(...)

They do not call:

ctx.TokenCanAccessRepo(repo)

The team activity feed handler also sets:

IncludePrivate: true

but does not apply:

opts.ApplyPublicOnly(ctx.PublicOnly)

PoC

Vulnerability is verified on latest gitea release (1.26.2) and nightly build. Frist, create a public-only organization-scoped token for a user who is a member of a team in a private org with private repositories:

image

image

Use the returned token to request team repositories:

image

Expected result: Private repositories should be hidden or rejected for a public-only token. Actual result: Private team repository metadata is returned.

The team activity feed endpoint can be tested similarly:

image

Impact

A public-only token can access private team resources that should be hidden from that token.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gitea.dev"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:50:11Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nGitea\u0027s `/api/v1/teams/{id}` API routes do not correctly enforce the `public-only` access token restriction.\n\nA `public-only` token is intended to limit API access to public repositories and public organizations. However, several team API routes continue to return private team repository metadata and private team activity feed entries when called with a `public-only` token.\n\n### Details\n\nThe `/api/v1/teams/{teamid}` route group uses:\n\n```go\norgAssignment(false, true)\n```\n\nThis loads `ctx.Org.Team`, but does not load `ctx.Org.Organization`.\n\nThe `checkTokenPublicOnly` middleware checks organization visibility through `ctx.Org.Organization`. When `ctx.Org.Organization` is nil, the organization visibility check silently passes.\n\nIn addition, the team repository handlers return repositories without applying repository-level `public-only` filtering:\n\n```go\nrepo_model.GetTeamRepositories(...)\nconvert.ToRepo(...)\n```\n\nThey do not call:\n\n```go\nctx.TokenCanAccessRepo(repo)\n```\n\nThe team activity feed handler also sets:\n\n```go\nIncludePrivate: true\n```\n\nbut does not apply:\n\n```go\nopts.ApplyPublicOnly(ctx.PublicOnly)\n```\n\n### PoC\n\nVulnerability is verified on latest gitea release (1.26.2) and nightly build.\nFrist, create a `public-only` organization-scoped token for a user who is a member of a team in a private org with private repositories:\n\n\u003cimg width=\"1075\" height=\"577\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4a01d0ab-f67c-47c9-94b1-e74ddd77d7bc\" /\u003e\n\n\u003cimg width=\"649\" height=\"375\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b5d91962-088e-40f4-bc51-88a17946e6d8\" /\u003e\n\nUse the returned token to request team repositories:\n\n\u003cimg width=\"1728\" height=\"190\" alt=\"image\" src=\"https://github.com/user-attachments/assets/0f15878f-5806-431d-958c-ffb39bf7c1e9\" /\u003e\n\nExpected result: Private repositories should be hidden or rejected for a public-only token.\nActual result: Private team repository metadata is returned.\n\nThe team activity feed endpoint can be tested similarly:\n\n\u003cimg width=\"1728\" height=\"237\" alt=\"image\" src=\"https://github.com/user-attachments/assets/280a5ddf-ad14-4769-86a8-1fdad858287c\" /\u003e\n\n### Impact\n\nA `public-only` token can access private team resources that should be hidden from that token.",
  "id": "GHSA-h56g-4qw7-2mxg",
  "modified": "2026-07-21T21:50:11Z",
  "published": "2026-07-21T21:50:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-h56g-4qw7-2mxg"
    },
    {
      "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: Public-only API token restriction is not enforced on team API routes"
}

GHSA-H56W-FXVX-4R52

Vulnerability from github – Published: 2026-09-09 15:35 – Updated: 2026-09-09 15:35
VLAI
Details

Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens*) with only 'web' and 'auth:web' middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user's own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-86755"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T14:17:24Z",
    "severity": "MODERATE"
  },
  "details": "Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport\u0027s auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens*) with only \u0027web\u0027 and \u0027auth:web\u0027 middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user\u0027s own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware.",
  "id": "GHSA-h56w-fxvx-4r52",
  "modified": "2026-09-09T15:35:13Z",
  "published": "2026-09-09T15:35:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-76pf-qf59-ff3q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86755"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/snipe-it-4.2.0-through-8.6.3-permission-bypass-via-oauth"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-H56X-6FP7-752G

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

In getDefaultSmsPackage of RoleManagerService.java, there is a possible way to get information about the default sms app of a different device user due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11 Android-10Android ID: A-177927831

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-0686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-06T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In getDefaultSmsPackage of RoleManagerService.java, there is a possible way to get information about the default sms app of a different device user due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11 Android-10Android ID: A-177927831",
  "id": "GHSA-h56x-6fp7-752g",
  "modified": "2022-07-13T00:00:59Z",
  "published": "2022-05-24T19:16:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0686"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2021-09-01"
    }
  ],
  "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-H595-VWHC-3XWX

Vulnerability from github – Published: 2024-03-01 18:30 – Updated: 2024-08-02 15:36
VLAI
Summary
Apache Archiva Incorrect Authorization vulnerability
Details

** UNSUPPORTED WHEN ASSIGNED **

Incorrect Authorization vulnerability in Apache Archiva: a vulnerability in Apache Archiva allows an unauthenticated attacker to modify account data, potentially leading to account takeover.

This issue affects Apache Archiva: from 2.0.0.

As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.

NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.archiva:archiva"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "last_affected": "2.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-27139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-01T20:12:19Z",
    "nvd_published_at": "2024-03-01T16:15:46Z",
    "severity": "HIGH"
  },
  "details": "** UNSUPPORTED WHEN ASSIGNED **\n\nIncorrect Authorization vulnerability in Apache Archiva: a vulnerability in Apache Archiva allows an unauthenticated attacker to modify account data, potentially leading to account takeover.\n\nThis issue affects Apache Archiva: from 2.0.0.\n\nAs this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.\n\nNOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
  "id": "GHSA-h595-vwhc-3xwx",
  "modified": "2024-08-02T15:36:12Z",
  "published": "2024-03-01T18:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27139"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/archiva"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/qr8b7r86p1hkn0dc0q827s981kf1bgd8"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/03/01/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Archiva Incorrect Authorization vulnerability"
}

GHSA-H5CR-94CG-HXMR

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

TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile’s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-16630"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-20T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "TI\u2019s BLE stack caches and reuses the LTK\u2019s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile\u2019s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission.",
  "id": "GHSA-h5cr-94cg-hxmr",
  "modified": "2022-05-24T22:28:41Z",
  "published": "2022-05-24T22:28:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16630"
    },
    {
      "type": "WEB",
      "url": "https://www.usenix.org/system/files/sec20-zhang-yue.pdf"
    },
    {
      "type": "WEB",
      "url": "http://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/3.20.00.68/exports/changelog.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H5F6-RR42-3R8X

Vulnerability from github – Published: 2025-01-16 21:30 – Updated: 2025-02-03 21:31
VLAI
Details

An access control issue in the component form2alg.cgi of D-Link 816A2_FWv1.10CNB05_R1B011D88210 allows unauthenticated attackers to set the agl service of the device via a crafted POST request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-57681"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-16T19:15:29Z",
    "severity": "MODERATE"
  },
  "details": "An access control issue in the component form2alg.cgi of D-Link 816A2_FWv1.10CNB05_R1B011D88210 allows unauthenticated attackers to set the agl service of the device via a crafted POST request.",
  "id": "GHSA-h5f6-rr42-3r8x",
  "modified": "2025-02-03T21:31:49Z",
  "published": "2025-01-16T21:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57681"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abcdefg-png/IoT-vulnerable/blob/main/Unauthorized_Vulnerability/D-Link/DIR-816/form2alg.md"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H5G2-X4VR-85QJ

Vulnerability from github – Published: 2022-05-24 22:01 – Updated: 2022-12-13 03:30
VLAI
Details

IBM Security Guardium Big Data Intelligence (SonarG) 4.0 discloses sensitive information to unauthorized users. The information can be used to mount further attacks on the system. IBM X-Force ID: 161037.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-4311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-29T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Guardium Big Data Intelligence (SonarG) 4.0 discloses sensitive information to unauthorized users. The information can be used to mount further attacks on the system. IBM X-Force ID: 161037.",
  "id": "GHSA-h5g2-x4vr-85qj",
  "modified": "2022-12-13T03:30:44Z",
  "published": "2022-05-24T22:01:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4311"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/161037"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/1098069"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H5HG-H7RR-GPF3

Vulnerability from github – Published: 2026-04-03 03:18 – Updated: 2026-04-06 19:42
VLAI
Summary
OpenClaw: Node browser proxy `allowProfiles` bypass through persistent profile mutation and runtime profile selection
Details

Summary

Node browser proxy allowProfiles bypass through persistent profile mutation and runtime profile selection

Current Maintainer Triage

  • Status: open
  • Normalized severity: high
  • Assessment: Real released allowProfiles bypass through profile mutation and runtime profile selection, fixed and shipped in v2026.3.22+, so keep open for publish rather than close.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.13-1
  • Patched versions: >= 2026.3.22
  • First stable tag containing the fix: v2026.3.22

Fix Commit(s)

  • eac93507c36ccd0c359fba18fa466ef6448be8a5 — 2026-03-23T00:56:44-07:00

Release Process Note

  • The fix is already present in released version 2026.3.22.
  • This draft looks ready for final maintainer disposition or publication, not additional code-fix work.

Thanks @smaeljaish771 for reporting.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.13-1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T03:18:10Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nNode browser proxy `allowProfiles` bypass through persistent profile mutation and runtime profile selection\n\n## Current Maintainer Triage\n- Status: open\n- Normalized severity: high\n- Assessment: Real released allowProfiles bypass through profile mutation and runtime profile selection, fixed and shipped in v2026.3.22+, so keep open for publish rather than close.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.13-1`\n- Patched versions: `\u003e= 2026.3.22`\n- First stable tag containing the fix: `v2026.3.22`\n\n## Fix Commit(s)\n- `eac93507c36ccd0c359fba18fa466ef6448be8a5` \u2014 2026-03-23T00:56:44-07:00\n\n## Release Process Note\n- The fix is already present in released version `2026.3.22`.\n- This draft looks ready for final maintainer disposition or publication, not additional code-fix work.\n\nThanks @smaeljaish771 for reporting.",
  "id": "GHSA-h5hg-h7rr-gpf3",
  "modified": "2026-04-06T19:42:23Z",
  "published": "2026-04-03T03:18:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-h5hg-h7rr-gpf3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/eac93507c36ccd0c359fba18fa466ef6448be8a5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Node browser proxy `allowProfiles` bypass through persistent profile mutation and runtime profile selection"
}

GHSA-H5JH-RP76-Q242

Vulnerability from github – Published: 2025-01-29 15:31 – Updated: 2025-02-06 19:54
VLAI
Summary
RuoYi has insecure permissions
Details

Insecure permissions in RuoYi v4.8.0 allows authenticated attackers to escalate privileges by assigning themselves higher level roles.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.ruoyi:ruoyi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-57438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-276",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-29T19:20:33Z",
    "nvd_published_at": "2025-01-29T15:15:17Z",
    "severity": "MODERATE"
  },
  "details": "Insecure permissions in RuoYi v4.8.0 allows authenticated attackers to escalate privileges by assigning themselves higher level roles.",
  "id": "GHSA-h5jh-rp76-q242",
  "modified": "2025-02-06T19:54:08Z",
  "published": "2025-01-29T15:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57438"
    },
    {
      "type": "PACKAGE",
      "url": "https://gitee.com/y_project/RuoYi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/peccc/restful_vul/blob/main/ruoyi_insecure_role_assignments/ruoyi_insecure_role_assignments.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yangzongzhuan/RuoYi"
    },
    {
      "type": "WEB",
      "url": "https://ruoyi.vip"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RuoYi has insecure permissions"
}
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