<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from pysec</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 10:30:54 +0000</lastBuildDate>
    <item>
      <title>PYSEC-2026-1339 — Inclusion of Untrusted polyfill.io Code Vulnerability in fides.js</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-1339</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: ethyca-fides&lt;/p&gt;
&lt;p&gt;### Note&lt;/p&gt;
&lt;p&gt;On Thursday, June 27, 2024, Cloudflare and Namecheap intervened at a domain level to ensure `polyfill.io` and its subdomains could not resolve to the compromised service, rendering this vulnerability **unexploitable**.&lt;/p&gt;
&lt;p&gt;The following sections describe this vulnerability prior to the domain level intervention, when it was still exploitable.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;`fides.js`, a client-side script used to interact with the consent management features of Fides, used the `polyfill.io` domain in a very limited edge case, when it detected a legacy browser such as IE11 that did not support the fetch standard.&lt;/p&gt;
&lt;p&gt;On June 25th, 2024, Sansec published the following regarding the `polyfill.io` domain.&lt;/p&gt;
&lt;p&gt;&amp;gt; The polyfill.js is a popular open source library to support older browsers. 100K+ sites embed it using the cdn.polyfill.io domain... However, in February this year, a Chinese company bought the domain and the Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io.&lt;/p&gt;
&lt;p&gt;Therefore it was possible for users of legacy, pre-2017 browsers who navigate to a page serving `fides.js` to download and execute malicious scripts from the compromised domain.&lt;/p&gt;
&lt;p&gt;No exploitation of `fides.js` via `polyfill.io` has been identified at this time, but other script developers who use `https://cdn.polyfill.io/v2/polyfill.min.js` have reported redirects to malicious websites.&lt;/p&gt;
&lt;p&gt;### Patches
The vulnerability has been patched in Fides version `2.39.…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: ethyca-fides&lt;/p&gt;
&lt;p&gt;### Note&lt;/p&gt;
&lt;p&gt;On Thursday, June 27, 2024, Cloudflare and Namecheap intervened at a domain level to ensure `polyfill.io` and its subdomains could not resolve to the compromised service, rendering this vulnerability **unexploitable**.&lt;/p&gt;
&lt;p&gt;The following sections describe this vulnerability prior to the domain level intervention, when it was still exploitable.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;`fides.js`, a client-side script used to interact with the consent management features of Fides, used the `polyfill.io` domain in a very limited edge case, when it detected a legacy browser such as IE11 that did not support the fetch standard.&lt;/p&gt;
&lt;p&gt;On June 25th, 2024, Sansec published the following regarding the `polyfill.io` domain.&lt;/p&gt;
&lt;p&gt;&amp;gt; The polyfill.js is a popular open source library to support older browsers. 100K+ sites embed it using the cdn.polyfill.io domain... However, in February this year, a Chinese company bought the domain and the Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io.&lt;/p&gt;
&lt;p&gt;Therefore it was possible for users of legacy, pre-2017 browsers who navigate to a page serving `fides.js` to download and execute malicious scripts from the compromised domain.&lt;/p&gt;
&lt;p&gt;No exploitation of `fides.js` via `polyfill.io` has been identified at this time, but other script developers who use `https://cdn.polyfill.io/v2/polyfill.min.js` have reported redirects to malicious websites.&lt;/p&gt;
&lt;p&gt;### Patches
The vulnerability has been patched in Fides version `2.39.…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-1339</guid>
      <pubDate>Tue, 07 Jul 2026 14:34:36 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-1497 — kiwi TCMS has possibility for user to update email address to unverified one</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-1497</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: kiwitcms&lt;/p&gt;
&lt;p&gt;### Impact
In previous versions of Kiwi TCMS users were able to update their email addresses via the &amp;#34;My profile&amp;#34; admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.&lt;/p&gt;
&lt;p&gt;### Patches
With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!&lt;/p&gt;
&lt;p&gt;### Workarounds
No workaround exists.&lt;/p&gt;
&lt;p&gt;### References
Disclosed by [@novemberdad](https://huntr.dev/bounties/1714df73-e639-4d64-ab25-ced82dad9f85/).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: kiwitcms&lt;/p&gt;
&lt;p&gt;### Impact
In previous versions of Kiwi TCMS users were able to update their email addresses via the &amp;#34;My profile&amp;#34; admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.&lt;/p&gt;
&lt;p&gt;### Patches
With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!&lt;/p&gt;
&lt;p&gt;### Workarounds
No workaround exists.&lt;/p&gt;
&lt;p&gt;### References
Disclosed by [@novemberdad](https://huntr.dev/bounties/1714df73-e639-4d64-ab25-ced82dad9f85/).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-1497</guid>
      <pubDate>Tue, 07 Jul 2026 11:45:18 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-1924 — sigstore CSRF possibility in OIDC authentication during signing</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-1924</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: sigstore&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The sigstore-python OAuth authentication flow is susceptible to Cross-Site Request Forgery.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`_OAuthSession` creates a unique &amp;#34;state&amp;#34; and sends it as a parameter in the authentication request but the &amp;#34;state&amp;#34; in the server response seems not not be cross-checked with this value.&lt;/p&gt;
&lt;p&gt;Fix should be fairly trivial.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;This should be low impact: A man-in-the middle attacker could trick a sigstore-python user into signing something with an identity controlled by the attacker (by returning the response to an authentication request they created). This would be quite confusing but not dangerous.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: sigstore&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The sigstore-python OAuth authentication flow is susceptible to Cross-Site Request Forgery.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`_OAuthSession` creates a unique &amp;#34;state&amp;#34; and sends it as a parameter in the authentication request but the &amp;#34;state&amp;#34; in the server response seems not not be cross-checked with this value.&lt;/p&gt;
&lt;p&gt;Fix should be fairly trivial.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;This should be low impact: A man-in-the middle attacker could trick a sigstore-python user into signing something with an identity controlled by the attacker (by returning the response to an authentication request they created). This would be quite confusing but not dangerous.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-1924</guid>
      <pubDate>Tue, 07 Jul 2026 16:03:20 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-2480 — Flawfinder output manipulation via untrusted filenames and source text</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2480</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: flawfinder&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;This vulnerability is an improper input neutralization issue leading to output manipulation, specifically, Terminal/ANSI Escape Sequence Injection and XML Injection:&lt;/p&gt;
&lt;p&gt;* Terminal Output Spoofing: A malicious file whose name contains ANSI escape sequences can end up being included in flawfinder&amp;#39;s standard terminal output, with many effects. For example, this might allow an attacker to hide critical scan results, falsely making it appear to a human reviewer that no security issues were found.&lt;/p&gt;
&lt;p&gt;* CSV and XML Injection: Untrusted fields (such as filenames, categories, or code context text) were not properly sanitized when generating structured reports. An attacker could exploit this to corrupt CSV formats or inject arbitrary XML attributes into SonarQube outputs via output_sonar().&lt;/p&gt;
&lt;p&gt;It impacts those who use flawfinder to evaluate intentionally malicious filenames or file contents.&lt;/p&gt;
&lt;p&gt;The initial filename injection problem was reported by Dan Lenz https://www.linkedin.com/in/dan-lenz/&lt;/p&gt;
&lt;p&gt;The other vulnerabilities were found by flawfinder project leader David A. Wheeler, GitHub david-a-wheeler, https://dwheeler.com/&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This issue has been fully patched in Version 2.0.20 (released 2026-05-16). All users should upgrade to version 2.0.20 or later immediately. If you use Python&amp;#39;s package manager, you can upgrade using `pip install --upgrade flawfinder`. If you are consuming flawfinder via GitHub Actions, ensure your workflow points to david-a-wheeler/flawfinder@2.0.2…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: flawfinder&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;This vulnerability is an improper input neutralization issue leading to output manipulation, specifically, Terminal/ANSI Escape Sequence Injection and XML Injection:&lt;/p&gt;
&lt;p&gt;* Terminal Output Spoofing: A malicious file whose name contains ANSI escape sequences can end up being included in flawfinder&amp;#39;s standard terminal output, with many effects. For example, this might allow an attacker to hide critical scan results, falsely making it appear to a human reviewer that no security issues were found.&lt;/p&gt;
&lt;p&gt;* CSV and XML Injection: Untrusted fields (such as filenames, categories, or code context text) were not properly sanitized when generating structured reports. An attacker could exploit this to corrupt CSV formats or inject arbitrary XML attributes into SonarQube outputs via output_sonar().&lt;/p&gt;
&lt;p&gt;It impacts those who use flawfinder to evaluate intentionally malicious filenames or file contents.&lt;/p&gt;
&lt;p&gt;The initial filename injection problem was reported by Dan Lenz https://www.linkedin.com/in/dan-lenz/&lt;/p&gt;
&lt;p&gt;The other vulnerabilities were found by flawfinder project leader David A. Wheeler, GitHub david-a-wheeler, https://dwheeler.com/&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This issue has been fully patched in Version 2.0.20 (released 2026-05-16). All users should upgrade to version 2.0.20 or later immediately. If you use Python&amp;#39;s package manager, you can upgrade using `pip install --upgrade flawfinder`. If you are consuming flawfinder via GitHub Actions, ensure your workflow points to david-a-wheeler/flawfinder@2.0.2…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2480</guid>
      <pubDate>Mon, 13 Jul 2026 15:46:24 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-2551 — Kiwi TCMS vulnerable to stored XSS via JavaScript: URI in extra_link field (TestPlan &amp; TestCase)</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2551</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: kiwitcms&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;In Kiwi TCMS the fields `TestCase.extra_link` and `TestPlan.extra_link` were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don&amp;#39;t validate will be reset to a null value.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a `Content-Security-Policy` header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: kiwitcms&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;In Kiwi TCMS the fields `TestCase.extra_link` and `TestPlan.extra_link` were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don&amp;#39;t validate will be reset to a null value.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a `Content-Security-Policy` header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2551</guid>
      <pubDate>Mon, 13 Jul 2026 15:46:28 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-2890 — Poetry has Path Traversal in tar extraction on Python 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2890</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: poetry&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The `extractall()` function in `src/poetry/utils/helpers.py:410-426` extracts sdist tarballs without path traversal protection on Python versions where `tarfile.data_filter` is unavailable. Considering only Python versions which are still supported by Poetry, these are 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Arbitrary file write (path traversal) from untrusted sdist content.&lt;/p&gt;
&lt;p&gt;**In practice, the impact is low** because an attacker who exploits this vulnerability can as well include arbitrary code in a `setup.py`, which will be executed when the sdist is built after tar extraction. In other words, a malicious sdist can write arbitrary files by design. However, since it is unexpected and not by design that the file write already happens during tar extraction, this is still considered a vulnerability.&lt;/p&gt;
&lt;p&gt;On Python 3.11.2 (Debian Bookworm default, directly tested), a crafted sdist with `../../` tar member paths writes files outside the intended extraction directory. The traversal occurs during metadata resolution (`poetry add --lock`), before the build backend is run.&lt;/p&gt;
&lt;p&gt;Affected Environments: 
- **Python 3.10.0 through 3.10.12** (inclusive): `tarfile.data_filter` absent or broken
- **Python 3.11.0 through 3.11.4** (inclusive): `tarfile.data_filter` absent or broken
- **Debian Bookworm**: Python 3.11.2 (default)
- **Ubuntu 22.04 LTS**: Python 3.10.6 (default)&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Versions 2.3.4 and newer of Poetry ensure that paths are inside the target directory.&lt;/p&gt;
&lt;p&gt;#…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: poetry&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The `extractall()` function in `src/poetry/utils/helpers.py:410-426` extracts sdist tarballs without path traversal protection on Python versions where `tarfile.data_filter` is unavailable. Considering only Python versions which are still supported by Poetry, these are 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Arbitrary file write (path traversal) from untrusted sdist content.&lt;/p&gt;
&lt;p&gt;**In practice, the impact is low** because an attacker who exploits this vulnerability can as well include arbitrary code in a `setup.py`, which will be executed when the sdist is built after tar extraction. In other words, a malicious sdist can write arbitrary files by design. However, since it is unexpected and not by design that the file write already happens during tar extraction, this is still considered a vulnerability.&lt;/p&gt;
&lt;p&gt;On Python 3.11.2 (Debian Bookworm default, directly tested), a crafted sdist with `../../` tar member paths writes files outside the intended extraction directory. The traversal occurs during metadata resolution (`poetry add --lock`), before the build backend is run.&lt;/p&gt;
&lt;p&gt;Affected Environments: 
- **Python 3.10.0 through 3.10.12** (inclusive): `tarfile.data_filter` absent or broken
- **Python 3.11.0 through 3.11.4** (inclusive): `tarfile.data_filter` absent or broken
- **Debian Bookworm**: Python 3.11.2 (default)
- **Ubuntu 22.04 LTS**: Python 3.10.6 (default)&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Versions 2.3.4 and newer of Poetry ensure that paths are inside the target directory.&lt;/p&gt;
&lt;p&gt;#…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2890</guid>
      <pubDate>Mon, 13 Jul 2026 15:02:52 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-2042 — Weblate has improper validation upon invitation acceptance</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2042</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: weblate&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;It was possible to accept an invitation opened by a different Weblate user.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;* https://github.com/WeblateOrg/weblate/pull/16913&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users should avoid leaving Weblate sessions with an unattended opened invitation.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;Thanks to Nahid0x for responsibly disclosing this vulnerability to Weblate.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: weblate&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;It was possible to accept an invitation opened by a different Weblate user.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;* https://github.com/WeblateOrg/weblate/pull/16913&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users should avoid leaving Weblate sessions with an unattended opened invitation.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;Thanks to Nahid0x for responsibly disclosing this vulnerability to Weblate.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2042</guid>
      <pubDate>Tue, 07 Jul 2026 16:03:12 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-195</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-195</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: mlflow&lt;/p&gt;
&lt;p&gt;A flaw has been found in MLflow up to 3.10.0. This issue affects the function mlflow.data.digest_utils of the file mlflow/data/digest_utils.py of the component Dataset Digest Computation. This manipulation causes use of weak hash. It is possible to launch the attack on the local host. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through a pull request but has not reacted yet.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: mlflow&lt;/p&gt;
&lt;p&gt;A flaw has been found in MLflow up to 3.10.0. This issue affects the function mlflow.data.digest_utils of the file mlflow/data/digest_utils.py of the component Dataset Digest Computation. This manipulation causes use of weak hash. It is possible to launch the attack on the local host. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through a pull request but has not reacted yet.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-195</guid>
      <pubDate>Thu, 04 Jun 2026 12:16:24 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-2516 — Home Assistant has stored XSS in history-graphs</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2516</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: homeassistant&lt;/p&gt;
&lt;p&gt;### Summary
The &amp;#34;remaining charge time&amp;#34;-sensor for mobile phones (imported/included from Android Auto it appears) is vulnerable to the same issue as CVE-2025-62172.
&amp;lt;img width=&amp;#34;431&amp;#34; height=&amp;#34;334&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/84e0dfad-b986-4e84-ad0e-674c5da88582&amp;#34; /&amp;gt;
This also indicates that any sensor showing their name in the history-graph, is likely to be vulnerable to this issue.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;Another entity was found which displays the same behavior as in this issue: [CVE-2025-62172](https://github.com/home-assistant/core/security/advisories/GHSA-mq77-rv97-285m)&lt;/p&gt;
&lt;p&gt;The History-graph card will sometimes display the name of the entity it is displaying, when the graph is shown as a line with values on the x and y axis. This appears to be vulnerable to Cross-Site scripting (_XSS_) as it does not have any output escaping or sanitization.&lt;/p&gt;
&lt;p&gt;The PoC in this instance only shows HTML-injection in the form of the `&amp;lt;s&amp;gt;` -tag being rendered as strike through, but the vulnerability also allows for injecting arbitrary tags which execute JavaScript, like the example given in the PoC description below.&lt;/p&gt;
&lt;p&gt;### PoC
1. Register a new sensor (or device) or change the name of an existing one, which provides a location
2. Change the name to something malicious, for example `test &amp;lt;img src=x onerror=alert(document.domain) /&amp;gt;`
    For a new entity, it should work when setting the name. For old entities, go here:
&amp;lt;img width=&amp;#34;1300&amp;#34; height=&amp;#34;411&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://gi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: homeassistant&lt;/p&gt;
&lt;p&gt;### Summary
The &amp;#34;remaining charge time&amp;#34;-sensor for mobile phones (imported/included from Android Auto it appears) is vulnerable to the same issue as CVE-2025-62172.
&amp;lt;img width=&amp;#34;431&amp;#34; height=&amp;#34;334&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/84e0dfad-b986-4e84-ad0e-674c5da88582&amp;#34; /&amp;gt;
This also indicates that any sensor showing their name in the history-graph, is likely to be vulnerable to this issue.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;Another entity was found which displays the same behavior as in this issue: [CVE-2025-62172](https://github.com/home-assistant/core/security/advisories/GHSA-mq77-rv97-285m)&lt;/p&gt;
&lt;p&gt;The History-graph card will sometimes display the name of the entity it is displaying, when the graph is shown as a line with values on the x and y axis. This appears to be vulnerable to Cross-Site scripting (_XSS_) as it does not have any output escaping or sanitization.&lt;/p&gt;
&lt;p&gt;The PoC in this instance only shows HTML-injection in the form of the `&amp;lt;s&amp;gt;` -tag being rendered as strike through, but the vulnerability also allows for injecting arbitrary tags which execute JavaScript, like the example given in the PoC description below.&lt;/p&gt;
&lt;p&gt;### PoC
1. Register a new sensor (or device) or change the name of an existing one, which provides a location
2. Change the name to something malicious, for example `test &amp;lt;img src=x onerror=alert(document.domain) /&amp;gt;`
    For a new entity, it should work when setting the name. For old entities, go here:
&amp;lt;img width=&amp;#34;1300&amp;#34; height=&amp;#34;411&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://gi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2516</guid>
      <pubDate>Mon, 13 Jul 2026 14:36:45 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-2517 — Home Assistant has stored XSS in Map-card through malicious device name</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2517</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: homeassistant&lt;/p&gt;
&lt;p&gt;### Summary
An authenticated party can add a malicious name to their device entity, allowing for Cross-Site Scripting attacks against anyone who can see a dashboard with a Map-card which includes that entity. It requires that the victim hovers over an information point (The lines or the dots representing that device&amp;#39;s movement, as shown in the screenshot below, with the example showing a html-injection using `&amp;lt;s&amp;gt;` to strikethrough the text)
&amp;lt;img width=&amp;#34;348&amp;#34; height=&amp;#34;355&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/1af3ef33-3a72-4816-8ade-e6405aace176&amp;#34; /&amp;gt;&lt;/p&gt;
&lt;p&gt;This allows an authenticated user to execute JavaScript in the context of any other users accessing a dashboard.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerability exists in the map-card by adding a malicious entity and having the property `hours_to_show` set.
See example below, with the malicious entity being `Pixel 9 &amp;lt;s&amp;gt; Fold Robin {{7*7}}`:
Map card with malicious device entity:
&amp;lt;img width=&amp;#34;338&amp;#34; height=&amp;#34;332&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/15229cc3-1b69-438c-9ee5-cbfa9483aec9&amp;#34; /&amp;gt;&lt;/p&gt;
&lt;p&gt;YAML-view of same card:
&amp;lt;img width=&amp;#34;338&amp;#34; height=&amp;#34;198&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/cd579266-75c3-4cdf-9d08-1544a6887feb&amp;#34; /&amp;gt;&lt;/p&gt;
&lt;p&gt;This issue largely resembles the issue documented in: [CVE-2025-62172](https://github.com/home-assistant/core/security/advisories/GHSA-mq77-rv97-285m), but with an entity which can be displayed in a Map, instead of in an energy-dashboard.&lt;/p&gt;
&lt;p&gt;### PoC
1. Register a new…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: homeassistant&lt;/p&gt;
&lt;p&gt;### Summary
An authenticated party can add a malicious name to their device entity, allowing for Cross-Site Scripting attacks against anyone who can see a dashboard with a Map-card which includes that entity. It requires that the victim hovers over an information point (The lines or the dots representing that device&amp;#39;s movement, as shown in the screenshot below, with the example showing a html-injection using `&amp;lt;s&amp;gt;` to strikethrough the text)
&amp;lt;img width=&amp;#34;348&amp;#34; height=&amp;#34;355&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/1af3ef33-3a72-4816-8ade-e6405aace176&amp;#34; /&amp;gt;&lt;/p&gt;
&lt;p&gt;This allows an authenticated user to execute JavaScript in the context of any other users accessing a dashboard.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerability exists in the map-card by adding a malicious entity and having the property `hours_to_show` set.
See example below, with the malicious entity being `Pixel 9 &amp;lt;s&amp;gt; Fold Robin {{7*7}}`:
Map card with malicious device entity:
&amp;lt;img width=&amp;#34;338&amp;#34; height=&amp;#34;332&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/15229cc3-1b69-438c-9ee5-cbfa9483aec9&amp;#34; /&amp;gt;&lt;/p&gt;
&lt;p&gt;YAML-view of same card:
&amp;lt;img width=&amp;#34;338&amp;#34; height=&amp;#34;198&amp;#34; alt=&amp;#34;image&amp;#34; src=&amp;#34;https://github.com/user-attachments/assets/cd579266-75c3-4cdf-9d08-1544a6887feb&amp;#34; /&amp;gt;&lt;/p&gt;
&lt;p&gt;This issue largely resembles the issue documented in: [CVE-2025-62172](https://github.com/home-assistant/core/security/advisories/GHSA-mq77-rv97-285m), but with an entity which can be displayed in a Map, instead of in an energy-dashboard.&lt;/p&gt;
&lt;p&gt;### PoC
1. Register a new…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2517</guid>
      <pubDate>Mon, 13 Jul 2026 14:36:45 +0000</pubDate>
    </item>
  </channel>
</rss>
