hermes - 💡(How to fix) Fix [Bug/Security hardening]: API key Replace can persist composite pasted secrets into .env/auth.json without validation [1 pull requests]

Summary

While configuring DeepSeek through hermes model / setup, I observed a corrupted DEEPSEEK_API_KEY persisted in ~/.hermes/.env. The value was not a single API key: it contained multiple sk-...-looking token substrings (old + new key, redacted) and, after a later attempt, a local screenshot path ending in .png.

I am not claiming Hermes generated the concatenation by itself. The source could be clipboard/session contamination. The problem is that Hermes accepted and persisted the composite secret silently, and then the same bad credential state could also appear through the credential pool in ~/.hermes/auth.json.

Because the key prompt is hidden (getpass), the user sees an apparently blank field and has no visible indication that a composite value was pasted.

Observed behavior

Redacted shape of the bad value:

DEEPSEEK_API_KEY=sk-old-REDACTED...sk-new-REDACTED... /home/<user>/Images/Captures.../Capture...2026-05-18...png

Additional forensic checks on the corrupted value before cleanup:

• starts with sk-: yes
• contains more than one key-like substring: yes, observed locally during Replace investigation
• contains whitespace: yes
• contains /: yes
• contains .png: yes
• DeepSeek returned HTTP 401 invalid API key while this value was active
• after extracting only the valid key-shaped segment and resetting the base URL, a minimal DeepSeek API call returned HTTP 200

Why this looks like a Hermes hardening gap

The replacement code path appears to replace the entire env line:

lines[i] = f"{key}={value}\n"

So if an old and new key are present in the final value, the likely explanations are:

1. the hidden prompt received an already-concatenated string and saved it as-is, or
2. another writer modified .env after replacement.

Either way, Hermes currently has no provider-aware validation to reject obviously invalid API-key payloads before persisting them.

Current/main code I checked also only strips bracketed paste markers and non-ASCII characters; it does not reject whitespace, path separators, or path-like suffixes in API keys:

• hermes_cli/setup.py: prompt(..., password=True) uses getpass.getpass(...), then _sanitize_pasted_input(...), then .strip()
• hermes_cli/config.py: save_env_value(...) removes \n / \r and strips non-ASCII, but keeps spaces, /, .png, and additional token-looking substrings

Expected behavior

When replacing a provider API key, Hermes should not silently persist an obviously composite value.

For API-key providers, especially known providers like DeepSeek/OpenAI-compatible sk-... tokens, I would expect at least one of:

• reject hidden prompt input containing whitespace for providers whose keys cannot contain whitespace;
• reject path-like substrings such as /home/..., file://..., text/uri-list, or .png in an API-key field;
• warn if the entered value contains more than one key-like substring;
• show non-secret diagnostics before saving, e.g. length, prefix shape, whether whitespace/path separators were detected;
• do not update auth.json / credential pool from an env secret that fails validation;
• add a --force escape hatch for unusual providers rather than accepting malformed secrets by default.

Minimal regression test idea

A test alongside the existing prompt/env tests could assert that a replacement input like this is refused:

bad = "sk-" + "a" * 32 + " " + "/home/user/Pictures/Capture.png"

and another one for duplicate key-like payloads:

bad = "sk-" + "a" * 32 + "sk-" + "b" * 32

For known providers, the expected result should be no .env update and a user-facing warning that the pasted value looks malformed.

Environment

• OS: Fedora, GNOME Wayland terminal session
• Provider: DeepSeek
• Model attempted: deepseek-v4-pro
• Local install commit observed: 4c46c35ed0d3864f1cec55d87ab6d0f838ec7a2e
• Local install was behind origin/main by 75 commits, but I checked current main and the same validation gap appears to remain: bracketed paste and non-ASCII are sanitized, but composite/path-like API-key values are still accepted.

Security note

No real API key is included here. The affected key was rotated/cleaned locally. This issue is framed as robustness/security hardening because hidden password prompts plus clipboard contamination make this failure mode difficult for users to detect before the bad secret is persisted.