CVE-2026-72872 is a command injection vulnerability in Dokploy's Bitbucket provider integration, but framing it as a simple bug misses the point. The real issue is that Dokploy's permission model assumes a trust boundary between "service deployment" and "host OS" that the implementation never actually enforces. A user with deployment permission can execute arbitrary commands on the host because the provider configuration flow interpolates user-controlled values directly into shell execution calls—likely a pattern of storing values and later passing them to exec() without proper escaping or parameterized interfaces.
The CVSS 9.9 is technically accurate but contextually misleading. It scores this as if 'service deployment permission' represents a low-privilege entry point, but that's precisely the permission Dokploy users are meant to have. The vulnerability isn't that someone got a permission they shouldn't have—it's that having that permission already equates to host compromise. For organizations using Dokploy in multi-tenant or semi-trusted scenarios, this means any member with deployment rights effectively has equivalent access to the Dokploy control plane and every other service on the same host.
The critical uncertainty is what version 0.29.13 actually changed. The code path lives in the Bitbucket provider integration specifically, suggesting the team may have reached for shell command execution (git CLI) rather than using parameterized git library calls—an understandable choice given inconsistent provider SDKs, but one that creates this vulnerability class. If the fix only added input validation or shell metacharacter escaping, treat this as a temporary patch: similar vulnerabilities will likely surface in other provider integrations (GitHub, GitLab) or through bypasses. Demand evidence that Dokploy has refactored to use parameterized git library calls, added explicit coding guidelines prohibiting shell interpolation, and audited all provider integrations.
Until then, treat Dokploy deployment permissions as equivalent to host root access. Do not use Dokploy to deploy services from untrusted tenants on shared infrastructure. The platform's architectural assumption—that deployment permission is a meaningful security boundary—contradicts its implementation, and you should design around that reality.