CVE-2025-27613

What it actually does

Gitk allows creation or truncation of arbitrary writable files when a user clones an untrusted repository and invokes gitk (with per-file encoding enabled or via Show origin of this line), due to insufficient path sanitization in Tcl/Tk handling of repository metadata.

Why it matters to the business

Attackers can corrupt or delete local files on developer workstations that process untrusted repositories, leading to data loss, disrupted workflows, and potential supply-chain risks in environments using affected Git tools; the Chainguard nemo package requires immediate upgrade to 2.3.2-r1 given the 475 days since disclosure and rising EPSS trend.

How an attack unfolds

An attacker crafts a malicious Git repository containing specially formatted metadata that triggers file operations in Gitk; the victim clones the repository and runs gitk (with Support per-file encoding or Show origin), causing Gitk to create or truncate files the user can write to. The Git Link Following Vulnerability context highlights link-following abuse in repository history viewers.

How to fix it

Upgrade Git to one of 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1, or 2.50.1; for Chainguard nemo upgrade specifically to 2.3.2-r1. Disable Support per-file encoding in Gitk preferences until patched and avoid running gitk on untrusted clones.

How to confirm the fix worked

Verify installed Git version against the fixed releases listed; confirm nemo package version is at least 2.3.2-r1; test by cloning a repository with per-file encoding enabled and checking that no unexpected files are created or truncated.

Typical attack path

1. Attacker publishes a malicious repository with crafted encoding or origin metadata
2. Victim clones the repository without additional arguments
3. Victim launches gitk with per-file encoding enabled or uses Show origin of this line
4. Gitk processes the metadata and performs unauthorized file creation or truncation

How to detect it

Review shell history and process logs for invocations of gitk after cloning external repositories; inspect file-system audit logs for unexpected creation or truncation events in user-writable directories shortly after gitk execution; correlate with repository clone timestamps from threat actor campaigns referencing Git Link Following Vulnerability.

What your security team should do

• Immediately upgrade all instances of nemo to 2.3.2-r1 and Git clients to a fixed release
• Add repository cloning from untrusted sources to the list of high-risk activities requiring review
• Update developer tooling policies to require patched Gitk before processing external repositories
• Monitor EPSS trend and reassess if exploit maturity changes from None