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

New Issue

GiteaMirror · 2026-04-25T07:59:01-05:00

GiteaMirror commented

2026-04-25 07:59:01 -05:00

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:

Users can create custom tools via /admin/workspace/tools
Tool content is Python code stored in the database
Code is executed server-side via exec() in:
- backend/open_webui/utils/plugin.py line 101
- backend/open_webui/utils/plugin.py line 145
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

Enable USER_PERMISSIONS_WORKSPACE_TOOLS_ACCESS=true
Grant workspace.tools permission to a non-admin user
Create tool with PoC code above
Execute tool from chat interface
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

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 closed this issue

2026-04-25 07:59:02 -05:00

GiteaMirror commented

2026-04-25 07:59:03 -05:00

@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.

@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.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#34066