Description

rollbackChatGptImportRun reads an import-run record by interpolating the caller-supplied runId into a path joined under the .openclaw-wiki/import-runs directory.

• runId is taken directly from the CLI argument (wiki chatgpt rollback <run-id>) and passed into readImportRunRecord without validation.
• resolveImportRunPath uses path.join(importRunsDir, ${runId}.json). If runId contains ../ segments (or absolute paths), path.join will normalize the result and can escape the intended directory.
• The parsed JSON record is then trusted to drive filesystem operations:
  • record.createdPaths entries are joined with vaultRoot and removed via fs.rm.
  • record.updatedPaths[].snapshotPath is joined with runDir and read.
  • record.updatedPaths[].path is joined with vaultRoot and written.

This means a crafted runId can cause arbitrary file read (read any *.json file reachable by traversal) and, if the attacker can point to a JSON file they control, can escalate to arbitrary file delete/write by supplying traversal payloads in createdPaths, updatedPaths[].path, and updatedPaths[].snapshotPath.

Vulnerable code:

function resolveImportRunPath(vaultRoot: string, runId: string): string {
  return path.join(resolveImportRunsDir(vaultRoot), `${runId}.json`);
}
...
const record = await readImportRunRecord(params.config.vault.path, params.runId);
...
await fs.rm(path.join(params.config.vault.path, relativePath), { force: true })
...
const snapshotPath = path.join(runDir, entry.snapshotPath);
const targetPath = path.join(params.config.vault.path, entry.path);

Recommendation

1. Validate runId against a strict allowlist (it is generated as chatgpt- + 12 hex chars):

const RUN_ID_RE = /^chatgpt-[a-f0-9]{12}$/;
if (!RUN_ID_RE.test(runId)) {
  throw new Error("Invalid run id");
}

2. Enforce directory containment when resolving paths (defense-in-depth). For example:

function safeJoin(baseDir: string, rel: string): string {
  const target = path.resolve(baseDir, rel);
  const base = path.resolve(baseDir) + path.sep;
  if (!target.startsWith(base)) throw new Error("Path traversal");
  return target;
}

function resolveImportRunPath(vaultRoot: string, runId: string): string {
  const dir = resolveImportRunsDir(vaultRoot);
  return safeJoin(dir, `${runId}.json`);
}

3. When consuming the JSON record during rollback, validate and constrain createdPaths, updatedPaths[].path, and updatedPaths[].snapshotPath to ensure they cannot escape their intended directories (vault root / run dir).

Description

getMemoryWikiPage() allows a lookup of the form claim:<id> to resolve to a pagePath taken from the on-disk claims digest (.openclaw-wiki/cache/claims.jsonl). That pagePath is then passed into readQueryableWikiPagesByPaths(), which blindly path.join()s it with the vault root and reads it.

Because readQueryableWikiPagesByPaths() does not validate that the resulting path stays within the vault root, a malicious/poisoned digest entry with a pagePath such as ../../../../etc/passwd (or an absolute path) would cause the backend to read arbitrary files when a client requests wiki.get for that claim.

Vulnerable flow:

• Input: RPC wiki.get lookup (attacker-controlled)
• Pivot: claims.jsonl pagePath (untrusted file content)
• Sink: fs.readFile(path.join(rootDir, relativePath)) without containment checks

Vulnerable code:

​// getMemoryWikiPage
const digestClaimPagePath = digest ? resolveDigestClaimLookup(digest, params.lookup) : null;
...
await readQueryableWikiPagesByPaths(effectiveConfig.vault.path, [digestClaimPagePath])

​// readQueryableWikiPagesByPaths
const absolutePath = path.join(rootDir, relativePath);
const raw = await fs.readFile(absolutePath, "utf8");

Recommendation

Treat any path coming from digests (or any other non-hardcoded source) as untrusted, and enforce strict containment within the vault and expected subdirectories.

Suggested fix: resolve and validate before reading.

function resolveVaultPath(rootDir: string, rel: string): string {
  if (!rel || path.isAbsolute(rel)) throw new Error("invalid path");
  ​// normalize and prevent traversal
  const resolved = path.resolve(rootDir, rel);
  const normalizedRoot = rootDir.endsWith(path.sep) ? rootDir : rootDir + path.sep;
  if (!resolved.startsWith(normalizedRoot)) throw new Error("path escapes vault");
  return resolved;
}

​// in readQueryableWikiPagesByPaths
const absolutePath = resolveVaultPath(rootDir, relativePath);

Additionally, consider rejecting any digest pagePath that is not under one of the allowed QUERY_DIRS and not ending in .md.

Description

isoFromUnix converts create_time / update_time values from a ChatGPT export into ISO strings via new Date(numeric * 1000).toISOString().

• Number.isFinite(numeric) filters out NaN/Infinity, but does not prevent extremely large/small finite numbers.
• For out-of-range timestamps, new Date(...) produces an Invalid Date, and toISOString() throws RangeError: Invalid time value.
• This exception is not caught in toConversationRecord / importChatGptConversations; it occurs while mapping all conversations, so a single malformed conversation entry can abort the entire import run.

Vulnerable code:

const numeric = Number(raw);
if (!Number.isFinite(numeric)) {
  return undefined;
}
return new Date(numeric * 1000).toISOString();

This is reachable with an untrusted or corrupted conversations.json export (local file input), and results in a reliable import-time crash (denial of service).

Recommendation

Harden timestamp parsing by validating/clamping the supported range and/or catching RangeError from toISOString().

Example safe implementation:

function isoFromUnix(raw: unknown): string | undefined {
  if (typeof raw !== "number" && typeof raw !== "string") return undefined;
  const numeric = Number(raw);
  if (!Number.isFinite(numeric)) return undefined;

  ​// Optional: clamp to reasonable unix seconds range (e.g., 1970..2100)
  if (numeric < 0 || numeric > 4102444800) return undefined;

  const ms = numeric * 1000;
  const date = new Date(ms);
  try {
    return date.toISOString();
  } catch {
    return undefined;
  }
}

Also consider wrapping record parsing so one bad conversation cannot abort the whole import (skip and log).

Description

The wiki.get implementation allows callers to request arbitrarily large lineCount values and performs work proportional to the entire page size before slicing, enabling resource exhaustion.

• Input: lineCount and fromLine are taken from gateway params and only normalized with Math.max(1, …) (no upper bound).
• Work amplification: for wiki corpus pages, the code calls parseWikiMarkdown(page.raw) and then parsed.body.split(...), which processes the whole document regardless of lineCount.
• Output amplification: the server returns slice.join("\n") up to lineCount lines. The UI now hard-codes lineCount: 5000 when opening a page, increasing default payload size.

An authenticated caller (scope operator.read) can repeatedly request very large lineCount values or target extremely large imported pages (e.g., transcripts) to consume CPU/memory and bandwidth on the gateway.

Recommendation

Enforce strict server-side limits and avoid parsing/splitting the entire document when only a window of lines is needed.

1. Clamp lineCount (and fromLine) to a reasonable maximum:

const MAX_LINE_COUNT = 500; // or lower
const fromLine = Math.max(1, Math.floor(params.fromLine ?? 1));
const requested = Math.max(1, Math.floor(params.lineCount ?? 200));
const lineCount = Math.min(requested, MAX_LINE_COUNT);

2. Consider early truncation strategies:

• Store pre-split lines or an index in the compiled vault.
• If operating on raw markdown, avoid full parseWikiMarkdown for windowed reads; stream/scan until you reach fromLine + lineCount.

3. Add gateway validation (in gateway.ts) so abusive values are rejected before deeper processing, and optionally rate-limit wiki.get calls.

Description

The wiki.importRuns gateway method returns import-run metadata parsed from JSON files, including absolute local filesystem paths.

• extensions/memory-wiki/src/gateway.ts registers wiki.importRuns with { scope: READ_SCOPE } (operator.read). Any client with read access can call it.
• listMemoryWikiImportRuns() returns exportPath and sourcePath (likely absolute paths such as /Users/<name>/...) and pagePaths derived from created/updated file paths.
• These values reveal sensitive host information (usernames, directory structure, vault layout, mounted volumes) that is not required for most UI display.

Vulnerable code:

return {
  runId,
  importType,
  appliedAt,
  exportPath,
  sourcePath,
  ...
  pagePaths,
  samplePaths: pagePaths.slice(0, 5),
};

If the gateway is reachable by any remote operator client (e.g., paired device/browser UI), this is an information disclosure risk.

Recommendation

Minimize/redact sensitive path data returned over the gateway:

• Prefer returning relative paths (e.g., relative to the vault root) or just basenames.
• Alternatively, omit exportPath/sourcePath entirely from the gateway response and keep them only in local logs.
• If paths are needed for power users, guard them behind a stricter scope (e.g., operator.admin) or a dedicated capability flag.

Example (redact to basenames and make page paths vault-relative):

import path from "node:path";

function redactPath(p: string): string {
  return path.basename(p);
}

​// when building response
return {
  ...,
  exportPath: redactPath(exportPath),
  sourcePath: redactPath(sourcePath),
  pagePaths: pagePaths.map((p) => p.replace(/^.*?\/vault\//, "")),
};

(Use the actual vault-root prefix rather than the placeholder above.)

Description

parseWikiMarkdown parses YAML frontmatter from wiki markdown using YAML.parse() and returns the resulting object directly. Other code later spreads this untrusted object into new objects.

If an attacker can place/modify markdown files in the vault (e.g., via import/sync), they can include YAML keys such as __proto__, constructor, or prototype to manipulate the prototype of the parsed frontmatter object and/or of objects created via spread.

Why this is risky:

• YAML.parse() produces ordinary JS objects; assigning __proto__ can invoke the __proto__ setter on Object.prototype (engine-dependent), potentially changing the prototype of the target object (prototype pollution).
• The code later does ...parsed.frontmatter in multiple places (e.g., apply.ts, compile.ts). If parsed.frontmatter contains poisoned keys, the resulting objects may have attacker-controlled prototypes/properties, which can lead to logic bypasses, crashes, or unexpected behavior when properties are read.

Vulnerable code:

const parsed = YAML.parse(match[1]) as unknown;
return {
  frontmatter:
    parsed && typeof parsed === "object" && !Array.isArray(parsed)
      ? (parsed as Record<string, unknown>)
      : {},
  body: content.slice(match[0].length),
};

And later usage (example):

frontmatter: {
  ...parsed.frontmatter,
  pageType: "synthesis",
  ​// ...
}

Recommendation

Harden frontmatter parsing by sanitizing keys and constructing frontmatter with a null prototype, or by whitelisting expected fields.

Example mitigation (key sanitization + null-prototype):

const UNSAFE_KEYS = new Set(["__proto__", "prototype", "constructor"]);

export function parseWikiMarkdown(content: string): ParsedWikiMarkdown {
  const match = content.match(FRONTMATTER_PATTERN);
  if (!match) return { frontmatter: Object.create(null), body: content };

  const parsed = YAML.parse(match[1]) as unknown;
  const frontmatter = Object.create(null) as Record<string, unknown>;

  if (parsed && typeof parsed === "object" && !Array.isArray(parsed)) {
    for (const [key, value] of Object.entries(parsed as Record<string, unknown>)) {
      if (UNSAFE_KEYS.has(key)) continue;
      frontmatter[key] = value;
    }
  }

  return { frontmatter, body: content.slice(match[0].length) };
}

Additionally:

• Consider validating frontmatter against a schema (e.g., zod) and only keeping known fields.
• Avoid spreading untrusted objects (...parsed.frontmatter) into other objects unless sanitized first.