GitLab finds the ConfigPoisoning flaw in DeepSeek-Reasonix

GitLab's Threat Research Group has disclosed a command execution vulnerability in DeepSeek-Reasonix Studio, a desktop Git client built for developers who pair with AI coding assistants. The flaw, which GitLab calls ConfigPoisoning, lets attacker-supplied code run when a developer opens a file's diff.

It is tracked as CVE-2026-102437 and advisory GHSA-grg2-7gc6-36m6. GitLab says the fix shipped on 30 September in DeepSeek-Reasonix Studio 2.21.0 and in the DeepSeek Reasonix npm package 1.39.3, the same day the CVE was assigned. GitLab traced the code path back to commit ea28602 and the studio-v2.9.0 pre-release tag, and confirmed it affects both the desktop app and the npm package.

How ConfigPoisoning works

DeepSeek-Reasonix hardens its git wrapper against several command-injection primitives. It disables core.fsmonitor and maintenance.auto on every call and passes --no-ext-diff and --no-textconv when it diffs. The one it never closed is filter.<driver>.clean, and its own source comments admit as much.

That gap matters because filter drivers are not selected from a fixed list of config keys. A repository's .gitattributes file assigns a file to a named filter driver, and the same repository's .git/config defines what that driver's clean command actually runs. No deny-list can cover it, because the key is chosen per file rather than declared in one place.

In practice a file named secret.bin can carry a .gitattributes entry pointing at a filter driver called pwn, with the driver's clean command set to a script of the attacker's choosing. When the developer opens that file's diff, Git invokes the clean filter to build the comparison blob, a step none of the hardening flags touch. Replaying the hardened command ran the payload twice, because diff builds a clean-filtered blob for each side of the comparison. A git status call, by contrast, only checks which files changed, which is why it leaves the filter untouched.

Why coding agents widen the attack surface

Coding agents run git against any directory a developer opens, and they inherit .git/config and .gitattributes from whoever wrote the repository rather than from the person working in it. GitLab notes that .gitattributes survives a clone while .git/config does not, so delivery of the poisoned configuration usually needs an archive, a synced folder, a CI cache or a devcontainer build.

For agentic tooling there is a more direct route. A rogue, compromised or prompt-injected coding agent already running on the developer's machine has the developer's own filesystem access, so it can write a poisoned .git/config straight into a repository that was cloned completely normally. No archive or shared folder is required.

What developers should do

GitLab's recommendation is to update to Studio 2.21.0 or npm 1.39.3. On older versions it advises against diffing any repository that was not obtained through a direct clone.

For teams building tools that shell out to git, the advice is broader. Read blobs with git cat-file or git show and diff in process where byte-level content is all that is needed. If a tool must shell out, GitLab recommends overriding every relevant key on every call: 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 any global or system files. One flag does not cover another, GitLab warns, noting that --no-ext-diff affects diff.external but does nothing for core.sshCommand.

Not an isolated bug

GitLab describes DeepSeek-Reasonix as the first case it is disclosing in full, and says several other widely used coding agents share the same class of flaw and are under coordinated disclosure. It draws a direct comparison with Serena, another AI coding tool that GitLab reported earlier this year for running attacker code from a project's own .serena/project.yml configuration file. Repositories hosted on GitLab are not affected, because cloning over HTTPS or SSH does not transfer local configuration files.

Our opinion

The interesting part of ConfigPoisoning is not the patch, it is the pattern. DeepSeek-Reasonix's maintainers knew about the risk, wrote a comment naming the exact key they had not closed, and shipped anyway, which is the ordinary human failure mode rather than a scandal. What makes it feel new is that AI coding agents keep handing repository files the trust normally reserved for the tool's own settings. A .gitattributes file sits next to source code and reads like part of the project, so an agent treats it as instructions. Every agent that wraps git its own way closes the primitive behind its last incident and leaves the next one open, which is a maintenance treadmill rather than a fix. GitLab's suggestion that tool builders override every relevant key on every call is good advice, and it is also an admission that the ecosystem has not settled on a safe way to shell out to git from an agent at all.