Exposed secret literal
- Finding
- File appears to expose a hardcoded API secret or token.
- Content
-H 'Authorization: Bearer [REDACTED]' \
Security checks across static analysis, malware telemetry, and agentic risk
This plugin is designed to run local commands and has several safeguards, but its Gateway RPC path appears less protected than the documentation claims.
Install only if you intentionally want OpenClaw to run selected local commands. Before enabling, set a strong token, keep the bind host on 127.0.0.1, whitelist only low-risk absolute-path commands, avoid allowUserArgs:true unless necessary, and understand that the Gateway RPC path may be callable without the HTTP bearer token.
-H 'Authorization: Bearer [REDACTED]' \
VirusTotal engine telemetry is currently stale for this artifact.
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A Gateway caller or agent with access to httpshell.run could invoke any configured whitelisted command without presenting the bearer token the user may expect to protect execution.
The Gateway RPC handler checks only that a token exists in configuration, then runs the named whitelisted command from RPC parameters. Unlike the HTTP /run route, the visible Gateway path does not verify an Authorization bearer token before executing.
api.registerGatewayMethod("httpshell.run", async ({ params, respond }) => {
...
if (!config.token) {
respond(false, { error: "token_not_configured" });
return;
}
...
const args = safeArgs(paramsRecord.args);
const result = await runNamedCommand(config, name, args);Treat the Gateway method as trusted-only unless the plugin adds per-call authorization, explicit user approval, or clearer OpenClaw permission controls. Keep the whitelist minimal and avoid dangerous binaries or allowUserArgs:true.
Users may believe the Gateway command-execution path has the same bearer-token protection as the HTTP endpoint when it does not appear to do so.
This security claim is stronger than the visible implementation for the Gateway method, which enforces the whitelist but appears to require only that a token be configured, not supplied by the caller.
Both surfaces share the exact same whitelist + token enforcement.
Update the implementation to require token/permission checks for Gateway calls or update the documentation to clearly state that Gateway access is controlled by OpenClaw runtime permissions rather than the bearer token.
Users may have a harder time confirming the exact source and release lineage for a plugin that can execute local commands.
The bundled package metadata uses a placeholder repository URL and version 0.1.0, while the registry metadata identifies version 1.0.0 and source svensxl/openclaw-plugins. This is a provenance/metadata inconsistency, not evidence of malicious behavior.
"version": "0.1.0" ... "url": "https://github.com/your-org/http-shell-exec"
Publisher should align package.json/openclaw.plugin.json versions and repository URLs with the registry source before release.