github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #18224] 🔒 Security: Insufficient RCE warning for USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS #18537

New Issue
Closed
opened 2026-04-20 00:46:00 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-20 00:46:00 -05:00
Owner
Copy Link

Originally created by @jacksonkasi1 on GitHub (Oct 10, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18224

Summary

The current documentation warns that enabling USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS allows "arbitrary code" upload, but doesn't explicitly communicate the critical Remote Code Execution (RCE) risk this creates on the server.

Technical Analysis

Current Behavior

When workspace.tools permission is enabled for non-admin users:

  1. Users can create custom tools via /admin/workspace/tools
  2. Tool content is Python code stored in the database
  3. Code is executed server-side via exec() in:
    • backend/open_webui/utils/plugin.py line 101
    • backend/open_webui/utils/plugin.py line 145
  4. Result: Full RCE with server privileges (typically root in Docker containers)

Code Reference

# backend/open_webui/utils/plugin.py (line 101)
def load_tool_module_by_id(tool_id, content=None):
    # ... setup code ...
    exec(content, module.__dict__)  # ⚠️ ARBITRARY CODE EXECUTION
    # ... rest of function ...

Configuration

# backend/open_webui/config.py (line 1214-1216)
USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS = (
    os.environ.get("USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS", "False").lower() == "true"
)

Default: False (SECURE) ✅ - But risk is underestimated when enabled.

Proof of Concept

A malicious user with workspace.tools permission can create this tool:

"""
title: System Information Tool
description: Demonstrates RCE capability
"""
import os
import subprocess

class Tools:
    def __init__(self):
        pass
    
    def get_server_info(self) -> str:
        """Returns server information"""
        try:
            user = subprocess.check_output(['whoami']).decode().strip()
            pwd = subprocess.check_output(['pwd']).decode().strip()
            hostname = subprocess.check_output(['hostname']).decode().strip()
            
            # Could also:
            # - Read /etc/passwd, /etc/shadow
            # - Access environment variables with secrets
            # - Spawn reverse shell
            # - Exfiltrate data
            # - Pivot to other containers/services
            
            return f"Running as: {user}\nDirectory: {pwd}\nHostname: {hostname}"
        except Exception as e:
            return f"Error: {str(e)}"

Impact:

  • Server compromise
  • Data exfiltration
  • Credential theft from environment variables
  • Lateral movement to other services
  • Container escape potential

Current vs. Recommended Documentation

Current Warning (Insufficient)

From https://docs.openwebui.com/features/workspace/permissions/:

"Notably, enabling tools access allows users to upload arbitrary code, which poses a security risk."

Recommended Enhancement

- Notably, enabling tools access allows users to upload arbitrary code, which poses a security risk.

+ ⚠️ **CRITICAL SECURITY WARNING**: Enabling tools access grants users the ability to execute 
+ ARBITRARY PYTHON CODE directly on the server with full application privileges. 
+
+ **This provides Remote Code Execution (RCE) capability**, which can lead to:
+ - Full server compromise
+ - Access to all data and credentials
+ - Lateral movement to connected systems
+
+ **Only enable this permission for FULLY TRUSTED users in secure environments.**
+
+ Consider implementing:
+ - Sandboxed execution (Docker-in-Docker, RestrictedPython, etc.)
+ - Code review requirements for custom tools
+ - Audit logging for tool creation/modification
+ - Network isolation for the Open WebUI instance

Severity Assessment

  • Severity: P1/Critical IF this permission is enabled
  • Default Configuration: Secure (disabled by default) ✅
  • Risk: High severity, but low probability (requires admin misconfiguration)
  • CVE: Not applicable (intended functionality, documentation gap)

Recommended Fixes

1. Documentation Enhancement (Immediate) ⭐

Update documentation to clearly communicate RCE risk and mitigation strategies.

2. UI Warning (High Priority)

Add a confirmation dialog when enabling this permission:

⚠️ SECURITY WARNING

Enabling workspace.tools permission allows users to execute 
arbitrary Python code on the server.

This grants Remote Code Execution (RCE) capability.

Only enable for FULLY TRUSTED users.

[ ] I understand the security implications
[Cancel] [Enable Anyway]

3. Audit Logging (Medium Priority)

Log all tool creation/modification events:

log.warning(f"SECURITY: Tool {tool_id} created/modified by user {user.id}")

4. Sandboxing (Future Enhancement)

Consider implementing execution sandboxing:

  • Docker-in-Docker for tool execution
  • RestrictedPython for code restrictions
  • Resource limits (CPU, memory, network)

Testing Steps

  1. Enable USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS=true
  2. Grant workspace.tools permission to a non-admin user
  3. Create tool with PoC code above
  4. Execute tool from chat interface
  5. Observe server-side code execution

References

Additional Context

This is not a code vulnerability - the exec() functionality is intentional to support custom tool development. However, the documentation doesn't adequately communicate the critical security implications of enabling this feature.

The goal of this issue is to help administrators make informed security decisions when configuring user permissions.

Environment:

  • Open WebUI Version: 0.6.33 (latest)
  • Analysis Date: 11 Oct 2025
  • Reporter: Security Research
Originally created by @jacksonkasi1 on GitHub (Oct 10, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/18224 ## Summary The current documentation warns that enabling `USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS` allows "arbitrary code" upload, but doesn't explicitly communicate the **critical Remote Code Execution (RCE) risk** this creates on the server. ## Technical Analysis ### Current Behavior When `workspace.tools` permission is enabled for non-admin users: 1. Users can create custom tools via `/admin/workspace/tools` 2. Tool content is Python code stored in the database 3. **Code is executed server-side via `exec()`** in: - `backend/open_webui/utils/plugin.py` line 101 - `backend/open_webui/utils/plugin.py` line 145 4. **Result: Full RCE with server privileges (typically root in Docker containers)** ### Code Reference ```python # backend/open_webui/utils/plugin.py (line 101) def load_tool_module_by_id(tool_id, content=None): # ... setup code ... exec(content, module.__dict__) # ⚠️ ARBITRARY CODE EXECUTION # ... rest of function ... ``` ### Configuration ```python # backend/open_webui/config.py (line 1214-1216) USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS = ( os.environ.get("USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS", "False").lower() == "true" ) ``` **Default: `False` (SECURE)** ✅ - But risk is underestimated when enabled. ## Proof of Concept A malicious user with `workspace.tools` permission can create this tool: ```python """ title: System Information Tool description: Demonstrates RCE capability """ import os import subprocess class Tools: def __init__(self): pass def get_server_info(self) -> str: """Returns server information""" try: user = subprocess.check_output(['whoami']).decode().strip() pwd = subprocess.check_output(['pwd']).decode().strip() hostname = subprocess.check_output(['hostname']).decode().strip() # Could also: # - Read /etc/passwd, /etc/shadow # - Access environment variables with secrets # - Spawn reverse shell # - Exfiltrate data # - Pivot to other containers/services return f"Running as: {user}\nDirectory: {pwd}\nHostname: {hostname}" except Exception as e: return f"Error: {str(e)}" ``` **Impact:** - Server compromise - Data exfiltration - Credential theft from environment variables - Lateral movement to other services - Container escape potential ## Current vs. Recommended Documentation ### Current Warning (Insufficient) From https://docs.openwebui.com/features/workspace/permissions/: > "Notably, enabling tools access allows users to upload arbitrary code, which poses a security risk." ### Recommended Enhancement ```diff - Notably, enabling tools access allows users to upload arbitrary code, which poses a security risk. + ⚠️ **CRITICAL SECURITY WARNING**: Enabling tools access grants users the ability to execute + ARBITRARY PYTHON CODE directly on the server with full application privileges. + + **This provides Remote Code Execution (RCE) capability**, which can lead to: + - Full server compromise + - Access to all data and credentials + - Lateral movement to connected systems + + **Only enable this permission for FULLY TRUSTED users in secure environments.** + + Consider implementing: + - Sandboxed execution (Docker-in-Docker, RestrictedPython, etc.) + - Code review requirements for custom tools + - Audit logging for tool creation/modification + - Network isolation for the Open WebUI instance ``` ## Severity Assessment - **Severity:** P1/Critical **IF** this permission is enabled - **Default Configuration:** Secure (disabled by default) ✅ - **Risk:** High severity, but low probability (requires admin misconfiguration) - **CVE:** Not applicable (intended functionality, documentation gap) ## Recommended Fixes ### 1. Documentation Enhancement (Immediate) ⭐ Update documentation to clearly communicate RCE risk and mitigation strategies. ### 2. UI Warning (High Priority) Add a confirmation dialog when enabling this permission: ``` ⚠️ SECURITY WARNING Enabling workspace.tools permission allows users to execute arbitrary Python code on the server. This grants Remote Code Execution (RCE) capability. Only enable for FULLY TRUSTED users. [ ] I understand the security implications [Cancel] [Enable Anyway] ``` ### 3. Audit Logging (Medium Priority) Log all tool creation/modification events: ```python log.warning(f"SECURITY: Tool {tool_id} created/modified by user {user.id}") ``` ### 4. Sandboxing (Future Enhancement) Consider implementing execution sandboxing: - Docker-in-Docker for tool execution - RestrictedPython for code restrictions - Resource limits (CPU, memory, network) ## Testing Steps 1. Enable `USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS=true` 2. Grant `workspace.tools` permission to a non-admin user 3. Create tool with PoC code above 4. Execute tool from chat interface 5. Observe server-side code execution ## References - **Code:** `backend/open_webui/utils/plugin.py` (lines 101, 145) - **Config:** `backend/open_webui/config.py` (line 1214) - **Docs:** https://docs.openwebui.com/features/workspace/permissions/ - **Security Policy:** https://github.com/open-webui/open-webui/blob/main/docs/SECURITY.md ## Additional Context This is **not a code vulnerability** - the `exec()` functionality is intentional to support custom tool development. However, the **documentation doesn't adequately communicate the critical security implications** of enabling this feature. The goal of this issue is to help administrators make **informed security decisions** when configuring user permissions. --- **Environment:** - Open WebUI Version: 0.6.33 (latest) - Analysis Date: 11 Oct 2025 - Reporter: Security Research
GiteaMirror commented 2026-04-20 00:46:01 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Oct 10, 2025):

Documentation enhancement suggestions belong in the docs repository. Not here.

And this is not an "issue" merely an area of possible docs improvement.

PR welcome.

<!-- gh-comment-id:3392153956 --> @Classic298 commented on GitHub (Oct 10, 2025): Documentation enhancement suggestions belong in the docs repository. Not here. And this is not an "issue" merely an area of possible docs improvement. PR welcome.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#18537
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?