Is humberto0o0/vision-analyze safe?
https://github.com/openclaw/skills/tree/main/skills/humberto0o0/vision-analyze
The vision-analyze skill presents a clean SKILL.md with no prompt injection vectors and caused no canary file compromise during installation. However, the skill's entire runtime execution path flows through an external shell script (/home/clawdbot/openclaw-tools/vision_analyze.sh) that was not included in the audited files and cannot be reviewed, representing significant opacity in the security posture. The skill's design of accepting arbitrary local file paths combined with Google Cloud Vision's data transmission model means any local file content could be sent externally if the agent is directed to analyze a sensitive path. Metadata anomalies (wrong skill in lock.json, organizational mismatch in commit URL) further reduce confidence in the skill's provenance.
Category Scores
Findings (8)
HIGH Primary execution path is an external unauditable shell script -35 ▶
skill.json's 'command' field points to /home/clawdbot/openclaw-tools/vision_analyze.sh, a script located outside the skill repository and not included among the audited files. The actual runtime behavior — what files it reads, what network calls it makes, what data it transmits and to whom — cannot be determined from this audit. This is the single most significant opacity in the skill's security posture.
HIGH Arbitrary local file path accepted as input; file content transmitted to Google Cloud Vision -28 ▶
The input schema places no restrictions on the 'input' parameter beyond type: string. When vision_analyze.sh is invoked with a sensitive local path (e.g., ~/.env, ~/.ssh/id_rsa, ~/.aws/credentials), the Vision API call will OCR or label that file's content and return it, effectively exfiltrating the data to Google. A malicious user or a confused agent could trigger this unintentionally.
MEDIUM External script may perform undisclosed data collection beyond Vision API call -20 ▶
Because vision_analyze.sh exists outside the skill repository, it could read additional environment variables, log the user's API keys, or exfiltrate data to secondary endpoints not mentioned in SKILL.md. The canary files were not touched during installation (when the script was not invoked), but runtime behavior at skill-execution time remains entirely unknown.
MEDIUM lock.json references wrong skill — provenance anomaly -17 ▶
.clawhub/lock.json declares a dependency on 'academic-research-hub' version 0.1.0 rather than on 'vision-analyze' or any of its dependencies. This file appears to have been copied verbatim from a different skill's repository without being updated, raising questions about the developer's care and whether other metadata was also copied incorrectly.
LOW Metadata commit URL references different GitHub organization than install source -13 ▶
_meta.json's latest.commit field points to https://github.com/clawdbot/skills/commit/5e6be55f... but the skill is distributed from https://github.com/openclaw/skills. While this may reflect a legitimate repo migration or fork, it constitutes a minor provenance inconsistency that could obscure the actual commit history of the published skill.
LOW URL input type creates minor agent-mediated SSRF risk -7 ▶
The skill accepts publicly accessible URLs as input. A malicious actor who can influence the agent's tool invocations could supply a crafted URL pointing to an attacker-controlled server, causing vision_analyze.sh to fetch that URL and potentially leak request metadata (IP, timing, headers) to the attacker. This is a low-severity concern that depends entirely on the runtime implementation of vision_analyze.sh.
INFO Post-install platform gateway established new connections to Amazon AWS -12 ▶
Following installation, the openclaw-gateway process (pid=1088) opened two new outbound TCP connections to 34.233.6.177:443 (Amazon AWS) and began listening on 127.0.0.1:18790 and 127.0.0.1:18793. This is consistent with the ClawdBot platform registering the newly installed skill with its backend service. No skill-authored code was responsible for this traffic.
INFO Canary files accessed exclusively by audit framework's own operations 0 ▶
Honeypot files were accessed at two distinct timestamps: 1771928992 (pre-install, consistent with audit framework placing canaries) and 1771929015 (post-install, consistent with audit framework running its final integrity scan). The access pattern — all files touched at identical millisecond timestamps in a batch — is characteristic of a scripted check, not opportunistic credential harvesting. All files confirmed intact with no writes or deletions.