Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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

7172 vulnerabilities reference this CWE, most recent first.

GHSA-MM5G-P9FC-43HM

Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2022-07-13 00:01
VLAI
Details

An improper access control vulnerability in FortiProxy SSL VPN portal 2.0.0, 1.2.9 and below versions may allow an authenticated, remote attacker to access internal service such as the ZebOS Shell on the FortiProxy appliance through the Quick Connection functionality.

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": [],
  "aliases": [
    "CVE-2021-22128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-04T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An improper access control vulnerability in FortiProxy SSL VPN portal 2.0.0, 1.2.9 and below versions may allow an authenticated, remote attacker to access internal service such as the ZebOS Shell on the FortiProxy appliance through the Quick Connection functionality.",
  "id": "GHSA-mm5g-p9fc-43hm",
  "modified": "2022-07-13T00:01:08Z",
  "published": "2022-05-24T17:43:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22128"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/advisory/FG-IR-20-235"
    }
  ],
  "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"
    }
  ]
}

GHSA-MM78-FGQ8-6PGR

Vulnerability from github – Published: 2026-03-12 14:49 – Updated: 2026-03-12 14:49
VLAI
Summary
StudioCMS S3 Storage Manager Authorization Bypass via Missing `await` on Async Auth Check
Details

Summary

The S3 storage manager's isAuthorized() function is declared async (returns Promise<boolean>) but is called without await in both the POST and PUT handlers. Since a Promise object is always truthy in JavaScript, !isAuthorized(type) always evaluates to false, completely bypassing the authorization check. Any authenticated user with the lowest visitor role can upload, delete, rename, and list all files in the S3 bucket.

Details

The isAuthorized function is typed as returning Promise<boolean> in packages/studiocms/src/handlers/storage-manager/definitions.ts:88:

export type ParsedContext = {
    getJson: () => Promise<ContextJsonBody>;
    getArrayBuffer: () => Promise<ArrayBuffer>;
    getHeader: (name: string) => string | null;
    isAuthorized: (type?: AuthorizationType) => Promise<boolean>;  // async
};

Both context drivers implement it as async — packages/studiocms/src/handlers/storage-manager/core/effectify-astro-context.ts:32:

isAuthorized: async (type) => {
    switch (type) {
        case 'headers': {
            // ... token verification ...
            const isEditor = level >= UserPermissionLevel.editor;
            if (!isEditor) return false;
            return true;
        }
        default: {
            const isEditor = locals.StudioCMS.security?.userPermissionLevel.isEditor || false;
            return isEditor;
        }
    }
},

But in the S3 storage manager, it's called without await — packages/@studiocms/s3-storage/src/s3-storage-manager.ts:200:

if (authRequiredActions.includes(jsonBody.action) && !isAuthorized(type)) {
    return { data: { error: 'Unauthorized' }, status: 401 };
}

And again at line 372 (PUT handler):

if (!isAuthorized(type)) {
    return { data: { error: 'Unauthorized' }, status: 401 };
}

isAuthorized(type) returns a Promise object. !Promise{...} is always false because a Promise is truthy. The 401 response is never returned.

Execution flow: 1. Visitor-role user sends POST to /studiocms_api/integrations/storage/manager 2. AstroLocalsMiddleware verifies session exists — passes (visitor is logged in) 3. Handler calls !isAuthorized('locals') → evaluates !Promise{...} = false 4. Authorization check is skipped entirely 5. Visitor performs the requested storage operation

PoC

# 1. Log in as a visitor-role user and obtain session cookie

# 2. List all files in S3 bucket (should require editor+)
curl -X POST 'http://localhost:4321/studiocms_api/integrations/storage/manager' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{"action":"list","prefix":""}'

# Expected: 401 Unauthorized
# Actual: 200 with full bucket listing

# 3. Upload a file as visitor (should require editor+)
curl -X PUT 'http://localhost:4321/studiocms_api/integrations/storage/manager' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/octet-stream' \
  -H 'x-storage-key: malicious/payload.html' \
  --data-binary '<h1>Uploaded by visitor</h1>'

# Expected: 401 Unauthorized
# Actual: 200 File uploaded

# 4. Delete a file as visitor (should require editor+)
curl -X POST 'http://localhost:4321/studiocms_api/integrations/storage/manager' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{"action":"delete","key":"important/document.pdf"}'

# Expected: 401 Unauthorized
# Actual: 200 File deleted

Impact

  • Any authenticated visitor gains full S3 storage management (upload, delete, rename, list) — capabilities restricted to editor role and above
  • Attacker can delete arbitrary files from the S3 bucket, causing data loss
  • Attacker can list all files and generate presigned download URLs, exposing all stored content
  • Attacker can upload arbitrary files or rename existing ones, replacing legitimate content with malicious payloads

Recommended Fix

Add await to both isAuthorized() calls in packages/@studiocms/s3-storage/src/s3-storage-manager.ts:

// POST handler (line 200) — before:
if (authRequiredActions.includes(jsonBody.action) && !isAuthorized(type)) {

// After:
if (authRequiredActions.includes(jsonBody.action) && !(await isAuthorized(type))) {

// PUT handler (line 372) — before:
if (!isAuthorized(type)) {

// After:
if (!(await isAuthorized(type))) {
Severity
7.6 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@studiocms/s3-storage"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-12T14:49:30Z",
    "nvd_published_at": "2026-03-11T21:16:16Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe S3 storage manager\u0027s `isAuthorized()` function is declared `async` (returns `Promise\u003cboolean\u003e`) but is called without `await` in both the POST and PUT handlers. Since a Promise object is always truthy in JavaScript, `!isAuthorized(type)` always evaluates to `false`, completely bypassing the authorization check. Any authenticated user with the lowest `visitor` role can upload, delete, rename, and list all files in the S3 bucket.\n\n## Details\n\nThe `isAuthorized` function is typed as returning `Promise\u003cboolean\u003e` in `packages/studiocms/src/handlers/storage-manager/definitions.ts:88`:\n\n```typescript\nexport type ParsedContext = {\n    getJson: () =\u003e Promise\u003cContextJsonBody\u003e;\n    getArrayBuffer: () =\u003e Promise\u003cArrayBuffer\u003e;\n    getHeader: (name: string) =\u003e string | null;\n    isAuthorized: (type?: AuthorizationType) =\u003e Promise\u003cboolean\u003e;  // async\n};\n```\n\nBoth context drivers implement it as `async` \u2014 `packages/studiocms/src/handlers/storage-manager/core/effectify-astro-context.ts:32`:\n\n```typescript\nisAuthorized: async (type) =\u003e {\n    switch (type) {\n        case \u0027headers\u0027: {\n            // ... token verification ...\n            const isEditor = level \u003e= UserPermissionLevel.editor;\n            if (!isEditor) return false;\n            return true;\n        }\n        default: {\n            const isEditor = locals.StudioCMS.security?.userPermissionLevel.isEditor || false;\n            return isEditor;\n        }\n    }\n},\n```\n\nBut in the S3 storage manager, it\u0027s called without `await` \u2014 `packages/@studiocms/s3-storage/src/s3-storage-manager.ts:200`:\n\n```typescript\nif (authRequiredActions.includes(jsonBody.action) \u0026\u0026 !isAuthorized(type)) {\n    return { data: { error: \u0027Unauthorized\u0027 }, status: 401 };\n}\n```\n\nAnd again at line 372 (PUT handler):\n\n```typescript\nif (!isAuthorized(type)) {\n    return { data: { error: \u0027Unauthorized\u0027 }, status: 401 };\n}\n```\n\n`isAuthorized(type)` returns a `Promise` object. `!Promise{...}` is always `false` because a Promise is truthy. The 401 response is never returned.\n\n**Execution flow:**\n1. Visitor-role user sends POST to `/studiocms_api/integrations/storage/manager`\n2. `AstroLocalsMiddleware` verifies session exists \u2014 passes (visitor is logged in)\n3. Handler calls `!isAuthorized(\u0027locals\u0027)` \u2192 evaluates `!Promise{...}` = `false`\n4. Authorization check is skipped entirely\n5. Visitor performs the requested storage operation\n\n## PoC\n\n```bash\n# 1. Log in as a visitor-role user and obtain session cookie\n\n# 2. List all files in S3 bucket (should require editor+)\ncurl -X POST \u0027http://localhost:4321/studiocms_api/integrations/storage/manager\u0027 \\\n  -H \u0027Cookie: studiocms-session=\u003cvisitor-session-token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"action\":\"list\",\"prefix\":\"\"}\u0027\n\n# Expected: 401 Unauthorized\n# Actual: 200 with full bucket listing\n\n# 3. Upload a file as visitor (should require editor+)\ncurl -X PUT \u0027http://localhost:4321/studiocms_api/integrations/storage/manager\u0027 \\\n  -H \u0027Cookie: studiocms-session=\u003cvisitor-session-token\u003e\u0027 \\\n  -H \u0027Content-Type: application/octet-stream\u0027 \\\n  -H \u0027x-storage-key: malicious/payload.html\u0027 \\\n  --data-binary \u0027\u003ch1\u003eUploaded by visitor\u003c/h1\u003e\u0027\n\n# Expected: 401 Unauthorized\n# Actual: 200 File uploaded\n\n# 4. Delete a file as visitor (should require editor+)\ncurl -X POST \u0027http://localhost:4321/studiocms_api/integrations/storage/manager\u0027 \\\n  -H \u0027Cookie: studiocms-session=\u003cvisitor-session-token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"action\":\"delete\",\"key\":\"important/document.pdf\"}\u0027\n\n# Expected: 401 Unauthorized\n# Actual: 200 File deleted\n```\n\n## Impact\n\n- Any authenticated visitor gains full S3 storage management (upload, delete, rename, list) \u2014 capabilities restricted to editor role and above\n- Attacker can delete arbitrary files from the S3 bucket, causing data loss\n- Attacker can list all files and generate presigned download URLs, exposing all stored content\n- Attacker can upload arbitrary files or rename existing ones, replacing legitimate content with malicious payloads\n\n## Recommended Fix\n\nAdd `await` to both `isAuthorized()` calls in `packages/@studiocms/s3-storage/src/s3-storage-manager.ts`:\n\n```typescript\n// POST handler (line 200) \u2014 before:\nif (authRequiredActions.includes(jsonBody.action) \u0026\u0026 !isAuthorized(type)) {\n\n// After:\nif (authRequiredActions.includes(jsonBody.action) \u0026\u0026 !(await isAuthorized(type))) {\n\n// PUT handler (line 372) \u2014 before:\nif (!isAuthorized(type)) {\n\n// After:\nif (!(await isAuthorized(type))) {\n```",
  "id": "GHSA-mm78-fgq8-6pgr",
  "modified": "2026-03-12T14:49:30Z",
  "published": "2026-03-12T14:49:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-mm78-fgq8-6pgr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32101"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withstudiocms/studiocms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "StudioCMS S3 Storage Manager Authorization Bypass via Missing `await` on Async Auth Check"
}

GHSA-MM7C-RHG6-QR4R

Vulnerability from github – Published: 2026-06-16 23:41 – Updated: 2026-06-16 23:41
VLAI
Summary
Gitea: Authorization Bypass via "Allow edits from maintainers" allows unauthorized commits to any readable repo
Details

Summary

Any authenticated low-privilege user with read access to a repository can push arbitrary commits directly to that repository, bypassing all write-access checks.

Vulnerability

Gitea's "Allow edits from maintainers" PR option can be abused via reverse-fork PRs:

  1. The web UI PR-create endpoint binds allow_maintainer_edit=true without verifying that the submitter has write access to the HEAD repository.
  2. Gitea allows creating a PR where BASE = attacker's fork and HEAD = upstream target. The attacker is "maintainer" of the BASE (their own fork), so the flag is set against the upstream HEAD.
  3. On git push over HTTP/SSH, Gitea relaxes the required access mode to Read when SupportProcReceive is enabled (routers/web/repo/githttp.go, routers/private/serv.go) and defers enforcement to the pre-receive hook.
  4. The pre-receive hook calls CanMaintainerWriteToBranch (models/issues/pull_list.go), which finds the malicious PR, sees AllowMaintainerEdit=true, and checks whether the pusher has write access to the BASE repo. Since BASE is the attacker's own fork, the check passes and the push is authorized against the upstream.

Exploitation

  1. Attacker forks the target repository.
  2. Attacker visits the web compare endpoint and creates a PR with BASE = their_fork, HEAD = upstream, and "Allow edits from maintainers" checked.
  3. Attacker clones their fork, makes a commit, and runs git push <upstream_url> <branch> — the push is accepted.

Reproduction

python3 poc.py --repo http://gitea:3000/victim/repo --user attacker --password attacker_pass

poc.py

Expected output:

[+] target: victim/my_repo  default branch: main
[*] forking -> attacker/my_repo_pocfork (202)
[+] fork ready
[+] malicious PR created (BASE=attacker fork, HEAD=upstream)

remote: . Processing 1 references
remote: Processed 1 references in total
To http://192.168.101.20:3000/victim/my_repo.git
   e5c07b3..9a0b884  main -> main

[+] latest commit on victim/my_repo@main: 'PoC: unauthorized commit via maintainer-edit bypass'
[+] CONFIRMED: unauthorized push to upstream succeeded.

A PWNED.txt file will appear on the target repo's default branch, committed by the attacker who has no write access.

Impact

Full repository compromise. Any logged-in user can backdoor any repository they can read, including all public repositories on the instance.

Suggested Fix

Two independent checks are missing; both should be added for defense in depth:

  1. At PR creation: before setting AllowMaintainerEdit = true, verify the submitter has write access to the HEAD repository.
  2. In CanMaintainerWriteToBranch: verify that the PR's HEAD repo matches the repository being pushed to, and that the PR was opened by a legitimate owner/writer of the HEAD repository. Do not trust AllowMaintainerEdit solely based on BASE write access.
Severity
8.5 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.26.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T23:41:01Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAny authenticated low-privilege user with read access to a repository can push arbitrary commits directly to that repository, bypassing all write-access checks.\n\n## Vulnerability\n\nGitea\u0027s \"Allow edits from maintainers\" PR option can be abused via reverse-fork PRs:\n\n1. The web UI PR-create endpoint binds `allow_maintainer_edit=true` **without** verifying that the submitter has write access to the HEAD repository.\n2. Gitea allows creating a PR where **BASE = attacker\u0027s fork** and **HEAD = upstream target**. The attacker is \"maintainer\" of the BASE (their own fork), so the flag is set against the upstream HEAD.\n3. On `git push` over HTTP/SSH, Gitea relaxes the required access mode to `Read` when `SupportProcReceive` is enabled ([`routers/web/repo/githttp.go`](https://github.com/go-gitea/gitea/blob/v1.25.5/routers/web/repo/githttp.go#L189), [`routers/private/serv.go`](https://github.com/go-gitea/gitea/blob/v1.25.5/routers/private/serv.go#L337)) and defers enforcement to the pre-receive hook.\n4. The pre-receive hook calls [`CanMaintainerWriteToBranch`](https://github.com/go-gitea/gitea/blob/v1.25.5/models/issues/pull_list.go#L72) (`models/issues/pull_list.go`), which finds the malicious PR, sees `AllowMaintainerEdit=true`, and checks whether the pusher has write access to the **BASE** repo. Since BASE is the attacker\u0027s own fork, the check passes and the push is authorized against the upstream.\n\n## Exploitation\n\n1. Attacker forks the target repository.\n2. Attacker visits the web compare endpoint and creates a PR with `BASE = their_fork`, `HEAD = upstream`, and \"Allow edits from maintainers\" checked.\n3. Attacker clones their fork, makes a commit, and runs `git push \u003cupstream_url\u003e \u003cbranch\u003e` \u2014 the push is accepted.\n\n## Reproduction\n\n```bash\npython3 poc.py --repo http://gitea:3000/victim/repo --user attacker --password attacker_pass\n```\n[poc.py](https://github.com/user-attachments/files/26641541/poc.py)\n\nExpected output:\n```\n[+] target: victim/my_repo  default branch: main\n[*] forking -\u003e attacker/my_repo_pocfork (202)\n[+] fork ready\n[+] malicious PR created (BASE=attacker fork, HEAD=upstream)\n\nremote: . Processing 1 references\nremote: Processed 1 references in total\nTo http://192.168.101.20:3000/victim/my_repo.git\n   e5c07b3..9a0b884  main -\u003e main\n\n[+] latest commit on victim/my_repo@main: \u0027PoC: unauthorized commit via maintainer-edit bypass\u0027\n[+] CONFIRMED: unauthorized push to upstream succeeded.\n```\n\nA `PWNED.txt` file will appear on the target repo\u0027s default branch, committed by the attacker who has no write access.\n\n\n## Impact\n\nFull repository compromise. Any logged-in user can backdoor any repository they can read, including all public repositories on the instance.\n\n## Suggested Fix\n\nTwo independent checks are missing; both should be added for defense in depth:\n\n1. **At PR creation:** before setting `AllowMaintainerEdit = true`, verify the submitter has write access to the **HEAD** repository.\n2. **In `CanMaintainerWriteToBranch`:** verify that the PR\u0027s HEAD repo matches the repository being pushed to, and that the PR was opened by a legitimate owner/writer of the HEAD repository. Do not trust `AllowMaintainerEdit` solely based on BASE write access.",
  "id": "GHSA-mm7c-rhg6-qr4r",
  "modified": "2026-06-16T23:41:01Z",
  "published": "2026-06-16T23:41:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-mm7c-rhg6-qr4r"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Authorization Bypass via \"Allow edits from maintainers\" allows unauthorized commits to any readable repo"
}

GHSA-MM7J-MHHJ-HJ36

Vulnerability from github – Published: 2026-05-08 00:31 – Updated: 2026-05-13 01:37
VLAI
Summary
OpenStack Cyborg uses rule:allow (check_str='@') as the default policy for multiple API endpoints
Details

OpenStack Cyborg before 16.0.1 uses rule:allow (check_str='@') as the default policy for multiple API endpoints. This unconditionally authorizes any request carrying a valid Keystone token regardless of roles, project membership, or scope. An authenticated user with zero role assignments can complete various actions such as reprogramming FPGA bitstreams on arbitrary compute nodes via agent RPC.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "openstack-cyborg"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "16.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-13T01:37:14Z",
    "nvd_published_at": "2026-05-07T22:16:34Z",
    "severity": "HIGH"
  },
  "details": "OpenStack Cyborg before 16.0.1 uses rule:allow (check_str=\u0027@\u0027) as the default policy for multiple API endpoints. This unconditionally authorizes any request carrying a valid Keystone token regardless of roles, project membership, or scope. An authenticated user with zero role assignments can complete various actions such as reprogramming FPGA bitstreams on arbitrary compute nodes via agent RPC.",
  "id": "GHSA-mm7j-mhhj-hj36",
  "modified": "2026-05-13T01:37:14Z",
  "published": "2026-05-08T00:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40213"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/openstack-cyborg/+bug/2143263"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/cyborg"
    },
    {
      "type": "WEB",
      "url": "https://security.openstack.org/ossa/OSSA-2026-011.html"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/05/07/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenStack Cyborg uses rule:allow (check_str=\u0027@\u0027) as the default policy for multiple API endpoints"
}

GHSA-MM7M-92G8-7M47

Vulnerability from github – Published: 2026-06-16 13:48 – Updated: 2026-06-16 13:48
VLAI
Summary
Nuxt: Route-rule middleware bypass via case-sensitivity mismatch between vue-router and the routeRules matcher
Details

Impact

Nuxt looks up routeRules for the current navigation by calling getRouteRules({ path: to.path }) from the page-router plugin and the no-pages router plugin. The compiled routeRules matcher (built on rou3) performs case-sensitive matching, while vue-router is configured with its default sensitive: false and matches paths case-insensitively.

The two routers therefore disagree on which rules apply to a given request path: vue-router still matches the page record for /Admin/dashboard, but the routeRules lookup for the same path returns no match. Any appMiddleware declared via routeRules is never added to the middleware set and never runs, on both SSR and client navigations. The same path skips other path-keyed route rules in the same way (ssr, redirect, appLayout, and the prerender / payload hints used client-side).

For applications using routeRules with appMiddleware as an authorization gate (a documented pattern), an attacker can flip the case of any static segment in a protected URL (for example /Admin/dashboard instead of /admin/dashboard) to render the protected page with the middleware skipped. The server returns the fully server-rendered page including any useFetch / useAsyncData results captured during SSR.

This is an instance of CWE-178 (Improper Handling of Case Sensitivity) leading to CWE-863 (Incorrect Authorization) for apps that treat appMiddleware as an authorization boundary.

Mitigating factors

  • Only affects apps that use routeRules.appMiddleware. The more idiomatic definePageMeta({ middleware }) is bound to the matched route record and is unaffected.
  • Nuxt route middleware is documented as an app-layer concern, not a server-side auth boundary; well-built apps enforce authorization again at the API / data-fetching layer.
  • Apps that explicitly set router.options.sensitive = true are not affected.

Patches

Fixed in nuxt@4.4.7 (commit 07e39cd6) and backported to nuxt@3.21.7 (commit 3f3e3fa7). The fix normalizes the path used for routeRules lookups so it matches vue-router's default case-insensitive semantics.

Workarounds

Until you can upgrade, you can mitigate by either:

  1. Setting router.options.sensitive = true so vue-router matches case-sensitively (this changes route-matching behaviour app-wide).
  2. Moving security-critical middleware off routeRules.appMiddleware and onto definePageMeta({ middleware: [...] }) on the protected page components, which is bound to the matched record.
  3. Enforcing authorization at the API / data-fetching layer (which you should be doing in any case).

Credit

Reported by Anthropic / Claude through Anthropic's coordinated vulnerability disclosure process. Reference: ANT-2026-9FSEBYMC.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.11.0"
            },
            {
              "fixed": "3.21.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T13:48:31Z",
    "nvd_published_at": "2026-06-12T15:16:31Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nNuxt looks up `routeRules` for the current navigation by calling\n`getRouteRules({ path: to.path })` from the page-router plugin and the\nno-pages router plugin. The compiled `routeRules` matcher (built on\n`rou3`) performs case-sensitive matching, while vue-router is configured\nwith its default `sensitive: false` and matches paths case-insensitively.\n\nThe two routers therefore disagree on which rules apply to a given\nrequest path: vue-router still matches the page record for\n`/Admin/dashboard`, but the `routeRules` lookup for the same path\nreturns no match. Any `appMiddleware` declared via `routeRules` is never\nadded to the middleware set and never runs, on both SSR and client\nnavigations. The same path skips other path-keyed route rules in the\nsame way (`ssr`, `redirect`, `appLayout`, and the prerender / payload\nhints used client-side).\n\nFor applications using `routeRules` with `appMiddleware` as an\nauthorization gate (a documented pattern), an attacker can flip the case\nof any static segment in a protected URL (for example `/Admin/dashboard`\ninstead of `/admin/dashboard`) to render the protected page with the\nmiddleware skipped. The server returns the fully server-rendered page\nincluding any `useFetch` / `useAsyncData` results captured during SSR.\n\nThis is an instance of CWE-178 (Improper Handling of Case Sensitivity)\nleading to CWE-863 (Incorrect Authorization) for apps that treat\n`appMiddleware` as an authorization boundary.\n\n## Mitigating factors\n\n- Only affects apps that use `routeRules.appMiddleware`. The more\n  idiomatic `definePageMeta({ middleware })` is bound to the matched\n  route record and is unaffected.\n- Nuxt route middleware is documented as an app-layer concern, not a\n  server-side auth boundary; well-built apps enforce authorization\n  again at the API / data-fetching layer.\n- Apps that explicitly set `router.options.sensitive = true` are not\n  affected.\n\n## Patches\n\nFixed in `nuxt@4.4.7` (commit [`07e39cd6`](https://github.com/nuxt/nuxt/commit/07e39cd6f26e407b4192b7865bd17bc44536b9bb)) and backported to `nuxt@3.21.7` (commit [`3f3e3fa7`](https://github.com/nuxt/nuxt/commit/3f3e3fa7b5eec8e495f4f8ce0a54813a8875a11e)). The fix normalizes the path used for `routeRules` lookups so it matches vue-router\u0027s default case-insensitive semantics.\n\n## Workarounds\n\nUntil you can upgrade, you can mitigate by either:\n\n1. Setting `router.options.sensitive = true` so vue-router matches\n   case-sensitively (this changes route-matching behaviour app-wide).\n2. Moving security-critical middleware off `routeRules.appMiddleware`\n   and onto `definePageMeta({ middleware: [...] })` on the protected\n   page components, which is bound to the matched record.\n3. Enforcing authorization at the API / data-fetching layer (which you\n   should be doing in any case).\n\n## Credit\n\nReported by Anthropic / Claude through Anthropic\u0027s coordinated\nvulnerability disclosure process. Reference: ANT-2026-9FSEBYMC.",
  "id": "GHSA-mm7m-92g8-7m47",
  "modified": "2026-06-16T13:48:31Z",
  "published": "2026-06-16T13:48:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-mm7m-92g8-7m47"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53721"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/07e39cd6f26e407b4192b7865bd17bc44536b9bb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/3f3e3fa7b5eec8e495f4f8ce0a54813a8875a11e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuxt/nuxt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nuxt: Route-rule middleware bypass via case-sensitivity mismatch between vue-router and the routeRules matcher"
}

GHSA-MM84-MW5G-8QMH

Vulnerability from github – Published: 2026-07-28 09:31 – Updated: 2026-07-28 09:31
VLAI
Details

A low privileged remote attacker can perform privileged configuration changes reserved for the administrator level including permission management due to incorrect authorization.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-14167"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-28T09:16:41Z",
    "severity": "HIGH"
  },
  "details": "A low privileged remote attacker can perform privileged configuration changes reserved for the administrator level including permission management due to incorrect authorization.",
  "id": "GHSA-mm84-mw5g-8qmh",
  "modified": "2026-07-28T09:31:29Z",
  "published": "2026-07-28T09:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14167"
    },
    {
      "type": "WEB",
      "url": "https://www.certvde.com/en/advisories/VDE-2026-076"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-MM88-H44M-W2GP

Vulnerability from github – Published: 2026-07-14 00:31 – Updated: 2026-07-14 00:31
VLAI
Details

OpenClaw Feishu tools (npm package @openclaw/feishu) in versions <= 2026.6.6 could ignore per-account disablement. A lower-trust caller or a configured input path could perform actions that should have required a stronger authorization or policy check, resulting in unauthorized operations. The issue is fixed in version 2026.6.9. Impact depends on the operator's configuration and whether lower-trust input can reach the affected feature.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-62187"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-13T22:16:49Z",
    "severity": "HIGH"
  },
  "details": "OpenClaw Feishu tools (npm package @openclaw/feishu) in versions \u003c= 2026.6.6 could ignore per-account disablement. A lower-trust caller or a configured input path could perform actions that should have required a stronger authorization or policy check, resulting in unauthorized operations. The issue is fixed in version 2026.6.9. Impact depends on the operator\u0027s configuration and whether lower-trust input can reach the affected feature.",
  "id": "GHSA-mm88-h44m-w2gp",
  "modified": "2026-07-14T00:31:03Z",
  "published": "2026-07-14T00:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-2q7j-2vhx-56g8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62187"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-feishu-tools-authorization-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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-MMFJ-QGGC-GFMR

Vulnerability from github – Published: 2026-09-09 03:30 – Updated: 2026-09-10 21:31
VLAI
Details

Incorrect authorization in WebUI in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to bypass system access restrictions into a privileged page via a crafted HTML page. (Chromium security severity: Medium)

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-87584"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T01:17:16Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in WebUI in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to bypass system access restrictions into a privileged page via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-mmfj-qggc-gfmr",
  "modified": "2026-09-10T21:31:27Z",
  "published": "2026-09-09T03:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87584"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0808145027.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/537466493"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MMG7-3C66-C28Q

Vulnerability from github – Published: 2025-12-01 18:30 – Updated: 2025-12-01 18:30
VLAI
Details

Incorrect Authorization vulnerability in Data Illusion Zumbrunn NGSurvey allows any logged-in user to obtain the private information of any other user.

Critical information retrieved: * APIKEY (1 year user Session) * RefreshToken (10 minutes user Session) * Password hashed with bcrypt * User IP * Email * Full Name

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-13829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-01T16:15:51Z",
    "severity": "HIGH"
  },
  "details": "Incorrect Authorization vulnerability in Data Illusion Zumbrunn NGSurvey allows any logged-in user to obtain the private information of any other user.\n\n\n\n Critical information retrieved: \n  *  APIKEY (1 year user Session)\n  *  RefreshToken (10 minutes user Session)\n  *  Password hashed with bcrypt\n  *  User IP\n  *  Email\n  *  Full Name",
  "id": "GHSA-mmg7-3c66-c28q",
  "modified": "2025-12-01T18:30:37Z",
  "published": "2025-12-01T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13829"
    },
    {
      "type": "WEB",
      "url": "https://docs.ngsurvey.com/installation-setup/change-log#id-3.6.17-2025-05-28"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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:Y/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-MMJP-G55X-JMRW

Vulnerability from github – Published: 2026-09-08 21:34 – Updated: 2026-09-08 21:34
VLAI
Details

Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. An attacker with high privileges could leverage this vulnerability to bypass security measures and gain unauthorized write access, causing a limited disruption to availability. Exploitation of this issue does not require user interaction. Scope is changed.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-77111"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T19:19:41Z",
    "severity": "HIGH"
  },
  "details": "Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. An attacker with high privileges could leverage this vulnerability to bypass security measures and gain unauthorized write access, causing a limited disruption to availability. Exploitation of this issue does not require user interaction. Scope is changed.",
  "id": "GHSA-mmjp-g55x-jmrw",
  "modified": "2026-09-08T21:34:17Z",
  "published": "2026-09-08T21:34:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77111"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb26-138.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:H",
      "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.

← Back to the CWE list