[PR #128] security: strip OPEN_TERMINAL_* from subprocess env #130

Open
opened 2026-10-18 21:11:04 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-terminal/pull/128
Author: @mazzz1y
Created: 5/19/2026
Status: 🔄 Open

Base: main ← Head: security/sanitize-subprocess-env


📝 Commits (1)

  • d349c51 security: strip OPEN_TERMINAL_* from subprocess env

📊 Changes

3 files changed (+25 additions, -7 deletions)

View changed files

📝 open_terminal/env.py (+18 -0)
📝 open_terminal/main.py (+4 -4)
📝 open_terminal/utils/runner.py (+3 -3)

📄 Description

User-spawned shells and commands inherited the full parent environment, including OPEN_TERMINAL_API_KEY. A user running env | grep OPEN_TERMINAL_ inside an /execute command or /api/terminals session could read internal configuration meant only for the server process.

This is the minimal, conservative fix:

  • OPEN_TERMINAL_* keys are stripped. Other variables such as PATH, HOME, USER, SHELL, TERM, LANG, etc pass through unchanged, so user shells continue to feel normal.
  • Caller-supplied env in POST /execute still wins on collision — authenticated callers can explicitly re-add any variable.

Tested in my environment — REST API with OpenWebUI

Another option was introducing a prefix convention to fully separate server variables from sandbox variables — e.g. SANDBOX_API_KEY on the server side becomes API_KEY inside the user's shell. This would give stronger isolation but is likely a breaking change: operators currently set env vars in their Dockerfile / compose / launch scripts and expect them to pass through to user commands. For that reason I did not choose this approach.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-terminal/pull/128 **Author:** [@mazzz1y](https://github.com/mazzz1y) **Created:** 5/19/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `security/sanitize-subprocess-env` --- ### 📝 Commits (1) - [`d349c51`](https://github.com/open-webui/open-terminal/commit/d349c5126133e616ea993b43e565a1fa280d7efa) security: strip OPEN_TERMINAL_* from subprocess env ### 📊 Changes **3 files changed** (+25 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `open_terminal/env.py` (+18 -0) 📝 `open_terminal/main.py` (+4 -4) 📝 `open_terminal/utils/runner.py` (+3 -3) </details> ### 📄 Description User-spawned shells and commands inherited the full parent environment, including `OPEN_TERMINAL_API_KEY`. A user running `env | grep OPEN_TERMINAL_` inside an `/execute` command or `/api/terminals` session could read internal configuration meant only for the server process. This is the minimal, conservative fix: - `OPEN_TERMINAL_*` keys are stripped. Other variables such as `PATH`, `HOME`, `USER`, `SHELL`, `TERM`, `LANG`, etc pass through unchanged, so user shells continue to feel normal. - Caller-supplied `env` in `POST /execute` still wins on collision — authenticated callers can explicitly re-add any variable. Tested in my environment — REST API with OpenWebUI Another option was introducing a prefix convention to fully separate server variables from sandbox variables — e.g. `SANDBOX_API_KEY` on the server side becomes `API_KEY` inside the user's shell. This would give stronger isolation but is likely a breaking change: operators currently set env vars in their Dockerfile / compose / launch scripts and expect them to pass through to user commands. For that reason I did not choose this approach. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
open-webui/open-terminal#130
No description provided.