Description

loadCliSessionHistoryMessages() resolves a session transcript path under the agent sessions directory, but then uses fs.statSync() and SessionManager.open() on that path without preventing symlink following.

If an attacker can create/modify files inside the OpenClaw state directory (e.g., OPENCLAW_STATE_DIR/.../agents/<id>/sessions/), they can replace the expected *.jsonl transcript with a symlink to an arbitrary target (e.g., /etc/passwd, $HOME/.ssh/id_rsa, /proc/kcore, device nodes).

Effects:

• Sensitive file disclosure: the target file is read and parsed; any parsed content may be returned and included in hook payloads.
• Denial of service / hangs: special files or FIFOs may block reads; or parsing non-JSONL content may consume CPU repeatedly.

Vulnerable code:

const stat = fs.statSync(sessionFile);
...
const entries = SessionManager.open(sessionFile).getEntries();

Recommendation

Harden transcript loading against symlinks/special files.

1. Use lstatSync() (or fs.promises.lstat) to detect and reject symlinks.
2. Resolve the realpath of the file and ensure it is still within the expected sessions directory realpath.
3. Consider opening the file with O_NOFOLLOW (where supported) and streaming/timeout protections.

Example (sync):

import path from "node:path";

const sessionsDir = path.dirname(sessionFile); // or return it from resolveSafeCliSessionFile
const base = fs.realpathSync(sessionsDir);

const lst = fs.lstatSync(sessionFile);
if (!lst.isFile() || lst.isSymbolicLink()) return [];

const realFile = fs.realpathSync(sessionFile);
const rel = path.relative(base, realFile);
if (!rel || rel.startsWith("..") || path.isAbsolute(rel)) return [];

const stat = fs.statSync(realFile);
if (stat.size > MAX_CLI_SESSION_HISTORY_FILE_BYTES) return [];

const entries = SessionManager.open(realFile).getEntries();

This prevents an attacker-controlled symlink inside the sessions directory from redirecting reads to arbitrary locations.

Description

runPreparedCliAgent now emits multiple plugin lifecycle hook events containing the full LLM prompt context and conversation content:

• llm_input includes systemPrompt, the user prompt, and historyMessages loaded from the local session transcript file
• llm_output includes the assistant response text (and optionally a structured lastAssistant message)
• agent_end always includes messages built from session history + current turn

Because hooks are implemented as plugins via the global hook runner, any enabled/loaded plugin that registers these hooks will receive this data. This can expose sensitive information (API keys, tokens, credentials, proprietary code, file paths, PII) present in prompts, system prompts, transcript history, or assistant output to third-party/untrusted plugins and to any external destinations those plugins may transmit to.

Vulnerable code (hook payload includes full prompt/history/system prompt and assistant output):

const llmInputEvent = {
  systemPrompt: context.systemPrompt,
  prompt: params.prompt,
  historyMessages,
};
...
runAgentHarnessLlmInputHook({ event: llmInputEvent, ctx: hookContext });
...
runAgentHarnessLlmOutputHook({ event: { assistantTexts, lastAssistant, usage: output.usage }, ctx: hookContext });
...
runAgentHarnessAgentEndHook({ event: { messages: buildAgentEndMessages(lastAssistant), ... }, ctx: hookContext });

Recommendation

Minimize and gate what is shared with hooks:

• Default deny / explicit opt-in: require a config flag per hook (or per plugin) to allow receiving prompt/history/systemPrompt/assistant text.
• Redaction: run the hook payload through a secret/PII redaction layer (e.g., mask tokens/keys, strip file contents, remove tool outputs) before invoking plugins.
• Scope limitation: provide only metadata by default (counts, hashes, model/provider, timing), and only include message contents when explicitly enabled.
• Document trust boundary: treat plugins as untrusted; warn users that enabling hooks can exfiltrate conversation contents.

Example approach (pseudo-code):

const safeEvent = cfg.plugins?.allowConversationHooks
  ? redactConversation(llmInputEvent)
  : { runId, sessionId, provider, model, imagesCount };

runAgentHarnessLlmInputHook({ event: safeEvent, ctx: hookContext });

1. src/agents/pi-embedded-runner/run/attempt.ts, line 2264-2267 (link)

   Current-turn messages are unbounded in agent_end

   buildAgentHookConversationMessages applies the 200-message window only to historyMessages (messages before the prompt). The currentTurnMessages (messagesSnapshot.slice(prePromptMessageCount)) is passed through without any size limit. For long agentic runs with many tool calls in a single turn, this slice could be very large, making the agent_end hook payload significantly bigger than the llm_input payload. This may be intentional, but it is worth confirming that downstream hook consumers can handle unbounded current-turn message lists.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/agents/pi-embedded-runner/run/attempt.ts
   Line: 2264-2267
   
   Comment:
   **Current-turn messages are unbounded in `agent_end`**
   
   `buildAgentHookConversationMessages` applies the 200-message window only to `historyMessages` (messages before the prompt). The `currentTurnMessages` (`messagesSnapshot.slice(prePromptMessageCount)`) is passed through without any size limit. For long agentic runs with many tool calls in a single turn, this slice could be very large, making the `agent_end` hook payload significantly bigger than the `llm_input` payload. This may be intentional, but it is worth confirming that downstream hook consumers can handle unbounded current-turn message lists.
   
   How can I resolve this? If you propose a fix, please make it concise.