Loading vulnerability…
CVE-2026-0766 was rejected after investigation determined that the reported behavior is intended functionality of Open WebUI's Plugins extension system. The original report characterized Python execution through load_tool_module_by_id as authenticated command injection caused by insufficient validation of user-supplied code. However, users granted the relevant plugin permissions are explicitly authorized to author Python that the server executes. This behavior does not establish a security vulnerability or an authorization bypass.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This is a small standalone Python exploit repository for CVE-2026-0766 affecting OpenWebUI. The repository contains one substantive code file, exploit.py, plus a README, license, and gitignore. The exploit is not part of a larger framework such as Metasploit or Nuclei. The exploit targets OpenWebUI's tool creation feature, where authenticated users can submit Python code that is executed server-side through exec() during tool loading. The script automates creation of a malicious tool through the OpenWebUI API and abuses the fact that module-level code executes immediately when the tool is created. To remain structurally valid, generated payloads also define a minimal Tools class expected by OpenWebUI. Capabilities described and implemented in the script include: (1) arbitrary shell command execution, (2) arbitrary file read, (3) reverse shell delivery to an attacker listener, (4) blind HTTP callback exfiltration, and (5) API-based output recovery by embedding command/file output into Pydantic model field defaults/descriptions that OpenWebUI later serializes via tool metadata/spec endpoints. This API-side exfiltration is a notable feature because it avoids requiring outbound network access for basic command output retrieval. Operational flow is: authenticate with JWT or API key, POST a malicious tool to /api/v1/tools/create, optionally query tool detail/spec endpoints to recover output, then optionally delete the tool via the API for cleanup. The README states the exploit was tested against OpenWebUI v0.8.10 and that exploitation requires an authenticated user with tool creation capability. Overall, this is a real, functional authenticated RCE proof of concept with multiple payload modes and cleanup support, making it more than a simple detection script but still a standalone PoC/operational exploit rather than a weaponized framework module.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
8 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.