OpenClaw Plugin Scans Could Hide Later Executable Calls

OpenClaw’s plugin package security scanner could stop exposing useful evidence after the first process-execution match in a file. A plugin containing several executable call sites could therefore produce review output that showed one call while omitting later ones.

PR #116222, merged to main on 30 July, changes the line-rule scanner to report distinct matches in source order, with a bounded maximum of 32 findings per rule and file.

Operator decision

If you approved, rejected or risk-rated a plugin using earlier scan output, rescan it with a confirmed containing build when multiple executable calls could change that decision. Prior output was not proof that the first reported call was the only one.

Prioritise rescanning:

• generated bundles or large source files;
• plugins that spawn subprocesses, invoke shells or launch package-manager commands;
• packages whose first finding looked benign because it referenced a known helper;
• plugins installed with broad filesystem, credential or network access; and
• any package admitted through automated review that treated finding count as a risk signal.

Do not execute a plugin merely to discover what the static scanner omitted. Inspect the package contents in an isolated review environment.

What changed

The scanner uses line rules to identify sensitive executable-call patterns. The defect was in evidence collection rather than a claim that no scan happened at all: once one matching call was found in a source or generated file, later matches could be absent from the report presented to the reviewer.

The merged change emits distinct matching sites in source order and caps evidence at 32 findings for each rule/file combination. That cap is an intentional resource bound, not a guarantee that a file contains at most 32 sensitive calls.

Interpretation: scanner output is evidence for human or policy review, not an execution safety boundary by itself. Completeness matters because the security meaning often lives in the later call—different arguments, a shell-enabled option, user-controlled input or a second binary—not in the first API name the scanner encounters.

Safe rescan workflow

1. Record the plugin package name, exact version and content digest already deployed.
2. Confirm the scanner revision includes commit 2899323 or a later containing change.
3. Scan the same immutable package artifact, not a freshly resolved floating version.
4. Compare old and new findings by file, line and rule.
5. Manually inspect every newly exposed call and the data flowing into its command, arguments, working directory and environment.
6. If the report reaches the 32-finding cap, treat it as truncated evidence and continue with direct source review.
7. Revoke or narrow plugin authority before re-enabling anything whose risk decision changes.

A higher finding count after upgrading does not prove the plugin became more dangerous. It means the review evidence became more complete.

Release boundary and evidence

The official OpenClaw collector recorded PR #116222 and merge commit 2899323 with a P1 security label. The upstream summary states that the old scanner omitted later executable calls and that the replacement reports distinct matches in source order with a 32-finding bound. Direct GitHub page extraction and independent search retrieval were unavailable during this run, so implementation claims beyond that official record are intentionally limited.

OpenClaw Academy did not scan a historical malicious fixture or assign an affected-version range. Operators should verify inclusion through release notes or source ancestry rather than assuming a current package already contains a same-day main merge.

Bottom line

A security scan that shows one executable call can still conceal the call that changes the verdict. Upgrade the scanner, rescan previously reviewed high-authority plugins and treat the 32-result bound as a cue for manual review—not a clean bill of health.