Description

Hermes Agent 0.18.2 through 0.21.0, fixed in commit f6234d0, contains a remote code execution vulnerability that allows attackers to execute arbitrary OS commands by supplying a malicious repository with a crafted .git/config that sets core.fsmonitor to an attacker-controlled command. When a user opens the malicious repository and sends any message, the agent triggers a git status index refresh which executes the injected command in the user's process context, exposing the full environment including configured provider API keys.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-03T16:18:21.710Z",
  "pubdate": "2026-09-03T16:18:21.710Z",
  "executiveSummary": "Hermes Agent versions 0.18.2 through 0.21.0 are susceptible to a critical Remote Code Execution (RCE) vulnerability stemming from improper validation of Git configuration files.\nThe vulnerability allows an unauthenticated attacker to execute arbitrary OS commands within the victim's process context by embedding a malicious payload into a repository's .git/config file.\nBy manipulating the core.fsmonitor configuration parameter, an attacker can trigger the execution of arbitrary binary files or scripts upon the agent's interaction with the repository.\nSuccessful exploitation grants the attacker the same permissions as the user running the Hermes Agent, leading to full environment exposure, including the exfiltration of sensitive provider API keys and other environment variables.\nThis vulnerability poses a significant risk to developers using the affected Hermes Agent versions, as merely opening a malicious repository and initiating a message exchange is sufficient to trigger the malicious payload.\nRemediation is achieved by upgrading the affected software to the version incorporating the fix in commit f6234d0.",
  "technicalDetails": "The root cause of this vulnerability lies in the Hermes Agent's interaction with the underlying Git environment. Specifically, the agent automatically triggers a git status index refresh when a user interacts with a repository. The application fails to sanitize or validate the git configuration parameters, allowing local or remote git configuration files to override default behavior.\nThe attack vector involves a crafted .git/config file where the attacker sets the core.fsmonitor configuration variable to point to an arbitrary, attacker-controlled command or script path. In Git, core.fsmonitor is intended to point to a hook or executable that provides file system change information to improve performance in large repositories.\nThe execution flow proceeds as follows: 1. An attacker delivers a malicious repository to the target, either via cloning or direct file transfer. 2. The user opens this repository within the Hermes Agent environment. 3. The user sends a message, triggering an automated git status check. 4. The agent executes the git status command, which subsequently invokes the binary or script defined in the malicious core.fsmonitor setting.\nBecause the agent executes this command in the user's process context, the malicious payload inherits the security token and environmental scope of the Hermes Agent application. This enables the attacker to perform post-exploitation activities such as listing directory contents, initiating network connections, or exfiltrating sensitive environment variables, most notably configured provider API keys used for authenticating to external services.\nThis vulnerability is particularly dangerous because it does not require administrative privileges; the execution occurs at the user level, effectively bypassing standard non-privileged execution constraints by leveraging the legitimate functional requirements of the git status command.\nAffected versions include 0.18.2 through 0.21.0. The vulnerability is explicitly fixed in commit f6234d0, which presumably implements stricter sanitization of git configuration parameters or restricts the execution of hooks to known-safe paths, thereby mitigating the risk of command injection via configuration-based hooks."
}