Hermes Agent is a fast-growing open-source, self-hosted autonomous agent whose core feature — memory that persists and compounds across sessions — is also its largest disclosed attack surface. Two distinct CVEs and a published third-party threat model give security teams a concrete starting point before they self-host it.
What Hermes Agent is
Hermes Agent is an open-source, MIT-licensed, self-hosted autonomous agent released by Nous Research on 25 February 2026. It is built to persist memory across sessions and to write its own reusable skills after completing tasks, rather than starting each session from a blank context (hermes-agent.org; Repello AI, 2 May 2026). That combination — durable memory plus self-authored, reusable procedures — is the product's core pitch, and it is also the reason its threat model looks different from a stateless chat-based assistant.
The project's growth curve is unusually fast for a self-hosted agent. Star counts, each dated to its own source, moved from 110,000 (Repello AI, 2 May 2026) to 140,000 (NVIDIA, 13 May 2026) to 214,000 with roughly 40,000 forks (TechCrunch, 13 Jul 2026) — a genuine adoption curve rather than a single spike. NVIDIA published a dedicated integration and optimization post for running Hermes Agent on RTX PCs and DGX Spark hardware on 13 May 2026, which is vendor-level validation that teams are running it on local, high-privilege hardware right now (NVIDIA Blog). As of late August 2026, Nous Research is also reported to be in talks for a funding round at a $1.5B valuation (≥$75M, led by Robot Ventures with USV) — reported, not a confirmed closed round (TechCrunch, 13 Jul 2026).
The persistent-memory attack surface
Hermes's persistent memory is, by a published third-party threat model's own framing, "the same memory that makes the product work" and "the largest unbounded attack surface" of the product (Repello AI, 2 May 2026). The mechanism is straightforward and exactly why it matters: an attacker can plant hidden instructions inside a shared document, and if that document is ingested into the agent's memory store, the instructions get retrieved and acted on in a future session — without the user ever seeing the injection happen in real time. This is a memory-poisoning variant of indirect prompt injection, distinguished from the ordinary case by the delay between planting and retrieval, which is exactly what makes it hard to catch through session-level review.
Two further design facts compound that surface, per the same review:
- Community skill marketplace as supply-chain risk. Skills are user-installable, and a malicious skill can execute code at install time — the same class of risk the site has already documented in third-party skill ecosystems generally (see the SKILL.md security checklist).
- Multi-provider credential exposure. The agent holds long-lived API keys across providers (OpenAI, Anthropic, and others) to do its job, which creates a concrete leakage path through logs and debug traces if those credentials aren't scoped and rotated (Repello AI, 2 May 2026).
Common first-run misconfigurations named in the same review include choosing an execution backend that doesn't match the deployment's security posture, and messaging-gateway credentials that aren't scoped correctly — both operator-facing setup mistakes, not flaws in Hermes's code itself.
Two disclosed CVEs, not one
Security research attention on Hermes Agent is already active, and two separate CVEs exist. Conflating them understates the picture in one direction and overstates it in the other, so it's worth being precise:
| CVE | Severity | Component | What it allows |
|---|---|---|---|
| CVE-2026-18993 | CVSS 6.3 (medium) | Memory Toolset (hermes-agent/model_tools.py) |
Improper access control lets an attacker bypass disabled toolsets via late tool injection; remotely exploitable in versions 0.1 through 0.16.0 |
| CVE-2026-7396 | Lower impact (path traversal) | WeChat messaging adapter | Path traversal in a specific messaging integration |
CVE-2026-18993 was updated 6 Aug 2026 and references a fix in pull request #46185 (cve.imfht.com). As of late August 2026, the source record infers a fix from that referenced pull request rather than stating a confirmed patched version number outright — teams should verify the exact fixed version against Hermes Agent's own changelog before relying on a specific "upgrade to X.Y.Z" instruction, rather than trusting a secondhand version claim. CVE-2026-7396, the WeChat adapter path traversal, was disclosed separately and is referenced in the same third-party writeup (Repello AI, 2 May 2026) — it is a distinct vulnerability in a distinct component, not a second report of the memory-toolset issue.
The practical read for a security reviewer: CVE-2026-18993 is the more consequential of the two because it sits in the Memory Toolset itself — the same component the broader threat model already flags as the product's core structural risk — and because "bypass a disabled toolset" defeats exactly the kind of configuration-based mitigation a team would otherwise reach for first.
What this means for a security review
None of this makes Hermes Agent uniquely dangerous among self-hosted autonomous agents — persistent memory, skill extensibility, and multi-provider credentials are increasingly standard features across this whole category, and the general goal-hijacking and indirect-prompt-injection patterns already documented for agents apply here without modification. What is unusual is how directly a third party has already mapped the specific attack surface, which gives a reviewing team a head start most new agent frameworks don't come with.
A pragmatic evaluation checklist before self-hosting:
- Pin to a version at or above the CVE-2026-18993 fix and re-verify the actual patched release against Hermes's own changelog rather than a secondhand summary.
- Treat every document the agent's memory can ingest as untrusted input, the same discipline covered in detecting prompt injection — memory-poisoning is delayed-onset prompt injection, not a separate problem.
- Scope and rotate every provider API key the agent holds, and keep credentials out of logs and debug traces by default, following the same reasoning as least-privilege for agents.
- Vet community skills before installing them, using the same checklist appropriate to any skill-execution ecosystem — see the Agent Skills vetting checklist for the full process.
- Match the execution backend to your actual security posture rather than accepting a convenient default, and scope messaging-gateway credentials narrowly — both named as common first-run mistakes above.
- Log every memory write and skill installation independently of the agent's own self-report, so a poisoned memory entry or a malicious skill is visible in an audit trail rather than discovered after the fact — consistent with the audit-trail practices in the AI agent security guide.
Why persistent memory changes the calculus
A stateless agent that starts each session with an empty context has a natural ceiling on how much a single successful injection can accomplish — the poisoned instruction lives only as long as the session does. Hermes Agent's core design point is the opposite: memory that compounds, and skills the agent writes for itself and reuses later. That is exactly what makes it useful, and exactly what turns a single successful memory-poisoning attempt into a standing liability rather than a one-session incident. An attacker does not need to compromise the agent again once a hidden instruction is durably stored — it simply waits to be retrieved.
This is also why the self-authored-skills feature deserves its own line of scrutiny, separate from the community skill marketplace risk already noted above. A skill the agent writes for itself after completing a task becomes part of its own reusable procedure library; if the task that produced it was itself influenced by poisoned memory or a manipulated tool result, the resulting skill can encode that manipulation into something the agent treats as its own trusted, previously-validated routine. Reviewing self-authored skills the same way you'd review a community-contributed one is a control most teams don't think to apply, precisely because the skill's origin feels internal rather than external.
Common questions
Is Hermes Agent safe to self-host? It can be run safely, but it demands the same active security discipline any self-hosted, memory-persistent, skill-extensible agent needs: patch to the CVE-2026-18993 fix, scope credentials, vet skills, and treat ingested documents as untrusted input. It is not safe to run with defaults and no review.
What is CVE-2026-18993? A CVSS 6.3 improper-access-control vulnerability in Hermes Agent's Memory Toolset (versions 0.1–0.16.0) that lets an attacker bypass a disabled toolset via late tool injection, remotely exploitable, with a fix referenced in pull request #46185 as of 6 Aug 2026.
Are CVE-2026-18993 and CVE-2026-7396 the same vulnerability? No. CVE-2026-18993 is an access-control flaw in the Memory Toolset; CVE-2026-7396 is a separate, lower-impact path traversal flaw in the WeChat messaging adapter. Treating them as one issue understates the product's actual disclosed surface.
What is Hermes Agent's biggest structural risk? Its persistent memory layer, per a published third-party threat model — the same feature that makes the product useful (memory that compounds across sessions) is also its largest unbounded attack surface, because content ingested into memory can carry hidden instructions retrieved in later sessions without the user seeing the injection happen.