A high-throughput and memory-efficient inference and serving engine for LLMs
Mirrored from https://github.com/tduncan-lum/Nvidia-Optimization-Stack---VLLM.git
Synced Nov 7, 06:30 UTC
[Docs] Document security risks of GPT-OSS Python tool (#35139)
Signed-off-by: Russell Bryant <rbryant@redhat.com>
Russell Bryant committed
Mar 4, 2026 at 15:27 UTC
636ee223ac976dfc3d4e93b31d33521230810f00
2 files changed
+46
-2
docs/usage/security.md
+41
@@ -219,6 +219,47 @@ The most effective approach is to deploy vLLM behind a reverse proxy (such as ng
219
- Blocks all other endpoints, including the unauthenticated inference and operational control endpoints
220
- Implements additional authentication, rate limiting, and logging at the proxy layer
221
222
+## Tool Server and MCP Security
223
+
224
+vLLM supports connecting to external tool servers via the `--tool-server` argument. This enables models to call tools through the Responses API (`/v1/responses`). Tool server support works with all models — it is not limited to specific model architectures.
225
+
226
+**Important:** No tool servers are enabled by default. They must be explicitly opted into via configuration.
227
+
228
+### Built-in Demo Tools (GPT-OSS)
229
+
230
+Passing `--tool-server demo` enables built-in demo tools that work with any model that supports tool calling. The tool implementations are not part of vLLM — they are provided by the separately installed [`gpt-oss`](https://github.com/openai/gpt-oss) package. vLLM provides thin wrappers that delegate to `gpt-oss`.
231
+
232
+- **Code interpreter** (`python`): Python execution via Docker (via `gpt_oss.tools.python_docker`)
233
+- **Web browser** (`browser`): Search via Exa API, requires `EXA_API_KEY` (via `gpt_oss.tools.simple_browser`)
234
+
235
+#### Code Interpreter (Python Tool) Security Risks
236
+
237
+The code interpreter executes model-generated code inside a Docker container. However, the container is **not configured with network isolation by default**. It inherits the host's Docker networking configuration (e.g., default bridge network or `--network=host`), which means:
238
+
239
+- The container may be able to access the host network and LAN.
240
+- Internal services reachable from the container may be exploited via SSRF (Server-Side Request Forgery).
241
+- Cloud metadata services (e.g., `169.254.169.254`) may be accessible.
242
+- If vulnerable internal services (such as `torch.distributed` endpoints) are reachable from the container, this could be used to attack them.
243
+
244
+This is particularly concerning because the code being executed is generated by the model, which may be influenced by adversarial inputs (prompt injection).
245
+
246
+#### Controlling Built-in Tool Availability
247
+
248
+Built-in demo tools are controlled by two settings:
249
+
250
+1. **`--tool-server demo`**: Enables the built-in demo tools (browser and Python code interpreter).
251
+
252
+2. **`VLLM_GPT_OSS_SYSTEM_TOOL_MCP_LABELS`**: When built-in tools are requested via the `mcp` tool type in the Responses API, this comma-separated allowlist controls which tool labels are permitted. Valid values are:
253
+ - `container` - Container tool
254
+ - `code_interpreter` - Python code execution tool
255
+ - `web_search_preview` - Web search/browser tool
256
+
257
+ If this variable is not set or is empty, no built-in tools requested via MCP tool type will be enabled.
258
+
259
+To disable the Python code interpreter specifically, omit `code_interpreter` from `VLLM_GPT_OSS_SYSTEM_TOOL_MCP_LABELS`.
260
+
261
+**Consider a custom implementation**: The GPT-OSS Python tool is a reference implementation. For production deployments, consider implementing a custom code execution sandbox with stricter isolation guarantees. See the [GPT-OSS documentation](https://github.com/openai/gpt-oss?tab=readme-ov-file#python) for guidance.
262
+
263
## Reporting Security Vulnerabilities
264
265
If you believe you have found a security vulnerability in vLLM, please report it following the project's security policy. For more information on how to report security issues and the project's security policy, please see the [vLLM Security Policy](https://github.com/vllm-project/vllm/blob/main/SECURITY.md).
vllm/entrypoints/openai/cli_args.py
+5
-2
@@ -125,8 +125,11 @@ class BaseFrontendArgs:
125
`--tool-call-parser`."""
126
tool_server: str | None = None
127
"""Comma-separated list of host:port pairs (IPv4, IPv6, or hostname).
128
- Examples: 127.0.0.1:8000, [::1]:8000, localhost:1234. Or `demo` for demo
129
- purpose."""
128
+ Examples: 127.0.0.1:8000, [::1]:8000, localhost:1234. Or `demo` for
129
+ built-in demo tools (browser and Python code interpreter). WARNING:
130
+ The `demo` Python tool executes model-generated code in Docker without
131
+ network isolation by default. See the security guide for more
132
+ information."""
133
log_config_file: str | None = envs.VLLM_LOGGING_CONFIG_PATH
134
"""Path to logging config JSON file for both vllm and uvicorn"""
135
max_log_len: int | None = None