https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 20:49:42 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-211157 EUVD-2026-211157 https://cve.radiocsirt.org/vuln/euvd-2026-211157 https://cve.radiocsirt.org/vuln/fkie_cve-2025-22620 <p>gitoxide is an implementation of git written in Rust. Prior to 0.17.0, gix-worktree-state specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations. This vulnerability is fixed in 0.17.0.</p> <p>gitoxide is an implementation of git written in Rust. Prior to 0.17.0, gix-worktree-state specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations. This vulnerability is fixed in 0.17.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-22620 https://cve.radiocsirt.org/vuln/ghsa-fqmf-w4xh-33rh <p><strong>Affected:</strong> crates.io: gix-worktree-state</p> <p>### Summary</p> <p>`gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations.</p> <p>### Details</p> <p>Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported).</p> <p>[`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable:</p> <p>- If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask. - If the file is considered possibly already to exist—even in a clean checkout if the application does not specify the option to treat the destination directory as empty—then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask.</p> <p>Specifically, [`checkout::entry::checkout`](https://github.c…</p> <p><strong>Affected:</strong> crates.io: gix-worktree-state</p> <p>### Summary</p> <p>`gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations.</p> <p>### Details</p> <p>Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported).</p> <p>[`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable:</p> <p>- If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask. - If the file is considered possibly already to exist—even in a clean checkout if the application does not specify the option to treat the destination directory as empty—then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask.</p> <p>Specifically, [`checkout::entry::checkout`](https://github.c…</p> https://cve.radiocsirt.org/vuln/ghsa-fqmf-w4xh-33rh https://cve.radiocsirt.org/vuln/opensuse-su-2025:14994-1 <p>gitoxide-0.42.0-1.1 on GA media</p> <p>gitoxide-0.42.0-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:14994-1 https://cve.radiocsirt.org/vuln/rustsec-2025-0001 <p><strong>Affected:</strong> crates.io: gix-worktree-state</p> <p>### Summary</p> <p>`gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations.</p> <p>### Details</p> <p>Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported).</p> <p>[`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable:</p> <p>- If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask. - If the file is considered possibly already to exist—even in a clean checkout if the application does not specify the option to treat the destination directory as empty—then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask.</p> <p>Specifically, [`checkout::entry::checkout`](https://github.c…</p> <p><strong>Affected:</strong> crates.io: gix-worktree-state</p> <p>### Summary</p> <p>`gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations.</p> <p>### Details</p> <p>Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported).</p> <p>[`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable:</p> <p>- If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask. - If the file is considered possibly already to exist—even in a clean checkout if the application does not specify the option to treat the destination directory as empty—then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask.</p> <p>Specifically, [`checkout::entry::checkout`](https://github.c…</p> https://cve.radiocsirt.org/vuln/rustsec-2025-0001 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-22620 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> Ubuntu:25.04: rust-gix-worktree-state</p> <p>gitoxide is an implementation of git written in Rust. Prior to 0.17.0, gix-worktree-state specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations. This vulnerability is fixed in 0.17.0.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> Ubuntu:25.04: rust-gix-worktree-state</p> <p>gitoxide is an implementation of git written in Rust. Prior to 0.17.0, gix-worktree-state specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations. This vulnerability is fixed in 0.17.0.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-22620