Configuration injection flaws let malicious repos run commands through AI coding agents

A new class of agent vulnerability

Security research from Manifold Security, reported in September 2026 and described in a dev.to analysis, documents a vulnerability class in AI coding agents in which repository-controlled configuration files can end up controlling what commands the agent executes. The affected tools named include Claude Code, Codex, Goose, Qwen Code and Grok Build, with the issues tracked under identifiers that include CVE-2026-19592 and rated in the CVSS 7.0 to 7.3 range.

The core problem, as the write-up frames it, is a trust chain drawn in the wrong place: the developer trusts the agent, the agent trusts whatever configuration it finds in the repository, and the repository may be controlled by an attacker. Nothing along that path verifies the assumption that repository content is safe to act on.

How the injection works

Modern coding agents are given the ability to read a repository, run commands and modify files. In the affected implementations, an agent that opens a repository also reads its configuration files, and values in those files can influence how the agent invokes subprocesses. Because a configuration value can specify a command, a shell fragment or an executable path, the configuration file effectively becomes an execution primitive.

The delivery paths are familiar ones: a crafted repository, a repository supplied through a pull request, or a cloned dependency. In each case the developer never has to open the malicious file themselves. The agent reads it first and, in the flawed designs, may act on it using the developer's privileges and without a confirmation step.

More than a workstation problem

The dev.to analysis pushes back on the idea that this is a single-laptop issue with a limited blast radius. Developers using coding agents typically hold credentials that reach source control, package registries, cloud environments and CI systems, and a command executed by the agent inherits that environment: environment variables, configuration files, credential helpers and SSH agent sockets. The asset being compromised is not the repository but the developer's identity and everything that identity can reach.

There is also an automation dimension. Where agents process repositories unattended, for example in a review pipeline or a scheduled task, the injection point shifts from the developer's workstation into an automated system that may hold broader privileges and leave less visible evidence behind.

The design decisions in common

According to the write-up, three patterns repeat across the affected tools:

• Configuration files inside a repository are treated as project settings rather than as untrusted input. This is convenient, and it is also the vulnerability.
• Configuration values are permitted to specify commands or executable paths, which turns configuration into code.
• There is insufficient separation between reading repository content and acting on it. An agent that only reads content is bounded; an agent that reads content and then executes it with the developer's privileges is not.

Practical controls

The recommended defences follow from that analysis:

• Treat repository configuration as untrusted input, and review changes to agent settings with the same scrutiny applied to changes in CI workflows or build scripts.
• Enable an approval step before the agent runs a command wherever the tool supports it, particularly for commands derived from repository content rather than from the developer's own instruction.
• Run agents with reduced privilege: scope the environment, remove unnecessary tokens from the shell and avoid long-lived cloud credentials in the developer context.
• Isolate unattended agent runs in a container or sandbox with a defined filesystem view and network policy, not on a host with access to production credentials.
• Patch the tooling, then investigate. Because the flaw results in command execution, an affected machine should be checked for unexpected outbound connections, new persistence entries and modifications to shell profiles or credential helpers.

Why it matters

This is not memory corruption or a subtle parser bug. It is a design assumption, namely that repository content is safe to act on, embedded in tools that are being deployed faster than their trust models are being documented. Any tool that reads a repository and then executes something should be tested against one question: if an attacker controls this file, what can they make the agent do? If the answer involves running a command with the developer's credentials, the configuration file is attack surface and should be treated as one.