AI coding agents changed the developer workflow by giving a model the ability to read a repository, run commands and modify files. That capability is also a trust boundary, and a class of vulnerabilities published in 2026 shows what happens when the boundary is drawn in the wrong place.
Research published by Manifold Security and reported in September 2026 describes flaws in several AI coding agents, including Claude Code, Codex, Goose, Qwen Code and Grok Build, tracked under identifiers including CVE-2026-19592 and rated in the CVSS 7.0 to 7.3 range.
The mechanism is configuration injection. An agent that opens a repository may read repository-controlled configuration files, and in the affected implementations that configuration could influence how the agent invokes subprocesses. A crafted repository, including one supplied as a pull request or a cloned dependency, could therefore cause the agent to execute attacker-controlled commands on the developer's machine.
The detail that matters is the direction of trust. The developer trusts the agent. The agent trusts the repository. The repository is attacker-controlled. Nothing in that chain validates the assumption.
It is tempting to classify this as a workstation issue with limited blast radius. That framing misses the context in which these agents run.
Developers using coding agents frequently operate with credentials that reach source control, package registries, cloud environments and CI systems. An agent that executes a command on the developer's machine inherits the environment it runs in: environment variables, configuration files, credential helpers and SSH agent sockets. The compromise is not the repository; it is the developer's identity and everything that identity can reach.
There is also a supply chain dimension. If an agent processes a repository automatically, for example in a review pipeline or a scheduled task, the injection point moves from the developer's workstation into an automated system that may hold broader privileges and leave less visible evidence.
Three design decisions appear repeatedly in this class of flaw.
Implicit trust in repository content. Configuration files inside a repository are treated as project settings rather than as untrusted input. This is convenient and it is also the vulnerability.
Command execution through configuration. When a configuration value can specify a command, a shell fragment or an executable path, the configuration file becomes an execution primitive.
Insufficient separation between reading and acting. An agent that only reads repository content is bounded. An agent that reads content and then acts on it, with the developer's privileges and without a confirmation step, is not.
Treat repository configuration as untrusted input. Review changes to agent configuration files the same way you review changes to build scripts. A pull request that modifies agent settings deserves the same scrutiny as one that modifies a CI workflow.
Require confirmation for command execution. Where the tool supports it, enable an approval step before the agent runs a command, particularly for commands derived from repository content rather than from the developer's own instruction.
Run agents with reduced privilege. An agent does not usually need the developer's full credential set. Scoping the environment, removing unnecessary tokens from the shell, and avoiding long-lived cloud credentials in the developer context limits what an injected command can accomplish.
Isolate automated agent runs. If agents run unattended, they should run in a container or sandbox with a defined filesystem view and network policy, not on a host with access to production credentials.
Patch, and check what the agent already ran. Updating the tooling closes the known path. Because the flaw results in command execution, an affected machine should be reviewed for evidence that something ran: unexpected outbound connections, new persistence entries, and modifications to shell profiles or credential helpers.
AI coding agents are being deployed faster than their trust models are being documented. The vulnerability class described here is not a subtle memory corruption bug. It is a design assumption that repository content is safe to act on.
That assumption is worth testing explicitly in any tool that reads a repository and then executes something. The question to ask is simple: 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 an attack surface and should be treated as one.