CWE-346
Allowed-with-ReviewOrigin Validation Error
Abstraction: Class · Status: Draft
The product does not properly verify that the source of data or communication is valid.
789 vulnerabilities reference this CWE, most recent first.
GHSA-873C-CC79-4G4Q
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2026-04-02 21:32A cookie management issue was addressed with improved state management. This issue is fixed in Safari 18.1, visionOS 2.1, tvOS 18.1, iOS 18.1 and iPadOS 18.1, watchOS 11.1. Cookies belonging to one origin may be sent to another origin.
{
"affected": [],
"aliases": [
"CVE-2024-44212"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:15:23Z",
"severity": "MODERATE"
},
"details": "A cookie management issue was addressed with improved state management. This issue is fixed in Safari 18.1, visionOS 2.1, tvOS 18.1, iOS 18.1 and iPadOS 18.1, watchOS 11.1. Cookies belonging to one origin may be sent to another origin.",
"id": "GHSA-873c-cc79-4g4q",
"modified": "2026-04-02T21:32:01Z",
"published": "2024-12-12T03:33:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44212"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121563"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121564"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121565"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121566"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121569"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121571"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8788-3QJ3-84J7
Vulnerability from github – Published: 2023-01-18 15:30 – Updated: 2023-01-26 18:30Plex media server 1.21 and before is vulnerable to ddos reflection attack via plex service.
{
"affected": [],
"aliases": [
"CVE-2021-33959"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-18T14:15:00Z",
"severity": "HIGH"
},
"details": "Plex media server 1.21 and before is vulnerable to ddos reflection attack via plex service.",
"id": "GHSA-8788-3qj3-84j7",
"modified": "2023-01-26T18:30:48Z",
"published": "2023-01-18T15:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33959"
},
{
"type": "WEB",
"url": "https://github.com/lixiang957/CVE-2021-33959"
},
{
"type": "WEB",
"url": "https://www.freebuf.com/articles/web/260338.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-89V2-PQFV-C5R9
Vulnerability from github – Published: 2024-10-10 21:36 – Updated: 2025-01-21 17:53Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability relates to CORS origin validation accepting a null origin. When a Gradio server is deployed locally, the localhost_aliases variable includes "null" as a valid origin. This allows attackers to make unauthorized requests from sandboxed iframes or other sources with a null origin, potentially leading to data theft, such as user authentication tokens or uploaded files. This impacts users running Gradio locally, especially those using basic authentication.
Patches
Yes, please upgrade to gradio>=5.0 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can manually modify the localhost_aliases list in their local Gradio deployment to exclude "null" as a valid origin. By removing this value, the Gradio server will no longer accept requests from sandboxed iframes or sources with a null origin, mitigating the potential for exploitation.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gradio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-47165"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-10T21:36:36Z",
"nvd_published_at": "2024-10-10T22:15:10Z",
"severity": "MODERATE"
},
"details": "### Impact\n**What kind of vulnerability is it? Who is impacted?**\n\nThis vulnerability relates to **CORS origin validation accepting a null origin**. When a Gradio server is deployed locally, the `localhost_aliases` variable includes \"null\" as a valid origin. This allows attackers to make unauthorized requests from sandboxed iframes or other sources with a null origin, potentially leading to data theft, such as user authentication tokens or uploaded files. This impacts users running Gradio locally, especially those using basic authentication.\n\n### Patches\nYes, please upgrade to `gradio\u003e=5.0` to address this issue.\n\n### Workarounds\n**Is there a way for users to fix or remediate the vulnerability without upgrading?**\n\nAs a workaround, users can manually modify the `localhost_aliases` list in their local Gradio deployment to exclude \"null\" as a valid origin. By removing this value, the Gradio server will no longer accept requests from sandboxed iframes or sources with a null origin, mitigating the potential for exploitation.",
"id": "GHSA-89v2-pqfv-c5r9",
"modified": "2025-01-21T17:53:31Z",
"published": "2024-10-10T21:36:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/security/advisories/GHSA-89v2-pqfv-c5r9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47165"
},
{
"type": "PACKAGE",
"url": "https://github.com/gradio-app/gradio"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/gradio/PYSEC-2024-214.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Gradio\u0027s CORS origin validation accepts the null origin"
}
GHSA-89VP-X53W-74FX
Vulnerability from github – Published: 2026-05-06 21:55 – Updated: 2026-05-19 20:17Summary
Prior to version 1.4.0, the rmcp crate's Streamable HTTP server transport (crates/rmcp/src/transport/streamable_http_server/) did not validate the incoming Host header. This allowed a malicious public website, via a DNS rebinding attack, to send authenticated requests to an MCP server running on the victim's loopback or private-network interface — violating the MCP specification's transport security guidance.
Impact
An attacker who convinces a victim to visit a malicious page can:
- Enumerate and invoke any tool exposed by a locally-running rmcp-based MCP server.
- Read resources, prompts, and any state accessible via the MCP session.
- Trigger side effects (file writes, shell execution, API calls, etc.) limited only by what tools the victim's server exposes.
Because MCP servers frequently run with the user's privileges and expose developer tooling (filesystems, shells, browser control, language servers, etc.), the practical impact can extend to arbitrary code execution on the victim's machine.
Affected Versions
rmcp < 1.4.0 — all prior releases of the Streamable HTTP server transport. Non-HTTP transports (stdio, child-process) are not affected.
Patched Versions
rmcp >= 1.4.0 (current: 1.5.1).
Patch
Fixed in PR #764 (commit 8e22aa2), released as v1.4.0 on 2026-04-09:
StreamableHttpServerConfig::allowed_hostsnow defaults to a loopback-only allowlist:["localhost", "127.0.0.1", "::1"].- All incoming HTTP requests pass through
validate_dns_rebinding_headers(), which parses theHostheader and returns HTTP 403 if the host is not on the allowlist. - Public deployments can configure an explicit allowlist via
StreamableHttpService::with_allowed_hosts(...), or opt out (not recommended without an upstream reverse proxy that validatesHost) viadisable_allowed_hosts().
This fix validates the Host header only. Origin header validation is tracked as a defense-in-depth follow-up in #822 and is not required to block the DNS rebinding attack described here — the browser cannot forge the Host header sent to the rebound server.
Workarounds for Unpatched Users
- Upgrade to
rmcp >= 1.4.0. - If upgrade is not possible, place the MCP server behind a reverse proxy (e.g. nginx, Caddy) configured to reject requests whose
Hostheader is not one of your expected hostnames. - Do not bind the MCP server to
0.0.0.0without such a proxy.
Resources
- PR: https://github.com/modelcontextprotocol/rust-sdk/pull/764
- Issue: https://github.com/modelcontextprotocol/rust-sdk/issues/815
- Follow-up (Origin validation): https://github.com/modelcontextprotocol/rust-sdk/issues/822
- MCP transport security guidance: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning
Related advisories (same class of vulnerability)
- TypeScript SDK: GHSA-w48q-cv73-mx4w
- Python SDK: GHSA-9h52-p55h-vw2f
- Go SDK: GHSA-xw59-hvm2-8pj6
- Java SDK: GHSA-8jxr-pr72-r468
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "rmcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42559"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-350"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T21:55:56Z",
"nvd_published_at": "2026-05-14T15:16:46Z",
"severity": "HIGH"
},
"details": "## Summary\n\nPrior to version 1.4.0, the `rmcp` crate\u0027s Streamable HTTP server transport (`crates/rmcp/src/transport/streamable_http_server/`) did not validate the incoming `Host` header. This allowed a malicious public website, via a DNS rebinding attack, to send authenticated requests to an MCP server running on the victim\u0027s loopback or private-network interface \u2014 violating the MCP specification\u0027s [transport security guidance](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning).\n\n## Impact\n\nAn attacker who convinces a victim to visit a malicious page can:\n\n- Enumerate and invoke any tool exposed by a locally-running rmcp-based MCP server.\n- Read resources, prompts, and any state accessible via the MCP session.\n- Trigger side effects (file writes, shell execution, API calls, etc.) limited only by what tools the victim\u0027s server exposes.\n\nBecause MCP servers frequently run with the user\u0027s privileges and expose developer tooling (filesystems, shells, browser control, language servers, etc.), the practical impact can extend to arbitrary code execution on the victim\u0027s machine.\n\n## Affected Versions\n\n`rmcp \u003c 1.4.0` \u2014 all prior releases of the Streamable HTTP server transport. Non-HTTP transports (stdio, child-process) are not affected.\n\n## Patched Versions\n\n`rmcp \u003e= 1.4.0` (current: 1.5.1).\n\n## Patch\n\nFixed in [PR #764](https://github.com/modelcontextprotocol/rust-sdk/pull/764) (commit `8e22aa2`), released as v1.4.0 on 2026-04-09:\n\n- `StreamableHttpServerConfig::allowed_hosts` now defaults to a loopback-only allowlist: `[\"localhost\", \"127.0.0.1\", \"::1\"]`.\n- All incoming HTTP requests pass through `validate_dns_rebinding_headers()`, which parses the `Host` header and returns HTTP 403 if the host is not on the allowlist.\n- Public deployments can configure an explicit allowlist via `StreamableHttpService::with_allowed_hosts(...)`, or opt out (not recommended without an upstream reverse proxy that validates `Host`) via `disable_allowed_hosts()`.\n\nThis fix validates the `Host` header only. `Origin` header validation is tracked as a defense-in-depth follow-up in [#822](https://github.com/modelcontextprotocol/rust-sdk/issues/822) and is not required to block the DNS rebinding attack described here \u2014 the browser cannot forge the Host header sent to the rebound server.\n\n## Workarounds for Unpatched Users\n\n- Upgrade to `rmcp \u003e= 1.4.0`.\n- If upgrade is not possible, place the MCP server behind a reverse proxy (e.g. nginx, Caddy) configured to reject requests whose `Host` header is not one of your expected hostnames.\n- Do not bind the MCP server to `0.0.0.0` without such a proxy.\n\n## Resources\n\n- PR: https://github.com/modelcontextprotocol/rust-sdk/pull/764\n- Issue: https://github.com/modelcontextprotocol/rust-sdk/issues/815\n- Follow-up (Origin validation): https://github.com/modelcontextprotocol/rust-sdk/issues/822\n- MCP transport security guidance: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning\n\n## Related advisories (same class of vulnerability)\n\n- TypeScript SDK: GHSA-w48q-cv73-mx4w\n- Python SDK: GHSA-9h52-p55h-vw2f\n- Go SDK: GHSA-xw59-hvm2-8pj6\n- Java SDK: GHSA-8jxr-pr72-r468",
"id": "GHSA-89vp-x53w-74fx",
"modified": "2026-05-19T20:17:47Z",
"published": "2026-05-06T21:55:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-89vp-x53w-74fx"
},
{
"type": "WEB",
"url": "https://github.com/nubo-db/dynoxide/security/advisories/GHSA-fvh2-gm75-j4j7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42559"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/issues/815"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/issues/822"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/pull/764"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/rust-sdk/commit/8e22aa2de28df5a285eed87c11cd89bf15fa90d3"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/rust-sdk"
},
{
"type": "WEB",
"url": "https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0140.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "rmcp Streamable HTTP server transport has a DNS rebinding vulnerability"
}
GHSA-8F6Q-MPH6-G8FX
Vulnerability from github – Published: 2024-07-09 09:30 – Updated: 2024-07-09 09:30There is a permissions and access control vulnerability in ZXCLOUD IRAI.An attacker can elevate non-administrator permissions to administrator permissions by modifying the configuration.
{
"affected": [],
"aliases": [
"CVE-2024-22062"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T07:15:03Z",
"severity": "MODERATE"
},
"details": "There is a permissions and access control vulnerability in ZXCLOUD IRAI.An attacker can elevate non-administrator permissions to administrator permissions by modifying the configuration.",
"id": "GHSA-8f6q-mph6-g8fx",
"modified": "2024-07-09T09:30:54Z",
"published": "2024-07-09T09:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22062"
},
{
"type": "WEB",
"url": "https://support.zte.com.cn/support/news/LoopholeInfoDetail.aspx?newsId=1036204"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-8G45-3JXC-CV2V
Vulnerability from github – Published: 2026-05-29 00:38 – Updated: 2026-05-29 21:31Inappropriate implementation in Media in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to bypass same origin policy via a crafted video file. (Chromium security severity: High)
{
"affected": [],
"aliases": [
"CVE-2026-9989"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T23:16:57Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Media in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to bypass same origin policy via a crafted video file. (Chromium security severity: High)",
"id": "GHSA-8g45-3jxc-cv2v",
"modified": "2026-05-29T21:31:20Z",
"published": "2026-05-29T00:38:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9989"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_0877304591.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/513054053"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-8H68-WR7W-W8W5
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12Incorrect security UI in Navigation in Google Chrome on Android prior to 92.0.4515.131 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2021-30596"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-26T18:15:00Z",
"severity": "MODERATE"
},
"details": "Incorrect security UI in Navigation in Google Chrome on Android prior to 92.0.4515.131 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.",
"id": "GHSA-8h68-wr7w-w8w5",
"modified": "2022-05-24T19:12:16Z",
"published": "2022-05-24T19:12:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30596"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/08/the-stable-channel-has-been-updated-to.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1214481"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5LVY4WIWTVVYKQMROJJS365TZBKEARCF"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IPJPUSAWIJMQFBQQQYXAICLI4EKFQOH6"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QW4R2K5HVJ4R6XDZYOJCCFPIN2XHNS3L"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8JPP-C53F-GVRM
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48The server in npupnp before 4.1.4 is affected by DNS rebinding in the embedded web server (including UPnP SOAP and GENA endpoints), leading to remote code execution.
{
"affected": [],
"aliases": [
"CVE-2021-31718"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-25T19:15:00Z",
"severity": "HIGH"
},
"details": "The server in npupnp before 4.1.4 is affected by DNS rebinding in the embedded web server (including UPnP SOAP and GENA endpoints), leading to remote code execution.",
"id": "GHSA-8jpp-c53f-gvrm",
"modified": "2022-05-24T17:48:45Z",
"published": "2022-05-24T17:48:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31718"
},
{
"type": "WEB",
"url": "https://framagit.org/medoc92/npupnp"
},
{
"type": "WEB",
"url": "https://www.lesbonscomptes.com/upmpdcli/npupnp-doc/libnpupnp.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/04/25/2"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8JXR-PR72-R468
Vulnerability from github – Published: 2026-04-07 20:13 – Updated: 2026-04-08 11:57Summary
The java-sdk contains a DNS rebinding vulnerability. This vulnerability allows an attacker to access a locally or network-private java-sdk MCP server via a victims browser that is either local, or network adjacent.
This allows an attacker to make any tool call to the server as if they were a locally running MCP connected AI agent.
Details
Prior to 1.0.0 no Origin header validation was occurring, in violation of the MCP specification. Base Protocol > Transports: 2.0.1 Security Warning:
1: Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks.
When the web server serving HTTP traffic to the MCP server does not perform standard CORS checks, a DNS rebinding attack is possible.
Some default server configurations and frameworks come with embedded Origin header validation. MCP servers built using those are not vulnerable to this issue. For example, the following are NOT vulnerable:
- Spring AI
Impact
Any developer connecting to a malicious website can inadvertently allow an attacker to make tool calls to local or private-network MCP servers.
Workarounds
Users can mitigate this risk by:
1. Running the MCP server behind a reverse proxy (like Nginx or HAProxy) configured to strictly validate the Host and Origin headers.
2. Using a framework that inherently enforces strict CORS and Origin validation (such as Spring AI).
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.modelcontextprotocol.sdk:mcp-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35568"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-07T20:13:32Z",
"nvd_published_at": "2026-04-07T22:16:23Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe java-sdk contains a DNS rebinding vulnerability. This vulnerability allows an attacker to access a locally or network-private java-sdk MCP server via a victims browser that is either local, or network adjacent.\n\nThis allows an attacker to make any tool call to the server as if they were a locally running MCP connected AI agent.\n\n### Details\n\nPrior to 1.0.0 no Origin header validation was occurring, in violation of the MCP specification. [Base Protocol \u003e Transports: 2.0.1 Security Warning](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning):\n\n\u003e 1: Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks.\n\nWhen the web server serving HTTP traffic to the MCP server does not perform standard CORS checks, a DNS rebinding attack is possible.\n\nSome default server configurations and frameworks come with embedded `Origin` header validation. MCP servers built using those are not vulnerable to this issue. For example, the following are NOT vulnerable:\n- Spring AI\n\n### Impact\n\nAny developer connecting to a malicious website can inadvertently allow an attacker to make tool calls to local or private-network MCP servers.\n\n### Workarounds\n\nUsers can mitigate this risk by:\n1. Running the MCP server behind a reverse proxy (like Nginx or HAProxy) configured to strictly validate the `Host` and `Origin` headers.\n2. Using a framework that inherently enforces strict CORS and Origin validation (such as Spring AI).",
"id": "GHSA-8jxr-pr72-r468",
"modified": "2026-04-08T11:57:14Z",
"published": "2026-04-07T20:13:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/java-sdk/security/advisories/GHSA-8jxr-pr72-r468"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35568"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/java-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/java-sdk/releases/tag/v1.0.0"
}
],
"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": "Java-SDK has a DNS Rebinding Vulnerability"
}
GHSA-8M32-P958-JG99
Vulnerability from github – Published: 2026-04-04 06:06 – Updated: 2026-04-07 14:19Summary
Directus's Single Sign-On (SSO) login pages lacked a Cross-Origin-Opener-Policy (COOP) HTTP response header. Without this header, a malicious cross-origin window that opens the Directus login page retains the ability to access and manipulate the window object of that page. An attacker can exploit this to intercept and redirect the OAuth authorization flow to an attacker-controlled OAuth client, causing the victim to unknowingly grant access to their authentication provider account (e.g. Google, Discord).
Impact
A successful attack allows the attacker to obtain an OAuth access token for the victim's third-party identity provider account. Depending on the scopes authorized, this can lead to: - Unauthorized access to the victim's linked identity provider account - Account takeover of the Directus instance if the attacker can authenticate using the stolen credentials or provider session
Patches
This issue has been addressed by adding the Cross-Origin-Opener-Policy: same-origin HTTP response header to SSO-related endpoints. This header instructs the browser to place the page in its own browsing context group, severing any reference the opener window may hold.
Workarounds
Users who are unable to upgrade immediately can mitigate this vulnerability by configuring their reverse proxy or web server to add the following HTTP response header to all Directus responses: Cross-Origin-Opener-Policy: same-origin
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.17.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35408"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-04T06:06:00Z",
"nvd_published_at": "2026-04-06T22:16:21Z",
"severity": "HIGH"
},
"details": "## Summary\n\nDirectus\u0027s Single Sign-On (SSO) login pages lacked a `Cross-Origin-Opener-Policy` (COOP) HTTP response header. Without this header, a malicious cross-origin window that opens the Directus login page retains the ability to access and manipulate the `window` object of that page. An attacker can exploit this to intercept and redirect the OAuth authorization flow to an attacker-controlled OAuth client, causing the victim to unknowingly grant access to their authentication provider account (e.g. Google, Discord).\n\n## Impact\n\nA successful attack allows the attacker to obtain an OAuth access token for the victim\u0027s third-party identity provider account. Depending on the scopes authorized, this can lead to:\n- Unauthorized access to the victim\u0027s linked identity provider account\n- Account takeover of the Directus instance if the attacker can authenticate using the stolen credentials or provider session\n\n## Patches\n\nThis issue has been addressed by adding the `Cross-Origin-Opener-Policy: same-origin` HTTP response header to SSO-related endpoints. This header instructs the browser to place the page in its own browsing context group, severing any reference the opener window may hold.\n\n## Workarounds\n\nUsers who are unable to upgrade immediately can mitigate this vulnerability by configuring their reverse proxy or web server to add the following HTTP response header to all Directus responses: `Cross-Origin-Opener-Policy: same-origin`",
"id": "GHSA-8m32-p958-jg99",
"modified": "2026-04-07T14:19:49Z",
"published": "2026-04-04T06:06:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-8m32-p958-jg99"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35408"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Directus: Missing Cross-Origin Opener Policy"
}
No mitigation information available for this CWE.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
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-160: Exploit Script-Based APIs
Some APIs support scripting instructions as arguments. Methods that take scripted instructions (or references to scripted instructions) can be very flexible and powerful. However, if an attacker can specify the script that serves as input to these methods they can gain access to a great deal of functionality. For example, HTML pages support <script> tags that allow scripting languages to be embedded in the page and then interpreted by the receiving web browser. If the content provider is malicious, these scripts can compromise the client application. Some applications may even execute the scripts under their own identity (rather than the identity of the user providing the script) which can allow attackers to perform activities that would otherwise be denied to them.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.
CAPEC-510: SaaS User Request Forgery
An adversary, through a previously installed malicious application, performs malicious actions against a third-party Software as a Service (SaaS) application (also known as a cloud based application) by leveraging the persistent and implicit trust placed on a trusted user's session. This attack is executed after a trusted user is authenticated into a cloud service, "piggy-backing" on the authenticated session, and exploiting the fact that the cloud service believes it is only interacting with the trusted user. If successful, the actions embedded in the malicious application will be processed and accepted by the targeted SaaS application and executed at the trusted user's privilege level.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-75: Manipulating Writeable Configuration Files
Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
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.