Is clawhub/searxng safe?
https://github.com/clawhub/searxng
This skill references a GitHub repository (clawhub/searxng) that could not be cloned, rendering its actual contents completely unauditable. The only artifact present is a .clawhub/lock.json file with a mismatched skill name ('academic-research-hub'). No malicious behavior was detected during the failed clone, and all canary files remain intact, but the inability to inspect the actual skill code or SKILL.md instructions means this skill cannot be verified as safe.
Category Scores
Findings (5)
HIGH Repository clone failed — contents unauditable -70 ▶
The git clone of https://github.com/clawhub/searxng failed with 'fatal: could not read Username for https://github.com: No such device or address'. This means the repository is either private, deleted, or requires authentication. The actual skill contents cannot be audited. This is a significant risk because the skill could contain any code or prompt injection once made accessible.
MEDIUM Skill name mismatch between lock.json and repository -15 ▶
The lock.json references skill name 'academic-research-hub' but the repository is named 'searxng'. This inconsistency suggests the skill may have been renamed, forked, or the lock.json was manually crafted. This does not prove malice but adds to the opacity of the skill's true purpose.
MEDIUM Empty SKILL.md — no declared behavior or permissions -50 ▶
The SKILL.md file is empty, meaning the skill declares no behavior, no required permissions, and no purpose. A properly constructed skill should declare what it does. The absence makes it impossible to assess whether the skill's actual behavior (once available) matches its declared intent.
LOW No prompt content to inject — but also no transparency -15 ▶
While the empty SKILL.md means there are currently zero prompt injection vectors, it also means the skill provides no useful functionality in its current state. If the repository becomes available later, prompt content could be introduced without re-audit.
INFO Standard system file reads during clone attempt 0 ▶
Filesystem monitoring detected reads of /etc/passwd, /etc/group, /etc/ld.so.cache, /etc/modprobe.d/, /etc/udev/rules.d/, and /etc/ssl/certs/. These are all standard system file accesses made by git, SSL libraries, and the dynamic linker during a clone operation. No writes were detected to any of these files.