Skip to content

OpenClaw has an Arbitrary Malicious Code Execution Vulnerability

High severity GitHub Reviewed Published Mar 27, 2026 in openclaw/openclaw • Updated Apr 10, 2026

Package

npm openclaw (npm)

Affected versions

<= 2025.3.23

Patched versions

2026.3.24

Description

Fixed in OpenClaw 2026.3.24, the current shipping release.

Summary

During the installation phase of OpenClaw local plugins/hooks, the Git executable can be hijacked by a project-level .npmrc file, leading to arbitrary code execution during installation.

Details

Please note that the source code locations mentioned below are based on version openclaw-2026.3.13-1, but the issue has been confirmed to still exist in the current latest version, 2026.3.23.

When installing a local plugin directory, local plugin archive, local hook pack directory, or local hook pack archive, OpenClaw first copies the source directory to a temporary stageDir, then executes the following in that directory:

npm install --omit=dev --silent --ignore-scripts

See src/infra/install-package-dir.ts:176-199.

Since this process does not strip the project root .npmrc, and npm reads the project-level .npmrc during local project installation, an attacker could use a .npmrc file in a malicious plugin or hook directory to override npm’s git executable path. By leveraging a Git dependency, the attacker could trigger npm to call this malicious program, thereby executing arbitrary local code during the installation phase.

Affected Paths

  • Plugin CLI entry point: src/cli/plugins-cli.ts:199-255
  • Hook CLI entry point: src/cli/hooks-cli.ts:573-676
  • Plugin local directory / archive installation: src/plugins/install.ts:379-405, src/plugins/install.ts:541-565
  • Hook local directory / archive installation: src/hooks/install.ts:380-403, src/hooks/install.ts:443-470
  • Actual execution of npm install --ignore-scripts: src/infra/install-package-dir.ts:176-199

Vulnerability Trigger Flow

  1. The user executes one of the following commands:

    • openclaw plugins install <path-or-spec>
    • openclaw hooks install <path-or-spec>

  2. If the argument is a local directory or local archive, OpenClaw navigates to the local installation path.

  3. OpenClaw copies the source directory to a temporary stageDir. See src/infra/install-package-dir.ts:176-177.

  4. If dependencies are present in package.json, OpenClaw executes the following in stageDir:

npm install --omit=dev --silent --ignore-scripts

See src/infra/install-package-dir.ts:188-199.

  1. npm reads the project-level .npmrc file in this directory. Official documentation: .npmrc
  2. If .npmrc is set to git=<path to malicious program> and there is a git dependency in the dependency tree, npm will invoke that git program when resolving the dependency. Official documentation: npm config git Git dependency documentation: package.json
  3. Consequently, an attacker can execute arbitrary local programs during the plugin/hook installation phase without waiting for the plugin or hook to be loaded later.

Triggering Commands

  • Plugin installation command:
openclaw plugins install <path-or-spec>
  • Hook installation command:
openclaw hooks install <path-or-spec>

When <path-or-spec> is a local directory or local archive, it will be resolved to the path used by the npm install --omit=dev --silent --ignore-scripts command mentioned above.

PoC

Currently, testpoc/ is a minimal PoC directory used to verify that “when installing local packages, OpenClaw enters the npm install --ignore-scripts path.” It is divided into two core sections:

testpoc/pkg/
Purpose: Simulates the local package directory installed by openclaw plugins install ... or openclaw hooks install ...
testpoc/repo/
Purpose: Simulates a Git dependency repository within the npm dependency tree
Directory Structure

testpoc/
├─ pkg/
│ ├─ .npmrc
│ ├─ package.json
│ └─ sample-hook/
│ ├─ HOOK.md
│ └─ handler.js
└─ repo/
├─ package.json
└─ .git/...
Function of Each Component

testpoc/pkg/.npmrc

Current content:
git=calc.exe
Function: Overrides npm’s Git executable configuration.
Meaning: When npm encounters a git dependency during installation, it will not call the system git but will attempt to call the program specified here.
This is the core trigger point of this PoC. See testpoc/pkg/.npmrc:1
testpoc/pkg/package.json

Currently, this is a “mixed-use” manifest that includes both plugin and hook fields:
{
“name”: “probe-host”,
“version”: “1.0.0”,
“private”: true,
“openclaw”: {
“extensions”: [“./dist/index.js”],
“hooks”: [“./sample-hook”]
},
“dependencies”: {
“probe-git-dep”: “git+file:///D:/AI Agent Source/OpenClaw/openclaw-2026.3.13-1/.testpoc/repo”
}
}
Its functionality is divided into three layers:
openclaw.extensions: Allows it to be validated as a plugin package
openclaw.hooks: Enables it to be validated as a hook package
The Git URL in dependencies: Forces npm to enter the Git dependency resolution path during installation
See testpoc/pkg/package.json:1
testpoc/pkg/sample-hook/HOOK.md

Purpose: To meet the minimum metadata requirements for a hook package.
This is the key file that allows openclaw hooks install pkg to pass the pre-check. See testpoc/pkg/sample-hook/HOOK.md:1
testpoc/pkg/sample-hook/handler.js

Current content:
export default async function handler() {
return { ok: true };
}
Purpose: Meets the requirement that the hook directory must contain a handler entry file.
It is not a usage point in itself; its sole purpose is to allow OpenClaw to proceed to the dependency installation phase. See testpoc/pkg/sample-hook/handler.js:1
testpoc/repo/package.json

Current content:
{“name”:“probe-git-dep”,‘version’:“1.0.0”}
Purpose: Serves as the minimum repository content corresponding to a Git dependency.
The focus is not on the repository code itself, but on the fact that “it is a Git repository,” allowing npm to perform Git-related operations on it. See testpoc/repo/package.json:1
testpoc/repo/.git/

Purpose: Makes testpoc/repo/ a real Git repository rather than a regular directory.
When npm resolves git+file://... When installing dependencies, this is treated as the Git source.
How the current PoC works

If installing via hooks:

openclaw hooks install testpoc/pkg
The trigger chain is:

OpenClaw identifies testpoc/pkg as the local hook package path
Through pre-validation in openclaw.hooks, HOOK.md, and handler.js
Proceeds to src/infra/install-package-dir.ts:188-199
Executes:
npm install --omit=dev --silent --ignore-scripts
npm reads testpoc/pkg/.npmrc
npm processes the git dependency in package.json
npm attempts to call the git=calc.exe specified in .npmrc

Impact

It is best described as an installation-time local command execution / unsafe package-install configuration issue.

More precisely:

OpenClaw installs local plugin and hook packs by running npm install --omit=dev --silent --ignore-scripts inside the staged package directory, see src/infra/install-package-dir.ts:188-199.
If that local package directory contains an attacker-controlled .npmrc, npm will still read it.
If .npmrc overrides npm’s git executable and the package has a git dependency, npm can invoke the attacker-chosen program during install.

Who is impacted

Users who run:

openclaw plugins install <local path/archive>
openclaw hooks install <local path/archive>

And who install a malicious or untrusted local package that includes:

a controlled .npmrc
a git dependency
a runnable attacker-controlled git target on that platform

This should be treated as a security issue, not just “malicious plugin behavior,” because the code execution happens during OpenClaw’s install workflow, before the plugin or hook is ever loaded as trusted runtime code.

The important distinction is:

A normal “trusted plugin” case is: the operator installs a plugin, enables it, and later that plugin runs with plugin privileges.
This issue is different: OpenClaw’s installer executes npm install --omit=dev --silent --ignore-scripts inside an attacker-controlled package directory, and npm still honors attacker-controlled project config from .npmrc.

That means an untrusted local plugin or hook package can influence the package manager itself and reach arbitrary program execution at install time, via npm’s git setting and a git dependency, even though --ignore-scripts is present.

Why this matters from a security perspective:

It is install-time execution, not post-install trusted execution.

The execution is triggered by OpenClaw’s installer in src/infra/install-package-dir.ts:188-199.

This occurs before the package is accepted as a trusted loaded plugin/hook in the usual sense.

It defeats an expected safety boundary.

The code explicitly uses --ignore-scripts, which strongly suggests an intent to make installation safer.

But the installer still allows attacker-controlled package-manager configuration from .npmrc to affect execution.

So the current mitigation is incomplete in a security-relevant way.

The dangerous input is part of a supported user flow.

OpenClaw explicitly supports installing plugins and hook packs from local directories and archives:

src/cli/plugins-cli.ts:199-255
src/cli/hooks-cli.ts:573-676

That makes “download a package/archive, then install it” a realistic operator action, not an artificial lab setup.

The issue is broader than plugin trust.

The problem is not “plugins can do bad things once trusted.”

The problem is “the installer consumes attacker-controlled package-manager config before trust is established.”

That is much closer to an unsafe install / supply-chain execution flaw than to ordinary trusted-plugin behavior.

Hooks are affected too.

The same installer path is used for hook packs, not only plugins.

So this is a shared install-surface issue, not an isolated plugin-runtime concern.

References

@steipete steipete published to openclaw/openclaw Mar 27, 2026
Published to the GitHub Advisory Database Mar 30, 2026
Reviewed Mar 30, 2026
Published by the National Vulnerability Database Apr 10, 2026
Last updated Apr 10, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Local
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction Active
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(1st percentile)

Weaknesses

Acceptance of Extraneous Untrusted Data With Trusted Data

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted. Learn more on MITRE.

Untrusted Search Path

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control. Learn more on MITRE.

CVE ID

CVE-2026-35641

GHSA ID

GHSA-m3mh-3mpg-37hw

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.
⚡