T09 · Insecure Skill Coding Practices
Warning
- Location
time_awareness/time_context.py:78- Finding
Unbounded Per-Session Timestamp Cache Can Cause Memory Exhaustion
- Content
View full analysis
unix timestamp def record_user_message(session_id: str, ts: Optional[float] = None) -> None: """Record when a user message was received. Called by the hook.""" import time with _last_user_ts_lock: _last_user_ts[session_id] = ts or time.time() ``` ### Technical Analysis The `pre_llm_call` hook records every non-empty `session_id` in the process-wide `_last_user_ts` dictionary. The cache has no maximum size, expiration policy, session-close cleanup, or validation of session identifiers. Existing session identifiers overwrite their prior entries, but every unique identifier creates a permanent entry for the lifetime of the Hermes process. If an untrusted or remotely accessible client can cause Hermes to create or process requests with many unique session identifiers, it can force the dictionary to grow continuously. The locking mechanism prevents concurrent corruption but does not mitigate resource exhaustion. ### Attack Path 1. An attacker obtains access to an interface that creates Hermes sessions or supplies session identifiers. 2. The attacker repeatedly sends requests using distinct session IDs. 3. The `pre_llm_call` hook invokes `record_user_message()` for each identifier. 4. Every unique identifier remains in `_last_user_ts`. 5. The long-running Hermes process consumes progressively more memory. 6. Sufficient requests can degrade performance or terminate the process through memory exhaustion. Exploitation depends on whether the surrounding Hermes deployment allows an attacker to create a large number of ...[truncated 591 chars]- Remediation
View remediation