ClawHub
Back to skill

Security audit

monorepo-scaffold

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly a coherent monorepo scaffolding guide, but it includes unpinned remote initializer execution and an unsafe database template that deserve review before installation.

Before installing, be comfortable with a skill that can create and modify project files after confirmation and run package-manager install/build commands. For safer use, require pinned generator versions instead of `@latest`, confirm before any `npx` or install command, and change the database template to a unique secret with localhost-only binding or no published port.

A.I.G

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

Error
Location
references/stack-recipes.md:94
Finding

Execution of an Unpinned Remote Nx Initializer

Content
View full analysis

Vulnerability Details

File Location: references/stack-recipes.md:94
Vulnerability Type: T08: Insecure Dependencies
Risk Level: High

Vulnerable Code:

markdown
1. Use `npx create-nx-workspace@latest` non-interactively where possible (pass flags for package manager and preset) rather than hand-rolling `nx.json` from scratch — Nx's generators keep the config in the shape Nx's own tooling expects.

Technical Analysis

The Skill instructs the Agent to execute create-nx-workspace through npx using the mutable latest distribution tag. If the package is not already available locally, npx retrieves it and executes its code. The code ultimately executed can therefore change after the Skill has been reviewed.

Pinning only a package name and mutable tag does not provide a reproducible or reviewable trust boundary. A compromised npm publisher account, malicious package release, registry compromise, or compromised transitive dependency could introduce arbitrary code. Package initialization logic and npm lifecycle scripts ordinarily execute with the permissions of the Agent's operating-system account.

This network activity is relevant to scaffolding an Nx project, but immediately executing an unpinned remote package exceeds the minimum privilege necessary. The initializer can be pinned, inspected, and separately invoked instead.

Attack Path

  1. An attacker compromises the create-nx-workspace release process, its publisher account, or a dependency included by a future release.
  2. The attacker publishes malicious code in the version referenced by the mutable latest tag.
  3. A user requests an Nx-based monorepo.
  4. Following the recipe, the Agent invokes npx create-nx-workspace@latest.
  5. npx downloads the current package and associated dependencies from the registry.
  6. The downloaded initializer or lifecycle scripts execute with the Agent user's permissions.
  7. Malicious code can acce ...[truncated 744 chars]
Remediation
View remediation

Remediation Suggestions

  1. Replace the mutable @latest reference with an exact, reviewed version, such as create-nx-workspace@X.Y.Z.
  2. Resolve and display the proposed version before execution and obtain user confirmation for remote code execution.
  3. Use the user's configured trusted registry and preserve registry integrity protections.
  4. Prefer downloading or installing the pinned package first, verifying its provenance and integrity, and invoking its binary as a separate step.
  5. Use a lockfile where feasible and retain integrity hashes for all resolved dependencies.
  6. Run scaffolding in a sandbox restricted to the destination directory, with unnecessary credentials removed from the environment and outbound network access limited to required registries.
  7. Avoid lifecycle scripts where supported, or explicitly review packages that require them before allowing execution.

T09 · Insecure Skill Coding Practices

Warning
Location
references/config-templates.md:228
Finding

Predictable PostgreSQL Password on a Host-Published Port

Content
View full analysis

Vulnerability Details

File Location: references/config-templates.md:228-234
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: Medium

Vulnerable Code:

yaml
services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: postgres
    ports:
      - "5432:5432"
    volumes:
      - db-data:/var/lib/postgresql/data

Technical Analysis

The Docker Compose template assigns PostgreSQL the predictable password postgres and publishes container port 5432 on the host without specifying a loopback-only bind address. Docker commonly interprets "5432:5432" as binding the port on all available host interfaces.

Although this template is described as being for local development, its configuration combines weak authentication with avoidable network exposure. If copied unchanged and started on a workstation, development server, shared CI runner, or cloud host, another network participant may be able to reach PostgreSQL and authenticate using the documented default password.

The static pre-scan's sensitive-network warning does not indicate outbound exfiltration here: the password configures a local container and is not sent to an external endpoint by the template. The confirmed issue is exposure of a network service protected by a hardcoded, publicly visible credential.

Attack Path

  1. The Skill generates the supplied Compose template without replacing the default password or restricting the bind address.
  2. The user runs docker compose up.
  3. Docker publishes PostgreSQL port 5432 on one or more externally reachable host interfaces.
  4. An attacker scans or otherwise identifies the exposed PostgreSQL service.
  5. The attacker attempts authentication with the predictable password postgres and an applicable database role.
  6. If authentication and host firewall rules permit the connection, the attacker gains database access and can read, alter ...[truncated 760 chars]
Remediation
View remediation

Remediation Suggestions

  1. Do not embed a working default password. Require explicit secret injection:

    yaml
    environment:
  POSTGRES_PASSWORD: "${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}"

  2. Bind the development service to the loopback interface unless remote access was explicitly requested:

    yaml
    ports:
  - "127.0.0.1:5432:5432"

  3. Add a non-secret .env.example containing only placeholder instructions, and ensure real .env files remain ignored by Git.

  4. Generate a unique, high-entropy development password or require the user to supply one during scaffolding.

  5. Document that development credentials must not be reused in CI, staging, or production.

  6. Avoid publishing the database port entirely when only other Compose services need database access; use the private Compose network instead.

  7. Apply host firewall rules and least-privileged PostgreSQL roles when network access is genuinely required.

SkillSpector

Vulnerability Patterns
  • 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
  • Rogue AgentSelf-Modification, Session Persistence
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Findings (7)

Self-Modification

High
Category
Rogue Agent
Confidence
85% confidence
Finding

The skill is designed to inspect directories and, with user approval, merge into existing files or scaffold into a non-empty location. Even though it says not to overwrite silently, permitting modification of existing content in a broad-trigger skill creates real risk of unintended repository changes, destructive edits, or corruption of an existing project if activated in the wrong context.

Content

Scanner excerpt · SKILL.md (reported line 26)May include surrounding context.

md
## Safety check

Before touching the filesystem:
- Confirm the target directory exists and list its contents. If it's not empty, stop and tell the user what's already there, then ask whether to proceed (merge into existing files), scaffold into a subfolder instead, or abort. Never silently overwrite existing files.
- Confirm whether the user wants git initialized here, or whether this folder is already inside a git repo (check for a `.git` directory, including in parent directories) — don't run `git init` inside an existing repo without asking.

## The interview

Credential Access

High
Category
Privilege Escalation
Confidence
60% confidence
Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · references/config-templates.md (reported line 91)May include surrounding context.

md
.next/
.turbo/
.nx/
.env
.env.local
*.log
.DS_Store

Credential Access

High
Category
Privilege Escalation
Confidence
60% confidence
Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · references/config-templates.md (reported line 92)May include surrounding context.

md
.turbo/
.nx/
.env
.env.local
*.log
.DS_Store
coverage/

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The trigger criteria are intentionally broad, including vague requests like starting a project with a frontend and backend. That can cause the skill to activate in situations where the user did not clearly request a monorepo scaffold, increasing the chance of unnecessary filesystem actions or an incorrect workflow being initiated.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
75% confidence
Finding

Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Content

Scanner excerpt · SKILL.md (reported line 27)May include surrounding context.

md
Before touching the filesystem:
- Confirm the target directory exists and list its contents. If it's not empty, stop and tell the user what's already there, then ask whether to proceed (merge into existing files), scaffold into a subfolder instead, or abort. Never silently overwrite existing files.
- Confirm whether the user wants git initialized here, or whether this folder is already inside a git repo (check for a `.git` directory, including in parent directories) — don't run `git init` inside an existing repo without asking.

## The interview

Rp1

Medium
Category
MCP Rug Pull
Confidence
90% confidence
Finding

The recipe recommends running npx changeset init without pinning an explicit package version. Because npx may fetch the latest package from the registry at execution time, a compromised upstream release, typo-squatted dependency resolution, or unexpected breaking update could execute unreviewed code on the developer's machine during scaffolding.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
95% confidence
Finding

The instruction to run npx create-nx-workspace@latest explicitly pulls and executes the newest published version at runtime. In a scaffolding skill, this is more dangerous because the whole purpose is to create and run setup commands automatically, so a malicious or compromised release could achieve immediate code execution in the user's environment before any review.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.