Most recent entries from pysec

pysec-2026-1339

2026-07-07T17:24:05.465705+00:00

### Note 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**. The following sections describe this vulnerability prior to the domain level intervention, when it was still exploitable. ### Impact `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. On June 25th, 2024, Sansec published the following regarding the `polyfill.io` domain. > 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. 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. 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. ### Patches The vulnerability has been patched in Fides version `2.39.1`. Users are advised to upgrade to this version or later to secure their systems against this threat. ### Workarounds Prior to the domain level intervention, there were no server-side workarounds and the confidentiality, integrity, and availability impacts of this vulnerability were high. Clients could ensure they were not affected by using a modern browser that supported the fetch standard. caniuse.com/fetch estimates that 97.52% of browser users use a browser that supports the fetch standard. ### References - https://sansec.io/research/polyfill-supply-chain-attack - https://github.com/ethyca/fides/pull/5026/ - https://fetch.spec.whatwg.org/

pysec-2026-1497

2026-07-07T17:24:26.101543+00:00

### Impact In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration. ### Patches With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account! ### Workarounds No workaround exists. ### References Disclosed by [@novemberdad](https://huntr.dev/bounties/1714df73-e639-4d64-ab25-ced82dad9f85/).

pysec-2026-1924

2026-07-07T17:25:24.106990+00:00

### Summary The sigstore-python OAuth authentication flow is susceptible to Cross-Site Request Forgery. ### Details `_OAuthSession` creates a unique "state" and sends it as a parameter in the authentication request but the "state" in the server response seems not not be cross-checked with this value. Fix should be fairly trivial. ### Impact 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.

pysec-2026-2480

2026-07-13T16:04:04.844690+00:00

### Impact This vulnerability is an improper input neutralization issue leading to output manipulation, specifically, Terminal/ANSI Escape Sequence Injection and XML Injection: * Terminal Output Spoofing: A malicious file whose name contains ANSI escape sequences can end up being included in flawfinder'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. * 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(). It impacts those who use flawfinder to evaluate intentionally malicious filenames or file contents. The initial filename injection problem was reported by Dan Lenz https://www.linkedin.com/in/dan-lenz/ The other vulnerabilities were found by flawfinder project leader David A. Wheeler, GitHub david-a-wheeler, https://dwheeler.com/ ### Patches 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'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.20 or later. ### Workarounds There is no configuration-based workaround within older versions of flawfinder. If an immediate upgrade is not possible, users can mitigate the risk by: * Pre-scanning filenames: Manually or programmatically verifying that target repositories do not contain filenames with control characters (including ANSI escape sequences) before passing them to flawfinder. * Inspecting raw output: Reviewing flawfinder outputs in a text editor or logging mechanism that explicitly displays or strips raw escape sequences, rather than relying on live terminal rendering. * Restricting untrusted inputs: Avoiding the generation of SonarQube or CSV reports from completely untrusted repositories until the tool is updated. ### Resources See the flawfinder GitHub Repository: https://github.com/david-a-wheeler/flawfinder

pysec-2026-2551

2026-07-13T16:04:27.718301+00:00

## Summary 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't validate will be reset to a null value. ## Impact 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.

pysec-2026-2890

2026-07-13T16:05:36.936329+00:00

### Summary 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. ### Impact Arbitrary file write (path traversal) from untrusted sdist content. **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. 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. 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) ### Patches Versions 2.3.4 and newer of Poetry ensure that paths are inside the target directory. ### Root Cause File: `src/poetry/utils/helpers.py`, lines 410-426: ```python def extractall(source: Path, dest: Path, zip: bool) -> None: """Extract all members from either a zip or tar archive.""" if zip: with zipfile.ZipFile(source) as archive: archive.extractall(dest) else: broken_tarfile_filter = {(3, 9, 17), (3, 10, 12), (3, 11, 4)} with tarfile.open(source) as archive: if ( hasattr(tarfile, "data_filter") and sys.version_info[:3] not in broken_tarfile_filter ): archive.extractall(dest, filter="data") else: archive.extractall(dest) # <-- NO FILTER: path traversal ``` On Python versions without a working `tarfile.data_filter`, the `else` branch at line 426 calls `tarfile.extractall()` without any filter or path validation. This enables three attack vectors: 1. **Direct path traversal**: Tar members with `../../` path components write files outside the extraction directory. 2. **Symlink traversal**: A symlink member pointing outside dest, followed by a file written through that symlink, escapes the boundary. 3. **Hardlink attacks**: Hardlink members can read arbitrary files (same inode) or overwrite targets outside dest. #### Call Sites This function is called from two locations: 1. **`src/poetry/installation/chef.py:104`** (`_prepare_sdist`): During `poetry install` / `poetry add` when building a package from sdist. Only triggered when the executor is enabled (actual installation). 2. **`src/poetry/inspection/info.py:322`** (`_from_sdist_file`): During dependency resolution (`poetry lock` / `poetry add`). This path is reached when the sdist's `PKG-INFO` lacks `Requires-Dist` metadata, forcing Poetry to extract the archive (and afterwards build the package). ### Suggested Fix Apply path validation in the `else` branch, covering direct traversal, symlinks, and hardlinks: ```python def extractall(source: Path, dest: Path, zip: bool) -> None: """Extract all members from either a zip or tar archive.""" if zip: with zipfile.ZipFile(source) as archive: archive.extractall(dest) else: broken_tarfile_filter = {(3, 9, 17), (3, 10, 12), (3, 11, 4)} with tarfile.open(source) as archive: if ( hasattr(tarfile, "data_filter") and sys.version_info[:3] not in broken_tarfile_filter ): archive.extractall(dest, filter="data") else: # Validate all member paths before extraction dest_resolved = dest.resolve() safe_members = [] for member in archive.getmembers(): member_path = (dest_resolved / member.name).resolve() if not member_path.is_relative_to(dest_resolved): raise ValueError( f"Refusing to extract {member.name}: " f"would write outside {dest}" ) if member.issym(): link_target = (member_path.parent / member.linkname).resolve() if not link_target.is_relative_to(dest_resolved): raise ValueError( f"Refusing symlink {member.name}: " f"target {member.linkname} outside {dest}" ) elif member.islnk(): link_target = (dest_resolved / member.linkname).resolve() if not link_target.is_relative_to(dest_resolved): raise ValueError( f"Refusing hardlink {member.name}: " f"target {member.linkname} outside {dest}" ) safe_members.append(member) archive.extractall(dest, members=safe_members) ```

pysec-2026-2042

2026-07-07T17:25:50.724725+00:00

### Impact It was possible to accept an invitation opened by a different Weblate user. ### Patches * https://github.com/WeblateOrg/weblate/pull/16913 ### Workarounds Users should avoid leaving Weblate sessions with an unattended opened invitation. ### References Thanks to Nahid0x for responsibly disclosing this vulnerability to Weblate.

pysec-2026-195

2026-06-05T10:22:43.284691+00:00

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.

pysec-2026-2516

2026-07-13T16:04:17.128159+00:00

### Summary The "remaining charge time"-sensor for mobile phones (imported/included from Android Auto it appears) is vulnerable to the same issue as CVE-2025-62172. This also indicates that any sensor showing their name in the history-graph, is likely to be vulnerable to this issue. ### Details 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) 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. The PoC in this instance only shows HTML-injection in the form of the `` -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. ### 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 ` For a new entity, it should work when setting the name. For old entities, go here:
**PS: the example pictures show changing the name of the device-tracker entity, which is wrong. Just change the name of the `remaining charge time`-sensor in order to validate this finding** 3. Add a history graph card with the malicious sensor 5. Hover the graph for payload execution ### Impact The impact of this vulnerability is that a user can target other users of the system and perform account takeover through client side exploitation of XSS. In the context of this system, I believe the vulnerability to be less impactful than the CVSS metric describes. It is not displayed anywhere by default, it is not natural to display this history graph, and it also has no potential for being imported through seemingly innocent integrations. It also appears to rely on having used/using Android Auto. Other devices which has the same sensor can trigger the same vulnerability, and I expect there to exists cloud-based devices that would enable a threat actor to deliver the payload remotely. Credit: Robin Lunde - [https://robinlunde.com](https://robinlunde.com)

pysec-2026-2517

2026-07-13T16:04:17.249850+00:00
### 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's movement, as shown in the screenshot below, with the example showing a html-injection using `` to strikethrough the text) This allows an authenticated user to execute JavaScript in the context of any other users accessing a dashboard. ### Details 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 Fold Robin {{7*7}}`: Map card with malicious device entity: YAML-view of same card: 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. ### 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 ` For a new entity, it should work when setting the name. For old entities, go here:
3. Add the entity to a map card, which has the "hours to show"-attribute set, to display movement history (The left arrow showing the custom setting, and the right arrow showing a data point which needs to be hovered) 4. The payload executes when hovering a data-point (here shown with an "alert(document.domain"-payload) ### Impact The impact of this vulnerability is that a user can target other users of the system and perform account takeover through client side exploitation of XSS. In the context of this system, I believe the vulnerability to be less impactful than the CVSS metric describes, as it requires a specific setup (map-card with attribute `hours_to_show` set, as this brings up the trail). It is interesting to note that any user who sets this attribute, will be highly likely to trigger the vulnerability through normal use. It also has no potential for being imported through seemingly innocent integrations and can only be set explicitly by another invited user, a device name, a cloud service or through social engineering. Other devices which has the same sensor can trigger the same vulnerability, and I expect there to exists cloud-based devices that would enable a threat actor to deliver the payload remotely. Suggested criticality: **Medium** Credit: Robin Lunde - [https://robinlunde.com](https://robinlunde.com)