GitLab finds ConfigPoisoning flaw that lets poisoned repo configs hijack AI coding agents

GitLab's Threat Research Group has disclosed a command execution vulnerability in DeepSeek-Reasonix Studio, a desktop git client for developers who work with AI coding assistants. The flaw, called ConfigPoisoning, could let attacker-supplied code run when a developer views a file's diff.
- GitLab's Threat Research Group disclosed ConfigPoisoning (CVE-2026-102437) in DeepSeek-Reasonix Studio.
- Viewing a file's diff could run attacker code via a filter.<driver>.clean entry set in .gitattributes and .git/config.
- Fixed in DeepSeek-Reasonix Studio 2.21.0 and DeepSeek Reasonix npm 1.39.3.
- GitLab says several other widely used coding agents share the same class of flaw and are under coordinated disclosure.
- Repositories hosted on GitLab are not affected, according to GitLab.
What GitLab found
The vulnerability is tracked as GHSA-grg2-7gc6-36m6 and CVE-2026-102437. According to GitLab, it affects both the DeepSeek-Reasonix desktop app and the npm package. Users should update to DeepSeek-Reasonix Studio 2.21.0 or DeepSeek Reasonix npm 1.39.3.
GitLab says this is not an isolated bug. Its researchers found that multiple widely used coding agents are susceptible to the same class of vulnerabilities, in which attacker-controlled commands run from a repository's own .git/config and .gitattributes files. DeepSeek-Reasonix is the first case GitLab is disclosing in full.
GitLab also notes that Git repositories hosted on GitLab are not affected, because cloning over HTTPS or SSH does not transfer local configuration files.
How the attack works
Coding agents run git against any directory a developer opens, and they inherit .git/config and .gitattributes from whoever wrote the repository. Several git configuration keys, including core.fsmonitor, core.hooksPath, diff.external and filter.<driver>.clean, run a named command during ordinary git operations.
According to GitLab, DeepSeek-Reasonix's git wrapper neutralizes core.fsmonitor and maintenance.auto on every call, and adds --no-ext-diff and --no-textconv to diffs. It does not touch filter.<driver>.clean. A code comment in the project named this as the one gap it had not closed. Because .gitattributes selects that key per file, a fixed deny-list cannot close it the way the others were closed.
GitLab describes the chain as follows:
- A file such as secret.bin is assigned in .gitattributes to a filter driver named pwn, and the repository's .git/config defines that driver's clean command as an attacker's script.
- A developer opens the file's diff in the desktop app.
- DeepSeek-Reasonix runs its hardened diff command, but git still invokes the clean filter to build the comparison blob.
- The attacker's command runs once for each side of the diff.
GitLab says git status leaves the filter untouched because it only checks which files changed, which isolates the bug to diff rendering.
Delivery routes and the agent angle
.gitattributes survives a clone, but .git/config does not. GitLab says delivery therefore needs an archive, a synced folder, a CI cache or a devcontainer build. The team confirmed the issue at commit ea28602 and the tagged pre-release studio-v2.9.0.
GitLab also points to 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 filesystem access. It can write the poisoned .git/config into a repository that was cloned normally.
The underlying problem, GitLab argues, is that tools treat repository configuration as part of the tool, when the repository's author controls it. Earlier this year the group found a similar pattern in Serena, another AI coding tool, which ran attacker code from the project's .serena/project.yml file when a developer opened the repository.
What users and tool builders should do
Users of DeepSeek-Reasonix should update to Studio 2.21.0 or npm 1.39.3. On older versions, GitLab advises avoiding diffs of any repository not obtained through a direct clone.
For developers of git-wrapping tools, GitLab recommends reading blobs with git cat-file or git show and diffing in-process where only byte-level content is needed. If a tool must shell out, it should override every relevant key on every call, including core.fsmonitor, core.pager, core.editor, core.hooksPath, diff.external, core.sshCommand, and filter.<driver>.clean or smudge for every driver name. GitLab stresses that one flag does not cover another: --no-ext-diff affects diff.external but does nothing for core.sshCommand. It also advises testing against a deliberately hostile config pair before shipping.
Security teams, GitLab says, should ask vendors how they neutralize repository-local configuration, not only how they handle an untrusted remote.
Disclosure timeline and what comes next
GitLab opened the advisory with the maintainer, esengine, on 2026-08-27. On 2026-09-29 esengine opened a temporary private fork and accepted the report. On 2026-09-30 the fix shipped, the advisory was published and the CVE was assigned.
GitLab says the same pattern is present in several other widely used agent tools that are currently under coordinated disclosure, and it will publish details on each once a fix is available.


