Supply Chain and Security Scanners

Automated software-composition and supply-chain scanners (for example socket.dev) periodically flag the Open WebUI PyPI packages and container images with risk indicators. This page is the Open WebUI team's official position on those indicators, so that security teams evaluating Open WebUI can interpret them accurately.

Looking for a specific CVE rather than a scanner flag?

If a database or scan report shows a CVE against Open WebUI, check whether the identifier is still live before acting on it. Several vulnerability databases do not reprocess CVE withdrawals, so records the issuing CNA has formally rejected keep displaying as active findings. See Rejected CVEs in Vulnerability Databases for the cases we are chasing and how to verify any record yourself in seconds.

The short version

None of the indicators these scanners raise against Open WebUI correspond to a named vulnerability, a CVE or confirmed malicious code. Most are automated behavioral heuristics that flag capabilities the software has by design. Some go further and publish alarming, unsubstantiated claims, most notably a "potential malware" banner, without identifying any specific file, function or line and without providing any evidence for the claim. No malicious code has been identified in Open WebUI. Because every published artifact is built from the public source in open-webui/open-webui and is reproducible from it, every one of these claims can be checked against the code directly.

What these scanners measure

Supply-chain scanners score a package on automated signals: which language features it uses, which system capabilities it can reach, what its dependencies look like and pattern-based classifiers. These signals describe what a package is capable of, not whether it misuses anything. For a self-hosted AI platform, the capabilities that score highest (running code, reaching the network, invoking a shell) are precisely the product's core, documented features. A high signal count therefore reflects what the software does, not a defect in it.

The headline numeric scores a scanner shows, for example a supply-chain score out of 100, are aggregates of these same automated signals, so a score below 100 reflects the heuristic flags described below rather than a count of confirmed defects.

We review each new flag, but a flag is a starting point for analysis, not a finding.

The indicators, category by category

Behavioral capability flags: "uses eval", "shell access", "network access"

These describe intended, documented functionality:

• Network access is how Open WebUI talks to model providers and external tools.
• Code execution ("eval") and shell access are the code interpreter and the Tools and Functions system, which execute code by design.

These capabilities are governed by administrator configuration and role-based permissions (see Code execution and sandboxing below). The scanner flags the capability, not any misuse of it, so none of these is a vulnerability.

Unsubstantiated classifications: "potential malware", "AI-detected security risk", "potential vulnerability"

These are the indicators most likely to alarm a reviewer, and they are the least substantiated:

• "Potential malware" is asserted with no identification of any specific file, function or line, and no supporting evidence attached. No malicious code has been identified in Open WebUI. Publishing a "malware detected" banner without naming the code or showing evidence is, in our view, materially misleading, especially to enterprise reviewers who reasonably read such a banner as a confirmed finding rather than an automated guess.
• "AI-detected security risk" is a machine-generated classification (the software "may contain potential security issues"), driven by the behavioral signals above. It names no specific code and confirms nothing.
• "Potential vulnerability" is, by the scanner's own wording, an item pending further analysis and confirmation. That is an open queue entry, not a finding.

Because Open WebUI's published packages are built entirely from the public source, any of these can be verified against the code, and we request re-review with the scanning vendor where an unsubstantiated banner appears.

Dependency alerts and "obfuscated code"

These originate in transitive dependencies and in the pre-built, minified front-end assets bundled in the distribution. Minified JavaScript is routinely classified as "obfuscated" by scanners because it is not human-readable, but it is ordinary compiled front-end code, not hand-obfuscated logic in Open WebUI's source. Dependency alerts track the wider ecosystem and are handled through routine dependency maintenance.

Container-image CVEs are a separate matter: those originate in the base image, are addressed by rebuilding on updated bases and are not part of the PyPI package scan discussed here.

Maintainer count

Scanners report a maintainer count taken from package metadata, often "1 maintainer" for Open WebUI. That figure is the number of accounts with publish rights on the PyPI package, a single release account, not the number of people who develop the project. Open WebUI is built by a core team and a broad base of external contributors, visible in the repository's contributor history and on our Team page. Publishing releases from one account is a common, deliberate packaging practice, not a maintenance bus-factor of one.

Code execution and sandboxing

Evaluators often ask whether Open WebUI executes code "without enforced sandboxing by default". The point that matters is that server-side code execution is gated behind explicit administrator action, not exposed to arbitrary users:

• Server-side execution engines (such as Jupyter) are opt-in and administrator-configured. They are not wired to a server runtime by default.
• Authoring server-side Tools and Functions is treated as equivalent to granting server code execution. It is restricted by the workspace.tools permission, which is disabled by default for non-administrators, and granting it is documented as equivalent to giving that user shell access to the server.
• Isolating the execution environment is a documented deployment responsibility. Where an administrator enables a server-side execution engine, running it within appropriate container, network and filesystem boundaries is covered in our hardening guidance.

This is intentional, layered design: server-side code execution is gated behind explicit administrator configuration and an off-by-default permission, rather than available to every user. See the Tools and Functions security model and the Security Policy for the full model.

For enterprise evaluators

Open WebUI is actively maintained by a core team that runs a defined, hands-on security process rather than relying on automated scoring:

• Every report is reviewed by a person. Incoming security reports are triaged and validated by hand against the actual code. Nothing is auto-closed or auto-classified.
• Valid findings are fixed and disclosed properly. We patch confirmed issues as quickly as we reasonably can, request CVE identifiers for valid findings and publish the outcome openly as a GitHub Security Advisory once a fix ships.
• The record is public and auditable. Our full history of accepted, fixed and published issues is visible on the Open WebUI Security Advisories page. Anyone can see what was found, how it was resolved and which release contains the fix.
• Invalid or mischaracterized claims are answered, not ignored. Where an external CVE misrepresents the software or our threat model, we publish a reasoned Vendor Disposition rather than leaving the public record unchallenged.
• One authoritative channel. All vulnerability handling runs through GitHub Security Advisories, with the team owning validation, remediation and disclosure timing.

Taken together, that is a materially stronger signal than an automated risk score: a public, auditable trail of found, fixed and published issues, produced by a process a person runs end to end. We are glad to support your evaluation directly.

Useful starting points:

• Security Policy: the reporting process, threat model and what is and is not treated as a vulnerability.
• Vendor Dispositions: our formal assessments of specific externally reported CVEs.
• Tools and Functions: the code-execution and permission model.

If you believe a scanner flag corresponds to a genuine security issue rather than a behavioral heuristic, please report it through GitHub Security Advisories so it can be validated and, if confirmed, published.