Back to skill

Security audit

Generate SaaS Growth Ad Creative Brief

Security checks for vulnerabilities and agentic risk

Overview

This looks like a simple SaaS ad-brief skill, but it asks for unnecessary shell access and has inconsistent source repository metadata.

Review this skill before installing. It should not need shell access to generate an ad creative brief, and the publisher should align the documented repository source before users rely on manual installation. Prefer installation through a reviewed ClawHub package or a pinned, verified release.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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)

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:4
Finding
Unnecessary Shell Capability Violates Least Privilege<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:4` **Vulnerability Type**: Excessive tool permissions **Risk Level**: Medium **Complete Code Snippet**: ```yaml allowed-tools: Bash, Read ``` ### Technical Analysis The skill declares access to the `Bash` tool even though its documented purpose is to generate SaaS advertising creative briefs. None of the workflow steps in `SKILL.md` require command execution, system administration, package installation, or shell-based processing. Exposing a general-purpose shell unnecessarily increases the skill's authority and violates the principle of least privilege. If attacker-controlled campaign content, copied reference material, or another instruction source successfully influences the agent, the unnecessary Bash permission could provide a path from prompt-level manipulation to local command execution. The declaration does not itself prove that commands are automatically executed. Exploitation depends on the hosting agent honoring this permission and being induced to invoke Bash. ### Attack Path 1. A user supplies attacker-controlled campaign text, reference material, or other content to the skill. 2. The content includes instructions designed to make the agent treat shell execution as part of generating or enriching the creative brief. 3. The agent follows the injected instructions and invokes the allowed `Bash` tool. 4. Commands execute with the operating-system privileges and filesystem access of the agent process. 5. Depending on the runtime sandbox, the attacker may read accessible files, modify workspace content, invoke installed programs, or make network requests through available system utilities. ### Impact Assessment Successful exploitation could obtain the effective privileges of the agent process through shell command execution. The affected scope may include readable files, writable project or user directories, environment variables, installed command-line tools, and network resources ...[truncated 291 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove `Bash` from `allowed-tools` because it is not required by the documented workflow: ```yaml allowed-tools: Read ``` - If local file access is also unnecessary, remove `Read` and expose no tools by default. - If a future feature genuinely requires command execution, replace unrestricted Bash access with a narrowly scoped tool that validates arguments and permits only specific operations. - Run the skill in a sandbox with minimal filesystem permissions, restricted network access, a sanitized environment, and no inherited credentials. - Require explicit user confirmation before any command execution. - Treat campaign briefs, copied web content, and reference files as untrusted data rather than executable instructions. ]]>

T08 · Insecure Dependencies

Note
Location
README.md:10
Finding
Conflicting Repository Ownership Creates Installation Provenance Risk<![CDATA[ ## Vulnerability Details **File Location**: `README.md:10-13` and `package.json:8-11` **Vulnerability Type**: Ambiguous and inconsistent software supply-chain source **Risk Level**: Low **Complete Code Snippets**: `README.md:10-13`: ```bash ### Manual Installation ```bash git clone https://github.com/qiaomucom/generate-saas-growth-ad-creative-brief.git cp -r generate-saas-growth-ad-creative-brief ~/.openclaw/skills/generate-saas-growth-ad-creative-brief ``` `package.json:8-11`: ```json "repository": { "type": "git", "url": "https://github.com/TobeyRebecca/generate-saas-growth-ad-creative-brief.git" } ``` ### Technical Analysis The manual installation instructions clone a repository owned by `qiaomucom`, while the package metadata identifies a repository owned by `TobeyRebecca`. Because the owners differ, users cannot determine from the package which repository is the authoritative upstream source. The installation instructions also clone the default branch without pinning a reviewed tag or commit. Consequently, the installed content can differ from the audited artifact and can change after review. The audit found no evidence that either referenced repository is malicious; the confirmed issue is the provenance conflict and the resulting inability to reliably verify the intended source. ### Attack Path 1. A user reviews or trusts the package metadata, which identifies the `TobeyRebecca` repository. 2. The user follows the manual installation instructions in `README.md`. 3. Git instead downloads the current default branch from the differently owned `qiaomucom` repository. 4. The user copies the downloaded files directly into `~/.openclaw/skills/`. 5. If that mutable repository is compromised, transferred, or contains content different from the reviewed artifact, the OpenClaw environment loads the unreviewed skill content. 6. Any resulting privileges depend on the content of the remotely cloned revision and the tools granted by the host. ### ...[truncated 626 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Select and verify one authoritative repository owner and URL. - Use the same canonical URL in `README.md`, `package.json`, ClawHub metadata, and external documentation. - Pin manual installation to a reviewed release tag or immutable commit rather than the mutable default branch. - Publish release checksums or signed provenance and document how users can verify them before installation. - Prefer a command sequence that explicitly checks out the reviewed revision, for example: ```bash git clone https://github.com/VERIFIED_OWNER/generate-saas-growth-ad-creative-brief.git cd generate-saas-growth-ad-creative-brief git checkout --detach VERIFIED_COMMIT_SHA ``` - Protect the canonical repository with multi-factor authentication, branch protection, signed releases, and restricted maintainer access. - Correct or remove stale repository references before distribution. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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

Static analysis

No suspicious patterns detected.