Originally published at HOL
A Hermes Agent workspace can run code from a repository before the user sends a prompt. Hermes 0.18.2 through 0.21.0 automatically asks the system Git client for workspace context, and Git honors executable settings from an attacker-supplied .git/config.
The practical boundary is how the repository arrived. A normal git clone does not copy the source repository .git/config. A shared ZIP that includes .git, a synchronized project folder, or removable media can carry it.
The HOL Guard evidence record for CVE-2026-71963 preserves the source record and patch references. This write-up focuses on operator decisions exposed by the patch.
Why the prompt approval boundary does not help
Hermes collects repository context before the first prompt, tool invocation, approval, or trust decision. The merged fix names the coding-workspace snapshot, gateway project-tree probe, working-diff path, goal fingerprint, context references, web Git path, and worktree setup as automatic Git callers.
A malicious local Git configuration can turn an ordinary status refresh into process execution with core.fsmonitor. Other sinks include core.hooksPath, credential helpers, pagers, editors, and repository-named diff or text conversion drivers. Code runs as the Hermes user, where provider API keys may be available.
The patch shows why one generic Git hardening switch is insufficient. Commit f6234d00c5d59450adea1d7edd30ad3859375c79 adds an isolated noninteractive Git environment. It separately injects both --no-ext-diff and --no-textconv for commands that render diffs. Tests show that either flag by itself leaves the other driver path active.
Who is not in scope
Workspaces created with a normal git clone are not exposed through an attacker-controlled .git/config, because clone does not transfer that file. Plain source archives with no .git directory are also outside this delivery path. The issue requires a repository directory whose Git metadata was supplied or modified by an untrusted party.
This is not an unauthenticated network RCE in a listening Hermes service, and it is not a claim that opening any cloned public repository executes code. It is local workspace trust crossing caused by preserved, attacker-controlled Git metadata.
Check workspaces without triggering a status refresh
hermes --version
Version 0.21.0 is the newest tagged release visible at publication time and predates the fix. For projects received as directories, ZIPs, sync shares, or removable-media copies, inspect local configuration before opening them in Hermes:
git -C /path/to/project config --local --show-origin --get-regexp "^(core\.fsmonitor|core\.hooksPath|credential\..*|diff\..*\.(command|textconv))$"
Any result deserves review. An empty result does not prove safety because the patch closes more than the reported core.fsmonitor sink. Also inspect whether an untrusted archive supplied the entire .git directory and whether .gitattributes names custom diff drivers.
How to fix
git -C /path/to/hermes-agent fetch origin f6234d00c5d59450adea1d7edd30ad3859375c79
git -C /path/to/hermes-agent merge --ff-only f6234d00c5d59450adea1d7edd30ad3859375c79
Update Hermes Agent to a build containing commit f6234d0 or a later vendor release. Do not treat the 0.21.0 tag as fixed. At publication time, the security commit was merged on September 2 but no newer tagged release was listed.
If an immediate rebuild is not possible, do not open repository directories that arrived with preserved Git metadata. Re-clone from a trusted remote into a fresh directory. Rotate provider credentials if a transferred workspace was already opened by a vulnerable Hermes process.
Patch verification
A fixed source tree contains noninteractive_git_env() overrides for core.fsmonitor, hooks, credential helpers, pager and editor behavior, plus harden_git_argv() adding both driver-disabling flags to diff-rendering subcommands. The merged pull request reports real-Git tests across ten automatic sinks and shows all ten blocked after the change.
There is no public evidence in the primary sources that this CVE is being exploited in the wild. Unexpected process activity during Hermes workspace initialization is an incident signal, but the CVE assignment alone is not proof of compromise.
Top comments (0)