Security audit
Security checks for vulnerabilities and agentic risk
This skill is a coherent VPS self-hosting guide, but it asks for privileged access and includes several unsafe default deployment patterns that warrant careful review before use.
Install only if you are comfortable reviewing and tightening the generated deployment steps. Do not paste SSH passwords or private keys into chat; use a temporary least-privileged deployment account or out-of-band secret handling. Before running commands, remove unnecessary Docker socket mounts, bind admin interfaces to localhost or VPN, pin images and installers, validate all domain/app/path values, and approve any cron job explicitly.
SKILL.md:974Unverified Remote Installer Executes with Administrative Privileges
SKILL.md:1242Privileged Persistent Backup Task Is Installed Without Adequate Hardening
SKILL.md:1148Unvalidated Deployment Values Are Interpolated into Privileged Shell Commands
SKILL.md:324Docker Socket Mounts Grant Containers Host-Equivalent Administrative Access
SKILL.md:850Mutable and Unverified Third-Party Dependencies Create Supply-Chain Exposure
SKILL.md:1033Nginx Proxy Manager Administration Port Is Publicly Bound with Known Default Credentials
The skill explicitly instructs the agent to request highly sensitive SSH credentials as part of normal operation. In this context, that is especially dangerous because the same skill also performs root-level administrative actions, so exposed credentials could immediately enable full VPS compromise.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cd /opt/supabase/docker
cp .env.example .env
**Critical `.env` changes:**
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cd /opt/supabase/docker
cp .env.example .env
**Critical `.env` changes:**
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cd /opt/supabase/docker
cp .env.example .env
**Critical `.env` changes:**
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cd /opt/supabase/docker
cp .env.example .env
**Critical `.env` changes:**
Mounting /var/run/docker.sock into Uptime Kuma gives the container direct access to the Docker daemon, which can enable effective host control or sensitive metadata exposure. Even if presented as optional monitoring, including it in the default template makes a high-risk privilege escalation path easy to adopt unintentionally.
- "127.0.0.1:3001:3001"
volumes:
- uptime-kuma-data:/app/data
- /var/run/docker.sock:/var/run/docker.sock:ro
healthcheck:
test: ["CMD-SHELL", "extra/healthcheck"]
interval: 30s
The skill instructs users to fetch and execute a remote install script for Coolify via curl piped directly to bash. This pattern bypasses review and integrity controls; if the remote script, transport, or supply chain is compromised, it can execute arbitrary code on the VPS with full privileges.
external: true
**Health check:** `curl -f http://localhost:8000/api/`
---
Using '| bash' to immediately execute fetched content is a classic dangerous command-chaining pattern that can turn a network or supply-chain compromise into instant remote code execution. In this skill, the risk is amplified because the workflow is explicitly about making administrative host changes.
Gotchas: Coolify manages its own Docker setup. Use the official install script instead of manual compose.
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
Coolify will be available at http://<VPS_IP>:8000. It handles its own reverse proxy, SSL, and database deployment.
The Portainer and Dockge templates mount /var/run/docker.sock, which effectively grants root-equivalent control over the Docker daemon and, by extension, the host. Any compromise of those applications, misconfiguration, or unsafe agent action could lead to container creation, filesystem mounts, secret extraction, or full host takeover.
Portainer with direct Docker socket access has near-total control over the host container environment, including creating privileged containers and mounting host filesystems. In a skill that auto-generates deployment steps, this represents a severe capability expansion and host-compromise risk.
ports:
- "127.0.0.1:9443:9443"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- portainer-data:/data
healthcheck:
test: ["CMD-SHELL", "curl -fk https://localhost:9443/api/system/status || exit 1"]
Dockge is also granted direct Docker socket access, which allows stack and container management with root-equivalent host impact. A compromise of the app or misuse of the generated deployment could therefore lead to full control of the VPS.
ports:
- "127.0.0.1:5001:5001"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- dockge-data:/app/data
- /opt/stacks:/opt/stacks
environment:
The trigger phrases are broad and include generic language like 'self-host' and 'deploy X', which can cause the skill to activate for common requests not specifically intended for this powerful deployment workflow. In a skill that requests credentials and performs host changes, overbroad activation materially increases the chance of unsafe or unintended use.
The usage guidance says to use the skill when users say generic phrases such as 'deploy X' or 'host my own X', which is ambiguous and can overlap with unrelated deployment needs. Because the skill later asks for privileged access and prescribes impactful system changes, accidental routing into this workflow becomes security-relevant.
The catalog includes infrastructure-management tools such as Nginx Proxy Manager, Portainer, and Dockge that provide broad control over networking, containers, and stack lifecycle beyond narrowly deploying a single self-hosted application. In this skill context, that expanded scope increases blast radius if the skill is auto-invoked or misused, because the agent may steer users toward tools that expose host-level operational control.
The skill requests root or sudo-level access to the VPS, enabling powerful system modification. While administrative access is often needed for deployment, asking for it directly in an agent skill without strong controls magnifies the consequences of agent error, compromise, or credential leakage.
Ask the user for:
1. **VPS IP address** and **SSH credentials** (root or sudo user)
2. **Domain/subdomain** for the app (e.g., `analytics.example.com`)
3. **Email address** for SSL certificate registration (Certbot)
4. Any **app-specific settings** (see gotchas per app below)
The skill instructs the agent to ask for SSH credentials directly, but provides no privacy warning, secure handling guidance, or safer alternative. Requesting root or sudo credentials in plain conversational flow creates a high risk of secret exposure, storage in logs, or misuse by an over-privileged agent.
The Uptime Kuma template mounts the Docker socket for optional monitoring, giving the container privileged visibility into host containers that is not necessary for basic uptime checks. Even read-only socket access can reveal sensitive metadata and may still enable meaningful abuse depending on daemon behavior and surrounding tooling.
The Paperless-ngx template forces PAPERLESS_OCR_LANGUAGE: eng, and the skill does not ask the user to choose OCR language or justify why English is required. This is a natural-language locale policy issue because it imposes a language setting by default without opt-in.
The Stirling PDF template sets LANGS=en_US, which hard-codes a specific language/locale without asking the user which language they want. This violates the policy against forcing a language choice when no opt-in is provided.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
external: true
**Health check:** `curl -fk https://localhost:9443/api/system/status`
---
These sections direct significant host modifications including package installation, Nginx reconfiguration, certificate issuance, file writes under /etc and /opt, Docker deployment, and cron persistence, but there is no up-front warning about the operational and security impact. In a deployment skill, omitting a clear warning makes it easier for users to authorize destructive or persistent changes without informed consent.
The backup setup installs a recurring cron job, creating persistent scheduled execution on the host. Persistence is not inherently malicious in an admin workflow, but doing it automatically without explicit consent or visibility increases operational and security risk if the script is later modified or mishandled.
chmod +x /opt/backups/backup-${APP_NAME}.sh
(crontab -l 2>/dev/null; echo "0 3 * * * /opt/backups/backup-${APP_NAME}.sh >> /var/log/backup-${APP_NAME}.log 2>&1") | crontab -
---
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
- [ ] Default passwords changed
- [ ] Signups disabled (if applicable — Vaultwarden, Gitea)
- [ ] Email/SMTP configured (if applicable — Ghost, n8n)
- [ ] Backup cron is running (`crontab -l`)
- [ ] Firewall only exposes ports 80, 443, and SSH (`ufw status`)
- [ ] Docker auto-updates considered (Watchtower or manual update schedule)
- [ ] Monitoring set up (deploy Uptime Kuma if not already running)
The n8n template defaults GENERIC_TIMEZONE to America/New_York, which imposes a locale-specific setting if the user does not override it. The skill does not ask for timezone preference before applying this US-centric default.
The Paperless-ngx template defaults PAPERLESS_TIME_ZONE to America/New_York, which applies a specific locale absent user selection. No user-choice step in the skill collects timezone preference before using this default.
No suspicious patterns detected.