Local git repositories can turn secret scans into code execution

At a glance

What this is: This is a vulnerability analysis showing that untrusted local Git repositories can turn secret-scanning into command execution through malicious repository configuration.

Why it matters: It matters because IAM and NHI teams increasingly rely on scanners and pipeline tools that touch repos containing secrets, and those tools must not inherit trust from copied repository state.

👉 Read TruffleHog's analysis of CVE-2025-41390 and untrusted git repositories

Context

The core security problem is not secret detection itself, but the assumption that a local repository copied file-for-file is equivalent to a clean clone. In reality, preserved .git metadata can carry configuration that changes how Git behaves, which makes the scanner part of the attack surface. For secret scanning, that means trust boundaries sit around repository provenance, not just around the credentials the tool is trying to find.

This is an NHI governance issue because scanners, automation jobs, and build tools often run with credentials or broad filesystem access. If they process untrusted repositories without isolating Git behavior, a routine scan can become a privilege-bearing execution path. That makes repository hygiene, tool invocation safety, and secret-scanning controls part of the same identity risk chain.

Key questions

Q: What breaks when secret-scanning tools trust copied git repositories?

A: Copied repositories can preserve malicious .git metadata that changes Git’s runtime behavior. If a scanner shells out to Git before normalizing the repo, repository-local configuration can trigger external commands during what should have been a read-only inspection. The failure is trust, not detection. Treat copied repositories as untrusted inputs and normalize them before execution.

Q: Why do untrusted repositories create risk for NHI and secrets workflows?

A: Because secret scanners and CI helpers often run with more access than the repository itself. When those tools invoke Git, attacker-controlled configuration inside the repo can influence runtime behavior and turn a discovery workflow into code execution. That is a governance issue for NHI tooling, not just a Git bug.

Q: How do security teams know if their repo-scanning controls are actually working?

A: Look for two signals: untrusted repositories are always cloned into a temporary workspace, and no scanner path shells out to Git on copied inputs. If either condition is missing, the control is incomplete. A working program makes repository provenance visible before execution and separates inspection from attacker-controlled metadata.

Q: Who is accountable when a security tool executes attacker-controlled Git behavior?

A: Accountability sits with the team that owns the tool, the pipeline, and the repository intake process. If a scanner executes configuration from an untrusted repository, that is a control design failure, not an unavoidable property of Git. Ownership should span platform security, IAM, and the team operating the scanning workflow.

Technical breakdown

Why copied git repositories are different from cloned repositories

A repository copied file-for-file preserves the .git directory exactly as it was on disk, including configuration that Git may interpret during later commands. A clone, by contrast, reconstructs repository state through Git’s own copy semantics and strips away a range of unsafe assumptions about how the repo was prepared. The difference matters because many tools call Git under the hood for status checks, parsing, or history walking. If the tool trusts the local path too early, it inherits whatever behavior the repository metadata can induce. That is why provenance matters as much as content when scanning untrusted repositories.

Practical implication: Treat copied repositories as untrusted inputs and route them through a clean clone before any Git command runs.

How malicious .git config entries can trigger command execution

Git supports configuration hooks and external command paths such as fsmonitor and other extensibility points. In a malicious repository, those settings can be weaponised so that an otherwise harmless command like git status triggers attacker-controlled behavior. This is not a secret-scanning bug in isolation. It is a command execution path created when tooling shells out to Git without constraining how Git interprets repository-local configuration. The risk increases when the scanner processes data from shared analysis spaces, ZIP imports, or repos collected from third parties, because the local filesystem then carries attacker influence into runtime.

Practical implication: Disable unsafe Git config behavior for untrusted inputs and review every tool that shells out to Git on copied repositories.

Why local clone hardening is the safer pattern for secret scanners

The strongest mitigation is to force a local clone into a temporary workspace before scanning. That replaces mutable repository-local behavior with a cleaner execution context and aligns the scanner with Git’s own security model for unsafe inputs. Denylists are brittle because new configuration vectors keep appearing, while allowlists can be hard to maintain across platforms. A temporary clone does not eliminate all risk, but it meaningfully reduces the chance that repository metadata can influence scanner execution. For NHI and secrets teams, this is a pattern decision, not just a patch detail.

Practical implication: Build secret-scanning pipelines so that untrusted repositories are normalized into temporary clones before inspection.

Threat narrative

Attacker objective: The attacker wants to turn a repository inspection workflow into code execution and broaden access to the scanning environment.

1. Entry occurs when an attacker places a malicious .git/config inside a repository that is later copied file-for-file into a shared analysis environment.
2. Escalation occurs when the secret-scanning tool shells out to Git and inherits repository-local configuration that can invoke external commands.
3. Impact occurs when the command executes with the scanner’s permissions, creating arbitrary code execution during what should have been a read-only inspection.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Millions of Misconfigured Git Servers Leaking Secrets — Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Repository provenance has become an identity control, not just a source-control concern. The vulnerability works because tools infer trust from a local path rather than from how the repository arrived there. That assumption collapses the moment untrusted metadata can influence the runtime of a secret scanner. Practitioners should treat copied repositories as a governed input class, not a convenience shortcut.

Local Git metadata is part of the attack surface for NHI tooling. Secret scanners, pipeline jobs, and analysis helpers often run with access that is more privileged than the repository itself. When those tools shell out to Git, they inherit command execution risk from configuration that should never have been trusted. The implication is that scanner design and NHI governance now overlap at the execution boundary.

Static denylist thinking is too fragile for this class of risk. Git exposes many configuration paths that can affect runtime behavior, and new ones are not hard to introduce. A narrow patch may close one vector while leaving the trust model intact. The practical conclusion is that governance should focus on normalizing untrusted repos into clean execution contexts before any Git-dependent processing begins.

Identity risk is present even in read-only security workflows. Secret scanning is often treated as passive discovery, but the runtime can still execute with meaningful authority. That means the real governance question is not only what secrets are found, but what identities and execution paths the scanner itself can touch while searching. Teams should map those trust edges explicitly.

Safe scanning depends on separating inspection from repository-controlled behavior. The decision to clone untrusted local repositories before processing is a control-pattern response to a broken trust assumption. It limits the scanner’s exposure to attacker-shaped Git state and makes the workflow more predictable for IAM and platform teams. Practitioners should review every path where repository data becomes executable context.

From our research:

• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to The 2024 State of Secrets Management Survey.
• From our research: 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to The 2024 State of Secrets Management Survey.
• From our research: The 52 NHI Breaches Analysis shows how control failures around non-human identities frequently begin with overlooked trust boundaries and end in broad exposure.

What this signals

Copied repository trust is now a practical control boundary for security teams that scan code and secrets. If your workflow allows arbitrary local repos to enter a scanner without normalization, you have a hidden execution path that sits outside conventional secrets policy. That gap is especially relevant for teams mapping scanner activity to the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

The operational lesson is that secret discovery cannot be separated from runtime governance. Tools that search for secrets often handle data from multiple tenants, shared workspaces, or third-party drops, so the repository intake step becomes part of the trust model. Teams that already rely on the Ultimate Guide to NHIs , Static vs Dynamic Secrets should extend that thinking to scanner execution paths.

Repository provenance gap: the hidden failure mode is treating file-for-file imports as equivalent to safe clones. Once that assumption is removed, the control question becomes whether the scanner can execute before Git-local state is stripped away. That change is small in code but large in governance, because it moves the trust decision earlier in the workflow.

For practitioners

• Force untrusted repositories through a temporary clone Require secret-scanning tools to clone local repositories into a clean temporary directory before any Git command runs. This removes repository-local configuration from the active execution context and reduces the chance of command injection through copied .git metadata.
• Audit Git shell-outs in scanner workflows Inventory every place your secret scanners, analysis jobs, and CI helpers invoke Git. Pay special attention to commands that read repository-local config, because those calls can inherit attacker-controlled behavior from copied repositories.
• Disable unsafe Git config handling for untrusted inputs Set safe.bareRepository to explicit where appropriate and use command-line options that suppress risky Git features for untrusted paths. The goal is to make repository processing deterministic before the scanner inspects secrets.
• Separate trust levels for cloned and copied repos Create a policy that distinguishes genuine clones from file-for-file imports, ZIP extractions, and shared analysis drops. Only the first should be eligible for direct scanner execution without normalization.

Key takeaways

• A copied Git repository can become an execution vector when scanner workflows trust local .git metadata.
• The relevant control failure is not secret detection accuracy, but unsafe repository intake and Git shell-out behavior.
• Security teams should normalize untrusted repositories into clean temporary clones before any Git-dependent processing begins.

Key terms

• Untrusted Repository Intake: The point at which a tool accepts a repository from outside its trusted build or source-control flow. For secret scanning, intake must be treated as a security boundary because copied repositories can preserve attacker-controlled metadata that affects runtime behavior.
• Git Shell-Out Risk: The hazard created when an application invokes Git commands on repository content it does not fully control. If local configuration is allowed to influence those commands, the application can inherit execution behavior from the repository itself.
• Repository Provenance: Evidence showing how a repository reached the system, including whether it was cloned, copied, downloaded, or reconstructed. Provenance matters because trust should follow the acquisition path, not just the file contents present at scan time.

What's in the full article

TruffleHog's full post covers the engineering details this analysis intentionally leaves at a higher level:

• The exact untrusted repository handling change that uses a local git clone before scanning.
• The reasoning behind rejecting denylist and allowlist approaches for unsafe repository configuration.
• The trust-local-git-config override and when it is meant to be used.
• The specific affected TruffleHog versions and update path for enterprise and open-source users.

👉 The full TruffleHog post covers the hardening approach, update path, and trust-local-git-config details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or secrets governance programme, it is worth exploring.