DeepSeek-Reasonix: How a poisoned config can hijack an AI coding agent

GitLab's Threat Research Group discovered a command execution vulnerability (GHSA-grg2-7gc6-36m6, CVE-2026-102437) in DeepSeek-Reasonix Studio, a desktop git client designed for developers pairing with AI coding assistants. The flaw, called ConfigPoisoning, could allow attacker-supplied code to execute when a developer views a file's diff. To address this vulnerability, you should update to DeepSeek-Reasonix Studio 2.21.0 or DeepSeek Reasonix npm 1.39.3.

This is not an isolated DeepSeek-Reasonix bug. GitLab's Threat Research Group found that multiple widely used coding agents are susceptible to the same class of vulnerabilities, which allow attacker-controlled commands to run from a repository's own .git/config and .gitattributes files. DeepSeek-Reasonix is the first case we're disclosing in full.

Note: Git repositories hosted on GitLab are not affected by this vulnerability, as cloning a repository over HTTPS or SSH does not transfer local configuration files.

TL;DR

• Critical vulnerability. GitLab's Threat Research Group found a critical command execution vulnerability in DeepSeek-Reasonix Studio, a desktop git client for AI-assisted development, that could run attacker-controlled code when a developer views a file's diff under specific repository configuration conditions.
• The root cause. DeepSeek-Reasonix's own git wrapper hardens several git config keys against command injection, but its own code comment names one gap it hadn't closed: filter.<driver>.clean, which git selects per file through .gitattributes rather than through a fixed config key.
• Immediate recommendations. Update to DeepSeek-Reasonix Studio 2.21.0 or DeepSeek Reasonix npm 1.39.3. If you build tools that shell out to git, don't just patch the one vulnerable key. Override every relevant key on every call, or avoid invoking git's filter and textconv machinery, which are the hooks git uses to transform file content before committing or diffing, altogether.

Why coding agents are a different kind of attack surface

Coding agents run git against any directory a developer opens. They inherit .git/config and .gitattributes from whoever wrote the repo, not from the developer who opens it. Several git configuration keys, among them core.fsmonitor, core.hooksPath, diff.external, and filter.<driver>.clean, run a named command as part of ordinary git operations. Plain git clients already carry advisories for this.

Because every coding agent wraps git its own way, each one tends to close only the primitive that caused its own last incident. DeepSeek-Reasonix's internal/gitcmd closed four of these primitives on every invocation. Its own code comment named the one it hadn't closed.

How the vulnerability works

internal/gitcmd neutralizes core.fsmonitor and maintenance.auto on every call, and adds --no-ext-diff and --no-textconv on diffs. It never touches filter.<driver>.clean. That key isn't picked from a fixed list. .gitattributes selects it per file, so no deny-list can close it the way the others were closed.

Here's the real call, from desktop/workspace_changes.go:

      args := []string{"-C", base, "diff", "--no-ext-diff", "--no-textconv", "--relative", "HEAD", "--", filepath.FromSlash(rel)}

    

The clean filter still runs here. It produces the comparison blob the diff needs, and that step never passes through the flags above.

Full call chain

Here's the full chain, step by step:

1. The setup. secret.bin carries a .gitattributes entry assigning it to a filter driver named pwn, and the repository's .git/config defines that driver's clean command as a script of the attacker's choosing.
2. The diff view opens. A developer opens the file's diff in DeepSeek-Reasonix's desktop app, an ordinary action for any file with an uncommitted change.
3. DeepSeek-Reasonix runs its hardened command. desktop/workspace_changes.go issues git -c core.fsmonitor=false -c maintenance.auto=false -C <repo> diff --no-ext-diff --no-textconv -- secret.bin, with every existing hardening flag in place.
4. The clean filter runs anyway. Git invokes filter.pwn.clean to build the comparison blob, a step none of those flags touch. The attacker's command executes, once for each side of the diff.

Replaying the hardened command ran the payload twice: diff builds a clean-filtered blob for each side of the comparison, so the filter fires once per side. git status only checks which files changed, so it never builds that blob and leaves the filter untouched. That isolates the bug to diff rendering, matching DeepSeek-Reasonix's actual code path.

Scope

.gitattributes survives a clone. .git/config doesn't. Delivery needs an archive, a synced folder, a CI cache, or a devcontainer build. We confirmed this at commit ea28602 and the tagged pre-release studio-v2.9.0. It affects both the desktop app and the npm package.

But there's a more direct vector specific to agentic tooling. A rogue, compromised, or prompt-injected coding agent already running on the developer's machine has the developer's own filesystem access. It can write the poisoned .git/config straight into a repository that was cloned completely normally. No archive, synced folder, or CI cache is required.

Why new tools inherit old bugs

None of this is unique to DeepSeek-Reasonix.

• Repository configuration gets treated as part of the tool. Coding agents read .git/config or .gitattributes as if they were the tool’s own settings, when it’s the repository’s author who controls them. That distinction is easy to miss, since the files sit right next to the code and look like they belong to it.
• We've seen this trust failure before, in a different file. Earlier this year, GitLab's Threat Research Group found the same pattern in Serena, another AI coding tool. It ran attacker code from a project's own configuration file, .serena/project.yml, when a developer opened the repository. In both cases, the tool trusted a file the repository author controlled, and we expect to find the same mistake in other agentic tools.

How this impacts you

If you use DeepSeek-Reasonix

Update to Studio 2.21.0 or DeepSeek Reasonix npm 1.39.3. On older versions, avoid diffing any repo you didn't obtain through a direct clone yourself.

If you build git-wrapping tools

These recommendations apply to any tool that shells out to git against a directory it doesn't control.

• Read blobs with git cat-file or git show, and diff in-process, when you only need byte-level content.
• If you must shell out, override every relevant key on every call. That means core.fsmonitor, core.pager, core.editor, core.hooksPath, diff.external, core.sshCommand, and filter.<driver>.clean or smudge for every driver name across .gitattributes, .git/info/attributes, and global or system files.
• One flag doesn't cover another. --no-ext-diff affects diff.external. It does nothing for core.sshCommand.
• Don't assume the poisoned config has to arrive with the repository. Another agent, extension, or process running with the developer's own permissions can write it straight into an already-cloned repo.
• Test against a deliberately hostile config pair before you ship.

If you lead a security team

A tool that shells out to git on a developer's machine runs with that developer's full access. Ask vendors how they neutralize repository-local configuration, not just how they handle an untrusted remote.

Disclosure timeline

Thanks to the DeepSeek-Reasonix maintainers for accepting the report and shipping a fix.

How GitLab can help

GitLab Duo Agent Platform Security Analyst Agent can help you check your codebase for this same pattern. Begin your investigation by asking the agent:

      "Does this code shell out to git against a directory it doesn't control, and does it neutralize `core.hooksPath, filter.*.clean`, and `diff.external` before running?"

    

The agent then will evaluate the potential impact on your environment.

Looking ahead

DeepSeek-Reasonix's history is a good reminder that even a well-documented, honest gap in security can still ship, simply because knowing about a risk and closing it aren't always the same thing. The same pattern is present in several other widely used agent tools, currently under coordinated disclosure. We'll publish details on each once a fix is available.

Explore more security research from the GitLab Threat Research Group.