CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
19659 vulnerabilities reference this CWE, most recent first.
GHSA-4PCG-253R-RF9W
Vulnerability from github – Published: 2026-05-14 20:24 – Updated: 2026-05-19 15:59Summary
Open WebUI v0.6.43 contains a vulnerability in its chat completion API, which allows attackers to bypass tool restrictions, potentially enabling unauthorized actions or access.
Details
In the chat_completion API, the parameters tool_ids and tool_servers are supplied by the user. These parameters are used to create a tools_dict by the middleware. This is then used by get_tool_by_id to retrieve the appropriate tool. However, there is no checks in that ensures the user that uses the API has permission to use the tool, meaning that a user can invoke any server tool by supplying the correct tool_id or tool_servers parameters via the chat completion API. Moreover, the authentication token stored in the server would be used when invoking the tool, so the tool will be invoked with the server privilege.
PoC
To reproduce the issue, create an admin user and create an external tool via the admin settings. Set the type to "MCP Streamable HTTP" for the tool, and the url pointing to a mcp server. For example, the public instance of the "Fetch" mcp server can be used, which is located at "https://remote.mcpservers.org/fetch/mcp". Other mcp servers, e.g. the GitHub MCP server can also be used. Then set the "Auth" field appropriately. (Fetch mcp does not require Auth to be set).
Set the ID, name and description for the MCP server and set visibility to private. This should prevent any user from using the mcp server. (For the example below, we use the fetch mcp server and set the ID to 1)
Next create a user with low privilege and enable API keys from the admin settings.
Then use the chat completion API with the low privilege user with a prompt specifying the use of the restricted tool, and include the id of the tool in the tool_ids parameter. For example, to use the fetch mcp server set up before:
def chat_with_model(token):
url = 'http://localhost:3000/api/chat/completions'
headers = {
'Authorization': f'Bearer {token}',
'Content-Type': 'application/json'
}
data = {
"model": "llama3.1:latest",
"messages": [
{
"role": "user",
"content": "Use the fetch tool to fetch content of the url https://raw.githubusercontent.com/modelcontextprotocol/servers/refs/heads/main/src/fetch/LICENSE"
}],
"tool_ids" : [
"server:mcp:1",
],
}
response = requests.post(url, headers=headers, json=data)
return response.json()
Note that the tool will be used to fetch the content of the file, despite the tool is restricted and has it's visibility set to private
Impact
This issue may lead to restricted tools being invoked by users via the chat completion API
Resolution
Fixed across two releases
-
Local Tool records (
tool_ids: ["<tool_id>"]referencing a stored Tool): fixed in commit 9b06fdc8f, first released in v0.7.0.get_tools()inbackend/open_webui/utils/tools.py(line 166) now resolves the caller's group memberships and rejects each requestedtool_idwhose owner isn't the caller and for which noAccessGrants.has_access(resource_type='tool', permission='read')grant exists. Admins continue to bypass whenBYPASS_ADMIN_ACCESS_CONTROLis enabled (its documented UI/posture purpose). -
Admin-configured MCP servers (
tool_ids: ["server:mcp:<id>"], the report's exact PoC): fixed in commit 4737e1f11, first released in v0.8.6. The MCP-resolution loop inbackend/open_webui/utils/middleware.py(line 2670) now callshas_connection_access(user, mcp_server_connection)and skips the server with a warning if the user has no grant — the server's stored credentials are never used on behalf of an unauthorized caller.
Users on >= 0.8.6 are not affected.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.5"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45350"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T20:24:48Z",
"nvd_published_at": "2026-05-15T22:16:55Z",
"severity": "HIGH"
},
"details": "### Summary\nOpen WebUI v0.6.43 contains a vulnerability in its chat completion API, which allows attackers to bypass tool restrictions, potentially enabling unauthorized actions or access.\n\n\n### Details\nIn the [chat_completion](https://github.com/open-webui/open-webui/blob/a7271532f8a38da46785afcaa7e65f9a45e7d753/backend/open_webui/main.py#L1529) API, the parameters [tool_ids and tool_servers](https://github.com/open-webui/open-webui/blob/a7271532f8a38da46785afcaa7e65f9a45e7d753/backend/open_webui/main.py#L1613-L1614) are supplied by the user. These parameters are used to [create a tools_dict by the middleware](https://github.com/open-webui/open-webui/blob/a7271532f8a38da46785afcaa7e65f9a45e7d753/backend/open_webui/utils/middleware.py#L1394). This is then used by [get_tool_by_id](https://github.com/open-webui/open-webui/blob/a7271532f8a38da46785afcaa7e65f9a45e7d753/backend/open_webui/models/tools.py#L139) to retrieve the appropriate tool. However, there is no checks in that ensures the user that uses the API has permission to use the tool, meaning that a user can invoke any server tool by supplying the correct tool_id or tool_servers parameters via the chat completion API. Moreover, the authentication token stored in the server would be used when invoking the tool, so the tool will be invoked with the server privilege.\n### PoC\nTo reproduce the issue, create an admin user and create an external tool via the admin settings. Set the type to \"MCP Streamable HTTP\" for the tool, and the url pointing to a mcp server. For example, the public instance of the [\"Fetch\" mcp server](https://github.com/modelcontextprotocol/servers/blob/main/src/fetch/README.md) can be used, which is located at \"https://remote.mcpservers.org/fetch/mcp\". Other mcp servers, e.g. the GitHub MCP server can also be used. Then set the \"Auth\" field appropriately. (Fetch mcp does not require Auth to be set).\n\nSet the ID, name and description for the MCP server and set visibility to private. This should prevent any user from using the mcp server. (For the example below, we use the fetch mcp server and set the ID to 1)\n\nNext create a user with low privilege and enable API keys from the admin settings.\n\nThen use the chat completion API with the low privilege user with a prompt specifying the use of the restricted tool, and include the id of the tool in the tool_ids parameter. For example, to use the fetch mcp server set up before:\n\n```\ndef chat_with_model(token):\n url = \u0027http://localhost:3000/api/chat/completions\u0027\n headers = {\n \u0027Authorization\u0027: f\u0027Bearer {token}\u0027,\n \u0027Content-Type\u0027: \u0027application/json\u0027\n }\n data = {\n \"model\": \"llama3.1:latest\",\n \"messages\": [\n {\n \"role\": \"user\",\n \"content\": \"Use the fetch tool to fetch content of the url https://raw.githubusercontent.com/modelcontextprotocol/servers/refs/heads/main/src/fetch/LICENSE\"\n }],\n \n \"tool_ids\" : [\n \"server:mcp:1\",\n ],\n }\n response = requests.post(url, headers=headers, json=data)\n return response.json()\n```\n\nNote that the tool will be used to fetch the content of the file, despite the tool is restricted and has it\u0027s visibility set to private\n\n### Impact\nThis issue may lead to restricted tools being invoked by users via the chat completion API\n\n## Resolution\n\nFixed across two releases\n\n- **Local Tool records** (`tool_ids: [\"\u003ctool_id\u003e\"]` referencing a stored Tool): fixed in commit [9b06fdc8f](https://github.com/open-webui/open-webui/commit/9b06fdc8fe1c933071610336be05f11e77e6c8eb), first released in **v0.7.0**. `get_tools()` in `backend/open_webui/utils/tools.py` (line 166) now resolves the caller\u0027s group memberships and rejects each requested `tool_id` whose owner isn\u0027t the caller and for which no `AccessGrants.has_access(resource_type=\u0027tool\u0027, permission=\u0027read\u0027)` grant exists. Admins continue to bypass when `BYPASS_ADMIN_ACCESS_CONTROL` is enabled (its documented UI/posture purpose).\n\n- **Admin-configured MCP servers** (`tool_ids: [\"server:mcp:\u003cid\u003e\"]`, the report\u0027s exact PoC): fixed in commit [4737e1f11](https://github.com/open-webui/open-webui/commit/4737e1f11), first released in **v0.8.6**. The MCP-resolution loop in `backend/open_webui/utils/middleware.py` (line 2670) now calls `has_connection_access(user, mcp_server_connection)` and skips the server with a warning if the user has no grant \u2014 the server\u0027s stored credentials are never used on behalf of an unauthorized caller.\n\nUsers on `\u003e= 0.8.6` are not affected.",
"id": "GHSA-4pcg-253r-rf9w",
"modified": "2026-05-19T15:59:53Z",
"published": "2026-05-14T20:24:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-4pcg-253r-rf9w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45350"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/4737e1f11"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.8.6"
}
],
"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"
}
],
"summary": "Open WebUI\u0027s chat completion API allows tool restrictions to be bypassed"
}
GHSA-4PCX-M3HV-2JW5
Vulnerability from github – Published: 2025-11-06 18:32 – Updated: 2026-01-20 15:31Missing Authorization vulnerability in Stylemix Cost Calculator Builder cost-calculator-builder.This issue affects Cost Calculator Builder: from n/a through <= 3.5.32.
{
"affected": [],
"aliases": [
"CVE-2025-62049"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-06T16:16:11Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Stylemix Cost Calculator Builder cost-calculator-builder.This issue affects Cost Calculator Builder: from n/a through \u003c= 3.5.32.",
"id": "GHSA-4pcx-m3hv-2jw5",
"modified": "2026-01-20T15:31:54Z",
"published": "2025-11-06T18:32:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62049"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/cost-calculator-builder/vulnerability/wordpress-cost-calculator-builder-plugin-3-5-32-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/cost-calculator-builder/vulnerability/wordpress-cost-calculator-builder-plugin-3-5-32-broken-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/cost-calculator-builder/vulnerability/wordpress-cost-calculator-builder-plugin-3-5-32-broken-access-control-vulnerability?_s_id=cve"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PF2-MX2W-V6H4
Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-10 18:31Missing Authorization vulnerability in Wpbens Filter Plus filter-plus allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Filter Plus: from n/a through <= 1.1.17.
{
"affected": [],
"aliases": [
"CVE-2026-39607"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T09:16:30Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Wpbens Filter Plus filter-plus allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Filter Plus: from n/a through \u003c= 1.1.17.",
"id": "GHSA-4pf2-mx2w-v6h4",
"modified": "2026-04-10T18:31:16Z",
"published": "2026-04-08T09:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39607"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/filter-plus/vulnerability/wordpress-filter-plus-plugin-1-1-17-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PFX-JFJ6-Q6CH
Vulnerability from github – Published: 2024-10-16 09:30 – Updated: 2024-10-16 09:30The NextScripts: Social Networks Auto-Poster plugin for WordPress is vulnerable to authorization bypass due to missing capability checks on multiple user privilege/security functions provided in versions up to, and including 4.3.17. This makes it possible for low-privileged attackers, like subscribers, to perform restricted actions that would be otherwise locked to a administrative-level user.
{
"affected": [],
"aliases": [
"CVE-2020-36831"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-16T07:15:07Z",
"severity": "MODERATE"
},
"details": "The NextScripts: Social Networks Auto-Poster plugin for WordPress is vulnerable to authorization bypass due to missing capability checks on multiple user privilege/security functions provided in versions up to, and including 4.3.17. This makes it possible for low-privileged attackers, like subscribers, to perform restricted actions that would be otherwise locked to a administrative-level user.",
"id": "GHSA-4pfx-jfj6-q6ch",
"modified": "2024-10-16T09:30:30Z",
"published": "2024-10-16T09:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36831"
},
{
"type": "WEB",
"url": "https://blog.sucuri.net/2020/09/insufficient-privilege-validation-in-nextscripts-social-networks-auto-poster.html"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/0641578b-16b9-4d79-af69-b4886840da36"
},
{
"type": "WEB",
"url": "https://www.acunetix.com/vulnerabilities/web/wordpress-plugin-nextscripts-social-networks-auto-poster-security-bypass-4-3-17"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3709465d-6d67-45bd-abb9-4875065b8129?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PG2-JRCH-M6P4
Vulnerability from github – Published: 2024-03-05 12:30 – Updated: 2025-04-23 21:30A CWE-862 “Missing Authorization” vulnerability in the “file_configuration” functionality of the web application allows a remote unauthenticated attacker to access confidential configuration files. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.
{
"affected": [],
"aliases": [
"CVE-2023-45596"
],
"database_specific": {
"cwe_ids": [
"CWE-425",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-05T12:15:46Z",
"severity": "MODERATE"
},
"details": "A CWE-862 \u201cMissing Authorization\u201d vulnerability in the \u201cfile_configuration\u201d functionality of the web application allows a remote unauthenticated attacker to access confidential configuration files. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.",
"id": "GHSA-4pg2-jrch-m6p4",
"modified": "2025-04-23T21:30:31Z",
"published": "2024-03-05T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45596"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2023-45596"
}
],
"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-4PG5-HX4C-34CX
Vulnerability from github – Published: 2024-06-10 09:31 – Updated: 2026-04-01 18:31Missing Authorization vulnerability in Tickera.This issue affects Tickera: from n/a through 3.5.2.6.
{
"affected": [],
"aliases": [
"CVE-2024-35729"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-10T08:15:50Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Tickera.This issue affects Tickera: from n/a through 3.5.2.6.",
"id": "GHSA-4pg5-hx4c-34cx",
"modified": "2026-04-01T18:31:49Z",
"published": "2024-06-10T09:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35729"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/tickera-event-ticketing-system/vulnerability/wordpress-tickera-wordpress-event-ticketing-plugin-3-5-2-6-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/tickera-event-ticketing-system/wordpress-tickera-wordpress-event-ticketing-plugin-3-5-2-6-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PGF-P454-MF4W
Vulnerability from github – Published: 2026-09-02 06:31 – Updated: 2026-09-02 12:31The WC Vendors WordPress plugin before 2.7.2.1 does not verify that the vendor submitting a front-end order shipment status change owns the referenced order, allowing any authenticated vendor to mark another vendor's order as shipped, add an order note falsely attributed to the victim vendor, and trigger the customer shipment notification email.
{
"affected": [],
"aliases": [
"CVE-2026-81427"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-02T06:17:19Z",
"severity": "MODERATE"
},
"details": "The WC Vendors WordPress plugin before 2.7.2.1 does not verify that the vendor submitting a front-end order shipment status change owns the referenced order, allowing any authenticated vendor to mark another vendor\u0027s order as shipped, add an order note falsely attributed to the victim vendor, and trigger the customer shipment notification email.",
"id": "GHSA-4pgf-p454-mf4w",
"modified": "2026-09-02T12:31:29Z",
"published": "2026-09-02T06:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81427"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/f7fcf650-6e5e-4629-97ac-a76a5a0551db"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PH2-8337-HM62
Vulnerability from github – Published: 2021-02-08 17:43 – Updated: 2021-02-05 21:22Impact
This advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified.
When key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider.
Patches
Fixed as of 1.3.0. We recommend users to modify their code and adopt CachingMostRecentProvider.
Workarounds
Users who cannot upgrade to use the CachingMostRecentProvider can call clear() on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "dynamodb-encryption-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2021-02-05T21:22:28Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nThis advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified.\n\nWhen key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider.\n\n### Patches\nFixed as of 1.3.0. We recommend users to modify their code and adopt `CachingMostRecentProvider`.\n\n\n### Workarounds\nUsers who cannot upgrade to use the `CachingMostRecentProvider` can call `clear()` on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.",
"id": "GHSA-4ph2-8337-hm62",
"modified": "2021-02-05T21:22:28Z",
"published": "2021-02-08T17:43:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-dynamodb-encryption-python/security/advisories/GHSA-4ph2-8337-hm62"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-dynamodb-encryption-python/commit/90606ec9af7c2b5cb338d64639a62ee867d38d6b"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-dynamodb-encryption-python/blob/master/CHANGELOG.rst#130----2021-02-04"
},
{
"type": "WEB",
"url": "https://pypi.org/project/dynamodb-encryption-sdk"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Key Caching behavior in the DynamoDB Encryption Client."
}
GHSA-4PJ2-VQ9J-XJ3G
Vulnerability from github – Published: 2026-07-31 18:32 – Updated: 2026-07-31 18:32The per-tool permission system (custom roles / role-based tool permissions, introduced in pgAdmin 4 9.3) did not enforce its permission check consistently. In SERVER mode, pgAdmin 4 gates each tool behind a per-tool Flask-Security permission, but the permission decorator (permissions_required) was applied only to a single "front door" route per tool. Every other backend route and Socket.IO handler in that tool's workflow relied solely on pga_login_required/socket_login_required, which check authentication but not the tool permission.
The reporter verified three cases against a test build: (1) a user without tools_query_tool permission received 403 on the protected sqleditor initialization route, but the same session went on to connect the server, initialize the viewdata backend chain, and retrieve real table row content; (2) a user without tools_grant_wizard received 403 on the protected acl route, but the same session still enumerated grantable objects, generated GRANT SQL, and successfully applied it -- confirmed database-side via has_table_privilege(); (3) a user without tools_schema_diff received 403 on the protected panel route, but the same session initialized schema diff, enumerated and connected databases, and obtained real DDL differences via the compare_database Socket.IO handler. The reporter also confirmed a related but distinct issue: a non-owner triggering /misc/workspace/adhoc_connect_server against an administrator-owned shared server caused pgAdmin to persist a new server row still owned by the administrator (user_id/shared unchanged from the source), even though the connection attempt itself reported failure.
During remediation, the same front-door-only permission gap was found to also affect the ERD, PSQL, and Debugger tools, and the Backup, Restore, Maintenance, and Import/Export blueprints, none of which were part of the original report; these were fixed using the same pattern as an extension of the reported defect class.
An authenticated user who had valid pgAdmin login and a stored, working database connection, but had been explicitly denied a specific tool's permission by an administrator, could therefore still drive that tool end-to-end through its other routes and sockets, including obtaining an interactive psql session over the /pty Socket.IO namespace and invoking backup/restore/maintenance/import-export jobs.
Because the bypass only restores access to tools operating over the user's own already-authenticated database connection, it does not grant the user any database privilege they did not already hold; it circumvents pgAdmin's own tool-level access-control policy (an organisational segregation-of-duties control, separate from database-level authorization), letting a user reach a pgAdmin feature an administrator intended to withhold from them, using capabilities their existing database role already permits through other means.
Socket.IO event handlers had no permission-aware equivalent of permissions_required; only socket_login_required existed, checking authentication but not the tool permission.
Fix adds a socket_permissions_required decorator (mirroring permissions_required, honouring the Administrator bypass, reading permissions via has_permission()) and applies it, alongside permissions_required, as the outermost decorator on every backend route and Socket.IO handler for the affected tools. Regression tests assert 403 on every gated route and socket handler for a permission-less user.
This issue affects pgAdmin 4 in SERVER mode: from 9.3 before 9.17.
{
"affected": [],
"aliases": [
"CVE-2026-17350"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-31T16:16:59Z",
"severity": "MODERATE"
},
"details": "The per-tool permission system (custom roles / role-based tool permissions, introduced in pgAdmin 4 9.3) did not enforce its permission check consistently. In SERVER mode, pgAdmin 4 gates each tool behind a per-tool Flask-Security permission, but the permission decorator (permissions_required) was applied only to a single \"front door\" route per tool. Every other backend route and Socket.IO handler in that tool\u0027s workflow relied solely on pga_login_required/socket_login_required, which check authentication but not the tool permission.\n\nThe reporter verified three cases against a test build: (1) a user without tools_query_tool permission received 403 on the protected sqleditor initialization route, but the same session went on to connect the server, initialize the viewdata backend chain, and retrieve real table row content; (2) a user without tools_grant_wizard received 403 on the protected acl route, but the same session still enumerated grantable objects, generated GRANT SQL, and successfully applied it -- confirmed database-side via has_table_privilege(); (3) a user without tools_schema_diff received 403 on the protected panel route, but the same session initialized schema diff, enumerated and connected databases, and obtained real DDL differences via the compare_database Socket.IO handler. The reporter also confirmed a related but distinct issue: a non-owner triggering /misc/workspace/adhoc_connect_server against an administrator-owned shared server caused pgAdmin to persist a new server row still owned by the administrator (user_id/shared unchanged from the source), even though the connection attempt itself reported failure.\n\nDuring remediation, the same front-door-only permission gap was found to also affect the ERD, PSQL, and Debugger tools, and the Backup, Restore, Maintenance, and Import/Export blueprints, none of which were part of the original report; these were fixed using the same pattern as an extension of the reported defect class.\n\nAn authenticated user who had valid pgAdmin login and a stored, working database connection, but had been explicitly denied a specific tool\u0027s permission by an administrator, could therefore still drive that tool end-to-end through its other routes and sockets, including obtaining an interactive psql session over the /pty Socket.IO namespace and invoking backup/restore/maintenance/import-export jobs.\n\nBecause the bypass only restores access to tools operating over the user\u0027s own already-authenticated database connection, it does not grant the user any database privilege they did not already hold; it circumvents pgAdmin\u0027s own tool-level access-control policy (an organisational segregation-of-duties control, separate from database-level authorization), letting a user reach a pgAdmin feature an administrator intended to withhold from them, using capabilities their existing database role already permits through other means.\n\nSocket.IO event handlers had no permission-aware equivalent of permissions_required; only socket_login_required existed, checking authentication but not the tool permission.\n\nFix adds a socket_permissions_required decorator (mirroring permissions_required, honouring the Administrator bypass, reading permissions via has_permission()) and applies it, alongside permissions_required, as the outermost decorator on every backend route and Socket.IO handler for the affected tools. Regression tests assert 403 on every gated route and socket handler for a permission-less user.\n\nThis issue affects pgAdmin 4 in SERVER mode: from 9.3 before 9.17.",
"id": "GHSA-4pj2-vq9j-xj3g",
"modified": "2026-07-31T18:32:17Z",
"published": "2026-07-31T18:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17350"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/issues/10190"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/461c3afba92baad37c70a6fbd52d205d13a9de53"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/64a9cdbd6a240a962144f84418beaf9e66419779"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/ba1984718ad703011740ad48cb9b82402b89cc2c"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/d36bd8dc96812c716664feac533d240544e70adc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4PMJ-QPM8-X7GV
Vulnerability from github – Published: 2025-01-31 00:30 – Updated: 2025-01-31 18:31This vulnerability allows remote attackers to disclose sensitive information on affected installations of Alpine Halo9 devices. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the DLT interface, which listens on TCP port 3490 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the device.
{
"affected": [],
"aliases": [
"CVE-2024-23962"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-31T00:15:09Z",
"severity": "HIGH"
},
"details": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Alpine Halo9 devices. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the DLT interface, which listens on TCP port 3490 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the device.",
"id": "GHSA-4pmj-qpm8-x7gv",
"modified": "2025-01-31T18:31:05Z",
"published": "2025-01-31T00:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23962"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-847"
}
],
"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"
}
]
}
Mitigation
- 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
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
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
- 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
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.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.