CVE-2026-129433: Critical Dokploy Command Injection — Detection and Remediation Guide | Security Arsenal

The National Vulnerability Database has published CVE-2026-129433, a critical-severity vulnerability affecting Dokploy — the open-source, self-hosted deployment platform that has seen rapid adoption as a PaaS alternative for teams running containerized workloads on their own infrastructure. With a CVSS v3 score of 9.9 (Critical) and a network-exploitable attack path, this is not a vulnerability that can sit in a queue.

Dokploy versions prior to 0.31.1 contain an OS command injection flaw in the getComposeContainerCommand() function. An authenticated organization member — a privilege level that in many Dokploy deployments is granted to developers, contractors, and CI service accounts — can inject shell metacharacters through the serviceName parameter via the backup.create or backup.update tRPC procedures. Because scheduled backups execute with root privileges and Dokploy hosts typically expose the Docker socket inside the management container, successful exploitation gives an attacker root on the underlying host and the ability to take over every container running on it.

If your organization uses Dokploy to manage Docker Swarm or Compose deployments — and especially if multiple users hold organization membership — treat this as an immediate patching event. The combination of low authentication requirements, root-level command execution, and Docker socket exposure creates a near-worst-case impact scenario.

Technical Analysis

Affected Product and Versions

Attribute	Detail
Product	Dokploy (self-hosted deployment platform)
Affected Versions	All versions before 0.31.1
Fixed Version	0.31.1 and later
CVE	CVE-2026-129433
CVSS v3 Score	9.9 / Critical
Attack Vector	Network
Privileges Required	Low (authenticated organization member)
User Interaction	None
Scope	Changed — compromise extends beyond the vulnerable component to the host OS

Root Cause: Command Injection in `getComposeContainerCommand()`

The vulnerability resides in Dokploy's backup subsystem. When an organization member creates or updates a backup configuration through the backup.create or backup.update tRPC procedures, the serviceName parameter is passed without adequate sanitization into the getComposeContainerCommand() function. That function builds a shell command string — likely something analogous to docker compose <serviceName> ... or a docker exec invocation — and executes it when the scheduled backup job runs.

Because the serviceName value is stored in Dokploy's database (PostgreSQL, by default) and later used to construct a command executed by a process running as root, this is a textbook stored OS command injection with deferred execution. The attacker does not need to be present when the command fires — they plant the payload and wait for the cron-triggered backup cycle to execute it.

Why the Docker Socket Makes This Worse

Dokploy's architecture mounts the Docker daemon socket (/var/run/docker.sock) into its management container. This is a common pattern in self-hosted PaaS tools — it is how Dokploy orchestrates deployments, manages networks, and inspects container state. However, it also means that any code execution inside the Dokploy container (or any process it spawns) has full, unmediated access to the Docker daemon. An attacker who achieves command execution can:

Create a privileged container with the host filesystem mounted
Read and write arbitrary files on the host, including /etc/shadow, SSH keys, and cloud credentials
Deploy cryptominers, web shells, or persistence mechanisms
Pivot laterally to other containers and networks managed by the same daemon

In practice, command injection in Dokploy is equivalent to host root.

Exploitation Chain Summary

Attacker authenticates to Dokploy as an organization member (legitimate credentials or compromised account).
Attacker sends a backup.create or backup.update tRPC request with a serviceName value containing shell metacharacters and an arbitrary command payload.
Dokploy stores the malicious serviceName in its database.
The scheduled backup job fires and calls getComposeContainerCommand(), which interpolates the tainted serviceName into a shell command.
The shell executes the injected command as root.
Attacker gains root-level access on the Dokploy container and, via the mounted Docker socket, full control of the host and all co-resident containers.

Exploitation Status

At the time of writing, there is no confirmed public proof-of-concept exploit and the vulnerability has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the vulnerability is straightforward to exploit once the injection point is understood, and the details are now publicly documented in the NVD entry. Given Dokploy's growing user base in the self-hosted DevOps community, defenders should assume that exploit development is imminent if not already underway in private circles.

Detection & Response

Sigma Rules

The following Sigma rules target the post-exploitation behaviors most likely to be observed after successful exploitation of CVE-2026-129433: Docker socket abuse from unexpected processes and shell command execution originating from Dokploy's backup subsystem.

YAML

---
title: Dokploy Backup Command Injection — Suspicious Shell Execution
description: Detects shell commands with injection metacharacters being executed by or spawned from Dokploy backup processes, indicating potential exploitation of CVE-2026-129433.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-129433
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'dokploy'
      - 'getComposeContainerCommand'
      - 'backup'
  selection_shell:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
  selection_payload:
    CommandLine|contains:
      - ';'
      - '&&'
      - '||'
      - '$('
      - '`'
      - 'curl '
      - 'wget '
      - 'nc -e'
      - 'bash -i'
      - '/dev/tcp/'
      - 'base64 -d'
  condition: selection_parent and selection_shell and selection_payload
falsepositives:
  - Legitimate Dokploy backup scripts using pipes or conditional logic
level: high
---
title: Docker Socket Access from Unexpected Process
description: Detects processes other than the Docker daemon or known container management tools accessing the Docker socket, which may indicate post-exploitation activity following CVE-2026-129433.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-129433
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.privilege_escalation
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - 'docker.sock'
      - '/var/run/docker'
  filter_known_tools:
    Image|endswith:
      - '/dockerd'
      - '/containerd'
      - '/docker'
      - '/docker-compose'
  condition: selection and not filter_known_tools
falsepositives:
  - Monitoring agents that query Docker API
  - CI/CD pipeline tools interacting with Docker daemon
level: high
---
title: Privileged Container Creation with Host Filesystem Mount
description: Detects creation of privileged Docker containers with host filesystem mounts, a common post-exploitation technique to escape container boundaries and achieve host persistence.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-129433
  - https://attack.mitre.org/techniques/T1610/
  - https://attack.mitre.org/techniques/T1611/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1611
  - attack.t1610
logsource:
  category: process_creation
  product: linux
detection:
  selection_run:
    CommandLine|contains:
      - 'docker run'
      - 'docker create'
  selection_privileged:
    CommandLine|contains:
      - '--privileged'
  selection_mount:
    CommandLine|contains:
      - '-v /:/'
      - '--mount type=bind,source=/'
      - '-v /etc:/'
      - '-v /root:/'
  condition: selection_run and selection_privileged and selection_mount
falsepositives:
  - Legitimate infrastructure tooling requiring host access (rare — investigate all hits)
level: critical

KQL — Microsoft Sentinel / Defender

This query hunts for process execution events consistent with Dokploy command injection and Docker socket abuse. It assumes you are ingesting Linux Syslog or using Defender for Endpoint on your Docker hosts.

KQL — Microsoft Sentinel / Defender

// Hunt for Dokploy backup command injection indicators and Docker socket abuse
// Time range: adjust as needed
let lookback = 7d;
union isfuzzy=true
    (DeviceProcessEvents
    | where TimeGenerated >= ago(lookback)
    | where ProcessCommandLine has_any ("docker.sock", "docker run", "docker exec")
    | where ProcessCommandLine has_any ("--privileged", "-v /:/", "curl", "wget", "nc ", "bash -i", "/dev/tcp/")
    | project TimeGenerated, DeviceName, ProcessCommandLine, FileName, InitiatingProcessCommandLine, InitiatingProcessFileName, AccountName, Source="DeviceProcessEvents"),
    (Syslog
    | where TimeGenerated >= ago(lookback)
    | where SyslogMessage has_any ("docker.sock", "--privileged", "getComposeContainerCommand", "backup.create", "backup.update")
    | where SyslogMessage has_any ("curl", "wget", "nc -e", "bash -i", "/dev/tcp/", "base64 -d")
    | project TimeGenerated, Computer, SyslogMessage, ProcessName, Source="Syslog")
| order by TimeGenerated desc

Velociraptor VQL

This VQL artifact hunts for evidence of post-exploitation on Dokploy hosts by enumerating running processes that reference the Docker socket or show signs of injected commands, alongside network connections from unexpected binaries.

VQL — Velociraptor

-- Hunt for Dokploy CVE-2026-129433 post-exploitation indicators
-- Targets: Docker socket abuse, suspicious processes, unexpected network connections

-- Part 1: Processes referencing Docker socket or containing injection artifacts
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(docker\\.sock|/var/run/docker|--privileged|-v /:/|curl |wget |nc -e|bash -i|/dev/tcp/)'
  AND Exe !~ '(dockerd|containerd|docker-compose)'

-- Part 2: Network connections from non-standard processes (potential C2 or reverse shell)
SELECT Pid, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State
FROM netstat()
WHERE Name !~ '(dockerd|containerd|sshd|systemd|node|postgres|redis)'
  AND State = 'ESTABLISHED'
  AND RemoteAddr !~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.|127\\.)'

Remediation Script

Use this Bash script to check your current Dokploy version, apply the patch, and perform basic hardening verification.

Bash / Shell

#!/bin/bash
# CVE-2026-129433 — Dokploy Command Injection Remediation Script
# Run as root or with sudo on the Dokploy host

set -euo pipefail

echo "==================================================="
echo " CVE-2026-129433 — Dokploy Remediation Script"
echo "==================================================="

# Step 1: Check current Dokploy version
echo ""
echo "[1] Checking current Dokploy version..."
DOKPLOY_CONTAINER=$(docker ps --filter "name=dokploy" --format "{{.Names}}" 2>/dev/null | head -1)

if [ -z "$DOKPLOY_CONTAINER" ]; then
    echo "    [!] No running Dokploy container found."
    echo "    [!] If Dokploy is installed but not running, check: docker ps -a"
    echo "    [!] Manual verification required."
else
    CURRENT_VERSION=$(docker exec "$DOKPLOY_CONTAINER" node -e "console.log(require('/app/package.json').version)" 2>/dev/null || echo "unknown")
    echo "    Current Dokploy version: $CURRENT_VERSION"

    # Compare versions
    if [ "$CURRENT_VERSION" != "unknown" ]; then
        VULNERABLE=$(printf '%s\n' "0.31.1" "$CURRENT_VERSION" | sort -V | head -1)
        if [ "$VULNERABLE" != "0.31.1" ] && [ "$CURRENT_VERSION" != "0.31.1" ]; then
            echo "    [VULNERABLE] Version $CURRENT_VERSION is below 0.31.1 — PATCH REQUIRED"
        else
            echo "    [OK] Version $CURRENT_VERSION is 0.31.1 or later — patched"
        fi
    fi
fi

# Step 2: Update Dokploy
echo ""
echo "[2] Updating Dokploy to latest version..."
echo "    Pulling latest Dokploy image..."
docker pull dokploy/dokploy:latest

echo "    Restarting Dokploy container with updated image..."
if [ -n "$DOKPLOY_CONTAINER" ]; then
    DOKPLOY_IMAGE=$(docker inspect "$DOKPLOY_CONTAINER" --format '{{.Config.Image}}')
    DOKPLOY_NETWORK=$(docker inspect "$DOKPLOY_CONTAINER" --format '{{range $k,$v := .NetworkSettings.Networks}}{{$k}}{{end}}')

    docker stop "$DOKPLOY_CONTAINER"
    docker rm "$DOKPLOY_CONTAINER"

    docker run -d \
        --name "$DOKPLOY_CONTAINER" \
        --network "$DOKPLOY_NETWORK" \
        -v /var/run/docker.sock:/var/run/docker.sock \
        -v /etc/dokploy:/etc/dokploy \
        --restart unless-stopped \
        dokploy/dokploy:latest

    echo "    [OK] Dokploy container restarted with latest image"
else
    echo "    [SKIP] No Dokploy container to update — deploy manually if needed"
fi

# Step 3: Verify update
echo ""
echo "[3] Verifying update..."
sleep 5
NEW_CONTAINER=$(docker ps --filter "name=dokploy" --format "{{.Names}}" 2>/dev/null | head -1)
if [ -n "$NEW_CONTAINER" ]; then
    NEW_VERSION=$(docker exec "$NEW_CONTAINER" node -e "console.log(require('/app/package.json').version)" 2>/dev/null || echo "unknown")
    echo "    New Dokploy version: $NEW_VERSION"
else
    echo "    [!] Could not verify — check container status: docker ps"
fi

# Step 4: Audit for suspicious serviceName entries
echo ""
echo "[4] Auditing backup configurations for injection indicators..."
echo "    Checking Dokploy database for suspicious serviceName values..."

# Attempt to query the Dokploy database for suspicious backup entries
DB_CONTAINER=$(docker ps --filter "name=dokploy-postgres" --format "{{.Names}}" 2>/dev/null | head -1)
if [ -n "$DB_CONTAINER" ]; then
    SUSPICIOUS=$(docker exec "$DB_CONTAINER" psql -U dokploy -d dokploy -t -c \
        "SELECT id, \\"serviceName\\" FROM backup WHERE \\"serviceName\\" ~ '[;|&\`\\$()]' OR \\"serviceName\\" ~ '(curl|wget|nc |bash|sh |/dev/tcp)'" 2>/dev/null || echo "")

    if [ -n "$SUSPICIOUS" ]; then
        echo "    [ALERT] Suspicious serviceName values found in backup configurations:"
        echo "$SUSPICIOUS"
        echo ""
        echo "    ACTION REQUIRED: Review and remove these entries immediately."
        echo "    Investigate any commands that may have already executed."
    else
        echo "    [OK] No suspicious serviceName values detected in backup table"
    fi
else
    echo "    [SKIP] Could not locate Dokploy PostgreSQL container"
    echo "    Manually review backup configurations in the Dokploy UI"
fi

# Step 5: Hardening recommendations
echo ""
echo "[5] Hardening recommendations:"
echo "    - Restrict Dokploy organization membership to trusted users only"
echo "    - Enable audit logging for all tRPC procedure calls"
echo "    - Consider network-segmenting the Dokploy management interface"
echo "    - Review all existing backup configurations for tampering"
echo "    - Monitor Docker socket access from unexpected processes"
echo "    - Rotate credentials for all Dokploy organization members"

echo ""
echo "==================================================="
echo " Remediation script complete."
echo "==================================================="

Remediation

Immediate Actions (Within 24 Hours)

Upgrade Dokploy to version 0.31.1 or later. This is the only complete fix. Pull the latest image and redeploy your Dokploy instance using the commands in the script above or the official upgrade procedure.
Audit all backup configurations. Review every backup entry in Dokploy for serviceName values containing shell metacharacters (;, |, &&, `, $(, etc.). Remove any that do not correspond to legitimate service names.
Audit organization membership. Review every user with organization member privileges. Remove inactive accounts, verify contractor access is still warranted, and enforce MFA if your Dokploy instance is exposed beyond localhost.
Check for signs of prior exploitation. Review process execution logs, shell histories, and Docker event logs for evidence of unexpected container creation, network connections from the Dokploy container, or modified files on the host.

Short-Term Hardening (Within 1 Week)

Restrict network access to the Dokploy management interface. Dokploy should not be directly accessible from the internet. Place it behind a VPN, a reverse proxy with IP allowlisting, or a zero-trust access gateway.
Rotate credentials. If there is any possibility that an organization member account was compromised or misused, rotate passwords, API tokens, and SSH keys for all users and any service accounts Dokploy uses.
Review Docker socket exposure. Evaluate whether Dokploy's Docker socket mount can be scoped down. Some deployments support Docker socket proxies (e.g., tecnativa/docker-socket-proxy) that expose only the API endpoints Dokploy actually needs, reducing the blast radius of any future code execution.

Longer-Term (Within 30 Days)

Implement container runtime monitoring. Deploy Falco, Tetragon, or an equivalent eBPF-based runtime security tool on Dokploy hosts to detect anomalous process execution, file access, and network connections from containers in real time.
Establish a patch SLA for self-hosted PaaS tooling. Dokploy is infrastructure software — it deserves the same patching rigor as your CI/CD pipeline, your hypervisors, and your identity provider. Define and enforce a maximum time-to-patch for critical vulnerabilities in deployment tooling.
Review the principle of least privilege for organization roles. If Dokploy's RBAC model allows it, restrict the ability to create and modify backup configurations to a smaller set of trusted administrators rather than all organization members.

Conclusion

CVE-2026-129433 is a high-impact, low-complexity vulnerability in a platform that is increasingly used to manage production container infrastructure. The combination of authenticated command injection, root-level execution, and Docker socket access creates a path from a low-privilege user account to full host compromise in a single request.

The fix is available. Patch now, audit your backup configurations and user accounts, and implement the detection controls above to catch any exploitation attempts that may already have occurred or that target you before you can complete the upgrade.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

CVE-2026-129433: Critical Dokploy Command Injection — Detection and Remediation Guide

Technical Analysis

Affected Product and Versions

Root Cause: Command Injection in getComposeContainerCommand()

Why the Docker Socket Makes This Worse

Exploitation Chain Summary

Exploitation Status

Detection & Response

Sigma Rules

KQL — Microsoft Sentinel / Defender

Velociraptor VQL

Remediation Script

Remediation

Immediate Actions (Within 24 Hours)

Short-Term Hardening (Within 1 Week)

Longer-Term (Within 30 Days)

Conclusion

Related Resources

Is your security operations ready?

Root Cause: Command Injection in `getComposeContainerCommand()`