Skip to content

Security Assessment: Hermes Agent GitHub Repository (posture review) #40889

Description

@shmrad

Security Assessment: Hermes Agent GitHub Repository

Target: github.com/NousResearch/hermes-agent
Analyst: ARES / Dragon Council Reconnaissance Division
Date: 2026-06-06


Executive Summary

This is a security posture assessment of the Hermes Agent repository (v0.16.0, @NousResearch). The project demonstrates strong overall security maturity for a pre-1.0 release, with several noteworthy defenses. However, a few areas warrant attention.

Repository Stats: 184,750 stars | 31,711 forks | 18,684 open issues | 245,728 LOC | 2,097 Python files


Findings

HIGH

1. Three acknowledged CVEs in pinned dependencies

  • requests==2.33.0 - CVE-2026-25645 (commented in pyproject.toml)
  • PyJWT[crypto]==2.12.1 - CVE-2026-32597 (commented in pyproject.toml)
  • starlette==1.0.1 - CVE-2026-48710 / BadHost (commented as intentionally pinned for this CVE)

These are publicly acknowledged by maintainers in source comments, which is good transparency, but they remain unpinned/unpatched.

2. 18,684 open issues
Massive backlog makes it difficult to surface security-relevant reports. Consider a security label with triage automation.

MEDIUM

3. API Server permits unauthenticated access when key is unset
gateway/platforms/api_server.py:855 - _check_auth() allows requests through when _api_key is empty. Binding to 0.0.0.0 (via API_SERVER_HOST env var) without API_SERVER_KEY exposes the full agent API without authentication.

4. No rate limiting on /v1/chat/completions or /v1/responses
No rate limiting visible in gateway/platforms/api_server.py. Leaked API keys could be used for unbounded token drain.

5. CORS wildcard origin permitted
gateway/platforms/api_server.py:769 - returns Access-Control-Allow-Origin: * when API_SERVER_CORS_ORIGINS=* is configured.

LOW

6. No SLSA/build attestation for PyPI or Docker publishes
upload_to_pypi.yml and docker-publish.yml publish without provenance attestation.

7. No Windows DPAPI encryption for credential storage
Anthropic adapter has macOS Keychain (agent/anthropic_adapter.py:800) but Windows stores secrets in plaintext config.yaml and .env files.

8. No GitHub secret scanning push protection
Given 855+ contributors and 5,121 lead commits, push protection would be a valuable safety net.


Strong Defenses Worth Highlighting

These were notable enough to include in the assessment (many are best-in-class for a v0.16.0 project):

Defense Location
Supply chain audit CI: .pth files, base64+exec, obfuscated subprocess detection .github/workflows/supply-chain-audit.yml
OSV dependency scanner: weekly CVE scan of uv.lock .github/workflows/osv-scanner.yml
Exact pinned deps (==X.Y.Z, no ranges) - adopted after litellm/mistralai worm pyproject.toml
Dep upper-bound enforcement in CI supply-chain-audit.yml (dep-bounds job)
SECURITY.md with formal trust model and 3-tier attack surface SECURITY.md
hmac.compare_digest for API key verification (constant-time) gateway/platforms/api_server.py:869
Dashboard auth: scrypt hashing + stateless HMAC session tokens plugins/dashboard_auth/basic/
Zero committed secrets in git history Verified via history scan
Network egress isolation docs for Docker docs/security/network-egress-isolation.md
uv.lock integrity check in CI (blocks stale lockfiles) uv-lockfile-check.yml
No telemetry/analytics embedded Verified via code search

Recommendations Priority

  1. CRITICAL: Implement security issue triage (label + automation) for 18,684 open issues
  2. HIGH: Remediate or formally document accept-risk rationale for all 3 CVEs in SECURITY.md
  3. HIGH: Add rate limiting to /v1/chat/completions and /v1/responses
  4. MEDIUM: Add startup guard that refuses to bind API Server to non-localhost without API_SERVER_KEY
  5. MEDIUM: Add Windows DPAPI encryption wrapper (CryptProtectData) for credential storage
  6. LOW: Add SLSA provenance attestation to PyPI and Docker publish workflows
  7. LOW: Enable secret scanning push protection for the repo

This assessment was conducted as part of the Dragon Council red-team program. Full PDF report available on request.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — cosmetic, nice to havetype/securitySecurity vulnerability or hardening

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions