Description

jsonlFileHasAssistantMessage() attempts to prevent symlink-following by checking lstat() and rejecting symlinks, but then later opens the path by name. This creates a time-of-check/time-of-use (TOCTOU) window where an attacker who can write to the directory containing the transcript can swap the file after the lstat() check (e.g., replace it with a symlink or different file) before open() occurs.

Impact depends on the privilege boundary:

• If the process runs with higher privileges than the attacker (or reads in a shared directory), this can lead to unintended file reads (information disclosure).
• Even without privilege escalation, it can be used for denial-of-service by swapping in special files or very large files.

Vulnerable flow:

• Check: fs.lstat(filePath) and stat.isSymbolicLink()/stat.isFile()
• Use: fs.open(filePath, "r") then stream/parse lines

Vulnerable code:

const stat = await fs.lstat(filePath);
if (stat.isSymbolicLink() || !stat.isFile()) {
  return false;
}

const fh = await fs.open(filePath, "r");

Recommendation

Eliminate the path-based TOCTOU by opening the file safely and validating the opened file descriptor, or by using OS flags that prevent symlink following.

Recommended approach (POSIX): open with O_NOFOLLOW and validate via fh.stat():

import fs from "node:fs/promises";
import { constants as FS } from "node:fs";

const fh = await fs.open(filePath, FS.O_RDONLY | FS.O_NOFOLLOW);
try {
  const st = await fh.stat();
  if (!st.isFile()) return false;
  ​// proceed to stream from fh
} finally {
  await fh.close();
}

If O_NOFOLLOW is unavailable on some platforms, use an fd-based validation pattern:

• fh = open(filePath, "r")
• st = fh.stat() and ensure it’s a regular file
• optionally compare (dev, ino) from a fresh lstat() to fh.stat() to detect swaps.

This closes the race because the checks apply to the already-open file, not a name that can be swapped.

Description

The new claudeCliSessionTranscriptHasContent helper can be forced to consume significant CPU/IO (and potentially memory) by scanning an unbounded number of project directories and parsing JSONL transcripts with no line-length/file-size safeguards.

• Unbounded directory enumeration: fs.readdir(projectsDir, { withFileTypes: true }) reads all entries under ~/.claude/projects and then iterates every subdirectory, attempting to open and scan ${sessionId}.jsonl.
• Large-line JSON parsing: jsonlFileHasAssistantMessage uses readline and JSON.parse(line) per line. Although there is a 500-record cap, a single line can be arbitrarily large; readline will buffer the entire line and JSON.parse will attempt to parse it, causing heavy memory/CPU usage.

This can be triggered whenever runAgentAttempt() runs with provider claude-cli and a stored cliSessionBinding.sessionId exists, because it calls claudeCliSessionTranscriptHasContent({ sessionId }) before deciding whether to resume. If an attacker can write to the executing user's ~/.claude/projects (or influence HOME/homeDir in the process environment), they can create many directories and/or craft very large JSONL lines to degrade performance (denial of service).

Recommendation

Add explicit resource limits for both directory scanning and JSONL parsing.

Suggested mitigations:

1. Cap project directories scanned (and optionally short-circuit based on known workspace/project name if available):

const MAX_PROJECT_DIRS = 50;
const projectEntries = (await fs.readdir(projectsDir, { withFileTypes: true }))
  .filter((e) => e.isDirectory())
  .slice(0, MAX_PROJECT_DIRS);

2. Skip oversized files before opening, and enforce a maximum line length / abort on very long lines:

const MAX_TRANSCRIPT_BYTES = 2 * 1024 * 1024; // 2MB
const st = await fs.stat(filePath);
if (st.size > MAX_TRANSCRIPT_BYTES) return false;

const MAX_LINE_CHARS = 64 * 1024;
for await (const line of rl) {
  if (line.length > MAX_LINE_CHARS) return false; // or break
  ...
}

3. Consider adding a time budget / AbortSignal for the scan, so the caller can bound how long resume-checking can take.

Description

A new warning log line interpolates params.sessionKey ?? params.sessionId without any sanitization/escaping.

• sanitizeForLog() is correctly applied to providerOverride, but not to sessionKey/sessionId.
• If an attacker can influence sessionKey or sessionId (e.g., via CLI/API inputs, stored session metadata, or crafted values containing newlines/control characters/ANSI escapes), they can:
  • forge log lines (CWE-117)
  • inject terminal escape sequences into operator terminals
  • corrupt downstream structured log parsing/pipelines
• These identifiers may also be sensitive correlation identifiers; logging them verbatim increases the risk of identifier exposure.

Vulnerable code:

log.warn(
  `cli session reset: provider=${sanitizeForLog(params.providerOverride)} reason=transcript-missing sessionKey=${params.sessionKey ?? params.sessionId}`,
);

Recommendation

Apply sanitizeForLog() to all interpolated untrusted values and consider redacting session identifiers.

Minimal fix (sanitization):

const sessionKeyForLog = sanitizeForLog(String(params.sessionKey ?? params.sessionId ?? ""));
log.warn(
  `cli session reset: provider=${sanitizeForLog(params.providerOverride)} reason=transcript-missing sessionKey=${sessionKeyForLog}`,
);

If session IDs/keys are considered sensitive, prefer redaction/truncation:

const raw = String(params.sessionKey ?? params.sessionId ?? "");
const sessionKeyForLog = sanitizeForLog(raw).slice(0, 8) + "…";

Even better, use structured logging fields (if supported) rather than string interpolation.