ClawHub
Back to skill

Security audit

Docker部署助手

Security checks for vulnerabilities and agentic risk

Overview

This Docker deployment skill appears legitimate, but its example deployment scripts include unsafe high-impact operations that users should review before installing or copying.

Install only if you are comfortable reviewing and hardening generated Docker scripts before use. Do not copy the deployment or rollback scripts into production as-is; validate tag inputs, avoid SSH heredoc interpolation, remove or gate docker system prune -f, pin production images by digest, and keep real secrets in Docker Secrets or another secret manager rather than committed .env files.

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 (3)

T09 · Insecure Skill Coding Practices

Error
Location
references/details.md:406
Finding

Remote Command Injection Through an Unvalidated Rollback Tag

Content
View full analysis

Vulnerability Details

File Location: references/details.md, lines 406 and 417-421
Vulnerability Type: Shell command injection across an SSH boundary
Risk Level: High

Vulnerable Code

bash
BACKUP_TAG=${1}
SERVER="deploy@example.com"
DEPLOY_DIR="/opt/${APP_NAME}"

if [ -z "$BACKUP_TAG" ]; then
    echo "❌ Please specify a rollback version: ./rollback.sh <tag>"
    exit 1
fi

ssh ${SERVER} << EOF
    cd ${DEPLOY_DIR}
    export TAG=${BACKUP_TAG}
    docker-compose pull
    docker-compose up -d
    sleep 10
    docker-compose ps
EOF

Technical Analysis

The rollback tag is read directly from the first command-line argument and interpolated without validation or shell-safe quoting into a heredoc processed by a remote shell.

Because ${BACKUP_TAG} becomes part of the remote command text, shell metacharacters such as semicolons, command substitutions, redirections, and newlines can change the intended command structure. For example, a tag containing v1; id; # would result in the injected command being evaluated by the remote shell.

Quoting only the local variable assignment would not fully resolve the issue because the value is ultimately embedded in dynamically generated remote shell code. The value must be strictly validated and transmitted as data rather than executable syntax.

Attack Path

  1. An attacker gains control over, or convinces an operator to use, the rollback tag argument.
  2. The operator invokes the generated script with a malicious value, such as:
    bash
    ./rollback.sh 'v1; malicious_command; #'
  3. The value is inserted into the SSH heredoc:
    bash
    export TAG=v1; malicious_command; #
  4. SSH sends the generated command stream to the configured deployment server.
  5. The remote shell executes the injected command with the privileges of the deployment SSH account.

Impact Assessment

Successful e ...[truncated 536 chars]

Remediation
View remediation

Remediation Suggestions

  1. Validate image tags against a strict allowlist before any network operation:
    bash
    BACKUP_TAG=${1:-}

if ! [[ "$BACKUP_TAG" =~ ^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$ ]]; then
    printf 'Invalid rollback tag.\n' >&2
    exit 1
fi
  2. Validate fixed configuration values such as SERVER and DEPLOY_DIR separately.
  3. Do not interpolate untrusted data directly into a heredoc containing remote commands.
  4. Pass the tag as a safely quoted positional argument to a fixed remote script, or deploy through an API that treats the tag as structured data.
  5. If shell transport is unavoidable, use robust shell escaping such as printf '%q' after allowlist validation.
  6. Restrict the deployment account to the minimum commands and directories required for deployment.
  7. Avoid granting the account unrestricted sudo or general-purpose interactive shell access.
  8. Record and alert on rollback operations so unexpected tags and commands can be investigated.

T09 · Insecure Skill Coding Practices

Warning
Location
references/details.md:393
Finding

Unconditional System-Wide Docker Cleanup Exceeds Deployment Scope

Content
View full analysis

Vulnerability Details

File Location: references/details.md, lines 393-395
Vulnerability Type: Destructive operation with excessive scope
Risk Level: Medium

Vulnerable Code

bash
# Clean up locally
echo "==> Cleaning up..."
docker system prune -f

Technical Analysis

docker system prune -f performs noninteractive, Docker-daemon-wide cleanup. It is not limited to the application deployed by the script and may remove stopped containers, unused networks, dangling images, and build cache associated with unrelated projects.

The -f option suppresses confirmation, and the command runs unconditionally after deployment. Global cleanup is not necessary to build, push, or deploy the declared application and therefore exceeds the minimum privileges and scope required for the Skill's functionality.

Attack Path

  1. An operator executes the supplied deployment script on a workstation or shared build host.
  2. The script builds and pushes the application image and performs the remote deployment.
  3. The cleanup phase automatically invokes docker system prune -f.
  4. Docker removes eligible objects across the entire local Docker daemon, including resources owned by unrelated projects.
  5. Other builds or services lose cached layers, stopped diagnostic containers, unused networks, or dangling images needed for recovery.

No attacker-controlled input is required; the destructive behavior occurs during normal execution.

Impact Assessment

The operation can cause loss of unrelated Docker artifacts, slower subsequent builds, loss of stopped containers retained for troubleshooting, and disruption of workflows sharing the same Docker daemon.

The command does not directly remove running containers or named volumes in the form shown, but its global scope can still produce operational damage. Impact is greater on shared CI runners, developer workstations, and multi-project deployment hosts.

Remediation
View remediation

Remediation Suggestions

  1. Remove automatic global pruning from the deployment script.
  2. Make cleanup a separate, explicit, opt-in maintenance action.
  3. Require interactive confirmation or a dedicated flag before destructive cleanup.
  4. Delete only resources associated with the current application, preferably using Docker labels and an application-specific filter.
  5. Display a dry-run inventory of candidate resources before removal.
  6. Apply retention rules to build cache and images rather than pruning all eligible resources after every deployment.
  7. Run deployment jobs against isolated Docker daemons or dedicated CI runners where practical.

T08 · Insecure Dependencies

Warning
Location
SKILL.md:184
Finding

Mutable Base Image Tags Permit Unreviewed Dependency Changes

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 184, 193, 216-217; references/details.md, lines 7, 21, 46, 69, 89, and 108
Vulnerability Type: Mutable container dependencies and non-reproducible builds
Risk Level: Medium

Vulnerable Code

Representative mutable image references include:

dockerfile
FROM node:18-alpine AS deps
FROM node:18-alpine AS builder
FROM node:18-alpine AS runner
dockerfile
FROM nginx:alpine

Other affected references include:

dockerfile
FROM python:3.11-slim AS builder
FROM python:3.11-slim AS runner
FROM golang:1.21-alpine AS builder
FROM maven:3.9-eclipse-temurin-21 AS builder
FROM eclipse-temurin:21-jre-alpine

Technical Analysis

Container tags such as node:18-alpine, nginx:alpine, and python:3.11-slim are mutable. A later build can resolve the same textual tag to a different image manifest and different filesystem content.

This undermines reproducibility and allows dependency changes to enter production without a corresponding change to the Dockerfile or review of the new image. It also conflicts with the Skill's own requirement to lock base-image versions.

No malicious upstream image is confirmed in the audited files. The finding is that the dependency-resolution mechanism permits silent upstream changes and expands supply-chain risk.

Attack Path

  1. A Dockerfile generated from the supplied template references a mutable base-image tag.
  2. The upstream publisher updates that tag, or the associated registry namespace is compromised.
  3. A later CI or developer build pulls the changed manifest under the unchanged tag.
  4. The new image content is incorporated into the application image without a source-level Dockerfile change.
  5. The resulting image is pushed and deployed through the documented deployment workflow.

Impact Assessment

The primary effects are non-reproducible builds, unexpected runtime ...[truncated 398 chars]

Remediation
View remediation

Remediation Suggestions

  1. Pin every production base image to an immutable digest:
    dockerfile
    FROM node:18.20.4-alpine3.20@sha256:<reviewed-digest>
  2. Use exact supported version tags in addition to digests to preserve readability.
  3. Apply the same pinning policy to every build and runtime stage.
  4. Update digests through a controlled dependency-update process that includes review, vulnerability scanning, testing, and approval.
  5. Generate and retain an SBOM and image provenance attestations for released images.
  6. Verify signatures where publishers support signed images.
  7. Configure CI to fail when production Dockerfiles contain unapproved mutable tags such as latest, alpine, or broad major-version tags without digests.
  8. Periodically rebuild with reviewed security updates rather than relying on silent movement of mutable tags.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (10)

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 · SKILL.md (reported line 212)May include surrounding context.

md
- REDIS_HOST=redis
      - REDIS_PORT=6379
    env_file:
      - .env
    depends_on:
      postgres:
        condition: service_healthy

Credential Access

High
Category
Privilege Escalation
Confidence
97% confidence
Finding

The .env example includes plaintext secrets for database, Redis, JWT, and SMTP credentials, which encourages storing sensitive values in an insecure local file format that is commonly leaked through backups, logs, screenshots, shell history, or accidental commits. In a Docker deployment skill, this is more dangerous because users are likely to copy the template directly into production-like environments.

Content

Scanner excerpt · references/details.md (reported line 254)May include surrounding context.

cpus: '1.0'

text

### 2.3 .env 文件配置
```bash
# .env（不要提交到git！）
# 应用配置

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The skill explicitly supports server deployment, compose orchestration, persistent volumes, CI/CD, and operational actions, but it does not prominently warn that these actions can affect running services, network exposure, and stored data. In practice, users may apply generated commands or configs to production systems without understanding rollback, backup, or downtime implications.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The trigger conditions are broad enough to match many ordinary conversations about Docker, containers, deployment, and troubleshooting. In an agent setting, this can cause unintended invocation of a skill that generates deployment instructions or configuration changes, increasing the chance of unsafe automation or user confusion in sensitive infrastructure contexts.

Content

No source excerpt is available for this finding.

Internal Network Request

Medium
Category
Server-Side Request Forgery
Confidence
70% confidence
Finding

Code issues a request to a loopback, link-local, or private-range host. This can reach internal services not meant to be exposed and is a common SSRF pivot.

Content

Scanner excerpt · references/details.md (reported line 55)May include surrounding context.

chown -R pyuser:pygroup /app USER pyuser EXPOSE 5000 HEALTHCHECK --interval=30s --timeout=3s CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:5000/health')" || exit 1 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "4", "app:app"]

text

Unsafe Defaults

Medium
Category
Tool Misuse
Confidence
60% confidence
Finding

Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Content

Scanner excerpt · references/details.md (reported line 238)May include surrounding context.

md
ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
    command: npm run dev

# docker-compose.prod.yml（生产环境）

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
91% confidence
Finding

The deployment script runs docker system prune -f automatically after deployment without clearly warning that it removes unused Docker resources. In operational environments this can delete images, stopped containers, networks, and build cache needed for rollback, debugging, or co-located workloads, causing service disruption or data loss-like operational impact.

Content

No source excerpt is available for this finding.

Rp1

Medium
Category
MCP Rug Pull
Confidence
75% confidence
Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
98% confidence
Finding

The file explicitly sets the output language to Chinese only. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale restriction is clearly justified or optional.

Content

No source excerpt is available for this finding.

Tool Parameter Abuse

Low
Category
Tool Misuse
Confidence
15% confidence
Finding

Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Content

Scanner excerpt · references/details.md (reported line 449)May include surrounding context.

md
gzip > ${BACKUP_DIR}/db_${DATE}.sql.gz

# 备份数据卷
docker run --rm -v ${APP_NAME}_app-data:/data -v ${BACKUP_DIR}:/backup \
    alpine tar czf /backup/data_${DATE}.tar.gz -C /data .

# 清理旧备份

Static analysis

No suspicious patterns detected.