Description

scenario-flow-runner evaluates scenario expr strings from qa-flow YAML using AsyncFunction/Function, and now explicitly exposes qaImport(specifier) => import(specifier) in the evaluation context.

If QA scenario markdown/YAML can be modified by an untrusted party (e.g., a PR author, a downloaded scenario pack, or any user-supplied scenario content), this becomes straightforward arbitrary code execution:

• Input: expr / detailsExpr strings are read from qa/scenarios/*.md (YAML fences) and parsed into QaScenarioFlow.
• Execution sink: new AsyncFunction(...names, \return (${expr});`)` executes the attacker-controlled string.
• Amplification in this change: qaImport allows importing powerful Node.js modules (e.g. node:child_process, node:fs) or other specifiers from inside expressions, enabling command execution / file reads without relying on ambient globals.

Vulnerable code (new behavior enabling arbitrary imports):

function createEvalContext(api: QaFlowApi, vars: QaFlowVars) {
  return {
    ...api,
    qaImport: (specifier: string) => import(specifier),
    vars,
    ...vars,
  };
}

Because evalExpr and buildLambda compile and run these expressions with AsyncFunction/Function, a malicious scenario can do e.g.:

(await qaImport('node:child_process')).execSync('...')

This is effectively unsandboxed code execution within the process running QA flows.

Recommendation

Treat scenario expr/detailsExpr as untrusted code and avoid evaluating them with Function/AsyncFunction.

Options (pick based on needed functionality):

1. Remove qaImport from the expression context, and disallow imports entirely in expressions.

2. If imports are required, strictly allowlist safe specifiers and block node: and path-like specifiers:

const ALLOWED_IMPORTS = new Set(["node:path", "node:url"]);
function qaImport(specifier: string) {
  if (!ALLOWED_IMPORTS.has(specifier)) {
    throw new Error(`Import not allowed: ${specifier}`);
  }
  return import(specifier);
}

3. Replace AsyncFunction evaluation with a real sandbox / expression language:

• parse expressions (e.g., jsep) and interpret against a safe AST
• or use vm/vm2-style isolation (with careful hardening), ensuring no access to Node builtins (process, require, dynamic import, etc.)

At minimum, document and enforce that scenario flow files are trusted-only, and prevent execution of scenarios from untrusted sources in CI/CD contexts.

Description

resolveQaNodeExecPath() resolves the Node executable by running which node/where node and then uses the returned path to spawn child processes.

• When the parent runtime is Bun (or process.execPath is not already Node), the code falls back to the first node found in PATH.
• The lookup uses the current environment by default (env is omitted by call sites), so a manipulated PATH can cause an attacker-controlled node binary/script to be selected.
• The resolved path is then executed via spawn() in gateway-child.ts and model-catalog.runtime.ts, inheriting a large environment that may contain secrets.

Vulnerable code:

const locator = platform === "win32" ? "where" : "which";
({ stdout } = await execFileImpl(locator, ["node"], {
  encoding: "utf8",
  env: params?.env,
}));
...
return resolved;

If an attacker can influence PATH in the environment where QA is run (e.g., CI jobs, developer shells, wrapper scripts), this becomes an execution of an attacker-controlled binary (RCE).

Recommendation

Avoid resolving the executable via untrusted PATH.

Options (choose one appropriate to the product’s distribution model):

1. Prefer a trusted absolute Node path

• If running under Node already, always use process.execPath.
• If running under Bun, require an explicit configuration/env var that points to a Node binary (absolute path), and validate it.

2. Harden PATH lookup

• Call the locator with a sanitized PATH (e.g., system directories only) and reject results outside trusted prefixes.
• Resolve symlinks and validate the target.

Example (explicit config + validation):

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

export async function resolveQaNodeExecPath(): Promise<string> {
  if (process.versions.bun !== undefined) {
    const configured = process.env.OPENCLAW_QA_NODE_PATH;
    if (!configured || !path.isAbsolute(configured)) {
      throw new Error("Set OPENCLAW_QA_NODE_PATH to an absolute Node executable path");
    }
    await access(configured, constants.X_OK);
    return configured;
  }
  return process.execPath;
}

This prevents executing arbitrary node from an attacker-controlled PATH.

Description

createQaBundledPluginsDir constructs a staging directory under ${repoRoot}/.artifacts/qa-runtime/${basename(tempRoot)} and then unconditionally deletes it with fs.rm(..., { recursive: true, force: true }).

Because the path is under a repo-controlled directory (.artifacts), a malicious checkout (or untrusted workspace) can replace .artifacts (or .artifacts/qa-runtime) with a symlink to an arbitrary location. When the QA suite runs, the code will then recursively delete outside the repository.

Key points:

• Attacker control: If an attacker can influence the repo working tree contents, they can create .artifacts as a symlink to another directory (e.g. ~, /var/tmp, etc.).
• Dangerous sink: fs.rm(stagedRoot, { recursive: true, force: true }) performs a recursive deletion on that attacker-influenced path.
• path.basename(tempRoot) is safe when tempRoot comes from mkdtemp, but it does not mitigate the symlink issue in the parent directories under repoRoot.

Vulnerable code:

const stagedRoot = path.join(
  params.repoRoot,
  ".artifacts",
  "qa-runtime",
  path.basename(params.tempRoot),
);
await fs.rm(stagedRoot, { recursive: true, force: true });

Recommendation

Harden staging directory creation/deletion against symlink attacks:

1. Resolve and validate parent directories (.artifacts and .artifacts/qa-runtime) using lstat/realpath and ensure they are real directories (not symlinks).
2. Ensure the final stagedRoot resolves under an expected base directory before deleting.
3. Consider using a dedicated temp dir outside the repo (OS temp) for staging, avoiding repo-controlled paths entirely.

Example mitigation (one approach):

const artifactsDir = path.join(params.repoRoot, ".artifacts");
const qaRuntimeDir = path.join(artifactsDir, "qa-runtime");

for (const p of [artifactsDir, qaRuntimeDir]) {
  if (existsSync(p)) {
    const st = await fs.lstat(p);
    if (st.isSymbolicLink()) throw new Error(`Refusing to use symlinked path: ${p}`);
    if (!st.isDirectory()) throw new Error(`Expected directory: ${p}`);
  }
}

await fs.mkdir(qaRuntimeDir, { recursive: true });
const stagedRoot = path.join(qaRuntimeDir, path.basename(params.tempRoot));

const realBase = await fs.realpath(qaRuntimeDir);
const realTargetParent = await fs.realpath(path.dirname(stagedRoot));
if (realTargetParent !== realBase) throw new Error("Unexpected stagedRoot parent");

await fs.rm(stagedRoot, { recursive: true, force: true });

This prevents .artifacts-symlink tricks from redirecting recursive deletion outside the repo.

Description

loadPrivateQaCliModule() dynamically imports a JS module from a packageRoot discovered via resolveOpenClawPackageRootSync({ moduleUrl, argv1, cwd }), and buildCandidates() includes cwd as a fallback.

When OPENCLAW_ENABLE_PRIVATE_QA_CLI=1, an attacker who can influence the process working directory (or argv[1] resolution) can cause packageRoot to resolve to an attacker-controlled directory that merely contains:

• a package.json with {"name":"openclaw"} (satisfies root resolution)
• marker paths .git and src
• the target module dist/plugin-sdk/qa-lab.js

The code then imports that file URL and executes it. This turns the private QA flag into an untrusted search path mechanism that can execute arbitrary code from the filesystem.

Vulnerable code:

const packageRoot = resolvePackageRootSync({ argv1, cwd, moduleUrl });
...
const sourceModulePath = path.join(packageRoot, "dist/plugin-sdk/qa-lab.js");
...
return (await import(pathToFileURL(sourceModulePath).href)) as Record<string, unknown>;

Notes:

• The .git/src checks are not an authenticity check; an attacker can create them.
• This is gated by OPENCLAW_ENABLE_PRIVATE_QA_CLI=1, but if that flag is enabled in a compromised environment (CI job, dev shell, or wrapper script), it provides a straightforward escalation to code execution.

Recommendation

Avoid resolving the import target from attacker-influenceable locations (notably cwd). Prefer a trusted anchor:

• Only resolve from import.meta.url of the currently executing, installed openclaw package, and do not fall back to cwd.
• Additionally, validate the resolved root more strongly (e.g., require a specific monorepo layout plus package.json name and repository-specific markers).
• Consider requiring an explicit absolute path env var (e.g. OPENCLAW_PRIVATE_QA_ROOT=/abs/path) and refuse to run otherwise.

Example hardening (remove cwd fallback):

const packageRoot = resolveOpenClawPackageRootSync({
  moduleUrl: import.meta.url,
  argv1: process.argv[1],
  ​// no cwd fallback
});
if (!packageRoot) throw new Error("...");

If you must allow cwd, require explicit opt-in to cwd-based resolution and display the resolved path before import, requiring confirmation in interactive use.