<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-18T07:38:42.062301+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-275723</id>
    <title>EUVD-2026-275723</title>
    <updated>2026-10-18T07:38:42.065483+00:00</updated>
    <content>EUVD-2026-275723</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-275723"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-32112</id>
    <title>fkie_cve-2026-32112</title>
    <updated>2026-10-18T07:38:42.065514+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>ha-mcp is a Home Assistant MCP Server. Prior to 7.0.0, the ha-mcp OAuth consent form renders user-controlled parameters via Python f-strings with no HTML escaping. An attacker who can reach the OAuth endpoint and convince the server operator to follow a crafted authorization URL could execute JavaScript in the operator's browser. This affects only users running the beta OAuth mode (ha-mcp-oauth), which is not part of the standard setup and requires explicit configuration. This vulnerability is fixed in 7.0.0.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-32112"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-pf93-j98v-25pv</id>
    <title>GHSA-pf93-j98v-25pv — ha-mcp has XSS via Unescaped HTML in OAuth Consent Form</title>
    <updated>2026-10-18T07:38:42.065546+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: ha-mcp</p>
<p>### Summary</p>
<p>The ha-mcp OAuth consent form renders user-controlled parameters via Python f-strings with no HTML escaping. An attacker who can reach the OAuth endpoint and convince the server operator to follow a crafted authorization URL could execute JavaScript in the operator's browser. This affects only users running the beta OAuth mode (`ha-mcp-oauth`), which is not part of the standard setup and requires explicit configuration.</p>
<p>### Details</p>
<p>**Unescaped f-string rendering**</p>
<p>`consent_form.py` builds HTML using Python f-strings. No call to `html.escape()` exists anywhere in the file. The following values are rendered unescaped:</p>
<p>- `client_name` / `client_id` — in HTML element context (lines 299, 303)
- `client_id`, `redirect_uri`, `state` — in HTML attribute context (lines 310–312), where a `"` character breaks out of `value=""`
- `error_message`, `error`, `error_description` — in error display paths (lines 36–40, 496–497)</p>
<p>An attacker can register a client with a malicious `client_name` via the `/register` (DCR) endpoint, which accepts `client_name` without sanitization. If the server operator then visits a crafted authorization URL for that client, the payload executes in their browser.</p>
<p>**Open Dynamic Client Registration**</p>
<p>DCR is enabled by default with no initial access token required. This is intentional: Claude.ai and ChatGPT must self-register on first use, which is the standard MCP OAuth flow (RFC 7591). Requiring a pre-shared token would break those integration…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-pf93-j98v-25pv"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2026-2508</id>
    <title>PYSEC-2026-2508 — ha-mcp has XSS via Unescaped HTML in OAuth Consent Form</title>
    <updated>2026-10-18T07:38:42.065597+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: ha-mcp</p>
<p>### Summary</p>
<p>The ha-mcp OAuth consent form renders user-controlled parameters via Python f-strings with no HTML escaping. An attacker who can reach the OAuth endpoint and convince the server operator to follow a crafted authorization URL could execute JavaScript in the operator's browser. This affects only users running the beta OAuth mode (`ha-mcp-oauth`), which is not part of the standard setup and requires explicit configuration.</p>
<p>### Details</p>
<p>**Unescaped f-string rendering**</p>
<p>`consent_form.py` builds HTML using Python f-strings. No call to `html.escape()` exists anywhere in the file. The following values are rendered unescaped:</p>
<p>- `client_name` / `client_id` — in HTML element context (lines 299, 303)
- `client_id`, `redirect_uri`, `state` — in HTML attribute context (lines 310–312), where a `"` character breaks out of `value=""`
- `error_message`, `error`, `error_description` — in error display paths (lines 36–40, 496–497)</p>
<p>An attacker can register a client with a malicious `client_name` via the `/register` (DCR) endpoint, which accepts `client_name` without sanitization. If the server operator then visits a crafted authorization URL for that client, the payload executes in their browser.</p>
<p>**Open Dynamic Client Registration**</p>
<p>DCR is enabled by default with no initial access token required. This is intentional: Claude.ai and ChatGPT must self-register on first use, which is the standard MCP OAuth flow (RFC 7591). Requiring a pre-shared token would break those integration…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2026-2508"/>
  </entry>
</feed>
