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.

6929 vulnerabilities reference this CWE, most recent first.

GHSA-9R5X-FJV3-Q6H4

Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2024-05-21 14:35
Withdrawn 2024-05-21 VLAI
Summary
Duplicate Advisory: Incorrect Access Control in github.com/nats-io/jwt and github.com/nats-io/nats-server/v2
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-62mh-w5cv-p88c (for github.com/nats-io/jwt) and GHSA-j756-f273-xhp4 (for github.com/nats-io/nats-server). This link is maintained to preserve external references.

Original Description

NATS Server (github.com/nats-io/nats-server/v2/server) 2.x before 2.2.0 and JWT library (github.com/nats-io/jwt/v2) before 2.0.1 have Incorrect Access Control because Import Token bindings are mishandled.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/jwt/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.3-0.20210314221642-a826c77dc9d2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-12T20:34:10Z",
    "nvd_published_at": "2021-03-16T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-62mh-w5cv-p88c (for github.com/nats-io/jwt) and GHSA-j756-f273-xhp4 (for github.com/nats-io/nats-server). This link is maintained to preserve external references.\n\n## Original Description\nNATS Server (github.com/nats-io/nats-server/v2/server) 2.x before 2.2.0 and JWT library (github.com/nats-io/jwt/v2) before 2.0.1 have Incorrect Access Control because Import Token bindings are mishandled.",
  "id": "GHSA-9r5x-fjv3-q6h4",
  "modified": "2024-05-21T14:35:21Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3127"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/jwt/pull/149"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/jwt/pull/149/commits/a826c77dc9d2671c961b75ceefdb439c41029866"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/commit/423b79440c80c863de9f4e20548504e6c5d5e403"
    },
    {
      "type": "WEB",
      "url": "https://advisories.nats.io/CVE/CVE-2021-3127.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Incorrect Access Control in github.com/nats-io/jwt and github.com/nats-io/nats-server/v2",
  "withdrawn": "2024-05-21T14:35:21Z"
}

GHSA-9R5X-WG6M-X2RC

Vulnerability from github – Published: 2026-06-16 23:40 – Updated: 2026-06-16 23:40
VLAI
Summary
Gitea: OAuth2 access token scope enforcement bypass via HTTP Basic authentication
Details

Summary

Gitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only read:user can use the same token as Authorization: Basic base64(<token>:x-oauth-basic) and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.

Details

Root cause: services/auth/basic.go accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context:

// services/auth/basic.go
if uid != 0 {
    store.GetData()["LoginMethod"] = OAuth2TokenMethodName
    store.GetData()["IsApiToken"] = true   // scope is NOT set
    return u, nil
}

The scope enforcement middleware in routers/api/v1/api.go exits early when ApiTokenScope is absent:

// routers/api/v1/api.go — tokenRequiresScopes
scope, scopeExists := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
if ctx.Data["IsApiToken"] != true || !scopeExists {
    return   //<- exits without checking scope, all actions permitted
}

When a token arrives via Bearer, ApiTokenScope is populated and scope checks apply normally. When the same token arrives via Basic auth, ApiTokenScope is never set, so tokenRequiresScopes returns immediately and no scope is enforced.

Suggested fix: When an OAuth2 access token is accepted in services/auth/basic.go, populate ApiTokenScope in the request context identically to the Bearer-token OAuth2 path.

PoC

  1. Create an OAuth2 application in Gitea.
  2. Authorize it as a normal user with scope read:user only.
  3. Take the resulting access token and call a write endpoint both ways:

Bearer | correctly blocked:

Authorization: Bearer <token>
PATCH /api/v1/user/settings  ->  403 Forbidden

Basic | bypass:

Authorization: Basic base64(<token>:x-oauth-basic)
PATCH /api/v1/user/settings  ->  200 OK

All verified bypass endpoints using a read:user-only token:

Endpoint Bearer Basic
PATCH /api/v1/user/settings 403 200
POST /api/v1/user/emails 403 200
POST /api/v1/user/repos 403 200
PATCH /api/v1/repos/{owner}/{repo} 403 200
DELETE /api/v1/repos/{owner}/{repo} 403 200

The bypass respects the user's normal repository permissions, it does not grant access to repositories the user cannot otherwise reach, and does not escalate to admin.

Impact

Any OAuth2 application with any restricted scope can silently operate beyond its granted permissions by switching from Bearer to Basic auth. An attacker who obtains a token (e.g. via a malicious OAuth2 app a user authorized) can:

  • Modify the victim's profile and settings
  • Add attacker-controlled email addresses to the victim's account
  • Create repositories as the victim
  • Modify or delete the victim's private repositories

The entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.

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

{
  "affected": [
    {
      "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-28699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T23:40:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nGitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only `read:user` can use the same token as `Authorization: Basic base64(\u003ctoken\u003e:x-oauth-basic)` and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.\n\n### Details\n\n**Root cause:** `services/auth/basic.go` accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context:\n\n```go\n// services/auth/basic.go\nif uid != 0 {\n    store.GetData()[\"LoginMethod\"] = OAuth2TokenMethodName\n    store.GetData()[\"IsApiToken\"] = true   // scope is NOT set\n    return u, nil\n}\n```\n\nThe scope enforcement middleware in `routers/api/v1/api.go` exits early when `ApiTokenScope` is absent:\n\n```go\n// routers/api/v1/api.go \u2014 tokenRequiresScopes\nscope, scopeExists := ctx.Data[\"ApiTokenScope\"].(auth_model.AccessTokenScope)\nif ctx.Data[\"IsApiToken\"] != true || !scopeExists {\n    return   //\u003c- exits without checking scope, all actions permitted\n}\n```\n\nWhen a token arrives via Bearer, `ApiTokenScope` is populated and scope checks apply normally. When the same token arrives via Basic auth, `ApiTokenScope` is never set, so `tokenRequiresScopes` returns immediately and no scope is enforced.\n\n**Suggested fix:** When an OAuth2 access token is accepted in `services/auth/basic.go`, populate `ApiTokenScope` in the request context identically to the Bearer-token OAuth2 path.\n\n### PoC\n\n1. Create an OAuth2 application in Gitea.\n2. Authorize it as a normal user with scope `read:user` only.\n3. Take the resulting access token and call a write endpoint both ways:\n\n**Bearer | correctly blocked:**\n```\nAuthorization: Bearer \u003ctoken\u003e\nPATCH /api/v1/user/settings  -\u003e  403 Forbidden\n```\n\n**Basic | bypass:**\n```\nAuthorization: Basic base64(\u003ctoken\u003e:x-oauth-basic)\nPATCH /api/v1/user/settings  -\u003e  200 OK\n```\n\n**All verified bypass endpoints using a `read:user`-only token:**\n\n| Endpoint | Bearer | Basic |\n|---|---|---|\n| `PATCH /api/v1/user/settings` | 403 | 200 |\n| `POST /api/v1/user/emails` | 403 | 200 |\n| `POST /api/v1/user/repos` | 403 | 200 |\n| `PATCH /api/v1/repos/{owner}/{repo}` | 403 | 200 |\n| `DELETE /api/v1/repos/{owner}/{repo}` | 403 | 200 |\n\nThe bypass respects the user\u0027s normal repository permissions, it does not grant access to repositories the user cannot otherwise reach, and does not escalate to admin.\n\n### Impact\n\nAny OAuth2 application with any restricted scope can silently operate beyond its granted permissions by switching from Bearer to Basic auth. An attacker who obtains a token (e.g. via a malicious OAuth2 app a user authorized) can:\n\n- Modify the victim\u0027s profile and settings\n- Add attacker-controlled email addresses to the victim\u0027s account\n- Create repositories as the victim\n- Modify or delete the victim\u0027s private repositories\n\nThe entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.",
  "id": "GHSA-9r5x-wg6m-x2rc",
  "modified": "2026-06-16T23:40:34Z",
  "published": "2026-06-16T23:40:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-9r5x-wg6m-x2rc"
    },
    {
      "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:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: OAuth2 access token scope enforcement bypass via HTTP Basic authentication"
}

GHSA-9R69-X87G-5765

Vulnerability from github – Published: 2026-06-15 15:31 – Updated: 2026-06-15 15:31
VLAI
Details

WordPress Ultimate Product Catalog 3.8.6 contains an arbitrary file upload vulnerability that allows authenticated users with contributor, editor, author, or administrator roles to upload malicious files by exploiting the custom fields functionality. Attackers can upload PHP shells through the Products tab custom file field and access them via the upcp-product-file-uploads directory to execute arbitrary code on the server.

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-2016-20075"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T14:16:30Z",
    "severity": "HIGH"
  },
  "details": "WordPress Ultimate Product Catalog 3.8.6 contains an arbitrary file upload vulnerability that allows authenticated users with contributor, editor, author, or administrator roles to upload malicious files by exploiting the custom fields functionality. Attackers can upload PHP shells through the Products tab custom file field and access them via the upcp-product-file-uploads directory to execute arbitrary code on the server.",
  "id": "GHSA-9r69-x87g-5765",
  "modified": "2026-06-15T15:31:32Z",
  "published": "2026-06-15T15:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-20075"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/40012"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wordpress-ultimate-product-catalog-arbitrary-file-upload-rce"
    },
    {
      "type": "WEB",
      "url": "http://www.EtoileWebDesign.com"
    }
  ],
  "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-9R83-7XQ3-VJRP

Vulnerability from github – Published: 2026-09-26 03:30 – Updated: 2026-09-26 03:30
VLAI
Details

OpenClaw (npm package 'openclaw') before 2026.8.1 fails to revoke memory tool access when an operator hot-disables memory configuration. Existing memory_search and memory_get tool instances retain the enabled configuration captured at creation time because the execution-time resolver treats explicit disablement like an unavailable configuration snapshot and restores the stale authority. As a result, during an already-running agent turn the model can continue searching and reading durable memory after the operator revoked that access, for the remainder of that run. Exploitation requires memory to be disabled while a previously created memory tool remains active. The issue is fixed in 2026.8.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-100539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-26T03:16:59Z",
    "severity": "LOW"
  },
  "details": "OpenClaw (npm package \u0027openclaw\u0027) before 2026.8.1 fails to revoke memory tool access when an operator hot-disables memory configuration. Existing memory_search and memory_get tool instances retain the enabled configuration captured at creation time because the execution-time resolver treats explicit disablement like an unavailable configuration snapshot and restores the stale authority. As a result, during an already-running agent turn the model can continue searching and reading durable memory after the operator revoked that access, for the remainder of that run. Exploitation requires memory to be disabled while a previously created memory tool remains active. The issue is fixed in 2026.8.1.",
  "id": "GHSA-9r83-7xq3-vjrp",
  "modified": "2026-09-26T03:30:24Z",
  "published": "2026-09-26T03:30:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-chr6-w4m5-57fv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100539"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-before-2026.8.1-memory-access-control-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:N/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-9R89-C96G-GF22

Vulnerability from github – Published: 2023-02-18 00:31 – Updated: 2023-02-28 21:30
VLAI
Details

TOTOLINK A720R V4.1.5cu.532_ B20210610 is vulnerable to Incorrect Access Control.

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-23064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-17T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "TOTOLINK A720R V4.1.5cu.532_ B20210610 is vulnerable to Incorrect Access Control.",
  "id": "GHSA-9r89-c96g-gf22",
  "modified": "2023-02-28T21:30:16Z",
  "published": "2023-02-18T00:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23064"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shellpei/TOTOLINK-Unauthorized/blob/main/CVE-2023-23064"
    }
  ],
  "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-9R8R-X3VG-6XH4

Vulnerability from github – Published: 2026-05-15 21:31 – Updated: 2026-06-09 00:01
Withdrawn 2026-06-09 VLAI
Summary
Duplicate Advisory: phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-jrc5-w569-h7h5. This link is maintained to preserve external references.

Original Description

phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpMyFAQ/phpMyFAQ"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpMyFAQ"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T20:53:52Z",
    "nvd_published_at": "2026-05-15T19:17:01Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-jrc5-w569-h7h5. This link is maintained to preserve external references.\n\n### Original Description\nphpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.",
  "id": "GHSA-9r8r-x3vg-6xh4",
  "modified": "2026-06-09T00:01:42Z",
  "published": "2026-05-15T21:31:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-jrc5-w569-h7h5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45009"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thorsten/phpMyFAQ"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/phpmyfaq-insufficient-authorization-check-in-admin-api-endpoints"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/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"
    }
  ],
  "summary": "Duplicate Advisory: phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check",
  "withdrawn": "2026-06-09T00:01:42Z"
}

GHSA-9RPJ-V7HF-VV2W

Vulnerability from github – Published: 2026-06-17 18:01 – Updated: 2026-07-20 21:11
VLAI
Summary
Open WebUI: Authenticated users can target arbitrary configured Ollama backends via unguarded url_idx path parameter
Details

Summary

Several direct, index-addressed Ollama proxy routes accept a caller-supplied url_idx path parameter and use it as a raw index into the admin-configured OLLAMA_BASE_URLS list. Access control on these routes validates only whether the user may use the requested model, never which backend the request is routed to. Any authenticated user can append an arbitrary url_idx to force their request onto an Ollama backend they were never authorized to reach, including internal, higher-privilege, or explicitly admin-disabled backends.

Affected endpoints

All indexed Ollama routes that resolve the backend through get_ollama_url():

POST /ollama/api/chat/{url_idx}
POST /ollama/api/generate/{url_idx}
POST /ollama/api/embed/{url_idx}
POST /ollama/api/embeddings/{url_idx}
POST /ollama/v1/chat/completions/{url_idx}
POST /ollama/v1/completions/{url_idx}
POST /ollama/v1/messages/{url_idx}
POST /ollama/v1/responses/{url_idx}

Root cause

backend/open_webui/routers/ollama.py — get_ollama_url() consults the model-to-backend allow-list (OLLAMA_MODELS[model]["urls"]) only when url_idx is omitted. When the caller supplies url_idx, that mapping is skipped and the value is used directly as an index:

async def get_ollama_url(request: Request, model: str, url_idx: Optional[int] = None):
    if url_idx is None:
        models = request.app.state.OLLAMA_MODELS
        if model not in models:
            raise HTTPException(...)
        url_idx = random.choice(models[model].get("urls", []))
    url = request.app.state.config.OLLAMA_BASE_URLS[url_idx]   # caller-controlled, no authz
    return url, url_idx

The outbound request is then sent to that backend using the backend's own configured API key. Backends an admin has disabled (OLLAMA_API_CONFIGS["<idx>"].enable = false) are hidden from model discovery but remain reachable through the indexed route, because the disabled state is never re-checked at request time.

Impact

A verified, non-admin user with read access to any single model can: - route requests to internal / higher-capability / restricted Ollama backends in multi-backend deployments, bypassing backend-level isolation; - reach backends the admin has explicitly disabled; - have those requests authenticated with the target backend's configured API key (the key is used server-side; it is not returned to the attacker); - consume the restricted backend's compute.

There is no cross-user data disclosure and no exfiltration of the backend credential itself; the impact is unauthorized access to, and use of, restricted backend resources.

Affected / Patched

  • Affected: <= 0.9.5
  • Patched: >= 0.9.6

Fix

0.9.6 adds validate_ollama_backend_idx(), invoked on every indexed route (directly and via get_ollama_url()), which returns 403 for any non-admin caller-supplied url_idx that is not in the requested model's allowed urls. Because disabled backends are absent from every model's urls, the same check also blocks routing to disabled backends.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T18:01:50Z",
    "nvd_published_at": "2026-06-23T18:18:07Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nSeveral direct, index-addressed Ollama proxy routes accept a caller-supplied `url_idx`\npath parameter and use it as a raw index into the admin-configured `OLLAMA_BASE_URLS`\nlist. Access control on these routes validates only whether the user may use the\nrequested *model*, never which *backend* the request is routed to. Any authenticated\nuser can append an arbitrary `url_idx` to force their request onto an Ollama backend\nthey were never authorized to reach, including internal, higher-privilege, or\nexplicitly admin-disabled backends.\n\n## Affected endpoints\n\nAll indexed Ollama routes that resolve the backend through `get_ollama_url()`:\n\n```\nPOST /ollama/api/chat/{url_idx}\nPOST /ollama/api/generate/{url_idx}\nPOST /ollama/api/embed/{url_idx}\nPOST /ollama/api/embeddings/{url_idx}\nPOST /ollama/v1/chat/completions/{url_idx}\nPOST /ollama/v1/completions/{url_idx}\nPOST /ollama/v1/messages/{url_idx}\nPOST /ollama/v1/responses/{url_idx}\n```\n\n## Root cause\n\n`backend/open_webui/routers/ollama.py` \u2014 `get_ollama_url()` consults the\nmodel-to-backend allow-list (`OLLAMA_MODELS[model][\"urls\"]`) only when `url_idx` is\nomitted. When the caller supplies `url_idx`, that mapping is skipped and the value is\nused directly as an index:\n\n```python\nasync def get_ollama_url(request: Request, model: str, url_idx: Optional[int] = None):\n    if url_idx is None:\n        models = request.app.state.OLLAMA_MODELS\n        if model not in models:\n            raise HTTPException(...)\n        url_idx = random.choice(models[model].get(\"urls\", []))\n    url = request.app.state.config.OLLAMA_BASE_URLS[url_idx]   # caller-controlled, no authz\n    return url, url_idx\n```\n\nThe outbound request is then sent to that backend using the backend\u0027s own configured\nAPI key. Backends an admin has disabled (`OLLAMA_API_CONFIGS[\"\u003cidx\u003e\"].enable = false`)\nare hidden from model discovery but remain reachable through the indexed route, because\nthe disabled state is never re-checked at request time.\n\n## Impact\n\nA verified, non-admin user with read access to any single model can:\n- route requests to internal / higher-capability / restricted Ollama backends in\n  multi-backend deployments, bypassing backend-level isolation;\n- reach backends the admin has explicitly disabled;\n- have those requests authenticated with the target backend\u0027s configured API key\n  (the key is used server-side; it is not returned to the attacker);\n- consume the restricted backend\u0027s compute.\n\nThere is no cross-user data disclosure and no exfiltration of the backend credential\nitself; the impact is unauthorized access to, and use of, restricted backend resources.\n\n## Affected / Patched\n\n- Affected: `\u003c= 0.9.5`\n- Patched: `\u003e= 0.9.6`\n\n## Fix\n\n0.9.6 adds `validate_ollama_backend_idx()`, invoked on every indexed route (directly and\nvia `get_ollama_url()`), which returns 403 for any non-admin caller-supplied `url_idx`\nthat is not in the requested model\u0027s allowed `urls`. Because disabled backends are absent\nfrom every model\u0027s `urls`, the same check also blocks routing to disabled backends.",
  "id": "GHSA-9rpj-v7hf-vv2w",
  "modified": "2026-07-20T21:11:10Z",
  "published": "2026-06-17T18:01:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-9rpj-v7hf-vv2w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54021"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-9rpj-v7hf-vv2w"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/open-webui/PYSEC-2026-2718.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/open-webui"
    }
  ],
  "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"
    }
  ],
  "summary": "Open WebUI: Authenticated users can target arbitrary configured Ollama backends via unguarded url_idx path parameter"
}

GHSA-9RQ6-59M3-GMGX

Vulnerability from github – Published: 2024-06-13 06:30 – Updated: 2024-06-13 06:30
VLAI
Details

The Download Manager plugin for WordPress is vulnerable to unauthorized access of data due to an improper authorization check on the 'protectMediaLibrary' function in all versions up to, and including, 3.2.89. This makes it possible for unauthenticated attackers to download password-protected files.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-2098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-289",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-13T06:15:09Z",
    "severity": "HIGH"
  },
  "details": "The Download Manager plugin for WordPress is vulnerable to unauthorized access of data due to an improper authorization check on the \u0027protectMediaLibrary\u0027 function in all versions up to, and including, 3.2.89. This makes it possible for unauthenticated attackers to download password-protected files.",
  "id": "GHSA-9rq6-59m3-gmgx",
  "modified": "2024-06-13T06:30:53Z",
  "published": "2024-06-13T06:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2098"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3072712/download-manager"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1301c8af-d81a-40f1-96fa-e8252309d8a4?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9RWJ-HHP6-M2CG

Vulnerability from github – Published: 2026-09-16 12:30 – Updated: 2026-09-16 12:30
VLAI
Details

On affected platforms running Arista EOS, an authenticated user with access to the gNMI (gRPC Network Management Interface) may receive incorrect authorization results, potentially allowing access beyond their currently assigned permissions.

This issue was discovered internally by Arista and the company is not aware of any malicious uses of this issue in customer networks.

Severity
4.2 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/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-19640"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T10:16:50Z",
    "severity": "LOW"
  },
  "details": "On affected platforms running Arista EOS, an authenticated user with access to the gNMI (gRPC Network Management Interface) may receive incorrect authorization results, potentially allowing access beyond their currently assigned permissions.\n\nThis issue was discovered internally by Arista and the company is not aware of any malicious uses of this issue in customer networks.",
  "id": "GHSA-9rwj-hhp6-m2cg",
  "modified": "2026-09-16T12:30:30Z",
  "published": "2026-09-16T12:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19640"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisory/24726-security-advisory-0170"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/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-9RX5-W522-5FH7

Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2024-01-30 22:43
VLAI
Summary
Jenkins Promoted Builds Plugin allowed unauthorized users to run some promotion processes
Details

An improper authorization vulnerability exists in Jenkins Promoted Builds Plugin 2.31.1 and earlier in Status.java and ManualCondition.java that allow an attacker with read access to jobs to perform promotions.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.31.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:promoted-builds"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1000114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-30T22:43:31Z",
    "nvd_published_at": "2018-03-13T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An improper authorization vulnerability exists in Jenkins Promoted Builds Plugin 2.31.1 and earlier in Status.java and ManualCondition.java that allow an attacker with read access to jobs to perform promotions.",
  "id": "GHSA-9rx5-w522-5fh7",
  "modified": "2024-01-30T22:43:31Z",
  "published": "2022-05-13T01:48:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000114"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2018-02-26/#SECURITY-746"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Promoted Builds Plugin allowed unauthorized users to run some promotion processes"
}
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