Back to skill

Security audit

Digital Product Builder

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent and not malicious, but it asks users to install an unpinned package and store a Groq API key in a persistent plaintext workspace file.

Review before installing. Use a virtual environment and pinned dependency version for Pillow, and prefer a session-scoped environment variable or secret manager for the Groq key. Do not send secrets, customer data, unpublished proprietary material, or licensed content to Groq unless you are comfortable with that provider processing it.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:20
Finding
Unpinned Third-Party Dependency Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:20-23` **Vulnerability Type**: Uncontrolled third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash pip3 install Pillow # or: pip install Pillow # or: python3 -m pip install Pillow ``` ### Technical Analysis The Skill instructs users or agents to install Pillow without specifying a reviewed version, verifying a package hash, using a lockfile, constraining the package index, or isolating the installation in a virtual environment. Consequently, the code installed when these commands are executed can change after the Skill has been audited. A compromised package release, package registry, mirror, or dependency could introduce malicious code. Python package installation and subsequent import may execute package-controlled code with the permissions of the user running the command. The package name is correctly spelled and obtained through normal `pip` behavior; therefore, this finding concerns insufficient supply-chain controls rather than evidence that Pillow itself is malicious. ### Attack Path 1. An attacker compromises a future Pillow release, one of its distribution artifacts, the configured Python package index, or an intermediary mirror. 2. A user or agent follows the Skill's Quick Start instructions. 3. `pip` resolves and downloads the current uncontrolled package version from the configured index. 4. Package-controlled code executes during installation or when Pillow is imported. 5. The malicious code gains access to files, environment variables, and network resources available to the invoking user. ### Impact Assessment Successful exploitation could execute arbitrary code under the invoking user's account. The accessible scope would be limited by that account and the surrounding execution environment, but it could include workspace data, user-readable files, environment variables, and locally available credentials. The instructions do not explicitly r ...[truncated 86 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Pin Pillow to a specifically reviewed version rather than installing the latest available release. - Place the dependency in a lockfile or hash-locked requirements file and require cryptographic hash verification, such as `pip install --require-hashes -r requirements.txt`. - Explicitly use the official Python Package Index or another trusted, controlled registry. - Install the package in a dedicated virtual environment instead of modifying the global or user Python environment. - Regularly review and deliberately update the pinned version after security and compatibility testing. - Avoid running package installation commands with `sudo`, as an administrator, or from another privileged account. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:141
Finding
API Key Stored in a Predictable Plaintext Workspace File<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:141` **Vulnerability Type**: Insecure credential storage guidance **Risk Level**: Medium ### Vulnerable Code ```text **API key location:** Store your Groq API key in `~/.openclaw/workspace/dashboard/.env` as `GROQ_API_KEY=your_key_here` ``` ### Technical Analysis The Skill directs the user to place a Groq API key in a predictable plaintext file under a workspace directory. It does not require restrictive file permissions, exclusion from version control, exclusion from backups or artifact collection, use of a dedicated secret manager, or credential rotation. Workspace directories are commonly inspected by development tools, synchronization processes, backup systems, and source-control workflows. A plaintext `.env` file in such a location can therefore be exposed accidentally or read by another process or local user when filesystem permissions are too broad. The later JavaScript example accesses `process.env.GROQ_API_KEY` but does not load the specified `.env` file. Thus, creating this persistent workspace file is not inherently necessary for the demonstrated request pattern. A session-scoped environment variable or secret-injection mechanism would provide the required API access with less exposure. No hardcoded live credential or covert transmission was found. The documented request sends the key as a bearer token only to the declared `api.groq.com` endpoint, which is consistent with the optional copy-generation functionality. ### Attack Path 1. A user follows the instruction and creates `~/.openclaw/workspace/dashboard/.env` containing a valid Groq API key. 2. The file receives permissive default permissions, is included in source control, is copied into an artifact or backup, or is read by another workspace-integrated process. 3. An unauthorized party obtains the plaintext key. 4. The party submits authenticated requests to Groq using the exposed bearer token. 5. The key remains usable ...[truncated 590 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Prefer an operating-system credential store, managed secret service, or runtime secret-injection facility. - For interactive use, document a session-scoped environment variable instead of a persistent workspace file. - If file-backed storage is unavoidable, place the file outside source-controlled and shared workspace directories. - Create the secret file with permission mode `0600` on Unix-like systems and equivalent user-only access controls on other platforms. - Add all secret-bearing `.env` files to `.gitignore` and applicable artifact, synchronization, logging, and backup exclusion rules. - Ensure scripts never print the API key or include it in error messages. - Use a dedicated, least-privileged key with spending and rate limits where supported. - Document immediate key revocation and rotation procedures following suspected exposure. - If the Skill retains `.env` usage, explicitly load the intended file through a reviewed mechanism; otherwise remove the unnecessary file-location instruction. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The skill directs users to place a Groq API key in a local .env file and send product prompts to Groq, but it does not disclose that prompts, listing copy, and possibly proprietary product materials will be transmitted to a third-party service. This creates a data exposure risk because users may unknowingly send confidential business information, unpublished content, or licensed material to an external API under that provider’s retention and usage policies.

Static analysis

No suspicious patterns detected.