CVE-2026-82021 in Hermes Agent
Summary
by MITRE • 08/28/2026
Hermes Agent 0.18.2 prior to 0.19.0 contains a supply chain vulnerability in its bundled MCP catalog that allows a remote attacker to execute arbitrary code by compromising a third-party upstream repository referenced via a mutable branch rather than a pinned commit SHA. An attacker who compromises the upstream repository can propagate malicious code to every host that installs the affected catalog entry, with no further action required by the operator.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in Hermes Agent versions prior to 0.19.0 represents a critical supply chain compromise vector rooted in insecure dependency management practices within its bundled Model Context Protocol (MCP) catalog. The core technical flaw lies in the method used to reference third-party upstream repositories during the installation and update processes of specific catalog entries. Instead of utilizing immutable commit SHAs, which provide cryptographic certainty regarding the exact code state being deployed, the system relies on mutable branch references such as main or master branches. This architectural decision introduces a significant trust boundary failure because it assumes that the upstream repository maintainers will not be compromised and that their CI/CD pipelines remain secure throughout the lifecycle of the Hermes Agent installation. By binding to a moving target rather than a fixed point in history, the agent effectively delegates its security posture to external parties who may have weaker security controls or whose repositories are more attractive targets for attackers seeking widespread impact through dependency confusion or repository hijacking attacks.
From an operational perspective, this vulnerability allows for silent and automated code execution across all affected hosts without requiring any direct interaction from system operators. Once a Hermes Agent instance is configured to use the vulnerable catalog entry, it will periodically check for updates against the mutable branch reference. If an attacker successfully compromises the upstream repository by injecting malicious payloads into the main branch or exploiting weak access controls on that repository, every agent pointing to that branch will automatically pull and execute the compromised code during its next update cycle. This mechanism transforms a localized compromise of a single third-party library into a mass exploitation event affecting all downstream consumers. The lack of operator intervention means there is no opportunity for human review or validation of the changes before they are executed, significantly increasing the risk of successful malware deployment, data exfiltration, or lateral movement within the target network environment.
This type of vulnerability aligns closely with CWE-829, which describes Inclusion of Functionality from Untrusted Control Sphere, as well as CWE-611, Improper Restriction of XML External Entity Reference if applicable to parsing mechanisms involved in fetching dependencies. Furthermore, it maps directly to the MITRE ATT&CK technique T1195.002, Supply Chain Compromise: Compromise Software Supply Chain, where adversaries target third-party software components to distribute malware widely. The attack path typically involves an adversary gaining write access to a popular or trusted upstream repository and then pushing malicious code that appears legitimate but contains backdoors, cryptominers, or remote access trojans. Because the Hermes Agent automates the retrieval process based on mutable references, it acts as a delivery mechanism for this supply chain poison, effectively bypassing traditional perimeter defenses by leveraging trusted update channels.
To mitigate this risk and prevent future occurrences of similar vulnerabilities, immediate remediation requires upgrading to Hermes Agent version 0.19.0 or later, which presumably implements strict pinning of dependencies to specific commit SHAs rather than mutable branch names. In environments where an upgrade is not immediately feasible, operators should manually audit the configuration files associated with the MCP catalog entries and replace any branch references with explicit SHA hashes corresponding to known good versions of the upstream repositories. Additionally, implementing a software bill of materials (SBOM) process can help track which specific versions of third-party components are in use across the infrastructure. Security teams should also enforce strict code signing verification for all incoming updates from external sources and consider deploying network-level controls that restrict outbound connections to only whitelisted package registries or repositories with verified integrity checks, thereby reducing the attack surface available to supply chain attackers seeking to exploit mutable dependency references.