CVE-2026-86059 in Dokploy
Summary
by MITRE • 09/22/2026
Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, Dokploy organization members without Git provider access can retrieve plaintext provider credentials through github.one, gitlab.one, gitea.one, and bitbucket.one because those protected procedures return full provider rows without applying getAccessibleGitProviderIds or an organization check. The application.one route also returns nested GitHub, GitLab, Gitea, and Bitbucket relations from findApplicationById with GitHub App private keys, OAuth tokens, client secrets, webhook secrets, and app passwords even when hasGitProviderAccess is false. A member with application read access or a provider identifier can therefore bypass per-member provider assignment and use the exposed credentials to access private repositories or manipulate external workflows. This issue is fixed in version 0.29.13.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Dokploy versions prior to 0.29.13 represents a critical failure in authorization logic within its Platform as a Service architecture, specifically affecting how organization members interact with integrated Git provider configurations. As a self-hostable PaaS solution, Dokploy relies on secure integration with external version control systems such as GitHub, GitLab, Gitea, and Bitbucket to manage application deployments and source code access. The core flaw lies in the backend API endpoints that handle requests for git provider information and application details. These endpoints fail to enforce proper role-based access controls when retrieving sensitive configuration data, allowing users who lack explicit permission to access specific Git providers to still retrieve plaintext credentials associated with those providers.
The technical mechanism of this vulnerability involves two primary attack vectors within the application's routing structure. First, requests directed at routes such as github.one, gitlab.one, gitea.one, and bitbucket.one return full provider rows containing sensitive authentication data without applying necessary filters like getAccessibleGitProviderIds or verifying organization-level access permissions. This means that any authenticated user with basic platform access can query these endpoints to extract the underlying configuration objects for all Git providers configured in the system, regardless of whether they are assigned as a member of those specific provider integrations. Second, the application.one route exhibits similar deficiencies by returning nested relationships from findApplicationById. When an application is fetched, this endpoint includes detailed GitHub App private keys, OAuth tokens, client secrets, webhook secrets, and app passwords for all associated Git providers, even if the requesting user does not have hasGitProviderAccess set to true. This behavior effectively bypasses per-member provider assignment restrictions that are intended to limit credential exposure on a need-to-know basis within multi-tenant or large organizational setups.
The operational impact of this vulnerability is severe due to the nature of the exposed data. The plaintext credentials retrieved include private keys, OAuth tokens, and webhook secrets, which serve as high-value targets for attackers. An adversary who gains access to these credentials can authenticate directly against external Git provider APIs using legitimate administrative or deployment-level permissions. This allows them to clone private repositories containing proprietary source code, intellectual property, and sensitive configuration files that were intended to be restricted from the compromised user's view. Furthermore, possession of webhook secrets enables the attacker to trigger malicious workflows or CI/CD pipelines within the victim organization, potentially leading to further compromise through supply chain attacks or unauthorized deployments of malicious code into production environments. The ability to manipulate external workflows amplifies the risk beyond simple data exfiltration to active system manipulation and potential lateral movement across integrated services.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to restrict access to resources based on user roles or permissions. It also maps closely to ATT&CK technique T1530 Data from Cloud Storage Object Misconfiguration, although in this case the misconfiguration is within an application's API logic rather than public cloud storage buckets. The exposure of credentials via standard API endpoints without adequate authorization checks constitutes a classic example of broken object level permissions where the system trusts user input or session context insufficiently when determining what data to return. To mitigate this issue, organizations running Dokploy must upgrade immediately to version 0.29.13 or later, which corrects these access control flaws by ensuring that getAccessibleGitProviderIds and organization checks are properly applied before returning sensitive provider rows. Until the update is applied, administrators should restrict API endpoint exposure through network-level controls such as firewalls or reverse proxy rules if possible, although upgrading remains the only definitive remediation for this logic flaw.