[Bug]: Log record injection via unescaped newlines in agent/tool-controlled log values

[Adolanium]

Bug Description

Values interpolated into Hermes log messages are not stripped of control characters, so an agent, tool, or user supplied value that contains a newline forges a second physical log line. Because hermes logs re-parses each physical line into a record (timestamp, level, component, session), the forged line is surfaced as a genuine record with an attacker-chosen level and component. The repo already neutralizes these characters for file-path log sinks (gateway/platforms/base.py _log_safe_path / _LOG_UNSAFE_CHARS, with a test) but the message-text sinks are unprotected.

Steps to Reproduce

1. From the repo root, format a record whose interpolated value carries a newline:

PYTHONPATH=. python - <<'PY'
import logging, io
from agent.redact import RedactingFormatter
buf = io.StringIO()
h = logging.StreamHandler(buf)
h.setFormatter(RedactingFormatter("%(asctime)s %(levelname)s %(name)s: %(message)s"))
lg = logging.getLogger("tools.approval"); lg.addHandler(h); lg.setLevel(logging.INFO); lg.propagate = False
cmd = "rm -rf /\n2026-07-09 12:00:00 ERROR gateway.run: operator approved deploy"
lg.warning("Hardline block: %s", cmd[:200])
print(buf.getvalue())
PY

2. The output is two physical lines, the second of which parses as a genuine ERROR gateway.run record:

2026-07-09 10:00:00,001 WARNING tools.approval: Hardline block: rm -rf /
2026-07-09 12:00:00 ERROR gateway.run: operator approved deploy

3. hermes logs errors --component gateway then surfaces the forged second line as a real gateway error.

Expected Behavior

A single log call produces a single record. Control and line-break characters in the interpolated message are neutralized so a supplied value cannot start a new record, matching what _log_safe_path already does for path sinks.

Actual Behavior

RedactingFormatter.format (agent/redact.py) runs secret redaction but never neutralizes control characters, so an embedded newline reaches the log file verbatim and creates a second parseable record.

Affected Component

Agent Core (logging)

Root Cause Analysis

• agent/redact.py RedactingFormatter.format formats and redacts but does not strip control characters from the message.
• hermes_cli/logs.py parses per physical line: _TS_RE (^ anchored) and _LEVEL_RE (\s(LEVEL)\s), so any physical line beginning with a timestamp and level is treated as a record.
• Unprotected message-text sinks include tools/approval.py:2259 (model command), tools/terminal_tool.py:2324 (model command and workdir), cron/scheduler.py:2678 (job name and prompt), gateway/platforms/msgraph_webhook.py:190 (model output), agent/agent_runtime_helpers.py:152 (invalid tool-call arguments). The path-sink guard _log_safe_path (gateway/platforms/base.py) shows the neutralization was intended but was applied only to the 3 path sinks.

Proposed Fix

Neutralize control and line-break characters in the interpolated message centrally in RedactingFormatter.format (every file handler uses it), leaving the appended exception traceback intact so multi-line tracebacks still render. A PR is attached.

Environment

• OS: Windows 11
• Python: 3.11.7
• Hermes: 0.18.2 (reproduced on main at current head)

[GottZ]

This was generated by AI during triage.

Summary

One PR, #61411, directly addresses #61409. Its formatter-boundary change neutralizes control characters in interpolated messages and defangs timestamp-shaped exception continuation lines, covering both the reported message-path injection and the exc_info variant.

Related pull requests

• fix(logging): neutralize control characters in formatted log records #61411 best fix — (+137/-2) — fixes: Centralizes protection in RedactingFormatter, replacing unsafe message control characters while preserving legitimate multiline tracebacks and preventing attacker-controlled exception text from becoming a timestamp-parsed record. The visible keep_open review on fix(logging): neutralize control characters in formatted log records #61411 identified an exc_info gap; the current diff explicitly addresses it with continuation-line defanging plus regression tests for forged timestamp lines and bare carriage returns in exception messages.

Suggested consolidation

Merge #61411 — it is the verified best fix, closes #61409 at the shared formatter boundary, and the current diff addresses the keep_open review's blocking exc_info concern while retaining forensic text and normal traceback structure. There are no competing PRs to close as duplicates.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I61409(["issue #61409 (open)"])
    P61411["PR #61411 (open)"]
    P61411 -->|best fix| I61409
    class I61409 open
    class I61409 target
    class P61411 open
    class P61411 best
    click I61409 "https://github.com/NousResearch/hermes-agent/issues/61409"
    click P61411 "https://github.com/NousResearch/hermes-agent/pull/61411"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 7 kB of PR diffs, 8 kB of issue/PR text, 3 kB of discussion (3 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.