Summary
The executecode plugin extracts Python code blocks from user prompts and executes them on the server using a live Jupyter ExecutePreprocessor kernel with no sandboxing whatsoever. This allows any client to achieve full remote code execution with the server process's OS privileges.
Affected Code
File: optillm/plugins/executecode_plugin.py, lines 60–73
def run(system_prompt, initial_query, client, model):
query, request_code = extract_python_code(initial_query)[0] if extract_python_code(initial_query) else (initial_query, "")
if should_execute_request_code(query) and request_code:
code_output = execute_code(request_code) # No sandbox
The should_execute_request_code() gate only checks for common words (run, execute, output, result) — trivially satisfied by any real request.
execute_code() (lines 29–56) creates a Jupyter notebook and runs arbitrary Python via ExecutePreprocessor(timeout=30, kernel_name='python3') as the server's OS user, with no chroot, container, seccomp, or capability restrictions.
Reproduction
- Start optillm with
--approach executecode or use the executecode- model prefix.
- Send:
curl -X POST http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "executecode-gpt-4o-mini",
"messages": [{"role": "user",
"content": "Please run this code:\n```python\nimport os; print(os.popen(\"id\").read())\n```"}]
}'
- The server executes the code with full OS privileges and returns the output.
Impact
- Full host compromise: arbitrary file read/write, process execution, network egress
- Credential exfiltration: environment variables,
~/.ssh, API keys on disk, cloud IMDS
- Lateral movement: the server can reach internal services the client cannot
- If
optillm_api_key is unset (the default), zero credentials are required
- Even with an API key set, any authorized client can fully compromise the host
Suggested Fix
Short-term: Disable the executecode plugin by default; require explicit opt-in with a documented warning that it must only be used in air-gapped, single-user environments.
Long-term: Run code execution inside an isolated sandbox (nsjail, gVisor, Firecracker) with no network, no host filesystem access, and CPU/memory limits.
Found via automated codebase analysis. Confirmed independently by three reviewers (Claude, Codex, Gemini).
Summary
The
executecodeplugin extracts Python code blocks from user prompts and executes them on the server using a live JupyterExecutePreprocessorkernel with no sandboxing whatsoever. This allows any client to achieve full remote code execution with the server process's OS privileges.Affected Code
File:
optillm/plugins/executecode_plugin.py, lines 60–73The
should_execute_request_code()gate only checks for common words (run,execute,output,result) — trivially satisfied by any real request.execute_code()(lines 29–56) creates a Jupyter notebook and runs arbitrary Python viaExecutePreprocessor(timeout=30, kernel_name='python3')as the server's OS user, with nochroot, container,seccomp, or capability restrictions.Reproduction
--approach executecodeor use theexecutecode-model prefix.Impact
~/.ssh, API keys on disk, cloud IMDSoptillm_api_keyis unset (the default), zero credentials are requiredSuggested Fix
Short-term: Disable the
executecodeplugin by default; require explicit opt-in with a documented warning that it must only be used in air-gapped, single-user environments.Long-term: Run code execution inside an isolated sandbox (nsjail, gVisor, Firecracker) with no network, no host filesystem access, and CPU/memory limits.
Found via automated codebase analysis. Confirmed independently by three reviewers (Claude, Codex, Gemini).