GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-1385

Allowed

Missing Origin Validation in WebSockets

Abstraction: Variant · Status: Incomplete

API response cwe.mitre.org

The product uses a WebSocket, but it does not properly verify that the source of data or communication is valid.

61 vulnerabilities reference this CWE, most recent first.

GHSA-MJF5-7G4M-GX5W

Vulnerability from github – Published: 2026-02-26 15:16 – Updated: 2026-02-26 15:16
VLAI
Summary
Storybook Dev Server is Vulnerable to WebSocket Hijacking
Details

Summary

The WebSocket functionality in Storybook's dev server, used to create and update stories, is vulnerable to WebSocket hijacking. This vulnerability only affects the Storybook dev server; production builds are not impacted.

Details

Exploitation requires a developer to visit a malicious website while their local Storybook dev server is running. Because the WebSocket connection does not validate the origin of incoming connections, a malicious site can silently send WebSocket messages to the local instance without any further user interaction.

If a Storybook dev server is intentionally exposed publicly (e.g. for design reviews or stakeholder demos) the risk is higher, as no malicious site visit is required. Any unauthenticated attacker can send WebSocket messages to it directly.

The vulnerability affects the WebSocket message handlers for creating and saving stories, which can be exploited via unauthorized WebSocket connections to achieve persistent XSS or Remote Code Execution (RCE).

Note: recent versions of Chrome have some protections against this, but Firefox does not.

Impact

This vulnerability can lead to supply chain compromise. Key risks include:

  • Remote Code Execution: The vulnerability can allow attackers to execute malicious code, with the extent of impact depending on the configuration. Server-side RCE is possible in non-default configurations, such as when stories are executed via portable stories in JSDOM, potentially allowing attackers to exfiltrate credentials and environment variables, access source code and the filesystem, establish backdoors, or pivot to internal network resources.
  • Persistent XSS: Malicious payloads are written directly into story source files. If the malicious payload is committed to version control, it becomes part of the codebase and can propagate to deployed Storybook documentation sites, affecting developers and stakeholders who view them.
  • Supply Chain Propagation: If the modified source files are committed, injected code can spread to other team members via git, execute in CI/CD pipelines, and affect shared component libraries used across multiple projects.

Affected versions

8.1 and above. While the exploitable functionality was introduced in 8.1, the patch has been applied to 7.x as a precautionary measure given the underlying WebSocket behaviour.

Recommended actions

Update to one of the patched versions: 7.6.23, 8.6.17, 9.1.19, 10.2.10.

Severity
8.9 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.1.0"
            },
            {
              "fixed": "8.6.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.7.0-alpha.0"
            },
            {
              "fixed": "9.1.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0-beta.0"
            },
            {
              "fixed": "10.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27148"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385",
      "CWE-74",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-26T15:16:10Z",
    "nvd_published_at": "2026-02-25T22:16:25Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe WebSocket functionality in Storybook\u0027s dev server, used to create and update stories, is vulnerable to WebSocket hijacking. This vulnerability **only affects the Storybook dev server; production builds are not impacted**.\n\n### Details\n\nExploitation requires a developer to visit a malicious website while their local Storybook dev server is running. Because the WebSocket connection does not validate the origin of incoming connections, a malicious site can silently send WebSocket messages to the local instance without any further user interaction.\n\nIf a Storybook dev server is intentionally exposed publicly (e.g. for design reviews or stakeholder demos) the risk is higher, as no malicious site visit is required. Any unauthenticated attacker can send WebSocket messages to it directly.\n\nThe vulnerability affects the WebSocket message handlers for creating and saving stories, which can be exploited via unauthorized WebSocket connections to achieve persistent XSS or Remote Code Execution (RCE).\n\n_Note: recent versions of Chrome have some protections against this, but Firefox does not._\n\n### Impact\nThis vulnerability can lead to supply chain compromise. Key risks include:\n\n- **Remote Code Execution**: The vulnerability can allow attackers to execute malicious code, with the extent of impact depending on the configuration. Server-side RCE is possible in non-default configurations, such as when stories are executed via portable stories in JSDOM, potentially allowing attackers to exfiltrate credentials and environment variables, access source code and the filesystem, establish backdoors, or pivot to internal network resources.\n- **Persistent XSS**: Malicious payloads are written directly into story source files. If the malicious payload is committed to version control, it becomes part of the codebase and can propagate to deployed Storybook documentation sites, affecting developers and stakeholders who view them.\n- **Supply Chain Propagation**: If the modified source files are committed, injected code can spread to other team members via git, execute in CI/CD pipelines, and affect shared component libraries used across multiple projects.\n\n### Affected versions\n\n8.1 and above. While the exploitable functionality was introduced in 8.1, the patch has been applied to 7.x as a precautionary measure given the underlying WebSocket behaviour.\n\n### Recommended actions\nUpdate to one of the patched versions: `7.6.23`, `8.6.17`, `9.1.19`, `10.2.10`.",
  "id": "GHSA-mjf5-7g4m-gx5w",
  "modified": "2026-02-26T15:16:10Z",
  "published": "2026-02-26T15:16:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/security/advisories/GHSA-mjf5-7g4m-gx5w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27148"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/commit/0affdf928bd6fafbadfb1dfe22ce6104805e10e8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/commit/54689a8add18ea75d628c540f4bc677592a1e685"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/commit/b8cfa77c73940c140acdcd8a06ab1ea913c44761"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/commit/d34085f39c647f5c23c3a3b2d197c18602fcf876"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/storybookjs/storybook"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/releases/tag/v10.2.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/releases/tag/v7.6.23"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/releases/tag/v8.6.17"
    },
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/releases/tag/v9.1.19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Storybook Dev Server is Vulnerable to WebSocket Hijacking"
}

GHSA-MQMF-9G99-4JVX

Vulnerability from github – Published: 2023-01-09 21:30 – Updated: 2023-01-13 21:30
VLAI
Details

A vulnerability was found in lukehutch Gribbit. It has been classified as problematic. Affected is the function messageReceived of the file src/gribbit/request/HttpRequestHandler.java. The manipulation leads to missing origin validation in websockets. The name of the patch is 620418df247aebda3dd4be1dda10fe229ea505dd. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-217716.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2014-125071"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385",
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-09T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability was found in lukehutch Gribbit. It has been classified as problematic. Affected is the function messageReceived of the file src/gribbit/request/HttpRequestHandler.java. The manipulation leads to missing origin validation in websockets. The name of the patch is 620418df247aebda3dd4be1dda10fe229ea505dd. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-217716.",
  "id": "GHSA-mqmf-9g99-4jvx",
  "modified": "2023-01-13T21:30:28Z",
  "published": "2023-01-09T21:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-125071"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lukehutch/gribbit/commit/620418df247aebda3dd4be1dda10fe229ea505dd"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.217716"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.217716"
    }
  ],
  "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"
    }
  ]
}

GHSA-P773-8MF4-RJM5

Vulnerability from github – Published: 2026-02-12 18:30 – Updated: 2026-02-12 22:14
VLAI
Summary
@farmfe/core is Missing Origin Validation in WebSocket
Details

npm @farmfe/core before 1.7.6 is Missing Origin Validation in WebSocket. The development (hot module reloading) server does not validate origin when connecting to a WebSocket client. This allows attackers to surveil developers running Farm who visit their webpage and steal source code that is leaked by the WebSocket server.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@farmfe/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-56647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-12T22:14:11Z",
    "nvd_published_at": "2026-02-12T16:16:03Z",
    "severity": "MODERATE"
  },
  "details": "npm @farmfe/core before 1.7.6 is Missing Origin Validation in WebSocket. The development (hot module reloading) server does not validate origin when connecting to a WebSocket client. This allows attackers to surveil developers running Farm who visit their webpage and steal source code that is leaked by the WebSocket server.",
  "id": "GHSA-p773-8mf4-rjm5",
  "modified": "2026-02-12T22:14:12Z",
  "published": "2026-02-12T18:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56647"
    },
    {
      "type": "WEB",
      "url": "https://github.com/farm-fe/farm/issues/2168"
    },
    {
      "type": "WEB",
      "url": "https://github.com/farm-fe/farm/commit/83342ef06e0aea37270950fd8c930422c4df0679"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/R4356th/d4372c6f83275d583c180c0e7d7332af"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/farm-fe/farm"
    }
  ],
  "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": "@farmfe/core is Missing Origin Validation in WebSocket"
}

GHSA-Q355-H244-969H

Vulnerability from github – Published: 2025-08-12 00:13 – Updated: 2025-08-12 00:13
VLAI
Summary
Komari vulnerable to Cross-site WebSocket Hijacking
Details

Summary

WebSocket upgrader has disabled origin checking, enabling Cross-Site WebSocket Hijacking (CSWSH) attacks against authenticated users

Details

https://github.com/komari-monitor/komari/blob/bd5a6934e1b79a12cf1e6a9bba5372d0e04f3abc/api/terminal.go#L33-L35

Any third party website can send requests to the terminal websocket endpoint with browser's cookies, resulting in remote code execution

PoC

  1. Login in to your komari instance
  2. Hosting the following HTML code on internet, replace <komari-addr> and <target-uuid> into yours
  3. Visit this HTML page, you can see your node is executing uptime without your actions
<pre></pre>
<script>
const socket = new WebSocket("wss://<komari-addr>/api/admin/client/<target-uuid>/terminal");
socket.addEventListener("open", (event) => {
  const binaryBlob = new Blob(['uptime\n'], { type: 'application/octet-stream' });
  socket.send(binaryBlob);
});
socket.addEventListener("message", (event) => {
  event.data.text().then(x => {document.querySelector("pre").append(x)});
});
</script>

Impact

An administrator of a Komari instance will execute commands on their nodes unnoticed when visiting a malware page.

Severity
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/komari-monitor/komari"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20250809073044-53171affcaf0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-12T00:13:28Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWebSocket upgrader has disabled origin checking, enabling Cross-Site WebSocket Hijacking (CSWSH) attacks against authenticated users\n\n### Details\n\nhttps://github.com/komari-monitor/komari/blob/bd5a6934e1b79a12cf1e6a9bba5372d0e04f3abc/api/terminal.go#L33-L35\n\nAny third party website can send requests to the terminal websocket endpoint with browser\u0027s cookies, resulting in remote code execution\n\n### PoC\n\n1. Login in to your komari instance\n2. Hosting the following HTML code on internet, replace `\u003ckomari-addr\u003e` and `\u003ctarget-uuid\u003e` into yours\n3. Visit this HTML page, you can see your node is executing `uptime` without your actions\n\n```\n\u003cpre\u003e\u003c/pre\u003e\n\u003cscript\u003e\nconst socket = new WebSocket(\"wss://\u003ckomari-addr\u003e/api/admin/client/\u003ctarget-uuid\u003e/terminal\");\nsocket.addEventListener(\"open\", (event) =\u003e {\n  const binaryBlob = new Blob([\u0027uptime\\n\u0027], { type: \u0027application/octet-stream\u0027 });\n  socket.send(binaryBlob);\n});\nsocket.addEventListener(\"message\", (event) =\u003e {\n  event.data.text().then(x =\u003e {document.querySelector(\"pre\").append(x)});\n});\n\u003c/script\u003e\n```\n\n### Impact\n\nAn administrator of a Komari instance will execute commands on their nodes unnoticed when visiting a malware page.",
  "id": "GHSA-q355-h244-969h",
  "modified": "2025-08-12T00:13:29Z",
  "published": "2025-08-12T00:13:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/komari-monitor/komari/security/advisories/GHSA-q355-h244-969h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/komari-monitor/komari/commit/53171affcaf050145810efaaef420651a6e630be"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/komari-monitor/komari"
    },
    {
      "type": "WEB",
      "url": "https://github.com/komari-monitor/komari/blob/bd5a6934e1b79a12cf1e6a9bba5372d0e04f3abc/api/terminal.go#L33-L35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/komari-monitor/komari/releases/tag/1.0.4-fix2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Komari vulnerable to Cross-site WebSocket Hijacking"
}

GHSA-R2C5-M74G-GVX4

Vulnerability from github – Published: 2025-01-29 21:31 – Updated: 2025-01-29 21:31
VLAI
Details

Missing Origin Validation in WebSockets vulnerability in FLXEON. Session management was not sufficient to prevent unauthorized HTTPS requests. This issue affects FLXEON: through <= 9.3.4.

Severity
9.4 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H
8.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-48849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-29T19:15:18Z",
    "severity": "HIGH"
  },
  "details": "Missing Origin Validation in WebSockets vulnerability in\u00a0FLXEON. Session management was not sufficient to prevent unauthorized HTTPS requests.\u00a0This issue affects FLXEON: through \u003c= 9.3.4.",
  "id": "GHSA-r2c5-m74g-gvx4",
  "modified": "2025-01-29T21:31:24Z",
  "published": "2025-01-29T21:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48849"
    },
    {
      "type": "WEB",
      "url": "https://search.abb.com/library/Download.aspx?DocumentID=9AKK108470A5684\u0026LanguageCode=en\u0026DocumentPartId=PDF\u0026Action=Launch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-R3GQ-2JPG-6V2W

Vulnerability from github – Published: 2025-12-12 06:31 – Updated: 2025-12-12 06:31
VLAI
Details

GroupSession Free edition prior to ver5.3.0, GroupSession byCloud prior to ver5.3.3, and GroupSession ZION prior to ver5.3.2. do not validate origins in WebSockets. If a user accesses a crafted page, Chat information sent to the user may be exposed.

Severity
5.3 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-61987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-12T05:16:07Z",
    "severity": "MODERATE"
  },
  "details": "GroupSession Free edition prior to ver5.3.0, GroupSession byCloud prior to ver5.3.3, and GroupSession ZION prior to ver5.3.2. do not validate origins in WebSockets. If a user accesses a crafted page, Chat information sent to the user may be exposed.",
  "id": "GHSA-r3gq-2jpg-6v2w",
  "modified": "2025-12-12T06:31:14Z",
  "published": "2025-12-12T06:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61987"
    },
    {
      "type": "WEB",
      "url": "https://groupsession.jp/info/info-news/security20251208"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN19940619"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-R8MM-5386-H387

Vulnerability from github – Published: 2024-04-25 18:30 – Updated: 2024-04-25 18:30
VLAI
Details

A flaw was found in the ansible automation platform. An insecure WebSocket connection was being used in installation from the Ansible rulebook EDA server. An attacker that has access to any machine in the CIDR block could download all rulebook data from the WebSocket, resulting in loss of confidentiality and integrity of the system.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-1657"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385",
      "CWE-319"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-25T17:15:48Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the ansible automation platform. An insecure WebSocket connection was being used in installation from the Ansible rulebook EDA server. An attacker that has access to any machine in the CIDR block could download all rulebook data from the WebSocket, resulting in loss of confidentiality and integrity of the system.",
  "id": "GHSA-r8mm-5386-h387",
  "modified": "2024-04-25T18:30:39Z",
  "published": "2024-04-25T18:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1657"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:1057"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-1657"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2265085"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V8J7-HP7C-738F

Vulnerability from github – Published: 2026-05-07 02:34 – Updated: 2026-05-14 20:54
VLAI
Summary
Kubetail has a Cross-Site WebSocket Hijacking issue that allows attacker to read Kubernetes logs from authenticated users
Details

Summary

Kubetail's dashboard exposes WebSocket endpoints that did not adequately validate the Origin header on connection upgrade. A malicious web page visited by a user with an active Kubetail session could open a WebSocket to the user's dashboard and read their Kubernetes logs in real time. This is a Cross-Site WebSocket Hijacking (CSWSH) vulnerability and affects both the desktop deployment (default http://localhost:7500) and cluster deployments (typically behind an Ingress with HTTP basic auth).

Impact

An attacker who can convince an authenticated Kubetail user to visit a page they control can:

  • Establish a WebSocket connection to the victim's dashboard from the attacker's origin
  • Stream container logs the victim has access to via the Kubernetes API
  • Exfiltrate the contents to an attacker-controlled server

The attacker gains read-only access to logs — no write or destructive operations are exposed. However, container logs frequently contain credentials accidentally written by application code, bearer tokens, internal hostnames, customer PII, and other secrets, so the practical impact of read access can be significant.

The desktop deployment is particularly exposed because the dashboard is reachable at a predictable localhost URL, requires no network reachability from the attacker, and the browser will attach ambient credentials to the WebSocket handshake. For cluster deployments fronted by HTTP basic auth, the browser's automatic re-sending of basic-auth credentials on the WebSocket upgrade request enables the same attack against the configured dashboard origin.

Affected versions

Component Name Affected Patched
Kubetail Dashboard docker image kubetail-dashboard < 0.14.0 >= 0.14.0
Kubetail Helm Chart kubetail/kubetail < 0.23.0 >= 0.23.0
Kubetail CLI kubetail < 0.16.0 >= 0.16.0

Confirmed in Google Chrome. Microsoft Edge is presumed affected as it shares Chromium's WebSocket implementation, but was not directly tested.

Preconditions for exploitation

  1. The victim has an active authenticated Kubetail session (desktop dashboard running, or browser holding valid credentials for a cluster deployment).
  2. The victim visits a web page controlled by the attacker in the same browser.
  3. The attacker knows or can guess the dashboard URL (trivial for desktop; cluster deployments require knowing the Ingress hostname).

Patches

Upgrade to: * Kubetail Dashboard 0.14.0 or later * Kubetail Helm Chart 0.23.0 or later * Kubetail CLI 0.16.0 or later

Workarounds

If users cannot upgrade immediately:

  • Desktop: Stop the dashboard (kubetail CLI process) when not actively in use. Avoid visiting untrusted sites in the same browser profile while the dashboard is running.
  • Cluster: Restrict Ingress access to a VPN, bastion, or office network. Add a stronger outer authentication layer (e.g. OAuth proxy) in front of basic auth. Consider browser profile isolation for cluster admins.
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubetail-org/kubetail/modules/dashboard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubetail-org/kubetail/modules/cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44514"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T02:34:32Z",
    "nvd_published_at": "2026-05-14T17:16:23Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nKubetail\u0027s dashboard exposes WebSocket endpoints that did not adequately validate the Origin header on connection upgrade. A malicious web page visited by a user with an active Kubetail session could open a WebSocket to the user\u0027s dashboard and read their Kubernetes logs in real time. This is a Cross-Site WebSocket Hijacking (CSWSH) vulnerability and affects both the desktop deployment (default http://localhost:7500) and cluster deployments (typically behind an Ingress with HTTP basic auth).\n\n### Impact\n\nAn attacker who can convince an authenticated Kubetail user to visit a page they control can:\n\n- Establish a WebSocket connection to the victim\u0027s dashboard from the attacker\u0027s origin\n- Stream container logs the victim has access to via the Kubernetes API\n- Exfiltrate the contents to an attacker-controlled server\n\nThe attacker gains **read-only** access to logs \u2014 no write or destructive operations are exposed. However, container logs frequently contain credentials accidentally written by application code, bearer tokens, internal hostnames, customer PII, and other secrets, so the practical impact of read access can be significant.\n\nThe desktop deployment is particularly exposed because the dashboard is reachable at a predictable localhost URL, requires no network reachability from the attacker, and the browser will attach ambient credentials to the WebSocket handshake.\nFor cluster deployments fronted by HTTP basic auth, the browser\u0027s automatic re-sending of basic-auth credentials on the WebSocket upgrade request enables the same attack against the configured dashboard origin.\n\n### Affected versions\n\n| Component                                    | Name                           | Affected | Patched   |\n| --------------------------------- | ---------------------- | -------- | ---------- |\n| Kubetail Dashboard docker image | `kubetail-dashboard` | \u003c 0.14.0  | \u003e= 0.14.0  |\n| Kubetail Helm Chart                       | `kubetail/kubetail`       | \u003c 0.23.0 | \u003e= 0.23.0 |\n| Kubetail CLI                                    | `kubetail`                     | \u003c 0.16.0 | \u003e= 0.16.0  |\n\nConfirmed in Google Chrome. Microsoft Edge is presumed affected as it shares Chromium\u0027s WebSocket implementation, but was not directly tested.\n\n**Preconditions for exploitation**\n\n1. The victim has an active authenticated Kubetail session (desktop dashboard running, or browser holding valid credentials for a cluster deployment).\n2. The victim visits a web page controlled by the attacker in the same browser.\n3. The attacker knows or can guess the dashboard URL (trivial for desktop; cluster deployments require knowing the Ingress hostname).\n\n### Patches\n\nUpgrade to:\n* Kubetail Dashboard 0.14.0 or later\n* Kubetail Helm Chart 0.23.0 or later\n* Kubetail CLI 0.16.0 or later\n\n### Workarounds\n\nIf users cannot upgrade immediately:\n\n* **Desktop:** Stop the dashboard (kubetail CLI process) when not actively in use. Avoid visiting untrusted sites in the same browser profile while the dashboard is running.\n* **Cluster:** Restrict Ingress access to a VPN, bastion, or office network. Add a stronger outer authentication layer (e.g. OAuth proxy) in front of basic auth. Consider browser profile isolation for cluster admins.",
  "id": "GHSA-v8j7-hp7c-738f",
  "modified": "2026-05-14T20:54:00Z",
  "published": "2026-05-07T02:34:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubetail-org/kubetail/security/advisories/GHSA-v8j7-hp7c-738f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44514"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubetail-org/kubetail"
    }
  ],
  "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": "Kubetail has a Cross-Site WebSocket Hijacking issue that allows attacker to read Kubernetes logs from authenticated users"
}

GHSA-VG6X-RCGG-RJX6

Vulnerability from github – Published: 2025-01-21 19:52 – Updated: 2025-02-07 17:38
VLAI
Summary
Websites were able to send any requests to the development server and read the response in vite
Details

Summary

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

[!WARNING] 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.

Upgrade Path

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

  • Using the backend integration feature
  • Using a reverse proxy in front of Vite
  • Accessing the development server via a domain other than localhost or *.localhost
  • Using a plugin / framework that connects to the WebSocket server on their own from the browser

Using the backend integration feature

If you are using the backend integration feature and not setting server.origin, you need to add the origin of the backend server to the server.cors.origin option. Make sure to set a specific origin rather than *, otherwise any origin can access your development server.

Using a reverse proxy in front of Vite

If 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 option. For example, if the reverse proxy is sending requests to http://vite:5173, you need to add vite to the server.allowedHosts option.

Accessing the development server via a domain other than localhost or *.localhost

You need to add the hostname to the new 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.

Using a plugin / framework that connects to the WebSocket server on their own from the browser

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

In that case, you can either:

  • fix the plugin / framework code to the make it compatible with the new version of Vite
  • set legacy.skipWebSocketTokenCheck: true to opt-out the fix for [2] while the plugin / framework is incompatible with the new version of Vite
  • When enabling this option, make sure that you are aware of the security implications described in the impact section of [2] above.

Mitigation without upgrading Vite

[1]: Permissive default CORS settings

Set server.cors to false or limit server.cors.origin to trusted origins.

[2]: Lack of validation on the Origin header for WebSocket connections

There aren't any mitigations for this.

[3]: Lack of validation on the Host header for HTTP requests

Use Chrome 94+ or use HTTPS for the development server.

Details

There are three causes that allowed malicious websites to send any requests to the development server:

[1]: Permissive default CORS settings

Vite sets the Access-Control-Allow-Origin header depending on 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.

Attack scenario:

  1. The attacker serves a malicious web page (http://malicious.example.com).
  2. The user accesses the malicious web page.
  3. The attacker sends a fetch('http://127.0.0.1:5173/main.js') request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.
  4. The attacker gets the content of http://127.0.0.1:5173/main.js.

[2]: Lack of validation on the Origin header for WebSocket connections

Vite starts a WebSocket server to handle HMR and other functionalities. This WebSocket server did not perform validation on the Origin header 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.), but plugins can send arbitrary messages and may include more sensitive information.

Attack scenario:

  1. The attacker serves a malicious web page (http://malicious.example.com).
  2. The user accesses the malicious web page.
  3. The attacker runs new WebSocket('http://127.0.0.1:5173', 'vite-hmr') by JS in that malicious web page.
  4. The user edits some files.
  5. Vite sends some HMR messages over WebSocket.
  6. The attacker gets the content of the HMR messages.

[3]: Lack of validation on the Host header for HTTP requests

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

  1. The attacker serves a malicious web page that is served on HTTP (http://malicious.example.com:5173) (HTTPS won't work).
  2. The user accesses the malicious web page.
  3. The attacker changes the DNS to point to 127.0.0.1 (or other private addresses).
  4. The attacker sends a fetch('/main.js') request by JS in that malicious web page.
  5. The attacker gets the content of http://127.0.0.1:5173/main.js bypassing the same origin policy.

Impact

[1]: Permissive default CORS settings

Users with the default server.cors option may:

  • get the source code stolen by malicious websites
  • give the attacker access to functionalities that are not supposed to be exposed externally
  • 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.

[2]: Lack of validation on the Origin header for WebSocket connections

All users may get the file paths of the files that changed and the file content where the error happened be stolen by malicious websites.

For users that is using a plugin that sends messages over WebSocket, that content may be stolen by malicious websites.

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

[3]: Lack of validation on the Host header for HTTP requests

Users using HTTP for the development server and using a browser that is not Chrome 94+ may:

  • get the source code stolen by malicious websites
  • give the attacker access to functionalities that are not supposed to be exposed externally
  • 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.

Chrome 94+ users are not affected for [3], because sending a request to a private network page from public non-HTTPS page is forbidden since Chrome 94.

Related Information

Safari has a bug that blocks requests to loopback addresses from HTTPS origins. This means when the user is using Safari and Vite is listening on lookback addresses, there's another condition of "the malicious web page is served on HTTP" to make [1] and [2] to work.

PoC

[2]: Lack of validation on the Origin header for WebSocket connections

  1. I used the react template which utilizes HMR functionality.
npm create vite@latest my-vue-app-react -- --template react
  1. Then on a malicious server, serve the following POC html:
<!doctype html>
<html lang="en">
    <head>
        <meta charset="utf-8" />
        <title>vite CSWSH</title>
    </head>
    <body>
        <div id="logs"></div>
        <script>
            const div = document.querySelectorAll('#logs')[0];
            const ws = new WebSocket('ws://localhost:5173','vite-hmr');
            ws.onmessage = event => {
                const logLine = document.createElement('p');
                logLine.innerHTML = event.data;
                div.append(logLine);
            };
        </script>
    </body>
</html>
  1. Kick off Vite 
npm run dev
  1. Load the development server (open http://localhost:5173/) as well as the malicious page in the browser.
  2. Edit src/App.jsx file and intentionally place a syntax error
  3. Notice how the malicious page can view the websocket messages and a snippet of the source code is exposed

Here's a video demonstrating the POC:

https://github.com/user-attachments/assets/a4ad05cd-0b34-461c-9ff6-d7c8663d6961

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

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

GHSA-VJ7Q-GJH5-988W

Vulnerability from github – Published: 2026-07-16 20:14 – Updated: 2026-07-16 20:14
VLAI
Summary
MCP Python SDK: WebSocket server transport does not support Host/Origin validation
Details

Summary

In affected versions, the deprecated WebSocket server transport (mcp.server.websocket.websocket_server) accepted the WebSocket handshake without applying any Host or Origin header validation. The TransportSecuritySettings mechanism that the SSE and Streamable HTTP transports use for this purpose was not wired into the WebSocket transport, so there was no SDK-level way to restrict which origins could connect.

Am I affected?

Only if a developer's application server exposes mcp.server.websocket.websocket_server. This transport has never been part of the MCP specification, is marked deprecated, and is not reachable through FastMCP — a developer must have wired it into an ASGI application themselves. Servers using stdio, SSE, or Streamable HTTP are not affected by this advisory.

Details

websocket_server() constructed a Starlette WebSocket and called accept(subprotocol="mcp") immediately, with no inspection of the connection's headers. By contrast, SseServerTransport and StreamableHTTPServerTransport accept an optional security_settings: TransportSecuritySettings and run TransportSecurityMiddleware.validate_request() against the incoming Host and Origin headers before establishing a session. Because browsers attach an Origin header to cross-origin WebSocket upgrade requests but do not enforce a same-origin policy on the response, a web page served from any origin could open a WebSocket to a reachable MCP server on this transport, complete the initialize handshake, and issue JSON-RPC requests on the resulting session.

Impact

A user who runs an MCP server on this transport bound to localhost or a LAN address, without a separate authentication or origin gate in front of it, and visits a malicious web page, can have that page enumerate and invoke the server's tools and read its resources. The consequences depend entirely on what the server exposes. The transport itself requires no token or prior session. Some browsers prompt before allowing a public page to open a connection to a local-network address, which adds a user-interaction step but is not a substitute for server-side validation.

Mitigation

Upgrade to version 1.28.1 or later, in which websocket_server() accepts the same optional security_settings: TransportSecuritySettings argument as the other HTTP-based transports and validates the Host and Origin headers before accepting the handshake; a request that fails validation is rejected with HTTP 403 and ValueError("Request validation failed") is raised to the caller. As with the other transports the parameter defaults to None, which leaves validation disabled, so upgrading alone does not change behaviour: pass a TransportSecuritySettings with enable_dns_rebinding_protection=True and appropriate allowed_hosts / allowed_origins to receive the protection. The recommended path remains to migrate off this deprecated transport to Streamable HTTP, where FastMCP enables this protection automatically for localhost binds. The WebSocket transport has been removed entirely in v2.

Severity
7.6 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.28.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1385",
      "CWE-346"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-16T20:14:34Z",
    "nvd_published_at": "2026-07-15T21:16:55Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nIn affected versions, the deprecated WebSocket server transport (`mcp.server.websocket.websocket_server`) accepted the WebSocket handshake without applying any `Host` or `Origin` header validation. The `TransportSecuritySettings` mechanism that the SSE and Streamable HTTP transports use for this purpose was not wired into the WebSocket transport, so there was no SDK-level way to restrict which origins could connect.\n\n### Am I affected?\nOnly if a developer\u0027s application server exposes `mcp.server.websocket.websocket_server`. This transport has never been part of the MCP specification, is marked deprecated, and is not reachable through `FastMCP` \u2014 a developer must have wired it into an ASGI application themselves. Servers using stdio, SSE, or Streamable HTTP are not affected by this advisory.\n\n### Details\n`websocket_server()` constructed a Starlette `WebSocket` and called `accept(subprotocol=\"mcp\")` immediately, with no inspection of the connection\u0027s headers. By contrast, `SseServerTransport` and `StreamableHTTPServerTransport` accept an optional `security_settings: TransportSecuritySettings` and run `TransportSecurityMiddleware.validate_request()` against the incoming `Host` and `Origin` headers before establishing a session. Because browsers attach an `Origin` header to cross-origin WebSocket upgrade requests but do not enforce a same-origin policy on the response, a web page served from any origin could open a WebSocket to a reachable MCP server on this transport, complete the `initialize` handshake, and issue JSON-RPC requests on the resulting session.\n\n### Impact\nA user who runs an MCP server on this transport bound to localhost or a LAN address, without a separate authentication or origin gate in front of it, and visits a malicious web page, can have that page enumerate and invoke the server\u0027s tools and read its resources. The consequences depend entirely on what the server exposes. The transport itself requires no token or prior session. Some browsers prompt before allowing a public page to open a connection to a local-network address, which adds a user-interaction step but is not a substitute for server-side validation.\n\n### Mitigation\nUpgrade to version 1.28.1 or later, in which `websocket_server()` accepts the same optional `security_settings: TransportSecuritySettings` argument as the other HTTP-based transports and validates the `Host` and `Origin` headers before accepting the handshake; a request that fails validation is rejected with HTTP 403 and `ValueError(\"Request validation failed\")` is raised to the caller. As with the other transports the parameter defaults to `None`, which leaves validation disabled, so upgrading alone does not change behaviour: pass a `TransportSecuritySettings` with `enable_dns_rebinding_protection=True` and appropriate `allowed_hosts` / `allowed_origins` to receive the protection. The recommended path remains to migrate off this deprecated transport to Streamable HTTP, where `FastMCP` enables this protection automatically for localhost binds. The WebSocket transport has been removed entirely in v2.",
  "id": "GHSA-vj7q-gjh5-988w",
  "modified": "2026-07-16T20:14:34Z",
  "published": "2026-07-16T20:14:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-vj7q-gjh5-988w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59950"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/pull/2992"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/commit/777b8d06710c140e3606b0d4598e2aa48546c266"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/python-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.28.1"
    }
  ],
  "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": "MCP Python SDK: WebSocket server transport does not support Host/Origin validation"
}
Mitigation
Implementation

Enable CORS-like access restrictions by verifying the 'Origin' header during the WebSocket handshake.

Mitigation
Implementation

Use a randomized CSRF token to verify requests.

Mitigation
Implementation

Use TLS to securely communicate using 'wss' (WebSocket Secure) instead of 'ws'.

Mitigation
Architecture and Design Implementation

Require user authentication prior to the WebSocket connection being established. For example, the WS library in Node has a 'verifyClient' function.

Mitigation
Implementation

Leverage rate limiting to prevent against DoS. Use of the leaky bucket algorithm can help with this.

Mitigation
Implementation

Use a library that provides restriction of the payload size. For example, WS library for Node includes 'maxPayloadoption' that can be set.

Mitigation
Implementation

Treat data/input as untrusted in both directions and apply the same data/input sanitization as XSS, SQLi, etc.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list