Common Weakness Enumeration

CWE-346

Allowed-with-Review

Origin Validation Error

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly verify that the source of data or communication is valid.

788 vulnerabilities reference this CWE, most recent first.

GHSA-V52W-28XH-V562

Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47

Summary

Kozou: Unauthenticated MCP HTTP server and bundled dev-stack hardening (DNS-rebinding, request-body limits, read-only reads, default network exposure)

Details

Kozou compiles a PostgreSQL schema into an Admin UI, a REST API, and an MCP server. Several hardening gaps in the bundled HTTP surfaces and the scaffolded dev stack are fixed in 1.8.1.

Issues

MCP HTTP server lacked DNS-rebinding protection. The Streamable HTTP transport is unauthenticated and loopback by default. Without Host/Origin validation, a malicious web page in the operator's browser could rebind a hostname it controls to the loopback address and drive the MCP endpoint — reading schema metadata, or (when the opt-in call execution tool is enabled) executing exposed functions as the execution role.
Unbounded request-body buffering (DoS). Both the MCP HTTP server and the in-house REST server read the entire request body into memory with no size limit, so a reachable client could drive the process toward memory exhaustion.
Read requests ran in a read/write transaction. The shared role-transaction envelope opened every request with a plain BEGIN, so a GET ran read/write. A SELECT that reaches a volatile function or a writable / INSTEAD-triggered view could perform a write that then commits — the "a GET only reads" contract was left to the serving role's grants rather than enforced.
No-auth dev surfaces published on all interfaces by default. The scaffolded docker-compose.yml (and the quickstart) published the unauthenticated Admin UI and MCP HTTP server — and the default-credential demo database — on every host interface, and the config defaulted those binds to 0.0.0.0.

What changed in 1.8.1

DNS-rebinding guard (MCP HTTP): the server validates the Host header (and a present Origin) against an allowlist before handling any request, on every route. Matching is on the hostname; loopback names are always accepted and an operator can add hosts via configuration. A browser cannot forge Host/Origin, so this closes the rebinding vector. (This is a browser-rebinding defence; network reachability of an unauthenticated server must still be constrained by the network — see workarounds.)
Request-body size cap: both HTTP servers reject an over-large declared Content-Length (413) and enforce the limit while streaming, so a chunked / Content-Length-less body cannot grow unbounded. A non-JSON Content-Type on a body is rejected with 415. The cap is configurable.
Read-only read transactions: read methods (GET) now run in a READ ONLY transaction, so the database refuses any write for the duration of the request regardless of the role's grants.
Loopback-by-default network posture: the Admin UI and MCP HTTP server now bind loopback by default; the bundled compose files publish every host port (Admin UI, MCP, database) on 127.0.0.1 only, while the container binds all interfaces internally so the loopback mapping still works. Operators opt into a broader bind explicitly.

Impact

The MCP HTTP server's exposure is greatest when the opt-in call execution tool is enabled and/or the server is reachable beyond loopback. The read/write-transaction issue has effect only when the schema exposes a read path that can write (a volatile-function-backed column or a writable/INSTEAD-triggered view) and the serving role holds write grants. The all-interface publish affected anyone who ran the scaffolded docker compose up on a host reachable from an untrusted network. Requests run under SET LOCAL ROLE, so PostgreSQL still enforces grants/RLS at runtime; these are defense-in-depth and read-contract hardening.

Affected / patched

npm packages kozou, @kozou/api, @kozou/mcp, @kozou/core (and the lockstep-versioned siblings): affected <= 1.8.0, patched 1.8.1.
Container image ghcr.io/kozou-dev/kozou: patched at tag v1.8.1.

Workarounds (if you cannot upgrade immediately)

Bind the Admin UI and MCP HTTP server to loopback and publish their host ports on 127.0.0.1 only; do not expose them to untrusted networks.
Do not enable the MCP call execution tool on a non-loopback / unauthenticated deployment.
Put an authenticating reverse proxy (with Host/Origin validation and a request-body limit) in front of any non-loopback deployment.
Change the demo database's default credentials and restrict its port.

Patches

Upgrade to Kozou 1.8.1 (all npm packages and the ghcr.io/kozou-dev/kozou image).

Severity

8.4 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "kozou"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@kozou/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@kozou/mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@kozou/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-272",
      "CWE-346",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:47:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Kozou compiles a PostgreSQL schema into an Admin UI, a REST API, and an MCP server. Several hardening gaps in the bundled HTTP surfaces and the scaffolded dev stack are fixed in **1.8.1**.\n\n## Issues\n\n1. **MCP HTTP server lacked DNS-rebinding protection.** The Streamable HTTP transport is unauthenticated and loopback by default. Without `Host`/`Origin` validation, a malicious web page in the operator\u0027s browser could rebind a hostname it controls to the loopback address and drive the MCP endpoint \u2014 reading schema metadata, or (when the opt-in `call` execution tool is enabled) executing exposed functions as the execution role.\n\n2. **Unbounded request-body buffering (DoS).** Both the MCP HTTP server and the in-house REST server read the entire request body into memory with no size limit, so a reachable client could drive the process toward memory exhaustion.\n\n3. **Read requests ran in a read/write transaction.** The shared role-transaction envelope opened every request with a plain `BEGIN`, so a `GET` ran read/write. A `SELECT` that reaches a volatile function or a writable / `INSTEAD`-triggered view could perform a write that then commits \u2014 the \"a GET only reads\" contract was left to the serving role\u0027s grants rather than enforced.\n\n4. **No-auth dev surfaces published on all interfaces by default.** The scaffolded `docker-compose.yml` (and the quickstart) published the unauthenticated Admin UI and MCP HTTP server \u2014 and the default-credential demo database \u2014 on every host interface, and the config defaulted those binds to `0.0.0.0`.\n\n## What changed in 1.8.1\n\n- **DNS-rebinding guard (MCP HTTP):** the server validates the `Host` header (and a present `Origin`) against an allowlist before handling any request, on every route. Matching is on the hostname; loopback names are always accepted and an operator can add hosts via configuration. A browser cannot forge `Host`/`Origin`, so this closes the rebinding vector. (This is a browser-rebinding defence; network reachability of an unauthenticated server must still be constrained by the network \u2014 see workarounds.)\n- **Request-body size cap:** both HTTP servers reject an over-large declared `Content-Length` (413) and enforce the limit while streaming, so a chunked / `Content-Length`-less body cannot grow unbounded. A non-JSON `Content-Type` on a body is rejected with 415. The cap is configurable.\n- **Read-only read transactions:** read methods (`GET`) now run in a `READ ONLY` transaction, so the database refuses any write for the duration of the request regardless of the role\u0027s grants.\n- **Loopback-by-default network posture:** the Admin UI and MCP HTTP server now bind loopback by default; the bundled compose files publish every host port (Admin UI, MCP, database) on `127.0.0.1` only, while the container binds all interfaces internally so the loopback mapping still works. Operators opt into a broader bind explicitly.\n\n## Impact\n\nThe MCP HTTP server\u0027s exposure is greatest when the opt-in `call` execution tool is enabled and/or the server is reachable beyond loopback. The read/write-transaction issue has effect only when the schema exposes a read path that can write (a volatile-function-backed column or a writable/`INSTEAD`-triggered view) and the serving role holds write grants. The all-interface publish affected anyone who ran the scaffolded `docker compose up` on a host reachable from an untrusted network. Requests run under `SET LOCAL ROLE`, so PostgreSQL still enforces grants/RLS at runtime; these are defense-in-depth and read-contract hardening.\n\n## Affected / patched\n\n- npm packages `kozou`, `@kozou/api`, `@kozou/mcp`, `@kozou/core` (and the lockstep-versioned siblings): affected `\u003c= 1.8.0`, patched **1.8.1**.\n- Container image `ghcr.io/kozou-dev/kozou`: patched at tag `v1.8.1`.\n\n## Workarounds (if you cannot upgrade immediately)\n\n- Bind the Admin UI and MCP HTTP server to loopback and publish their host ports on `127.0.0.1` only; do not expose them to untrusted networks.\n- Do not enable the MCP `call` execution tool on a non-loopback / unauthenticated deployment.\n- Put an authenticating reverse proxy (with `Host`/`Origin` validation and a request-body limit) in front of any non-loopback deployment.\n- Change the demo database\u0027s default credentials and restrict its port.\n\n## Patches\n\nUpgrade to **Kozou 1.8.1** (all npm packages and the `ghcr.io/kozou-dev/kozou` image).",
  "id": "GHSA-v52w-28xh-v562",
  "modified": "2026-06-19T20:47:19Z",
  "published": "2026-06-19T20:47:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kozou-dev/kozou/security/advisories/GHSA-v52w-28xh-v562"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kozou-dev/kozou"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kozou: Unauthenticated MCP HTTP server and bundled dev-stack hardening (DNS-rebinding, request-body limits, read-only reads, default network exposure)"
}

GHSA-V5XX-F9GC-J856

Vulnerability from github – Published: 2026-05-27 09:31 – Updated: 2026-05-27 09:31

Details

An origin validation error vulnerability in Synology Active Backup for Business Agent before 3.1.0-4967 allows local users to write arbitrary files with restricted content during installation.

Severity

6.1 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-66592"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T09:16:27Z",
    "severity": "MODERATE"
  },
  "details": "An origin validation error vulnerability in Synology Active Backup for Business Agent before 3.1.0-4967 allows local users to write arbitrary files with restricted content during installation.",
  "id": "GHSA-v5xx-f9gc-j856",
  "modified": "2026-05-27T09:31:16Z",
  "published": "2026-05-27T09:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66592"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/en-global/security/advisory/Synology_SA_25_16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9C2-W942-7R95

Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2025-11-04 00:32

Details

This issue was addressed by enabling hardened runtime. This issue is fixed in macOS Sequoia 15.2. A local attacker may gain access to user's Keychain items.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-54490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-12T02:15:30Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed by enabling hardened runtime. This issue is fixed in macOS Sequoia 15.2. A local attacker may gain access to user\u0027s Keychain items.",
  "id": "GHSA-v9c2-w942-7r95",
  "modified": "2025-11-04T00:32:14Z",
  "published": "2024-12-12T03:33:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54490"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121839"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Dec/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9W2-V7J9-RJPR

Vulnerability from github – Published: 2021-09-02 22:02 – Updated: 2021-09-13 20:27

Summary

Remote code execution in Eclipse Theia

Details

In Eclipse Theia 0.3.9 to 1.8.1, the "mini-browser" extension allows a user to preview HTML files in an iframe inside the IDE. But with the way it is made it is possible for a previewed HTML file to trigger an RCE. This exploit only happens if a user previews a malicious file.

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@theia/mini-browser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.9"
            },
            {
              "fixed": "1.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-34435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-668",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-02T17:12:13Z",
    "nvd_published_at": "2021-09-01T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "In Eclipse Theia 0.3.9 to 1.8.1, the \"mini-browser\" extension allows a user to preview HTML files in an iframe inside the IDE. But with the way it is made it is possible for a previewed HTML file to trigger an RCE. This exploit only happens if a user previews a malicious file.",
  "id": "GHSA-v9w2-v7j9-rjpr",
  "modified": "2021-09-13T20:27:30Z",
  "published": "2021-09-02T22:02:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34435"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-theia/theia/pull/8759"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-theia/theia/commit/0761dcf5fe3c14c27432683d42d2c526ad0cfbd5"
    },
    {
      "type": "WEB",
      "url": "https://bugs.eclipse.org/bugs/show_bug.cgi?id=568018"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eclipse-theia/theia"
    }
  ],
  "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": "Remote code execution in Eclipse Theia"
}

GHSA-VCQX-V2MG-7CHX

Vulnerability from github – Published: 2025-09-11 23:26 – Updated: 2025-09-11 23:26

Summary

Neo4j Cypher MCP server is vulnerable to DNS rebinding

Details

Impact

DNS rebinding vulnerability in Neo4j Cypher MCP server allows malicious websites to bypass Same-Origin Policy protections and execute unauthorised tool invocations against locally running Neo4j MCP instances. The attack relies on the user being enticed to visit a malicious website and spend sufficient time there for DNS rebinding to succeed.

Patches

CORS Middleware added to Cypher MCP server v0.4.0 that blocks all web-based access by default.

Workarounds

If you cannot upgrade to v0.4.0 and above, use stdio mode.

References

Vendor Advisory https://www.cve.org/CVERecord?id=CVE-2025-10193

Credits We want to publicly recognize the contribution of Evan Harris from mcpsec.dev for reporting this issue and following the responsible disclosure policy.

Severity

7.4 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-neo4j-cypher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.2"
            },
            {
              "fixed": "0.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-10193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-11T23:26:00Z",
    "nvd_published_at": "2025-09-11T14:15:40Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nDNS rebinding vulnerability in Neo4j Cypher MCP server allows malicious websites to bypass Same-Origin Policy protections and execute unauthorised tool invocations against locally running Neo4j MCP instances.\u0026nbsp;The attack relies on the user being enticed to visit a malicious website and spend sufficient time there for DNS rebinding to succeed.\n\n### Patches\nCORS Middleware added to Cypher MCP server v0.4.0 that blocks all web-based access by default.\n\n### Workarounds\nIf you cannot upgrade to v0.4.0 and above, use stdio mode.\n\n### References\n[Vendor Advisory](https://neo4j.com/security/cve-2025-10193)\nhttps://www.cve.org/CVERecord?id=CVE-2025-10193 \n\nCredits\nWe want to publicly recognize the contribution of Evan Harris from [mcpsec.dev](https://mcpsec.dev/) for reporting this issue and following the responsible disclosure [policy](https://neo4j.com/trust-center/responsible-disclosure/).",
  "id": "GHSA-vcqx-v2mg-7chx",
  "modified": "2025-09-11T23:26:00Z",
  "published": "2025-09-11T23:26:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/neo4j-contrib/mcp-neo4j/security/advisories/GHSA-vcqx-v2mg-7chx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10193"
    },
    {
      "type": "WEB",
      "url": "https://github.com/neo4j-contrib/mcp-neo4j/pull/165"
    },
    {
      "type": "WEB",
      "url": "https://github.com/neo4j-contrib/mcp-neo4j/commit/5b9fbdda6401668d7aa006daf7e644805c067c15"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/neo4j-contrib/mcp-neo4j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/neo4j-contrib/mcp-neo4j/releases/tag/mcp-neo4j-cypher-v0.4.0"
    },
    {
      "type": "WEB",
      "url": "https://neo4j.com/security/cve-2025-10193"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": " Neo4j Cypher MCP server is vulnerable to DNS rebinding "
}

GHSA-VCV7-W6FC-R5XC

Vulnerability from github – Published: 2022-05-13 01:27 – Updated: 2022-05-13 01:27

Details

Google Chrome before 18.0.1025.151 allows remote attackers to bypass the Same Origin Policy via vectors related to pop-up windows.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2011-3072"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-04-05T22:02:00Z",
    "severity": "MODERATE"
  },
  "details": "Google Chrome before 18.0.1025.151 allows remote attackers to bypass the Same Origin Policy via vectors related to pop-up windows.",
  "id": "GHSA-vcv7-w6fc-r5xc",
  "modified": "2022-05-13T01:27:23Z",
  "published": "2022-05-13T01:27:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3072"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/74632"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A15480"
    },
    {
      "type": "WEB",
      "url": "http://code.google.com/p/chromium/issues/detail?id=118467"
    },
    {
      "type": "WEB",
      "url": "http://googlechromereleases.blogspot.com/2012/04/stable-and-beta-channel-updates.html"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/81042"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/48732"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/48749"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-201204-03.xml"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/52913"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1026892"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VF6M-WHR4-PFVQ

Vulnerability from github – Published: 2026-02-02 15:30 – Updated: 2026-02-02 15:30

Details

An unauthenticated remote attacker is able to use an existing session id of a logged in user and gain full access to the device if configuration via ethernet is enabled.

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-50975"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-02T15:16:27Z",
    "severity": "HIGH"
  },
  "details": "An unauthenticated remote attacker is able to use an existing session id of a logged in user and gain full access to the device if configuration via ethernet is enabled.",
  "id": "GHSA-vf6m-whr4-pfvq",
  "modified": "2026-02-02T15:30:34Z",
  "published": "2026-02-02T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50975"
    },
    {
      "type": "WEB",
      "url": "https://www.innomic.com/.well-known/csaf/white/2026/ids-2026-0001.html"
    },
    {
      "type": "WEB",
      "url": "https://www.innomic.com/.well-known/csaf/white/2026/ids-2026-0001.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VG6X-RCGG-RJX6

Vulnerability from github – Published: 2025-01-21 19:52 – Updated: 2025-02-07 17:38

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:

The attacker serves a malicious web page (http://malicious.example.com).
The user accesses the malicious web page.
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.
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:

The attacker serves a malicious web page (http://malicious.example.com).
The user accesses the malicious web page.
The attacker runs new WebSocket('http://127.0.0.1:5173', 'vite-hmr') by JS in that malicious web page.
The user edits some files.
Vite sends some HMR messages over WebSocket.
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.

The attacker serves a malicious web page that is served on HTTP (http://malicious.example.com:5173) (HTTPS won't work).
The user accesses the malicious web page.
The attacker changes the DNS to point to 127.0.0.1 (or other private addresses).
The attacker sends a fetch('/main.js') request by JS in that malicious web page.
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

I used the react template which utilizes HMR functionality.

npm create vite@latest my-vue-app-react -- --template react

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>

Kick off Vite

npm run dev

Load the development server (open http://localhost:5173/) as well as the malicious page in the browser.
Edit src/App.jsx file and intentionally place a syntax error
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

JSON

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-VH29-M7WQ-7X2H

Vulnerability from github – Published: 2023-06-09 21:30 – Updated: 2024-04-04 04:42

Details

An issue found in Yandex Navigator v.6.60 for Android allows unauthorized apps to cause a persistent denial of service by manipulating the SharedPreference files.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-29751"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-09T21:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue found in Yandex Navigator v.6.60 for Android allows unauthorized apps to cause a persistent denial of service by manipulating the SharedPreference files.",
  "id": "GHSA-vh29-m7wq-7x2h",
  "modified": "2024-04-04T04:42:58Z",
  "published": "2023-06-09T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29751"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LianKee/SO-CVEs/blob/main/CVEs/CVE-2023-29751/CVE%20detailed.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VHFM-8GX7-F4CP

Vulnerability from github – Published: 2023-06-13 21:30 – Updated: 2024-04-04 04:48

Details

The underlying feedback mechanism of

Rockwell Automation's FactoryTalk System Services that transfers the FactoryTalk Policy Manager rules to relevant devices on the network does not verify that the origin of the communication is from a legitimate local client device. This may allow a threat actor to craft a malicious website that, when visited, will send a malicious script that can connect to the local WebSocket endpoint and wait for events as if it was a valid client device. If successfully exploited, this would allow a threat actor to receive information including whether FactoryTalk Policy Manager is installed and potentially the entire security policy.

Severity

4.1 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-2639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-13T21:15:10Z",
    "severity": "MODERATE"
  },
  "details": "The underlying feedback mechanism of \n\nRockwell Automation\u0027s\u00a0FactoryTalk System Services that transfers the FactoryTalk Policy Manager rules to relevant devices on the network does not verify that the origin of the communication is from a legitimate local client device.\u00a0 This may allow a threat actor to craft a malicious website that, when visited, will send a malicious script that can connect to the local WebSocket endpoint and wait for events as if it was a valid client device. If successfully exploited, this would allow a threat actor to receive information including whether FactoryTalk Policy Manager is installed and potentially the entire security policy.\u00a0\n\n\n",
  "id": "GHSA-vhfm-8gx7-f4cp",
  "modified": "2024-04-04T04:48:04Z",
  "published": "2023-06-13T21:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2639"
    },
    {
      "type": "WEB",
      "url": "https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1139683"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.

← Back to the CWE list

CWE-346

Origin Validation Error

Issues

What changed in 1.8.1

Impact

Affected / patched

Workarounds (if you cannot upgrade immediately)

Patches

Impact

Patches

Workarounds

References

Summary

Upgrade Path

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

Mitigation without upgrading Vite

[1]: Permissive default CORS settings

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

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

Details

[1]: Permissive default CORS settings

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

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

Impact

[1]: Permissive default CORS settings

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

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

Related Information

PoC

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

CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)

CAPEC-141: Cache Poisoning

CAPEC-142: DNS Cache Poisoning

CAPEC-160: Exploit Script-Based APIs

CAPEC-21: Exploitation of Trusted Identifiers

CAPEC-384: Application API Message Manipulation via Man-in-the-Middle

CAPEC-385: Transaction or Event Tampering via Application API Manipulation

CAPEC-386: Application API Navigation Remapping

CAPEC-387: Navigation Remapping To Propagate Malicious Content

CAPEC-388: Application API Button Hijacking

CAPEC-510: SaaS User Request Forgery

CAPEC-59: Session Credential Falsification through Prediction

CAPEC-60: Reusing Session IDs (aka Session Replay)

CAPEC-75: Manipulating Writeable Configuration Files

CAPEC-76: Manipulating Web Input to File System Calls

CAPEC-89: Pharming

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