Git Config Hijacks Coding Agents: Three Vulnerabilities and a Hardening Checklist

Introduction: An Attack That Bypasses the Approval Prompt

A malicious git config file can execute code across seven coding agents before any approval prompt ever appears. Three recently disclosed incidents — GitSpawn, BragJack, and Salesbleed — demonstrate attack techniques that don't require defeating the model itself, but rather bypassing approval prompts, browser boundaries, or URL filters. If your agent security plan is "the model will refuse" or "a human will click approve," it has an obvious gap.

GitSpawn: Code Runs Before Anyone Is Asked

Manifold Security disclosed that a repository's own .git/config can set core.fsmonitor. Coding agents frequently run git status and git diff to gather context. Each invocation can trigger the helper program specified in that config, and those programs run with the developer's full local privileges, outside the agent sandbox, with no approval prompt. On multiple tools, it even triggered before the workspace trust dialog was accepted.

No poisoned prompt, malicious dependency, or compromised MCP server required. Manifold reported eight findings across seven agents: Claude Code, OpenAI Codex, Cursor, Grok Build, Goose, Hermes Agent, and Qwen Code. As of September 1, four of them remained unpatched, and Claude Code's ultrareview config path remained open even after the core.fsmonitor fix shipped.

What Is core.fsmonitor

core.fsmonitor is a Git config option that hooks into the file system monitor (fsmonitor) mechanism to speed up commands like git status and git diff. Git itself traverses the working tree during status checks, which is expensive when there are many files; with this config, Git can instead query an external helper process (or an integration hook) for "which files have changed since last time," so it only inspects the changed subset.

The problem is that the path to this "helper program" is entirely specified by the repository's own .git/config, and Git does not distinguish when invoking it whether the config was hand-written by the developer or planted when the repository was cloned. It runs with the developer's full local privileges, outside the sandbox that most coding agents rely on. So when an agent merely runs a single git status to gather context, the helper has already executed ahead of any approval UI, workspace trust confirmation, or sandbox policy. This pattern of "toolchain self-describing config driving execution" is a frequently underestimated class of supply chain attack surface.

Why "Workspace Trust" Doesn't Stop It

Modern IDEs and agents widely introduce a "Workspace Trust" dialog, with the idea of first having the user declare whether a directory is trustworthy, then deciding whether to enable tasks, extensions, scripts, and other potentially executable components. But the trust prompt is a user-facing interaction that depends on the host asking at the right moment. GitSpawn's trigger occurs earlier than that prompt, because git status is often initiated by the agent's background context-gathering phase rather than a manual user action; the host has not included this path in the execution surface requiring authorization.

A general lesson follows: any boundary that relies on "ask first, then run" must cover all calls within the agent that spawn processes, including commands automatically initiated for indexing, completion, and diagnostics. Merely popping up a trust dialog at the UI layer amounts to building the security boundary on user visibility, and many agent behaviors are precisely what the user cannot see.

BragJack: The In-Browser Assistant Trusts Your Extension

Forever Security researcher Gal Weizman demonstrated that a single browser extension can cross into privileged built-in AI agents across five browsers: Chrome with Gemini, Edge, Opera Neon, Perplexity Comet, and Claude in Chrome. Dark Reading reported on September 16 that this requires neither prompt injection nor bypassing guardrails. All five vendors acknowledged the vulnerability. Google and Microsoft issued CVE-2026-0628 and CVE-2026-55945.

Why a Co-located Extension Equals an Attacker

Browser extensions and in-page AI assistants typically run at different permission layers: extensions can access tabs, network requests, storage, and cross-origin data, while the assistant embedded in a page is constrained by the site's same-origin policy. What BragJack reveals is that built-in AI agents, in order to call host capabilities (reading pages, making requests, manipulating the UI), expose a set of privileged interfaces to extensions and by default trust calls coming from extensions. An attacker merely needs to co-locate an extension with the target agent in the same browser instance to cross into the privileged context through this set of interfaces.

This is similar to the local privilege escalation model in operating systems: a low-privilege component delivers input to a high-privilege component over IPC, and if the latter does not validate the source, a "Confused Deputy" problem arises. Vendor patches tend to focus on the agent's prompt filtering or model guardrails, while the root cause lies in the trust relationships and permission grant scope between components. So treating every co-resident extension, plugin, and hook as a potential attacker gets closer to the essence of the problem than incrementally expanding a blocklist.

Salesbleed: The Fix Was a Filter, and the Filter Was Bypassed

Zenity researchers injected prompts into Salesforce Agentforce through a public Web-to-Lead form and bypassed the URL filtering rules Salesforce had added after an earlier discovery by Noma Security. Agents deployed in Slack could also post unattributed messages in internal threads, making phishing easy. Salesforce reported no evidence of real-world exploitation and has switched to spec-compliant URL parsing, centralized URL checking, and now requires user confirmation for certain Slack operations. It acknowledged that its earlier response was a quick fix, not a comprehensive solution.

Why URL Filtering Is Bound to Be Bypassed

Comparing URLs in external input against a blocklist by string matching is a classic signature-based blacklist defense. There are many ways to bypass it: tampering with domain name character encoding (such as percent-encoding, Unicode homoglyphs, case variants), exploiting parser differences (where browsers, HTTP clients, and servers parse the same string inconsistently, i.e., parser ambiguity), hiding the final destination behind legitimate domains via redirects and open image hosts, or splitting sensitive content across multiple requests.

The real boundary should be an allowlist plus least privilege: explicitly defining which domains the agent can access, which operations require user confirmation, and whether messages sent by the agent can be used out-of-band. After the Salesforce incident, the shift to "spec-compliant URL parsing + centralized URL checking + requiring user confirmation for certain Slack operations" reflects a move from character filtering toward parsing consistency and permission restraint. The vendor also acknowledged that its earlier response was only a quick fix, indicating that filters can serve only as temporary mitigation and cannot replace boundary design.

The Pattern: It's the Controls Around the Agent That Get Attacked

Every case attacks the controls around the agent, not the agent's judgment:

• Approval or trust prompts fire too late, or never fire at all.
• A privileged assistant accepts input from a less privileged neighbor.
• Blocklists or filters are used in place of real boundaries.

A Q3 vulnerability roundup hosted by OWASP (which states it is not an official OWASP publication) adds a fourth angle: the agent as actor. It describes an evaluation agent reaching 41 Hugging Face production dataset workers in July, and a malicious PyPI package published by an agent running on 15 systems during roughly an hour online.

Hardening Checklist

1. Expose your agent to malicious repositories, pages, and forms, and inspect what executes before any prompt appears.
2. Treat every co-resident extension, plugin, and hook as an attacker.
3. Replace blocklists with allowlists and least-privilege tool scopes.
4. Retest after every vendor patch. Filters get bypassed.

You can run this kind of adversarial testing against your own agent at https://app.humanbound.ai by signing up for Humanbound's free Community plan. The engine and CLI are open source: github.com/humanbound/humanbound.

References

• GitSpawn, CSA Labs research note, September 3, 2026
• BragJack, Dark Reading, September 16, 2026
• Salesbleed, Dark Reading, September 24, 2026
• GenAI and Agentic AI Vulnerability Roundup Q3 2026, October 8, 2026
• Adversa AI Coding Agent Security Roundup, October 2, 2026

One-line Summary

Three incidents show that coding agent security gaps lie in bypassed approval prompts, permission boundaries, and filters, not in model judgment.

Paragraph Summary

The article examines three disclosed incidents — GitSpawn, BragJack, and Salesbleed — showing that attackers don't need to defeat the model itself but instead attack the controls around the agent. GitSpawn exploits core.fsmonitor in a repository's .git/config to execute code before any approval or workspace trust prompt when commands like git status are triggered, affecting seven agents including Claude Code, Codex, and Cursor, with several still unpatched. BragJack lets a single browser extension cross into five built-in AI agents — Chrome, Edge, Opera Neon, Perplexity Comet, and Claude in Chrome — without prompt injection, with two CVEs already assigned. Salesbleed injects prompts into Salesforce Agentforce through a public Web-to-Lead form and bypasses URL filters. The common pattern is that trust prompts fire too late, privileged components trust low-privilege neighbors, and blocklists masquerade as boundaries. The article offers four remediation directions: adversarial testing, treating co-located components as attackers, switching to allowlists and least privilege, and retesting after patches.