Picture this: you find a useful MCP server in Hermes’ official catalog, hit install, it asks for a few environment variables, you paste your API key, and everything works. Now imagine the catalog entry was malicious — or just sloppily written. Before the fix merged on August 26, any environment variable in the install request was persisted verbatim to your profile’s .env file — including HERMES_YOLO_MODE, a switch that changes your security posture outright. In other words, installing an MCP tool was theoretically the key to “auto-yolo on every future startup”. That hole is now closed (PR #91139).

What the Vulnerability Looked Like

The problem sat in POST /api/mcp/catalog/install. Before the fix, it accepted an arbitrary env mapping and persisted every non-empty value to the selected profile’s .env file before running the install. The endpoint was meant to receive the credentials you type into the wizard, but since it accepted anything, a request could attach HERMES_YOLO_MODE (or any other runtime control) to an otherwise legitimate credential submission, write it to .env, and have it take effect on the next process startup.

The subtler danger was generic persistence itself: once an endpoint can write arbitrary keys to .env, it becomes a generic write primitive — able to replace the MCP catalog’s trust root, acquire Copilot ACP executable authority, or inject any HERMES_* control. The catalog is supposed to help you fill in credentials, not own that kind of power.

The Fix: Catalog Credentials Are a Closed Schema

The patched behavior:

• Closed-schema validation: each catalog entry declares which environment variables it needs (its auth.env list). Any name in the submission that isn’t declared → HTTP 400, rejected before the first write or install action;
• Validate the whole map before the first write: a request mixing valid and invalid keys cannot partially persist credentials;
• Name-level denylist: the shared environment writer refuses to persist Hermes runtime and approval-control variables — HERMES_YOLO_MODE, HERMES_ACCEPT_HOOKS, HERMES_REDACT_SECRETS, HERMES_INTERACTIVE, HERMES_EXEC_ASK, HERMES_GATEWAY_SESSION, HERMES_CRON_SESSION, HERMES_SESSION_KEY, HERMES_CONFIG_PATH, HERMES_ENV_PATH and friends — so a malformed catalog entry cannot authorize itself;
• Errors don’t leak secrets: rejected names only; submitted values are never echoed back.

Note the denylist is name-specific, not a blanket block on HERMES_* — many integration credentials follow the HERMES_* convention themselves (e.g. HERMES_LANGFUSE_PUBLIC_KEY), and nuking the whole prefix would break every provider setup wizard. The gate blocks runtime controls and lets integration credentials through.

What Changes for Normal Users

Practically nothing. The desktop already renders and submits only the credential fields declared by the catalog entry, so legitimate installs keep their exact request shape; manually configured MCP servers are untouched. This is pure defensive hardening: you use it as usual, attackers lose an entry point.

Advice for You

• Keep using the catalog installs: the flow is now backed by a closed schema — credentials only ever land in declared keys;
• Manual MCP config — glance at your .env: if you hand-write MCP server configs and put variables in .env yourself, follow least privilege — don’t drop HERMES_YOLO_MODE-class switches there; use hermes config or the dedicated CLI controls when you need them;
• Contributing catalog entries: declare every environment variable your entry needs in auth.env — that’s what shapes the user’s form and keeps installs from being rejected with a 400.

Wrapping Up

At its core this fix narrows permissions: catalog installs went from “may write arbitrary environment variables” to “may only write declared credentials”, with a name-level denylist over security-control variables. Security fixes are the easiest updates to overlook, yet they protect the moment you’re most relaxed — third-party install wizards. To dig deeper into the MCP side of Hermes, see MCP config context variables and the official remote MCP catalog; and if you run webhook-driven monitoring, deploying this fix is an easy peace-of-mind upgrade.