## 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 ```bash 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: ```python import datetime, jwt, uuid SECRET = "my-test-key-but-now-longer-than-32-bytes" EMAIL = "[email protected]" # 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="") ``` ```bash TOKEN=$

AI Analysis