Trust Assessment
tribe-protocol received a trust score of 48/100, placing it in the Untrusted category. This skill has significant security findings that require attention before use in production.
SkillShield's automated analysis identified 21 findings: 5 critical, 10 high, 4 medium, and 2 low severity. Key findings include Sensitive environment variable access: $HOME, Node lockfile missing, Arbitrary Code Execution via DID Document (eval).
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 0/100, indicating areas for improvement.
Last analyzed on February 14, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings21
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| CRITICAL | Arbitrary Code Execution via DID Document (eval) The skill's JavaScript implementation sketch demonstrates the use of `eval()` to execute code from a `document.serviceEndpoint.code` field within a DID document. If an attacker can manipulate the content of a DID document, they can achieve arbitrary code execution on the host system. Avoid using `eval()` or `new Function()` with untrusted or partially trusted input. If dynamic code execution is strictly necessary, ensure the source is cryptographically signed and verified, or use a secure sandboxed environment. Re-evaluate the need for such functionality. | LLM | legacy/tribe-protocol-examples/implementation-sketch.js:190 | |
| CRITICAL | Arbitrary Code Execution via DID Document (new Function) The skill's JavaScript implementation sketch demonstrates the use of `new Function()` to execute code from a `document.serviceEndpoint.code` field within a DID document. This is functionally equivalent to `eval()` and allows arbitrary code execution if an attacker can manipulate the DID document. Avoid using `eval()` or `new Function()` with untrusted or partially trusted input. If dynamic code execution is strictly necessary, ensure the source is cryptographically signed and verified, or use a secure sandboxed environment. Re-evaluate the need for such functionality. | LLM | legacy/tribe-protocol-examples/implementation-sketch.js:193 | |
| CRITICAL | Arbitrary Command Execution via DID Document (child_process.exec) The skill's JavaScript implementation sketch demonstrates the use of `child_process.exec()` to execute shell commands from a `document.serviceEndpoint.command` field within a DID document. This allows arbitrary command execution on the host system if an attacker can manipulate the DID document. Avoid executing shell commands from untrusted or partially trusted input. If external command execution is necessary, use a whitelist of allowed commands and strictly sanitize all arguments. Re-evaluate the need for such functionality. | LLM | legacy/tribe-protocol-examples/implementation-sketch.js:196 | |
| CRITICAL | Arbitrary File Read via DID Document (fs.readFileSync) The skill's JavaScript implementation sketch demonstrates reading arbitrary files using `fs.readFileSync()` based on a `document.serviceEndpoint.filepath` field from a DID document. This allows an attacker to exfiltrate sensitive files from the host system if they can manipulate the DID document. Restrict file access to a predefined, secure directory. Implement strict path validation and sanitization to prevent directory traversal attacks. Avoid reading file paths directly from untrusted input. | LLM | legacy/tribe-protocol-examples/implementation-sketch.js:199 | |
| CRITICAL | Environment Variable Exfiltration via DID Document (process.env) The skill's JavaScript implementation sketch demonstrates accessing environment variables using `process.env[document.serviceEndpoint.envVar]` based on a `document.serviceEndpoint.envVar` field from a DID document. This allows an attacker to exfiltrate sensitive environment variables (e.g., API keys, secrets) if they can manipulate the DID document. Avoid accessing environment variables based on untrusted input. If specific environment variables must be exposed, use a strict whitelist and ensure they do not contain sensitive credentials. | LLM | legacy/tribe-protocol-examples/implementation-sketch.js:202 | |
| HIGH | Server-Side Request Forgery (SSRF) via DID Document (fetch) The skill's JavaScript implementation sketch demonstrates making network requests using `fetch()` to a URL specified in a DID document's `serviceEndpoint.url` field. If an attacker can manipulate the DID document, they could force the bot to make requests to internal network resources or arbitrary external sites, leading to SSRF or data exfiltration. Implement strict URL validation and whitelisting for all network requests initiated based on untrusted input. Prevent requests to private IP ranges and ensure only expected domains are accessed. | LLM | legacy/tribe-protocol-examples/implementation-sketch.js:205 | |
| HIGH | SQL Injection in scripts/access.sh (grant command) The `grant` command in `access.sh` constructs an SQL `INSERT OR REPLACE` query by directly concatenating user-controlled variables (`$SERVER`, `$CHANNEL`, `$CHANNEL_NAME`) without proper SQL escaping. An attacker can inject malicious SQL code by providing specially crafted input for these arguments, leading to unauthorized data modification, deletion, or exfiltration. Apply `sql_escape` to all user-controlled variables (`$SERVER`, `$CHANNEL`, `$CHANNEL_NAME`) before concatenating them into SQL queries. For example, `'$SERVER'` should become `'$(sql_escape "$SERVER")'`. | LLM | scripts/access.sh:39 | |
| HIGH | SQL Injection in scripts/access.sh (revoke command) The `revoke` command in `access.sh` constructs SQL `DELETE` queries by directly concatenating user-controlled variables (`$SERVER`, `$CHANNEL`) without proper SQL escaping. An attacker can inject malicious SQL code by providing specially crafted input for these arguments, leading to unauthorized data deletion or modification. Apply `sql_escape` to all user-controlled variables (`$SERVER`, `$CHANNEL`) before concatenating them into SQL queries. For example, `'$SERVER'` should become `'$(sql_escape "$SERVER")'`. | LLM | scripts/access.sh:69 | |
| HIGH | SQL Injection in scripts/add.sh (owner lookup) The `add` command in `add.sh` performs an entity lookup by name using a user-controlled `$OWNER` variable directly in an SQL query without escaping. An attacker can inject malicious SQL code via the `--owner` argument, leading to unauthorized data access or manipulation. Apply `sql_escape` to the `$OWNER` variable before using it in the SQL query. For example, `name='$(sql_escape "$OWNER")'`. | LLM | scripts/add.sh:67 | |
| HIGH | SQL Injection in scripts/add.sh (tag addition) The `add` command in `add.sh` inserts entity tags using a user-controlled `$tag` variable directly in an SQL query without escaping. An attacker can inject malicious SQL code via the `--tag` argument, leading to unauthorized data modification or deletion. Apply `sql_escape` to the `$tag` variable before using it in the SQL query. For example, `tag='$(sql_escape "$tag")'`. | LLM | scripts/add.sh:120 | |
| HIGH | SQL Injection in scripts/init.sh (seeding entities) The `init.sh` script directly uses user-controlled variables (`$BOT_NAME`, `$BOT_DISCORD_ID`, `$HUMAN_NAME`, `$HUMAN_DISCORD_ID`, `$S_SLUG`, `$GUILD_CLAUSE`) in `sqlite3` commands without escaping. This allows SQL injection during the initialization phase if malicious arguments are provided to `tribe init`. Apply `sql_escape` to all user-controlled variables before using them in `sqlite3` commands. For example, `'$BOT_NAME'` should become `'$(sql_escape "$BOT_NAME")'`. | LLM | scripts/init.sh:70 | |
| HIGH | SQL Injection in scripts/lookup.sh (type lookup) The `lookup` command in `lookup.sh` allows querying entities by type, using the user-controlled `$TYPE` variable directly in an SQL query without escaping. An attacker can inject malicious SQL code via the `--type` argument. Apply `sql_escape` to the `$TYPE` variable before using it in the SQL query. For example, `e.type='$(sql_escape "$TYPE")'`. | LLM | scripts/lookup.sh:110 | |
| HIGH | SQL Injection in scripts/roster.sh (multiple filters) The `roster` command in `roster.sh` constructs a complex SQL query using multiple user-controlled variables (`$TYPE`, `$SERVER`, `$ROLE`, `$TAG`) directly in the `WHERE` clause without proper SQL escaping. This creates a significant SQL injection vulnerability where an attacker can manipulate the query to bypass filters, access unauthorized data, or perform arbitrary database operations. Apply `sql_escape` to all user-controlled variables (`$TYPE`, `$SERVER`, `$ROLE`, `$TAG`) before concatenating them into the SQL query. For example, `e.type='$(sql_escape "$TYPE")'`. | LLM | scripts/roster.sh:40 | |
| HIGH | SQL Injection in scripts/tag.sh (tag management) The `tag` command in `tag.sh` uses the user-controlled `$TAG` variable directly in SQL `INSERT` and `DELETE` queries without escaping. An attacker can inject malicious SQL code via the `<tag>` argument, leading to unauthorized data modification or deletion. Apply `sql_escape` to the `$TAG` variable before using it in the SQL query. For example, `tag='$(sql_escape "$TAG")'`. | LLM | scripts/tag.sh:30 | |
| HIGH | SQL Injection in scripts/update.sh (set-status command) The `set-status` command in `update.sh` updates an entity's status using the user-controlled `$NEW_STATUS` variable directly in an SQL query without escaping. An attacker can inject malicious SQL code via the `<status>` argument, leading to unauthorized data modification. Apply `sql_escape` to the `$NEW_STATUS` variable before using it in the SQL query. For example, `status='$(sql_escape "$NEW_STATUS")'`. | LLM | scripts/update.sh:70 | |
| MEDIUM | Sensitive environment variable access: $HOME Access to sensitive environment variable '$HOME' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/cheenu1092-oss/tribe-protocol/scripts/init.sh:119 | |
| MEDIUM | Sensitive environment variable access: $HOME Access to sensitive environment variable '$HOME' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/cheenu1092-oss/tribe-protocol/scripts/lib/db.sh:10 | |
| MEDIUM | Excessive Permissions via Environment Variable Control (TRIBE_DB/CLAWD_HOME) The skill determines its database path using `TRIBE_DB` or `CLAWD_HOME` environment variables. If an attacker can control these environment variables, they can redirect the skill to operate on arbitrary SQLite database files, potentially overwriting or reading sensitive data outside the intended skill directory. This grants excessive file system access. Restrict the ability to override critical paths via environment variables. If overrides are necessary, implement strict path validation to ensure they remain within an allowed, sandboxed directory. Consider using a fixed, non-configurable path for sensitive data. | LLM | scripts/lib/db.sh:4 | |
| MEDIUM | Data Exfiltration via 'export' command The `export` command explicitly dumps the entire contents of the `tribe.db` database to standard output in markdown format. While this is intended functionality, it represents a significant data exfiltration vector. If an attacker gains control over the AI agent or can trick it into executing this command, all stored entity information, access rules, and audit logs can be exfiltrated, bypassing any trust tier boundaries. Implement robust authorization checks before allowing the `export` command to be executed. Ensure that only highly trusted entities (e.g., the owner) can trigger this command. Consider redacting sensitive fields from the export or providing granular export options. | LLM | scripts/export.sh:1 | |
| LOW | Node lockfile missing package.json is present but no lockfile was found (package-lock.json, pnpm-lock.yaml, or yarn.lock). Commit a lockfile for deterministic dependency resolution. | Dependencies | skills/cheenu1092-oss/tribe-protocol/package.json | |
| LOW | Prompt Injection Risk in TRIBE.md Generation The `init.sh` script substitutes the user-controlled `HUMAN_DISCORD_ID` directly into the `TRIBE.md` template without any escaping. If `TRIBE.md` is later consumed by an LLM, a malicious `HUMAN_DISCORD_ID` containing LLM instructions could lead to prompt injection, manipulating the LLM's behavior. Sanitize or escape user-controlled inputs (like `HUMAN_DISCORD_ID`) before embedding them into documents that will be consumed by an LLM. This could involve removing special characters or encoding them to prevent them from being interpreted as instructions. | LLM | scripts/init.sh:105 |
Scan History
Embed Code
[](https://skillshield.io/report/bb0378443bd51bee)
Powered by SkillShield