Is aprilox/philips-hue safe?
https://github.com/openclaw/skills/tree/main/skills/aprilox/philips-hue
The philips-hue skill provides genuine Philips Hue bridge control functionality and showed no active malicious behavior during install: canary files were untouched, no unexpected network connections occurred, and install was limited to a GitHub clone. Two findings warrant caution before deployment: the SKILL.md closes with a tip that instructs agents to write command reminders into the workspace TOOLS.md (a low-cost prompt persistence vector that survives skill removal), and hue.sh contains a Python heredoc injection vulnerability where unsanitized hex color input is interpolated into Python source, creating a code execution path if an attacker can influence the color argument in an agentic workflow.
Category Scores
Findings (7)
MEDIUM TOOLS.md Persistence Instruction in SKILL.md -20 ▶
The final line of SKILL.md is framed as a helpful tip but instructs the agent to write Hue command documentation into TOOLS.md at the workspace root. Files like TOOLS.md are commonly auto-loaded into agent context at session start. If the agent complies, skill-authored content persists across sessions and after the skill is removed, giving the skill author a low-cost mechanism to inject persistent instructions into the agent's context.
MEDIUM Python Heredoc Code Injection via Unsanitized $hex Variable -28 ▶
The hex_to_hsb() shell function in hue.sh constructs a Python script on-the-fly using a heredoc and directly interpolates the $hex variable (derived from user/agent-supplied color argument after only stripping '#' with sed) into Python source code. A crafted color value such as '#FF0000"; import os; os.system("..."); x="' would execute arbitrary Python with the agent's privileges. In an agentic context where the agent synthesizes light-control commands from natural language, the color parameter is agent-controlled and this path is reachable.
LOW Network-Capable Shell Script with Configurable Endpoint -7 ▶
hue.sh makes unauthenticated HTTP calls via curl to http://$BRIDGE_IP/api/$USERNAME/$path. Both BRIDGE_IP and USERNAME are loaded from a .env file the agent is directed to create. If a second skill or prompt injection modifies .env, all subsequent hue.sh invocations will send requests (including full light state JSON) to an attacker-controlled server rather than the local Hue bridge.
LOW Hue API Key Stored in Plaintext .env in Skill Directory -10 ▶
The skill requires BRIDGE_IP and USERNAME (the Hue API key) in a .env file co-located with the skill. Any agent that lists or reads files in the skill directory will pull these secrets into its context window, from where they may appear in conversation history, logs, or be leaked to a model grader API call.
INFO Credential Canary File Reads Observed — Attributable to Audit Framework -8 ▶
Inotify and auditd logs show OPEN/ACCESS of /home/oc-exec/.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCP credentials. However, the access timestamps (auditd epoch 1771906629 at session start and 1771906652 at session close) bracket the entire install window, matching the audit framework's own pre-install canary baseline and post-install integrity verification pattern. No EXECVE trace ties these reads to hue.sh or any skill-installed process. Canary integrity check independently confirms files were not modified or exfiltrated.
INFO Expected GitHub Clone — No Anomalous Network or Process Behavior -10 ▶
Install performed a standard shallow sparse-checkout clone of the openclaw/skills monorepo from GitHub (140.82.121.3:443). No other outbound destinations were contacted. No processes were spawned outside of git, cp, and rm. Connection diff shows no new persistent listeners or established connections after install.
INFO All Canary Files Intact -10 ▶
Post-install canary verification confirmed no honeypot files were modified or had content exfiltrated. The two rounds of credential file access observed in logs are consistent with audit framework operation, not skill behavior.