<?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 all</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>Mon, 05 Oct 2026 03:10:53 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-368148</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-368148</link>
      <description>EUVD-2026-368148</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-368148</guid>
    </item>
    <item>
      <title>fkie_cve-2025-24890</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-24890</link>
      <description>&lt;p&gt;gitoxide is an implementation of git written in Rust. Prior to 0.13.3, the gix-sec crate on Windows incorrectly treats repositories controlled by another user as trusted when an administrator runs a dependent program with an unfiltered elevated token. In gix-sec/src/identity.rs, gix_sec::identity::is_path_owned_by_current_user obtains folder_owner and token_owner, but its administrator-specific IsWellKnownSid and CheckTokenMembership checks examine the running token rather than confirming the directory owner. This bypasses safe.directory-style protection for repositories owned and configured by a limited user, allowing repository configuration or hooks to execute commands with the administrator&amp;#39;s privileges when an affected operation is performed. Exploitation requires Windows, an elevated administrator, a program that relies on gix-sec trust results, and interaction with a repository controlled by another user. An unelevated UAC process is not affected, and cloning is not affected because repository configuration and hooks are not copied. This issue is fixed in version 0.13.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;gitoxide is an implementation of git written in Rust. Prior to 0.13.3, the gix-sec crate on Windows incorrectly treats repositories controlled by another user as trusted when an administrator runs a dependent program with an unfiltered elevated token. In gix-sec/src/identity.rs, gix_sec::identity::is_path_owned_by_current_user obtains folder_owner and token_owner, but its administrator-specific IsWellKnownSid and CheckTokenMembership checks examine the running token rather than confirming the directory owner. This bypasses safe.directory-style protection for repositories owned and configured by a limited user, allowing repository configuration or hooks to execute commands with the administrator&amp;#39;s privileges when an affected operation is performed. Exploitation requires Windows, an elevated administrator, a program that relies on gix-sec trust results, and interaction with a repository controlled by another user. An unelevated UAC process is not affected, and cloning is not affected because repository configuration and hooks are not copied. This issue is fixed in version 0.13.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-24890</guid>
    </item>
    <item>
      <title>GHSA-7rhf-42qf-vrvc — gix-sec safe.directory protections absent for elevated administrators</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7rhf-42qf-vrvc</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: gix-sec&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;In a process run with full administrative rights on Windows, `gix-sec` wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of `safe.directory`. [This is because](https://git-scm.com/docs/git.html#_security) of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.&lt;/p&gt;
&lt;p&gt;On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the `Administrators` group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.&lt;/p&gt;
&lt;p&gt;Code in `gix-sec` intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the `Administrators` group, yet instead accidentally examines *itself* again, rather than the directory.&lt;/p&gt;
&lt;p&gt;Specificall…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: gix-sec&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;In a process run with full administrative rights on Windows, `gix-sec` wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of `safe.directory`. [This is because](https://git-scm.com/docs/git.html#_security) of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.&lt;/p&gt;
&lt;p&gt;On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the `Administrators` group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.&lt;/p&gt;
&lt;p&gt;Code in `gix-sec` intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the `Administrators` group, yet instead accidentally examines *itself* again, rather than the directory.&lt;/p&gt;
&lt;p&gt;Specificall…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7rhf-42qf-vrvc</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-24890 — gix-sec safe.directory protections absent for elevated administrators</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-24890</link>
      <description>msrc_CVE-2025-24890</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-24890</guid>
    </item>
  </channel>
</rss>
