Description

The packaged install path now eagerly installs bundled plugin runtime dependencies during postinstall by default unless OPENCLAW_EAGER_BUNDLED_PLUGIN_DEPS is explicitly set to 0/false/off.

Impact:

• Runs npm install automatically during installation, causing unwanted network access in environments that expect offline/reproducible installs.
• The dependency versions come from bundled plugin package.json and are only validated as a semver range (e.g., ^1.60.0), meaning the resolved version can change over time.
• The install environment explicitly disables lockfile generation (npm_config_package_lock: "false"), removing a primary integrity/reproducibility control.
• Although --ignore-scripts is used (good: blocks lifecycle scripts), this still expands the supply-chain attack surface (dependency confusion/registry compromise/typosquatting) by fetching packages at install time.

Vulnerable behavior (key excerpts):

function shouldEagerInstallBundledPluginDeps(env = process.env) {
  const normalized = env?.[EAGER_BUNDLED_PLUGIN_DEPS_ENV]?.trim().toLowerCase();
  return !normalized || !DISABLED_EAGER_BUNDLED_PLUGIN_DEPS_VALUES.has(normalized);
}

export function createBundledRuntimeDependencyInstallEnv(env = process.env) {
  return {
    ...createNestedNpmInstallEnv(env),
    npm_config_legacy_peer_deps: "true",
    npm_config_package_lock: "false",
    npm_config_save: "false",
  };
}

export function createBundledRuntimeDependencyInstallArgs(missingSpecs) {
  return ["install", "--ignore-scripts", ...missingSpecs];
}

And the eager install is executed in runBundledPluginPostinstall() for packaged installs when deps are missing.

Recommendation

Treat eager installation of dependencies as an opt-in operation and make installs reproducible.

Recommended changes:

1. Default to not running network installs in postinstall; require explicit enablement (e.g., OPENCLAW_EAGER_BUNDLED_PLUGIN_DEPS=1).
2. Prefer pinned versions (no ranges) for bundled plugin runtime deps, or ship a lockfile and use npm ci.
3. Avoid disabling lockfiles. If you must install at postinstall time, enforce deterministic resolution:
   • ship a lockfile for the packaged distribution and run npm ci instead of npm install.
4. Harden npm configuration for non-interactive install behavior and reduced attack surface (example):

export function createBundledRuntimeDependencyInstallEnv(env = process.env) {
  return {
    ...createNestedNpmInstallEnv(env),
    npm_config_ignore_scripts: "true", // defense-in-depth
    npm_config_audit: "false",
    npm_config_fund: "false",
    npm_config_update_notifier: "false",
    ​// consider pinning/controlling registry if appropriate:
    ​// npm_config_registry: "https://registry.npmjs.org/",
  };
}

export function createBundledRuntimeDependencyInstallArgs(missingSpecs) {
  return ["ci", "--ignore-scripts", ...missingSpecs];
}

Also ensure the bundled plugin dist/extensions/**/package.json content is immutable/trusted in the packaged artifact; if end-users can modify it before installation, they can force installation of attacker-chosen packages.

Description

runBundledPluginPostinstall() reads dependency entries from each bundled plugin's package.json and only validates the version/spec with semver/ranges/valid. The dependency name (object key) is not validated.

As a result, a malicious bundled plugin manifest can provide a dependency name such as ../tmp/evil (or other path-like strings). This name is then used in two security-sensitive ways:

• Path traversal in sentinel checks: dependencySentinelPath(depName) splits on / and joins under node_modules/, allowing .. segments to escape node_modules.
• Bypass of spec validation to install from arbitrary locations: missing specs are built as ${dep.name}@${dep.version}. With a path-like name, the resulting npm install argument can be interpreted by npm as a local path (or other non-registry specifier), despite the version being a valid semver range.

Vulnerable code:

function dependencySentinelPath(depName) {
  return join("node_modules", ...depName.split("/"), "package.json");
}
...
.map((dep) => `${dep.name}@${dep.version}`);

Recommendation

Validate bundled runtime dependency names before using them in paths or building npm install arguments.

Recommended approach:

1. Reject any dependency name that is not a valid npm package name (including scoped names). Use validate-npm-package-name.
2. Additionally, when building any filesystem path from a package name, ensure the resolved path stays within the intended root (<packageRoot>/node_modules).

Example:

import validateName from "validate-npm-package-name";
import { join, resolve, relative, isAbsolute } from "node:path";

function assertSafePackageName(name) {
  const result = validateName(name);
  if (!result.validForOldPackages && !result.validForNewPackages) {
    throw new Error(`unsafe bundled runtime dependency name: ${name}`);
  }
}

function safeDependencySentinelPath(packageRoot, depName) {
  assertSafePackageName(depName);
  const sentinel = join(packageRoot, "node_modules", ...depName.split("/"), "package.json");
  const rel = relative(join(packageRoot, "node_modules"), resolve(sentinel));
  if (rel.startsWith("..") || isAbsolute(rel)) {
    throw new Error(`dependency sentinel path escape for ${depName}`);
  }
  return sentinel;
}

Also consider building install specs using npm's npm-package-arg parser and rejecting any spec whose type is not a registry semver/range.

Description

dependencySentinelPath(depName) builds a filesystem path from a dependency name taken directly from bundled plugin package.json dependency keys. While the code validates the dependency version/range with semver.validRange(), it does not validate the dependency name.

An attacker who can influence a bundled plugin manifest could supply a dependency name containing path traversal segments (e.g. ../...) which will be normalized by path.join() and escape node_modules/, causing the postinstall script to probe/read files outside the intended directory.

Impact:

• runtimeDepNeedsInstall() calls existsSync() and readJson() on join(packageRoot, dep.sentinelPath).
• With a crafted name like "../somewhere", dep.sentinelPath becomes "packageRoot/somewhere/package.json" instead of staying under packageRoot/node_modules/....
• This is a classic path traversal primitive (even if current sinks are limited to existence checks / JSON reads).

Vulnerable code:

function dependencySentinelPath(depName) {
  return join("node_modules", ...depName.split("/"), "package.json");
}

Data flow:

• input: dependency name keys from collectRuntimeDeps(packageJson) in discoverBundledPluginRuntimeDeps()
• transformation: dependencySentinelPath(name)
• sink: existsSync(join(packageRoot, dep.sentinelPath)) and readJson(join(packageRoot, dep.sentinelPath)) in runtimeDepNeedsInstall()

Recommendation

Validate dependency names before using them in filesystem paths (and ideally before forming install specs).

Suggested approach:

• Enforce npm package name rules using validate-npm-package-name (or equivalent) and reject names with path traversal tokens.
• Additionally, ensure no path segments are "." or ".." and disallow backslashes.

Example fix:

import validatePackageName from "validate-npm-package-name";

function assertSafeBundledRuntimeDependencyName(name) {
  if (typeof name !== "string") throw new Error("invalid dependency name");
  if (name.includes("\\")) throw new Error(`unsafe dependency name: ${name}`);
  for (const segment of name.split("/")) {
    if (segment === "." || segment === ".." || segment.length === 0) {
      throw new Error(`unsafe dependency name: ${name}`);
    }
  }
  const result = validatePackageName(name);
  if (!result.validForNewPackages) {
    throw new Error(`unsafe dependency name: ${name}`);
  }
}

​// in discoverBundledPluginRuntimeDeps loop:
assertSafeBundledRuntimeDependencyName(name);
assertSafeBundledRuntimeDependencySpec(name, version);

This keeps dependencySentinelPath() constrained to node_modules/<pkg>/package.json and prevents traversal.

Description

discoverBundledPluginRuntimeDeps() enforces assertSafeBundledRuntimeDependencySpec() before building npm install args, but isSafeBundledRuntimeDependencySpec() only blocks a small set of leading prefixes and :///absolute paths.

As a result, npm-supported non-registry specifiers can still pass validation and cause npm install to fetch code from git or other non-registry sources, e.g.:

• Git host shorthands: github:user/repo, gitlab:user/repo, bitbucket:user/repo, or even user/repo
• Alias specs: npm:otherpkg@​github:user/repo (or npm:otherpkg@​file:../...)
• Other protocols npm supports (e.g., patch:) that do not contain ://

Because the postinstall script runs during packaged installs and eagerly installs these dependencies, a compromised bundled plugin manifest could trigger fetching and installing attacker-controlled code outside the registry constraints the check appears to intend.

Vulnerable code:

function isSafeBundledRuntimeDependencySpec(spec) {
  const lower = normalized.toLowerCase();
  if (lower.startsWith("file:") || /* ... */ lower.startsWith("https:")) {
    return false;
  }
  if (normalized.includes("://") || normalized.startsWith("/") || normalized.startsWith("\\")) {
    return false;
  }
  return true;
}

Recommendation

Use npm’s own spec parser and implement an allowlist of registry-only spec forms.

For example, with npm-package-arg (used by npm itself), reject anything whose resolved type is not a registry version/range/tag:

import npa from "npm-package-arg";

function assertRegistryOnly(depName, spec) {
  const parsed = npa(`${depName}@${spec}`);
  ​// Accept only registry dependencies.
  if (parsed.type !== "tag" && parsed.type !== "version" && parsed.type !== "range") {
    throw new Error(`unsafe bundled runtime dependency spec for ${depName}: ${spec}`);
  }
  ​// Additionally disallow aliases if you want to prevent indirection.
  if (parsed.subSpec) {
    throw new Error(`unsafe bundled runtime dependency spec for ${depName}: ${spec}`);
  }
}

This blocks git shorthands (github:user/repo, user/repo), npm: aliases, patch:, and other non-registry sources without relying on brittle string-prefix checks.