Back to skill

Security audit

hi-light Ear Skill

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent HiLight setup helper, but it handles an API key and opens/enables a third-party OpenClaw channel with unsafe defaults that users should review before installing.

Review this skill before installing. Use it only if you trust the @art_style666/hi-light plugin source, avoid dry-run or terminal transcripts with real API keys, rotate any key that was exposed in command history or logs, and set a restrictive dmPolicy and allowFrom list instead of accepting the wildcard defaults.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (3)

T08 · Insecure Dependencies

Error
Location
scripts/setup_hi_light.sh:3
Finding
Unpinned and Environment-Overridable Third-Party Plugin Installation<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup_hi_light.sh`, lines 3 and 101-103 **Vulnerability Type**: Untrusted and unpinned third-party dependency installation **Risk Level**: High ### Vulnerable Code ```bash PLUGIN_SPEC="${PLUGIN_SPEC:-@art_style666/hi-light}" ``` ```bash if [[ "$INSTALL_PLUGIN" -eq 1 ]]; then echo "[INFO] Installing plugin ${PLUGIN_SPEC}" run_cmd openclaw plugins install "$PLUGIN_SPEC" ``` ### Technical Analysis The setup script installs `@art_style666/hi-light` without an exact version or integrity pin. As a result, the code installed during a future setup can differ from the package version originally reviewed. The package specification can also be replaced through the inherited `PLUGIN_SPEC` environment variable. No validation restricts that value to the intended package name, version, registry, or integrity digest. An attacker who can influence the execution environment can therefore cause the setup script to install a different package. The script subsequently enables the plugin, placing the installed dependency within the OpenClaw runtime trust boundary: ```bash run_cmd openclaw plugins enable "$PLUGIN_ID" ``` ### Attack Path 1. An attacker compromises the upstream package or publishes a malicious future version under the same package name; alternatively, the attacker controls the `PLUGIN_SPEC` environment variable in the environment where setup runs. 2. The user invokes the documented setup script without `--skip-install`. 3. `openclaw plugins install` resolves and installs the unpinned or attacker-selected package. 4. The script enables the plugin. 5. Code supplied by that plugin can run within the permissions and data-access scope granted to OpenClaw plugins. ### Impact Assessment Successful exploitation can introduce arbitrary plugin behavior into OpenClaw. The resulting privileges depend on OpenClaw's plugin isolation model, but may include access to OpenClaw configuration, channel data, cre ...[truncated 330 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin the plugin to a reviewed, immutable version, for example an exact package version rather than an unconstrained package name. 2. Verify the package with a trusted integrity hash, lockfile, signature, or registry-supported provenance mechanism. 3. Remove the `PLUGIN_SPEC` environment override unless it is strictly required. 4. If configurability is required, validate the value against an explicit allowlist of approved package names, versions, and registries. 5. Prevent installation from arbitrary registries or local package paths. 6. Require explicit user confirmation showing the exact package identity and version before installation. 7. Review and update the pinned dependency through a controlled security-review process. 8. Run plugins with the minimum filesystem, credential, and network privileges supported by OpenClaw. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
scripts/setup_hi_light.sh:39
Finding
HiLight API Key Exposure Through Dry-Run Output and Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup_hi_light.sh`, lines 39-43 and 111 **Vulnerability Type**: Sensitive credential disclosure **Risk Level**: High ### Vulnerable Code ```bash run_cmd() { if [[ "$DRY_RUN" -eq 1 ]]; then printf '[dry-run] ' printf '%q ' "$@" printf '\n' return 0 fi "$@" } ``` ```bash run_cmd openclaw config set 'channels["hi-light"].authToken' "$API_KEY" ``` The documented invocation also places the credential in the setup script's command-line arguments: ```bash bash scripts/setup_hi_light.sh --api-key '<token>' ``` ### Technical Analysis In dry-run mode, `run_cmd` prints every command argument using `printf '%q '`. When the configuration command is processed, the API key is included in the argument array and is therefore printed without redaction. The dry-run feature consequently discloses the exact secret it is expected to protect. During a normal run, the API key is passed as a command-line argument to both the setup script and the `openclaw config set` child process. Command-line arguments may be observable through process inspection interfaces, process-monitoring agents, audit systems, diagnostic tooling, or command transcripts. When users type the documented command directly into a shell, the token may also be retained in shell history. Quoting prevents shell command injection but does not provide confidentiality. ### Attack Path 1. A user supplies a valid HiLight API key through the documented `--api-key` command-line option. 2. If `--dry-run` is used, the script passes the token to `printf '%q '`, causing the credential to appear in terminal output and any associated logs or transcripts. 3. During a normal run, the token appears in process arguments while the setup script and configuration command are running. 4. A local observer, monitoring service, CI log collector, terminal recorder, or person with access to shell history captures the token. 5. The observer reuses the ex ...[truncated 689 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not accept API keys through ordinary command-line arguments. 2. Read the token from an interactive hidden prompt, a protected file descriptor, standard input, or an approved operating-system secret store. 3. Prefer a dedicated OpenClaw secret-management interface if one is available. 4. Modify `run_cmd` so sensitive arguments are explicitly marked and replaced with a constant such as `[REDACTED]` in dry-run output. 5. Ensure verbose, debug, error, and audit output cannot serialize the token. 6. Avoid placing real credentials in shell commands, documentation examples, environment variables, or CI configuration where they may be logged. 7. Restrict permissions on any configuration file that ultimately stores the credential. 8. Rotate any API key that has already been used with the current dry-run mode or exposed in command history and logs. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
scripts/setup_hi_light.sh:6
Finding
Default Configuration Permits Direct Messages From All Senders<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup_hi_light.sh`, lines 6-7 and 112-113 **Vulnerability Type**: Overly permissive access-control configuration **Risk Level**: High ### Vulnerable Code ```bash DEFAULT_DM_POLICY="open" DEFAULT_ALLOW_FROM='["*"]' ``` ```bash run_cmd openclaw config set 'channels["hi-light"].dmPolicy' "$DM_POLICY" run_cmd openclaw config set 'channels["hi-light"].allowFrom' "$ALLOW_FROM" ``` ### Technical Analysis The standard setup path assigns an open direct-message policy and a wildcard sender allowlist. The user does not need to opt into public access, and the primary workflow does not require an explicit trusted-sender list. This violates least-privilege principles because a newly configured channel is exposed to every sender recognized by the channel rather than only to identities authorized by the user. Since the script restarts the gateway by default, this permissive policy becomes active immediately after setup. The script supports overriding these values, but insecure defaults remain effective whenever the user follows the documented standard command without additional options. ### Attack Path 1. A user runs the standard setup command without specifying a restrictive direct-message policy or sender allowlist. 2. The script writes `dmPolicy` as `open` and `allowFrom` as `["*"]`. 3. The script validates the configuration and restarts the gateway. 4. An untrusted HiLight sender contacts the configured channel. 5. Because the wildcard policy accepts the sender, the attacker can interact with functionality exposed through the OpenClaw channel. 6. The attacker may submit malicious prompts, consume resources, solicit sensitive responses, or invoke any actions made available to unauthenticated channel users. ### Impact Assessment The vulnerability expands channel access to unauthorized senders. Successful exploitation can provide access to the agent's conversational interface and any tools or data that t ...[truncated 339 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace the open policy with a deny-by-default or authenticated-only policy. 2. Require the user to provide an explicit allowlist of trusted sender identifiers during setup. 3. Reject wildcard allowlists unless the user gives informed, explicit confirmation after receiving a security warning. 4. Do not restart or expose the channel until access-control validation confirms that the configured policy is appropriately restrictive. 5. Display a redacted summary of the effective access policy before applying it. 6. Add validation that prevents contradictory combinations such as an open direct-message policy with a wildcard allowlist in security-sensitive deployments. 7. Document the consequences of public channel access and provide a secure example configuration. 8. Apply least-privilege restrictions to agent tools so that channel senders cannot automatically invoke sensitive filesystem, command-execution, credential, or administrative operations. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Rogue AgentSelf-Modification, Session Persistence
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (6)

Session Persistence

Medium
Category
Rogue Agent
Content
---
name: hi-light-openclaw
description: 以用户可执行的工作流方式安装、配置和排查 HiLight OpenClaw 插件。用户想把 OpenClaw 连接到 HiLight、安装 `@art_style666/hi-light` 插件、把 `channels["hi-light"]` 写入 OpenClaw 配置、更新 HiLight API Key 或 WebSocket 地址、或排查 HiLight 无法连接时使用。 Install, configure, and troubleshoot the HiLight OpenClaw plugin as a user-facing setup workflow. Use when a user wants to connect OpenClaw to HiLight, install `@art_style666/hi-light`, write `channels["hi-light"]` into OpenClaw config, update the HiLight API key or websocket URL, or diagnose why the HiLight channel does not connect.
---

# HiLight For OpenClaw
Confidence
86% confidence
Finding
The skill is designed to persist configuration, including writing `channels["hi-light"]` settings and updating API key or websocket endpoint values in OpenClaw config. Persisting secrets and connection settings across sessions can create risk if stored insecurely, modified without clear consent, or later reused by other workflows, especially because the skill also instructs collecting an API key and applying it via a setup script.

Natural-Language Policy Violations

Medium
Confidence
88% confidence
Finding
The document is explicitly split into Chinese and English sections and instructs the agent to provide concrete example phrasing in those languages, but it does not state that the user's preferred language should be asked or preserved. This can violate a language/locale policy when interacting with users who prefer another language.

Natural-Language Policy Violations

Medium
Confidence
88% confidence
Finding
The natural-language strings explicitly prioritize Chinese first ('中文在前') and present the prompt in Chinese-first form, but there is no indication that the user can opt into another language. This can violate language/locale policy expectations when a skill imposes a language preference without documented user choice or justification.

Vague Triggers

Medium
Confidence
91% confidence
Finding
The default prompt encourages using the skill to install or configure the plugin and 'fill in my API key' without clearly constraining when the skill should activate or what safety boundaries apply. In an agent environment, overly broad invocation text can cause unintended routing of unrelated requests into a skill that handles sensitive configuration material, increasing the chance of credential exposure or unsafe config changes.

Natural-Language Policy Violations

Medium
Confidence
90% confidence
Finding
The file is explicitly structured as bilingual-only instructions under '# 中文' and '# English', which imposes specific languages rather than offering a user language choice. The policy allows locale constraints only when users can opt in or when the limitation is clearly justified as region-specific, neither of which is stated here.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The script stores the HiLight API key in OpenClaw configuration and then prints the full `channels["hi-light"]` object as JSON, which may expose `authToken` in terminal output, logs, CI job traces, shell history captures, or support screenshots. In this setup-oriented skill, users are specifically encouraged to run the workflow interactively, which increases the likelihood of inadvertent credential disclosure during normal use or troubleshooting.

Static analysis

No suspicious patterns detected.