Description

loadCliSessionHistoryMessages() resolves a session transcript path under the state sessions directory and then validates it using fs.statSync().

• fs.statSync() follows symlinks, so a transcript path that is a symlink to another file will pass the isFile() and size checks.
• The file is then opened via SessionManager.open(sessionFile).getEntries(), which will read and parse the file.
• The resulting messages are forwarded into hook payloads (llm_input, before_prompt_build, agent_end), enabling exfiltration of the target file’s contents if an attacker can create/replace the transcript path within the sessions directory.

Vulnerable code:

const stat = fs.statSync(sessionFile);
if (!stat.isFile() || stat.size > MAX_CLI_SESSION_HISTORY_FILE_BYTES) {
  return [];
}
const entries = SessionManager.open(sessionFile).getEntries();

Recommendation

Harden transcript file access against symlink/hardlink attacks.

Minimum mitigation (symlink refusal):

• Use lstatSync() and reject isSymbolicLink().
• Optionally, also verify the resolved realpath stays within the expected sessions directory.

Example:

import path from "node:path";

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

const real = fs.realpathSync(sessionFile);
const sessionsDir = path.resolve(path.dirname(sessionFile)); // or the resolved sessions root
if (!real.startsWith(sessionsDir + path.sep)) return [];

Stronger mitigation (TOCTOU-resistant):

• Open the file with O_NOFOLLOW (where supported) and then fstat the opened fd before reading, to prevent swap-after-check.
• Ensure the sessions directory is created with restrictive permissions (e.g., 0700) so untrusted users/processes cannot plant links.

Description

loadCliSessionHistoryMessages() resolves the session transcript file path using an agentId derived from untrusted caller-controlled inputs (params.agentId and/or params.sessionKey). Because resolveSessionAgentIds() prefers the explicit agentId over the parsed sessionKey, a caller who can influence these parameters can cause the code to read history from a different agent’s session directory.

Impact:

• If RunCliAgentParams.agentId or sessionKey can be set by an external requester (e.g., HTTP/API parameter), an attacker can request history for another agent by specifying that agent’s id.
• The loaded messages are then:
  • included in lifecycle hook events (llmInputEvent.historyMessages, agentEndHook.messages), and
  • used during prompt-build hooks in prepare.ts.
    This can leak prior conversation content (transcripts) across agents/sessions.

Vulnerable code:

const { defaultAgentId, sessionAgentId } = resolveSessionAgentIds({
  sessionKey: params.sessionKey,
  config: params.config,
  agentId: params.agentId,
});
...
resolveSessionFilePath(..., resolveSessionFilePathOptions({
  agentId: sessionAgentId ?? defaultAgentId,
}))

Recommendation

Bind transcript resolution to an authenticated/authorized agent scope rather than caller-provided identifiers.

Options:

1. Do not accept agentId for history loading from external callers. Derive the agent id solely from trusted server-side session metadata.
2. If sessionKey is the intended scoping mechanism, require it to parse as a valid agent session key and ignore/forbid explicit agentId overrides for transcript reads.
3. Add an explicit authorization check that the resolved sessionAgentId is allowed for the current requester.

Example hardening (prefer sessionKey-derived scope and disallow override):

const parsed = params.sessionKey ? parseAgentSessionKey(params.sessionKey) : null;
if (!parsed) throw new Error("Missing/invalid sessionKey");
const sessionAgentId = normalizeAgentId(parsed.agentId);

return resolveSessionFilePath(
  params.sessionId,
  { sessionFile: params.sessionFile },
  resolveSessionFilePathOptions({ agentId: sessionAgentId }),
);

If you must support agentId, only accept it from trusted internal code paths and validate it against the authenticated principal/session ownership.