bool-cli

• Outcome: Review
• Latest audit: Sep 11, 2026 · 2:15 AM UTC
• Version: 1.0.1

Overview

This skill is for a real deployment workflow, but it normalizes broad recursive uploads and confirmation-skipped deletion, which users should review carefully before installing.

Install only if you trust the bool-cli npm package and are comfortable with a global CLI. Before deploying or using shipit, deploy from a clean build/output directory or review .boolignore and exclusions so secrets are not uploaded. Require explicit confirmation and verify the slug before any bool bools delete command, despite the skill's -y guidance. Keep ~/.config/bool-cli/config.json and .bool/config private, and ensure .bool/ is ignored by version control.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:21
• Finding: Unpinned Global Installation of a Third-Party npm Package## Vulnerability Details **File Location**: `SKILL.md`, lines 21-25 and 35 **Vulnerability Type**: Unpinned third-party dependency installed globally **Risk Level**: Medium ### Complete Code Snippet ```yaml install: - id: npm kind: npm package: bool-cli global: true bins: ["bool"] label: "Install bool-cli (npm)" ``` ```markdown 1. **Install**: `npm install -g bool-cli` ``` ### Technical Analysis The Skill directs users or agents to install `bool-cli` globally using only its mutable npm package name. It does not pin a reviewed version, specify an integrity digest, provide a lockfile, or disable npm lifecycle scripts. npm installation can execute package lifecycle scripts, while a global installation exposes the resulting executable throughout the user's environment. Consequently, the effective code installed by this Skill can change after the Skill has been audited. If the npm package, publisher account, or a future release is compromised, following these instructions could execute attacker-controlled code with the privileges of the user performing the installation. No evidence in the audited file establishes that the current `bool-cli` package is malicious. The vulnerability is the unsafe, mutable dependency-installation practice and the associated supply-chain exposure. ### Attack Path 1. An attacker compromises the npm publisher account, package release process, or another component of the package's dependency chain. 2. The attacker publishes a malicious version under the same `bool-cli` package name. 3. An agent follows `npm install -g bool-cli` without selecting a previously reviewed version. 4. npm resolves the mutable package name to the attacker-controlled release. 5. Malicious package code may run through an installation lifecycle script or when the globally installed `bool` executable is invoked. 6. The code executes with the installing user's privileges and can access ...[truncated 689 chars]
• Remediation: ## Remediation Suggestions - Pin `bool-cli` to a specific, reviewed version rather than resolving the latest mutable release. - Verify the package using a trusted integrity digest and retain a lockfile or equivalent reproducible-installation record. - Prefer a project-local installation over a global installation to reduce scope and prevent unintended executable replacement. - Run the CLI with `npx --ignore-existing` or an equivalent controlled mechanism only after verifying the exact package version and integrity. - Disable npm lifecycle scripts with `--ignore-scripts` where the package can function without them. - Verify package provenance, publisher identity, release signatures, and repository correspondence before installation. - Execute the package in a restricted environment with minimal filesystem, credential, and network access.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:186
• Finding: Recursive Deployment Can Upload Unexcluded Sensitive Files## Vulnerability Details **File Location**: `SKILL.md`, lines 186-195 **Vulnerability Type**: Overly broad recursive file upload with insufficient default exclusions **Risk Level**: High ### Complete Code Snippet ```markdown ## Deploy Behavior - `bool deploy` recursively reads the directory and uploads all text files - **Auto-create Bool**: If no slug is provided (and no `.bool/config` exists), a new Bool is created automatically, named after the directory - **Live URL**: The live deployment URL is displayed in the output after successful deployment - **Binary files** (images, PDFs, archives, fonts, etc.) are automatically skipped - **Default excludes**: `.git`, `node_modules`, `__pycache__`, `.DS_Store`, `.bool` - **Custom excludes**: Use `--exclude <pattern>` (repeatable) for additional patterns - **`.boolignore`**: If a `.boolignore` file exists in the deploy directory, it is respected (gitignore syntax) - File paths in the payload are **relative** to the deploy directory ``` ### Technical Analysis The documented deployment behavior recursively reads and uploads every text file beneath the selected directory unless a file matches a limited exclusion list. The default exclusions do not cover common sensitive files such as `.env`, `.env.local`, private keys, cloud-provider credentials, SSH configuration, package-manager credentials, database exports, local application configuration, or secret-manager exports. Filtering by text-versus-binary format is not a security boundary because credentials, tokens, source code, private keys, and configuration secrets are commonly stored as text. Custom exclusions and `.boolignore` are optional, so safe behavior depends on users anticipating every sensitive file before deployment. Deployments also have a live URL, and the Skill supports `public` and `unlisted` visibility. Therefore, an unintentionally uploaded secret may be transferred to Bool.com and could become accessible ...[truncated 1778 chars]
• Remediation: ## Remediation Suggestions - Replace recursive allow-by-default collection with a default-deny policy that uploads only explicitly selected build artifacts. - Display the complete file manifest before transmission and require explicit confirmation for files outside expected deployment directories. - Add default exclusions for `.env`, `.env.*`, `*.pem`, `*.key`, `*.p12`, `*.pfx`, `credentials.json`, service-account files, `.npmrc`, `.pypirc`, `.netrc`, `.ssh/`, `.aws/`, `.azure/`, `.config/gcloud/`, database dumps, and backup files. - Run secret scanning against the upload manifest and block deployment when likely credentials or private keys are detected. - Recommend deploying a clean build-output directory rather than a repository root or home directory. - Default new deployments to private visibility and require explicit authorization before changing them to public or unlisted. - Clearly warn that `.boolignore` must be reviewed before every deployment and provide a secure template. - Support a dry-run mode that reports included and excluded files without uploading anything. - Document immediate credential revocation and rotation procedures for accidental deployments.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill explicitly instructs agents to use `-y` with a destructive delete operation, removing an interactive safety check without requiring any compensating confirmation step. In an agent context, this increases the chance of accidental or unauthorized remote resource deletion, especially if the slug is inferred from prior context or local config.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

bool bools create <name>       # Create a new Bool
bool bools info [slug]         # Show Bool details + latest version info
bool bools update [slug] --name "New Name" --description "desc" --visibility public
bool bools delete [slug] -y    # Delete a Bool (always use -y to skip prompt)
bool bools open [slug]         # Open Bool in browser
bool bools visibility [slug]         # Show current visibility
bool bools visibility [slug] --set private    # Change visibility

• Confidence: 89% confidence
• Finding: The documentation normalizes autonomous execution of a destructive command by instructing agents to 'always use -y to skip prompt' for deletion. In security terms, this weakens human oversight for irreversible actions and makes accidental or context-manipulated deletions more likely in automated workflows.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The deploy workflow describes convenience behavior but does not prominently warn that local directory contents are uploaded to a third-party remote service. In an agent setting, this can lead to unintended exfiltration of sensitive source files, configs, or proprietary content if the selected directory or exclusions are wrong.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The `shipit` workflow encourages anonymous publishing without a strong warning that it remotely publishes project contents and stores a reusable local secret in `.bool/config`. This combination can expose private code or data and leave behind credentials that enable later updates to the published site.