542094a0ad
* docs: add security policy and correct multi-user mode wording The README promised that files, commands and terminals are isolated between users in multi-user mode. A single shared container cannot hold that promise: everyone shares one kernel, one process list, one network stack and one temp directory, and provisioning per-user accounts requires elevated privileges inside that container. The wording now says what the mode actually gives you, which is a separate workspace per user so people and their agents do not walk over each other's files, and it points at Terminals for deployments where users have to be protected from each other. The new SECURITY.md adopts the Open WebUI security policy wherever it is semantically applicable, names this repository as the reporting channel, and writes down what is designed behaviour here: the API key is a full-access credential, X-User-Id is asserted by the caller, the latest image gives its user passwordless sudo, and bare metal runs as your own user. It also states what remains in scope, so that reports crossing out of the instance still get the attention they deserve. * docs: point per-user isolation at Terminals and its enterprise license The pointer to Terminals now says what it actually gives you, a separate container per user with its own files, processes, limits and network boundary, and states that production use needs an Open WebUI Enterprise License, with the deployment and licensing docs linked. The same note is added where the security policy sends people to Terminals. * docs: link the enterprise license to the docs page
5.4 KiB
Security Policy
Open Terminal is led and maintained by the same core team as Open WebUI, and it follows the same security process.
Relationship to the Open WebUI Security Policy
The Open WebUI Security Policy applies to Open Terminal in full wherever it is semantically applicable. That includes, and is not limited to: the rules for reporting a vulnerability, the proof-of-concept and remediation requirements, AI disclosure, CVSS accuracy, admin actions being out of scope, default configuration testing, already-fixed reports, self-affecting issues, duplicate and consolidation handling, our position on foreign CNAs and vendor disposition, and responsible disclosure.
Read that policy before filing. Everything in it that can sensibly be applied to Open Terminal is applied to Open Terminal. This document adds what is specific to this project, and where the two documents differ, this one governs reports filed here.
Reporting Channel
Report through GitHub Security Advisories on this repository. Reports for Open Terminal code filed against open-webui/open-webui are closed there and have to be re-filed here, which costs you time, so file in the right place from the start.
Supported Versions
Only the latest release is supported. Reproduce your finding against the latest release or against main before filing.
What Open Terminal Is
Open Terminal runs commands on behalf of whoever holds its API key. Executing commands, reading and writing files, installing packages, and reaching the network from inside the terminal are the product working as designed. The following therefore are not vulnerabilities, and reports about them will be closed:
- Command execution through the API. Running arbitrary commands is the entire purpose of this software.
- The API key grants everything. The key is a single full-access credential. Anyone holding it can run any command, read any file the service can reach, and use every endpoint. Treat it like a root password, and never hand it to users you would not give a shell to.
X-User-Idis asserted by the caller. Open Terminal does not authenticate end users. The calling application (for example Open WebUI) authenticates its users and sets the header, and Open Terminal trusts it. A client that holds the API key can name any user it likes, by design.- Root inside the container in images that ship
sudo. Thelatestimage gives its default user passwordlesssudoso that packages can be installed at runtime. Reaching root inside that container is documented behaviour. Useslim,alpine, oropenshiftwhen you do not want that. - Bare metal runs as you. Installed with
pip, commands run as your own user with your own permissions and your own files. That is the point of the bare metal mode. - Operator configuration. Mounting the Docker socket, granting extra capabilities, disabling the egress firewall, or exposing the API to an untrusted network are operator decisions with documented consequences.
Multi-User Mode
OPEN_TERMINAL_MULTI_USER=true gives each user their own Linux account and home directory inside one shared container. It separates workspaces so that users and their agents do not walk over each other's files. It does not isolate users from each other, and it is not designed for production multi-user deployments.
All users share one kernel, one process list, one network stack, and one temp directory, and the service that provisions their accounts has to hold elevated privileges inside that container. In that shape, the following are expected consequences of running many users in one container, and are out of scope:
- One user reading, observing, or interfering with another user's processes, command lines, ports, or resources.
- Privilege escalation to root inside the container.
- Cross-user access to files, sessions, terminals, notebooks, or background processes in a single instance.
- Resource exhaustion affecting other users of the same instance.
If your users need to be protected from each other, run one Open Terminal per user, for example with Terminals, which provisions a separate container per user and requires an Open WebUI Enterprise License for production use. Reports asking us to defend a boundary inside a single shared container are closed as documented behaviour under this section.
What We Do Want to Hear About
Findings that cross out of the instance or out of the API's own trust model are in scope, including:
- Acting on the API without a valid API key, or any bypass of the key check.
- Escaping the container onto the host in a default Docker deployment.
- Anything that lets terminal content or terminal responses run with the privileges of the calling application, for example executing at the client application's origin or reaching its credentials.
- Path traversal or file access that reaches outside what the API is meant to expose in a single-user deployment.
- Anything that affects the operator, the host, or a party other than the reporter.
When in doubt, file it. A report that lands outside the scope above is closed quickly and without drama, and we would rather read one of those than miss something real.
Last updated on 2026-09-17.