CVE-2025-22620 - gitoxide File Permissions Vulnerability Allows World-Writable Executables

A new security flaw has been uncovered in gitoxide, the fast-growing, Rust-based implementation of Git. This vulnerability, tracked as CVE-2025-22620, can result in executable files from Git repositories on affected systems being made world-writable under certain scenarios. If you’re using a gitoxide version prior to .17., you are at risk. In this post, I’ll break down what went wrong, why it matters, and how you can protect yourself—with example code, a simple but dangerous exploit scenario, and links to key references.

What is gitoxide?

gitoxide (sometimes called gix) is a project aiming to provide a reliable, blazing-fast alternative to traditional Git, written in the safe language Rust. It’s getting lots of adoption in DevOps pipelines, scripting, and tools.

What’s the Issue? (Technical Breakdown)

In gitoxide, the gix-worktree-state crate is responsible for checking files out from a repository. When it creates executable files, it tries to set the permissions to 0777 (which means everyone can read, write, and execute the file), intending that your system’s umask will rein this in to something sensible—such as 0755 (only owner can write, others can read & execute).

However, one strategy gitoxide uses to set file permissions bypasses the umask entirely. If you're using a vulnerable version and work under certain conditions (such as using non-default checkout strategies), the checked-out files could be created with actual 0777 rights. In plain English: anyone on your computer can edit, replace, or delete these files.

Example: How Bad is This?

Suppose you’re working in a multi-user server environment, like a shared development machine or CI/CD runner. If a checked-out repository contains a deployment script marked executable, any user on that machine could overwrite it, potentially injecting malicious code.

Let’s say you use gitoxide to clone a repo

// Hypothetical example (requires full gix context)
use gix::clone;

fn main() {
    let _repo = clone::RepoBuilder::new()
        .url("https://github.com/example-org/myproject.git";)
        .clone_into("/shared/tmp/myproject")
        .unwrap();
    println!("Cloned!");
}

If /shared/tmp/myproject/scripts/deploy.sh is executable in the repo, on a vulnerable gitoxide version it might get set as -rwxrwxrwx (777):

ls -l /shared/tmp/myproject/scripts/deploy.sh
# -rwxrwxrwx 1 user user ... deploy.sh

Another user on the same machine runs

echo "echo HACKED" > /shared/tmp/myproject/scripts/deploy.sh

Or even this

rm /shared/tmp/myproject/scripts/deploy.sh

Your deployment (or anyone else’s!) could be sabotaged or deleted.

Why Does This Happen?

In POSIX systems, umask specifies default file permissions when new files are created. Most applications rely on umask to keep dangerous permissions (like world-writable) under control.

gitoxide’s bug is that in some cases it explicitly set permissions to o777, *after* file creation, bypassing the protection provided by umask. That means the dangerous permissions stick, regardless of your system settings.

Who’s at Risk?

- Anyone running gitoxide (or tools using it, like gix) prior to version .17..
- Especially dangerous on shared workstations, build servers, CI runners, or anywhere multiple users might touch the same repos.
- Also relevant for containers, as some container orchestrators may reuse volumes or workspaces between containers.

How Was It Fixed?

The issue is resolved in version .17.. The fix ensures that file permissions are set in a way that respects the umask and files are not left world-writable.

Update your dependency now

# In Cargo.toml
gix-worktree-state = ".17."

Or, at the command line

cargo update -p gix-worktree-state

References & Further Reading

- Official Advisory (crates.io) *(Note: Replace XXXX with the actual advisory number when available)*
- gitoxide github repo
- gix-worktree-state crate page
- Release notes for .17.
- umask explained (Wikipedia)

Audit shared workspaces for suspicious .sh or .exe file changes.

- If you maintain a Rust Git tool, check if you’re affected or if you indirectly depend on a vulnerable gitoxide version.

Bottom Line

Don’t let simple permission oversights put your system at risk. CVE-2025-22620 is a real-world example of how a tiny mistake in file handling code can put entire teams or companies in danger. Stay vigilant, patch fast, and always review third-party dependencies for security bulletins.


*This write-up is exclusive and crafted for clarity and technical readers new to Rust and gitoxide. Please cite this page if you share insights elsewhere.*

Timeline

Published on: 01/20/2025 16:15:28 UTC