Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
SysClaw Reporting
v4.0.0Report system issues and submit resource requests to SysClaw via the cross-agent communication system. Use when an agent needs to report an error, warning, o...
⭐ 0· 172·0 current·0 all-time
byMorten Bojer@mbojer
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
high confidencePurpose & Capability
The skill claims to submit reports/requests to 'SysClaw' and the included scripts perform exactly that by writing to a PostgreSQL database (system_comm). Requiring DB host/user/password is consistent with that purpose. However, the registry metadata declares no required environment variables or primary credential while the SKILL.md and scripts clearly require SYSCLAW_DB_* (or per-script overrides). This metadata omission is an incoherence that makes it harder to reason about required secrets before install.
Instruction Scope
Runtime instructions and the scripts only perform database operations (insert/select/update) and check hostname; they do not call external web endpoints or run arbitrary remote code. However, SKILL.md explicitly instructs operators to place plaintext DB credentials into wrapper scripts and a cron job (e.g., writing a script to /usr/local/bin and adding a crontab entry). That guidance creates a credential exposure risk and broad persistence if followed. The scripts also permit direct SQL usage; while parameterized queries and JSON validation are used, direct DB access still grants substantial power and should be limited to least-privileged accounts.
Install Mechanism
There is no installer that downloads or executes remote code; this is an instruction-only skill with bundled scripts. The only dependency is psycopg2 (installed via pip), which is explicitly called out. No external arbitrary-download or extraction steps are present in the manifest.
Credentials
The scripts legitimately require SYSCLAW_DB_HOST/PORT/NAME/USER/PASSWORD (or per-script overrides). Those environment variables are proportionate to the function (direct DB access). However, the skill registry lists no required env vars or primary credential, which is inconsistent and dangerous because users may not know it will require database credentials. Additionally, SKILL.md suggests embedding DB_PASSWORD in a system-wide wrapper script and cron, which is disproportionate from a least-privilege and secret-handling perspective.
Persistence & Privilege
The skill is not force-included (always: false) and does not autonomously modify other skills or global agent settings. The documentation recommends (optional) creating a cron wrapper in /usr/local/bin and writing notifications to workspace memory; these are user-driven persistence steps. They increase exposure if followed, but are not automatic privileges requested by the skill itself.
What to consider before installing
This skill appears to do what it says (submit reports/requests by writing to a PostgreSQL database), but there are important warnings to consider before installing or using it:
- Metadata mismatch: The registry declares no required environment variables, but the scripts and SKILL.md require SYSCLAW_DB_HOST/PORT/NAME/USER/PASSWORD (or per-script equivalents). Treat that omission as a red flag and ask the publisher to correct the manifest before use.
- Credential safety: The scripts require a DB user + password. Do NOT store high-privilege credentials in plaintext wrapper scripts or crontab entries. If you must run periodic checks, prefer a least-privileged DB account, secure storage for secrets (OS keyring, vault), and avoid embedding passwords in files under /usr/local/bin or crontab lines.
- Network security: The scripts connect to a DB host without explicit TLS/sslmode configuration. Ensure connections to the DB are restricted to trusted networks or use SSL/TLS and network-level access controls to protect credentials in transit.
- Least privilege: Create a dedicated DB role for reporting with only the necessary INSERT/SELECT/UPDATE privileges on the specific tables used (issues, agent_requests, notifications). Do not reuse admin or broad-privilege DB credentials.
- Audit and review the DB schema: Because these scripts write directly to the database, verify the schema, triggers, and any downstream automation that acts on inserted rows (SysClaw may execute approved actions). Ensure you trust the operator(s) who have access to that automation.
- Ask the maintainer for clarification: Request an updated registry manifest listing required environment variables and a justification for any suggested persistent cron-install steps. If you cannot verify the SysClaw operator and DB host, do not provide credentials.
If you want to proceed, only provide a tightly-scoped DB user with minimal privileges and avoid the suggested plaintext cron wrapper; instead use credential management tooling and secure scheduling mechanisms.Like a lobster shell, security has layers — review code before you run it.
latestvk97fvx11t8z688mg2gaaztt9ts8330m2
License
MIT-0
Free to use, modify, and redistribute. No attribution required.