<?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-02T16:04:20.924002+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/cve-2024-40644</id>
    <title>CVE-2024-40644 — gitoxide's gix-path can use a fake program files location</title>
    <updated>2026-10-02T16:04:20.956224+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Byron gitoxide</p>
<p>gitoxide An idiomatic, lean, fast &amp; safe pure Rust implementation of Git. `gix-path` can be tricked into running another `git.exe` placed in an untrusted location by a limited user account on Windows systems. Windows permits limited user accounts without administrative privileges to create new directories in the root of the system drive. While `gix-path` first looks for `git` using a `PATH` search, in version 0.10.8 it also has a fallback strategy on Windows of checking two hard-coded paths intended to be the 64-bit and 32-bit Program Files directories. Existing functions, as well as the newly introduced `exe_invocation` function, were updated to make use of these alternative locations. This causes facilities in `gix_path::env` to directly execute `git.exe` in those locations, as well as to return its path or whatever configuration it reports to callers who rely on it. Although unusual setups where the system drive is not `C:`, or even where Program Files directories have non-default names, are technically possible, the main problem arises on a 32-bit Windows system. Such a system has no `C:\Program Files (x86)` directory. A limited user on a 32-bit Windows system can therefore create the `C:\Program Files (x86)` directory and populate it with arbitrary contents. Once a payload has been placed at the second of the two hard-coded paths in this way, other user accounts including administrators will execute it if they run an application that uses `gix-path` and do not have `git…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-40644"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-mgvv-9p9g-3jv4</id>
    <title>GHSA-mgvv-9p9g-3jv4 — gix-path can use a fake program files location</title>
    <updated>2026-10-02T16:04:20.956312+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: gix-path</p>
<p>### Summary</p>
<p>When looking for Git for Windows so it can run it to report its paths, `gix-path` can be tricked into running another `git.exe` placed in an untrusted location by a limited user account.</p>
<p>### Details</p>
<p>Windows permits limited user accounts without administrative privileges to create new directories in the root of the system drive. While `gix-path` first looks for `git` using a `PATH` search, in version 0.10.8 it also has a fallback strategy on Windows of checking two hard-coded paths intended to be the 64-bit and 32-bit Program Files directories:</p>
<p>https://github.com/Byron/gitoxide/blob/6cd8b4665bb7582f744c3244abaef812be39ec35/gix-path/src/env/git.rs#L9-L14</p>
<p>Existing functions, as well as the newly introduced `exe_invocation` function, were updated to make use of these alternative locations. This causes facilities in `gix_path::env` to directly execute `git.exe` in those locations, as well as to return its path or whatever configuration it reports to callers who rely on it.</p>
<p>Although unusual setups where the system drive is not `C:`, or even where Program Files directories have non-default names, are technically possible, the main problem arises on a 32-bit Windows system. Such a system has no `C:\Program Files (x86)` directory.</p>
<p>A limited user on a 32-bit Windows system can therefore create the `C:\Program Files (x86)` directory and populate it with arbitrary contents. Once a payload has been placed at the second of the two hard-coded paths in this way, other use…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-mgvv-9p9g-3jv4"/>
  </entry>
</feed>
