Back to skill

Security audit

Dokploy

Security checks for vulnerabilities and agentic risk

Overview

This Dokploy management skill is mostly purpose-aligned, but it handles API keys and application secrets unsafely enough that users should review it before installing.

Install only if you are comfortable reviewing or patching the shell scripts first. Prefer environment variables or a real secret store over dokploy-config, use HTTPS for remote Dokploy servers, avoid running config show or env list in shared logs/transcripts, and rotate any API key that may have been printed or stored in a readable ~/.dokployrc file.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (5)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/dokploy-config.sh:31
Finding
Shell Command Injection Through Executable Configuration File Generation## Vulnerability Details **File Location**: `scripts/dokploy-config.sh:31-38` **Vulnerability Type**: Persistent shell command injection **Risk Level**: High ### Vulnerable Code ```bash # Save to config file mkdir -p "$(dirname "$CONFIG_FILE")" cat > "$CONFIG_FILE" << EOF export DOKPLOY_API_URL="${DOKPLOY_API_URL}" export DOKPLOY_API_KEY="${DOKPLOY_API_KEY}" EOF log_success "Config saved to $CONFIG_FILE" log_info "Run: source $CONFIG_FILE to load" ``` ### Technical Analysis User-controlled values supplied through `--url` and `--key` are inserted directly into an executable shell file. The values are not escaped or validated for quotation marks, newlines, command substitutions, or other shell syntax. Expansion while generating the file does not safely encode the resulting value. An input containing a closing quotation mark and a newline can terminate the intended `export` statement and add arbitrary shell commands. The script then explicitly directs the user to execute the generated file with `source`. For example, a malicious URL value can cause the generated file to contain: ```bash export DOKPLOY_API_URL="https://example.invalid" attacker_command #" ``` This is persistent until `~/.dokployrc` is replaced and executes in the context of every shell that subsequently sources the file. ### Attack Path 1. An attacker supplies or recommends a crafted `--url` or `--key` value containing quotation marks, a newline, and a shell command. 2. The user or Agent runs `dokploy-config set` with that value. 3. The script writes the attacker-controlled shell syntax to `~/.dokployrc`. 4. The user follows the displayed instruction and runs `source ~/.dokployrc`, or sources it later from another shell initialization workflow. 5. The injected command executes with the privileges of that user. ### Impact Assessment Successful exploitation permits arbitrary command execution under the account running the Skil ...[truncated 331 chars]
Remediation
## Remediation Suggestions - Do not store configuration in an executable shell file. - Use a non-executable data format such as JSON and parse it with `jq`. - Validate the API URL with an explicit scheme and host policy. - Reject carriage returns, newlines, null bytes, and other control characters in configuration values. - If shell-format output is unavoidable, encode values with a shell-safe mechanism such as `printf '%q'` and test round-trip behavior. - Remove instructions that encourage sourcing attacker-influenced files. - Replace existing configuration files atomically after validating all inputs.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/dokploy-config.sh:31
Finding
Dokploy API Key Stored Without Enforced Restrictive Permissions## Vulnerability Details **File Location**: `scripts/dokploy-config.sh:3,31-36` **Vulnerability Type**: Plaintext credential storage with unsafe default permissions **Risk Level**: Medium ### Vulnerable Code ```bash CONFIG_FILE="$HOME/.dokployrc" ``` ```bash # Save to config file mkdir -p "$(dirname "$CONFIG_FILE")" cat > "$CONFIG_FILE" << EOF export DOKPLOY_API_URL="${DOKPLOY_API_URL}" export DOKPLOY_API_KEY="${DOKPLOY_API_KEY}" EOF ``` ### Technical Analysis The Dokploy API key is written in plaintext to `~/.dokployrc`. The script does not set a restrictive `umask`, create the file with mode `0600`, or correct the permissions of a pre-existing file. Consequently, the final permissions depend on the process umask or the existing file mode. In environments with a permissive umask, shared home directory, backup collection, or an already world-readable file, other local principals may read the credential. ### Attack Path 1. The user runs `dokploy-config set --url ... --key ...`. 2. The API key is stored verbatim in `~/.dokployrc`. 3. The file is created or retained with permissions that allow another local account or service to read it. 4. That principal extracts `DOKPLOY_API_KEY`. 5. The stolen key is used against the configured Dokploy API within the permissions granted to that token. ### Impact Assessment Exposure grants the attacker the same Dokploy API privileges as the compromised key. Depending on token permissions, this may include reading deployment data and environment secrets, creating or modifying applications and domains, triggering deployments, or deleting projects and applications. The exact server-side scope is bounded by the permissions of the stolen API key.
Remediation
## Remediation Suggestions - Set `umask 077` before creating credential-bearing files. - Create a temporary file with mode `0600`, write the validated configuration, and atomically rename it into place. - Explicitly run `chmod 600 "$CONFIG_FILE"` to correct pre-existing permissive modes. - Prefer an operating-system credential store or secret manager instead of plaintext files. - Never place the API key in shell initialization files, process arguments, diagnostic output, or general-purpose logs. - Document key rotation procedures for users whose configuration file may have been exposed.

T09 · Insecure Skill Coding Practices

Error
Location
scripts/dokploy-config.sh:41
Finding
Configuration Display Command Reveals the Complete API Key## Vulnerability Details **File Location**: `scripts/dokploy-config.sh:41-43` **Vulnerability Type**: Sensitive information disclosure **Risk Level**: High ### Vulnerable Code ```bash show) echo "Dokploy Configuration:" echo " API URL: ${DOKPLOY_API_URL:-not set}" echo " API Key: ${DOKPLOY_API_KEY:+***set***} ${DOKPLOY_API_KEY:-not set}" ``` ### Technical Analysis The first API-key expansion displays `***set***` when a key exists, but the second expansion immediately prints the complete value because `${DOKPLOY_API_KEY:-not set}` expands to the API key whenever it is non-empty. Therefore, the output is effectively: ```text API Key: ***set*** actual-secret-value ``` This defeats the apparent masking and exposes the credential to the terminal, command-capture systems, CI logs, Agent transcripts, screen sharing, and any process collecting standard output. ### Attack Path 1. A valid `DOKPLOY_API_KEY` is present in the environment. 2. The user, Agent, support workflow, or CI job runs `dokploy-config show`. 3. The complete key is written to standard output. 4. An attacker obtains the terminal history, transcript, CI artifact, screen capture, or centralized log. 5. The attacker reuses the key against the Dokploy API. ### Impact Assessment The exposed key provides the attacker with all privileges assigned to that API token. Potential effects include deployment modification, application or domain deletion, access to application metadata and environment values, and execution of deployment operations. No privilege beyond the server-side token scope is obtained automatically.
Remediation
## Remediation Suggestions Replace the vulnerable line with output that never expands the secret: ```bash if [ -n "${DOKPLOY_API_KEY:-}" ]; then echo " API Key: ***set***" else echo " API Key: not set" fi ``` Also: - Add tests asserting that the configured key never appears in command output. - Avoid partial key display unless explicitly required. - Treat existing logs and transcripts containing this output as compromised. - Rotate any API key that may already have been displayed or captured.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/dokploy.sh:39
Finding
API Credentials Can Be Transmitted Over Unencrypted HTTP## Vulnerability Details **File Location**: `scripts/dokploy.sh:7,39-60` **Vulnerability Type**: Cleartext transmission of authentication credentials **Risk Level**: Medium ### Vulnerable Code ```bash DOKPLOY_API_URL="${DOKPLOY_API_URL:-http://localhost:3000}" ``` ```bash api_request() { local method="$1" local endpoint="$2" local data="$3" local url="${DOKPLOY_API_URL}/api${endpoint}" # Silent mode - don't log when DOKPLOY_SILENT is set if [ -z "$DOKPLOY_SILENT" ]; then log_info "API: ${method} ${url}" fi if [ -z "$DOKPLOY_API_KEY" ]; then log_error "DOKPLOY_API_KEY not set. Run: export DOKPLOY_API_KEY='your-key'" exit 1 fi if [ -n "$data" ]; then curl -s -X "${method}" "${url}" \ -H "accept: application/json" \ -H "x-api-key: ${DOKPLOY_API_KEY}" \ -H "Content-Type: application/json" \ -d "${data}" else curl -s -X "${method}" "${url}" \ -H "accept: application/json" \ -H "x-api-key: ${DOKPLOY_API_KEY}" fi } ``` ### Technical Analysis Sending the API key to the configured Dokploy server is necessary for the Skill's declared functionality and is not evidence of hidden exfiltration. However, the script accepts arbitrary HTTP URLs and sends the key in the `x-api-key` header without requiring transport encryption. The localhost HTTP default is reasonable for a service bound exclusively to loopback, but the implementation does not restrict HTTP usage to loopback addresses. If a user configures a remote `http://` endpoint, network observers or a man-in-the-middle attacker can read and reuse the API key and inspect or modify request and response data. ### Attack Path 1. The user configures a remote `DOKPLOY_API_URL` using `http://`, whether through mistake, misleading instructions, or a downgraded endpoint. 2. The Skill in ...[truncated 702 chars]
Remediation
## Remediation Suggestions - Require `https://` for all non-loopback destinations. - Permit plaintext HTTP only for explicitly recognized loopback hosts such as `localhost`, `127.0.0.1`, and `::1`. - Reject unsupported URL schemes and malformed URLs before invoking `curl`. - Do not disable certificate verification. - Consider certificate or public-key pinning for high-trust automated deployment environments. - Emit a blocking error rather than a warning when a remote HTTP endpoint is configured.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/dokploy-app.sh:258
Finding
Environment Variable Listing Prints Application Secrets in Plaintext## Vulnerability Details **File Location**: `scripts/dokploy-app.sh:258-267` **Vulnerability Type**: Sensitive environment-variable disclosure **Risk Level**: Medium ### Vulnerable Code ```bash list) if [ -z "$2" ]; then log_error "Usage: dokploy app env list <application-id>" exit 1 fi log_info "Fetching environment variables for $2..." local response=$(api_request "GET" "/application.byId?applicationId=$2") echo "$response" | jq -r '.env | to_entries[] | "\(.key)=\(.value)"' 2>/dev/null || log_error "Failed to fetch env vars" ;; ``` ### Technical Analysis Environment-variable management is explicitly declared in `SKILL.md`, and the request is sent only to the configured Dokploy API. The behavior is therefore necessary in general and is not undeclared network exfiltration. Nevertheless, the listing command prints every environment-variable value in plaintext by default. Application environments commonly contain database passwords, private tokens, signing keys, and cloud credentials. These values can enter Agent transcripts, terminal capture, CI logs, shell-session recording, or support output. ### Attack Path 1. An application contains sensitive values in its Dokploy environment. 2. A user or automated Agent runs `dokploy app env list APPLICATION_ID`. 3. The API returns the environment object. 4. The command writes each secret as `KEY=VALUE` to standard output. 5. Another party obtains the transcript, log, screen output, or redirected command output and reuses the exposed credentials. ### Impact Assessment Impact depends on the disclosed environment values. Exposure may grant access to databases, cloud accounts, third-party APIs, signing systems, or other production services. The Dokploy request itself stays within the declared feature scope, but plaintext output unnecessarily broadens secret exposure beyond the API operation.
Remediation
## Remediation Suggestions - Redact values by default and print only variable names or fixed masks. - Add an explicit option such as `--show-values` for intentional secret retrieval. - Require interactive confirmation before revealing values when a terminal is attached. - Warn users that revealed values must not be copied into logs or Agent transcripts. - Offer structured secret-safe output that omits values entirely. - Ensure error handling never prints the complete API response when it may contain environment secrets.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (12)

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The description says the skill manages Dokploy resources via API, but the documented behavior also includes storing API credentials in persistent local configuration and handling local environment setup. That mismatch can mislead users and security policy engines about the true data-handling behavior, increasing the chance that sensitive tokens are written to disk or exposed without informed consent.

Credential Access

High
Category
Privilege Escalation
Content
fi
                log_info "Fetching environment variables for $2..."
                local response=$(api_request "GET" "/application.byId?applicationId=$2")
                echo "$response" | jq -r '.env | to_entries[] | "\(.key)=\(.value)"' 2>/dev/null || log_error "Failed to fetch env vars"
                ;;
            set)
                shift
Confidence
95% confidence
Finding
The code retrieves .env data from the application object and prints each key/value pair verbatim. Because environment stores frequently hold credentials and tokens, this behavior directly enables credential access and exfiltration through terminal output, automation logs, or upstream agent responses.

Credential Access

High
Category
Privilege Escalation
Content
# Get current env, update, and save
                local response=$(api_request "GET" "/application.byId?applicationId=$appId")
                local currentEnv=$(echo "$response" | jq -r '.env // {}')
                local newEnv=$(echo "$currentEnv" | jq --arg key "$key" --arg value "$value" '. + {($key): $value}')

                local data=$(jq -n --argjson env "$newEnv" '{env: $env}')
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
# Get current env, update, and save
                local response=$(api_request "GET" "/application.byId?applicationId=$appId")
                local currentEnv=$(echo "$response" | jq -r '.env // {}')
                local newEnv=$(echo "$currentEnv" | jq --arg key "$key" --arg value "$value" '. + {($key): $value}')

                local data=$(jq -n --argjson env "$newEnv" '{env: $env}')
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Lp3

Medium
Category
MCP Least Privilege
Confidence
88% confidence
Finding
The skill advertises shell-based commands and required binaries but does not declare any explicit tool scope or allowed-tools boundary. In an agent setting, this weakens least-privilege controls and can allow broader shell execution than users or policy expect, especially when the skill manages infrastructure and credentials.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The skill documents destructive operations such as project or application deletion without any warning, confirmation guidance, or emphasis on irreversibility. In an agent-driven workflow, this raises the risk of accidental destructive actions against live infrastructure from ambiguous or misinterpreted user prompts.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The env list command prints all application environment variables directly to stdout with no masking, redaction, or confirmation. In a deployment-management skill, environment variables commonly contain API keys, passwords, tokens, and other secrets, so this creates a straightforward secret disclosure path to any caller or log sink consuming the output.

Missing User Warnings

Medium
Confidence
84% confidence
Finding
This code retrieves and updates application environment variables, which commonly contain secrets, and sends them over API calls without any explicit disclosure about handling sensitive configuration. The informational log mentions the key being set, but it does not warn the user about the sensitivity or impact of modifying application secrets.

Missing User Warnings

Medium
Confidence
83% confidence
Finding
The delete flow fetches the current environment, removes a key, and PATCHes the updated configuration back to the API, which can break deployments or remove secrets. While the script logs the action, it does not provide any warning or confirmation despite the potentially disruptive effect on application behavior.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The script persists the Dokploy API key in a shell config file under the user's home directory in plaintext, with no permission hardening or warning to the user. If the file is readable by other local users, included in backups, exposed through dotfile syncing, or accidentally shared, the API key can be recovered and used to access or modify Dokploy-managed resources.

External Transmission

Medium
Category
Data Exfiltration
Content
fi

    if [ -n "$data" ]; then
        curl -s -X "${method}" "${url}" \
            -H "accept: application/json" \
            -H "x-api-key: ${DOKPLOY_API_KEY}" \
            -H "Content-Type: application/json" \
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Low
Confidence
82% confidence
Finding
The skill instructs users to export and configure an API key but does not warn about credential sensitivity, shell history exposure, process leakage, or risks of storing secrets in local config. This can lead to inadvertent disclosure of Dokploy API credentials that grant deployment-management access.

Static analysis

No suspicious patterns detected.