🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🟠 Uncontrolled module resolution root via createRequire(candidate.source) when plugin path contains symlinks

Description

loadOpenClawPlugins() sets a global require for each plugin using createRequire(candidate.source). However, candidate.source originates from plugin discovery/config as a resolved but not necessarily canonical path (it may include symlink segments).

Because Node computes module.paths from the path passed to createRequire(), using a non-canonical/symlinked candidate.source can cause CommonJS resolution to search node_modules in ancestor directories of the symlink path (e.g., /tmp/alias/node_modules, /tmp/node_modules, etc.) instead of the plugin’s canonical root.

Security impact:

• A local attacker who can influence the plugin entry path to include a symlinked prefix (or can control directories in that symlink’s ancestor chain) may be able to place a malicious package in an earlier searched node_modules directory.
• When the plugin (or its dependencies) calls require("some-package"), Node may load the attacker-controlled module, resulting in arbitrary code execution in the OpenClaw process.
• This can undermine the project’s existing “plugin root” boundary/ownership checks, because those checks validate the plugin entry file, not the node_modules search path induced by the symlinked candidate.source.

Vulnerable code:

​// Anchor require() resolution to the plugin's directory so its CJS
​// dependencies resolve packages from the plugin's own node_modules.
globalThis.require = createRequire(candidate.source);

Recommendation

Anchor createRequire() to the canonical, boundary-validated path you already computed (safeSource / opened.path) instead of the raw discovered path.

Suggested fix:

​// Use the canonical path returned by openBoundaryFileSync()
globalThis.require = createRequire(safeSource);

Optionally, also consider:

• Using pathToFileURL(safeSource) if you want to be explicit about URL handling.
• Avoiding a process-global require if possible (pass a scoped require into the plugin/jiti context) to reduce cross-plugin interference.

2. 🔵 Global require shim can remain corrupted if plugin loading throws before restoration

Description

loadOpenClawPlugins() mutates globalThis.require to a per-plugin createRequire() so jiti-loaded code can call require(). However, restoration back to the original savedRequire happens only at the end of the function and is not protected by try/finally.

This means any uncaught exception between setting savedRequire and the final restore (including attacker-controlled exceptions from plugin exports) can leave the process-wide globalThis.require permanently pointing at a plugin directory.

Impact:

• Denial of service / reliability break: subsequent code (or later plugin loads) may resolve modules from the wrong location or crash unexpectedly.
• Cross-plugin contamination: a plugin can intentionally trigger an exception after globalThis.require is switched, causing other code to run under altered module-resolution semantics.

Vulnerable pattern:

const savedRequire = globalThis.require;
...
globalThis.require = createRequire(candidate.source);
...
​// not in finally
globalThis.require = savedRequire;

Because resolvePluginModuleExport(mod), config/schema validation, or other logic after import can throw outside the existing try/catch blocks, a malicious plugin can intentionally prevent restoration and leave global state corrupted.

Recommendation

Use try/finally to guarantee restoration even if any plugin-related step throws. Ideally, restore per plugin as well to minimize the window of global mutation.

Example (outer guard + per-plugin guard):

const savedRequire = globalThis.require;
try {
  for (const candidate of discovery.candidates) {
    const pluginRequire = createRequire(candidate.source);
    const prior = globalThis.require;
    globalThis.require = pluginRequire;
    try {
      const mod = getJiti()(safeSource) as OpenClawPluginModule;
      ​// ... resolve exports, validate config, register, etc.
    } finally {
      globalThis.require = prior;
    }
  }
} finally {
  globalThis.require = savedRequire;
}

Also consider avoiding process-global state entirely by passing a scoped require into plugin evaluation if the loader/runtime supports it.

Analyzed PR: #13109 at commit e894379

_{Last updated on: 2026-03-05T04:22:20Z}