CWE-346
Allowed-with-ReviewOrigin Validation Error
Abstraction: Class · Status: Draft
The product does not properly verify that the source of data or communication is valid.
784 vulnerabilities reference this CWE, most recent first.
GHSA-VCQX-V2MG-7CHX
Vulnerability from github – Published: 2025-09-11 23:26 – Updated: 2025-09-11 23:26Impact
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.
{
"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:27Google Chrome before 18.0.1025.151 allows remote attackers to bypass the Same Origin Policy via vectors related to pop-up windows.
{
"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:30An 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.
{
"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:38Summary
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
localhostor*.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: trueto 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.jsbypassing 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.proxymay 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.proxymay 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
reacttemplate 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.jsxfile 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
{
"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:42An 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.
{
"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:48The 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.
{
"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"
}
]
}
GHSA-VJM9-GQ46-WC5J
Vulnerability from github – Published: 2025-12-18 18:30 – Updated: 2026-02-11 15:30A Cross-Origin Resource Sharing (CORS) misconfiguration vulnerability exists in Dify v1.9.1 in the /console/api/setup endpoint. The endpoint implements an insecure CORS policy that reflects any Origin header and enables Access-Control-Allow-Credentials: true, permitting arbitrary external domains to make authenticated requests.
{
"affected": [],
"aliases": [
"CVE-2025-63386"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T16:15:54Z",
"severity": "CRITICAL"
},
"details": "A Cross-Origin Resource Sharing (CORS) misconfiguration vulnerability exists in Dify v1.9.1 in the /console/api/setup endpoint. The endpoint implements an insecure CORS policy that reflects any Origin header and enables Access-Control-Allow-Credentials: true, permitting arbitrary external domains to make authenticated requests.",
"id": "GHSA-vjm9-gq46-wc5j",
"modified": "2026-02-11T15:30:21Z",
"published": "2025-12-18T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63386"
},
{
"type": "WEB",
"url": "https://github.com/langgenius/dify/pull/32224"
},
{
"type": "WEB",
"url": "https://gist.github.com/Cristliu/1610daac87c711ac3e0250c58f5cc4f9"
},
{
"type": "WEB",
"url": "https://gist.github.com/Cristliu/8ad993126be05c9210c71cc7d49fa112"
},
{
"type": "WEB",
"url": "https://github.com/langgenius/dify/discussions"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-VJQH-VXPX-8294
Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-06-26 21:31Autel MaxiCharger AC Wallbox Commercial Origin Validation Error Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of Autel MaxiCharger AC Wallbox Commercial. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability.
The specific flaw exists within the handling of bluetooth pairing requests. The issue results from insufficient validation of the origin of commands. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-26353.
{
"affected": [],
"aliases": [
"CVE-2025-5824"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-25T18:15:23Z",
"severity": "MODERATE"
},
"details": "Autel MaxiCharger AC Wallbox Commercial Origin Validation Error Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of Autel MaxiCharger AC Wallbox Commercial. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability.\n\nThe specific flaw exists within the handling of bluetooth pairing requests. The issue results from insufficient validation of the origin of commands. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-26353.",
"id": "GHSA-vjqh-vxpx-8294",
"modified": "2025-06-26T21:31:13Z",
"published": "2025-06-26T21:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5824"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-25-343"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-VJX2-FP9G-Q2MC
Vulnerability from github – Published: 2026-07-14 09:31 – Updated: 2026-07-14 21:31In versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server's domain, in violation of RFC 6265 section 5.3. An attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain.
When the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker's account. Sensitive data included in the victim application's requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.
{
"affected": [],
"aliases": [
"CVE-2026-15076"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T09:16:40Z",
"severity": "HIGH"
},
"details": "In versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server\u0027s domain, in violation of RFC 6265 section 5.3.\nAn attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain.\n\n\n\n\nWhen the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker\u0027s account. Sensitive data included in the victim application\u0027s requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.",
"id": "GHSA-vjx2-fp9g-q2mc",
"modified": "2026-07-14T21:31:35Z",
"published": "2026-07-14T09:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15076"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/162"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/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-VM32-9RQF-RH3R
Vulnerability from github – Published: 2024-12-10 22:42 – Updated: 2024-12-10 22:42Summary
pnpm seems to mishandle overrides and global cache: 1. Overrides from one workspace leak into npm metadata saved in global cache 2. npm metadata from global cache affects other workspaces 3. installs by default don't revalidate the data (including on first lockfile generation)
This can make workspace A (even running with ignore-scripts=true) posion global cache and execute scripts in workspace B
Users generally expect ignore-scripts to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it).
Here, that expectation is broken
Details
See PoC.
In it, overrides from a single run of A get leaked into e.g. ~/Library/Caches/pnpm/metadata/registry.npmjs.org/rimraf.json and persistently affect all other projects using the cache
PoC
Postinstall code used in PoC is benign and can be inspected in https://www.npmjs.com/package/ponyhooves?activeTab=code, it's just a console.log
- Remove store and cache
On mac:
rm -rf ~/Library/Caches/pnpm ~/Library/pnpm/storeThis step is not required in general, but we'll be using a popular package for PoC that's likely cached - Create
A/package.json:json { "name": "A", "pnpm": { "overrides": { "rimraf>glob": "npm:ponyhooves@1" } }, "dependencies": { "rimraf": "6.0.1" } }Install it withpnpm i --ignore-scripts(the flag is not required, but the point of the demo is to show that it doesn't help) - Create
B/package.json:json { "name": "B", "dependencies": { "rimraf": "6.0.1" } }Install it withpnpm i
Result:
Packages: +3
+++
Progress: resolved 3, reused 3, downloaded 0, added 3, done
node_modules/.pnpm/ponyhooves@1.0.1/node_modules/ponyhooves: Running postinstall script, done in 51ms
dependencies:
+ rimraf 6.0.1
Done in 1.4s
Also, that code got leaked into another project and it's lockfile now!
Impact
Global state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs
As a work-around, use separate cache and store dirs in each workspace
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-53866"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-426"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-10T22:42:41Z",
"nvd_published_at": "2024-12-10T18:15:42Z",
"severity": "MODERATE"
},
"details": "### Summary\n\npnpm seems to mishandle overrides and global cache:\n1. Overrides from one workspace leak into npm metadata saved in global cache\n2. npm metadata from global cache affects other workspaces\n3. installs by default don\u0027t revalidate the data (including on first lockfile generation)\n\nThis can make workspace A (even running with `ignore-scripts=true`) posion global cache and execute scripts in workspace B\n\nUsers generally expect `ignore-scripts` to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it).\n\nHere, that expectation is broken\n\n### Details\n\nSee PoC.\n\nIn it, overrides from a single run of A get leaked into e.g. `~/Library/Caches/pnpm/metadata/registry.npmjs.org/rimraf.json` and persistently affect all other projects using the cache\n\n### PoC\n\nPostinstall code used in PoC is benign and can be inspected in \u003chttps://www.npmjs.com/package/ponyhooves?activeTab=code\u003e, it\u0027s just a `console.log`\n\n1. Remove store and cache\n On mac: `rm -rf ~/Library/Caches/pnpm ~/Library/pnpm/store`\n This step is not required in general, but we\u0027ll be using a popular package for PoC that\u0027s likely cached\n2. Create `A/package.json`:\n ```json\n {\n \"name\": \"A\",\n \"pnpm\": { \"overrides\": { \"rimraf\u003eglob\": \"npm:ponyhooves@1\" } },\n \"dependencies\": { \"rimraf\": \"6.0.1\" }\n }\n ```\n Install it with `pnpm i --ignore-scripts` (the flag is not required, but the point of the demo is to show that it doesn\u0027t help)\n4. Create `B/package.json`:\n ```json\n {\n \"name\": \"B\",\n \"dependencies\": { \"rimraf\": \"6.0.1\" }\n }\n ```\n Install it with `pnpm i`\n\nResult:\n```console\nPackages: +3\n+++\nProgress: resolved 3, reused 3, downloaded 0, added 3, done\nnode_modules/.pnpm/ponyhooves@1.0.1/node_modules/ponyhooves: Running postinstall script, done in 51ms\n\ndependencies:\n+ rimraf 6.0.1\n\nDone in 1.4s\n```\n\nAlso, that code got leaked into another project and it\u0027s lockfile now! \n\n### Impact\n\nGlobal state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs\n\nAs a work-around, use separate cache and store dirs in each workspace\n",
"id": "GHSA-vm32-9rqf-rh3r",
"modified": "2024-12-10T22:42:41Z",
"published": "2024-12-10T22:42:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-vm32-9rqf-rh3r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53866"
},
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/commit/11afcddea48f25ed5117a87dc1780a55222b9743"
},
{
"type": "PACKAGE",
"url": "https://github.com/pnpm/pnpm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "pnpm no-script global cache poisoning via overrides / `ignore-scripts` evasion"
}
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.