EUVD-2026-55737Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network API requires authenticated low-privilege account; high confidentiality from credential exposure; no integrity or availability impact applies.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, application.one in apps/dokploy/server/api/routers/application.ts returns provider relations loaded by findApplicationById in packages/server/src/services/application.ts without redacting githubClientSecret, githubPrivateKey, or githubWebhookSecret, allowing a user with only service:read permission to retrieve another user’s Git provider secrets even when hasGitProviderAccess is false and unauthorizedProvider is set. This issue is fixed in version 0.29.13.
AnalysisAI
Dokploy's application.one API endpoint exposes unredacted Git provider credentials - including GitHub client secrets, private keys, and webhook secrets, as well as GitLab and Gitea access and refresh tokens, and Bitbucket app passwords - to any authenticated user holding service:read permission, regardless of whether that user has been granted Git provider access. The root cause is that findApplicationById eagerly loads full provider relations without column-level exclusions, and the hasGitProviderAccess authorization check does not prevent these fields from appearing in the returned application object. All Dokploy deployments prior to version 0.29.13 are affected; no public exploit has been identified, though the patch diff published in PR #4859 precisely documents the vulnerable data paths.
Technical ContextAI
Dokploy is a Node.js self-hostable PaaS built on tRPC routers. The vulnerable code path begins at the application.one route in apps/dokploy/server/api/routers/application.ts, which calls findApplicationById in packages/server/src/services/application.ts. Before version 0.29.13, that service function issued an ORM query that included github: true, gitlab: true, bitbucket: true, and gitea: true - returning complete provider relation objects without any column-level filtering. The fix in commit 68ea9f7771afe6acca57032dc4328f93c4f25999 replaces these boolean includes with explicit column exclusions (e.g., githubClientSecret: false, githubPrivateKey: false, githubWebhookSecret: false for GitHub; secret: false, accessToken: false, refreshToken: false for GitLab and Gitea; appPassword: false, apiToken: false for Bitbucket). The root cause class is CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor - specifically server-side insufficient output filtering where the data access layer returns more data than the API consumer is authorized to receive, with the authorization check (hasGitProviderAccess) operating at the wrong layer.
RemediationAI
Upgrade Dokploy to version 0.29.13 or later; this is a vendor-released patch confirmed by the tagged release at https://github.com/Dokploy/dokploy/releases/tag/v0.29.13 and commit 68ea9f7771afe6acca57032dc4328f93c4f25999. Following the upgrade, organizations should immediately rotate all Git provider credentials that may have been exposed: GitHub App client secrets, private keys, and webhook secrets; GitLab and Gitea OAuth access and refresh tokens; and Bitbucket app passwords and API tokens - for any application accessible to users holding service:read permission prior to patching. If immediate upgrade is not feasible, restrict service:read permission assignments to only fully trusted internal users as a compensating control, accepting that this may limit operational workflows for legitimate read-only users. There is no known configuration flag to disable the leaking endpoint independently.
Dokploy self-hosted PaaS prior to 0.26.6 has a critical command injection vulnerability (CVSS 9.9) allowing authenticate
Dokploy versions before 0.26.6 contain hardcoded database credentials in the installation script, causing nearly all dep
Command injection in Dokploy (self-hosted PaaS) before 0.29.13 lets an authenticated low-privilege member run arbitrary
Command injection in Dokploy (self-hosted PaaS) before 0.29.13 lets an authenticated panel user run arbitrary commands o
Remote code execution in Dokploy 0.27.0 through 0.29.2 allows unauthenticated attackers to forge email-verification JWTs
Command injection in Dokploy (self-hostable PaaS) before 0.29.13 lets an authenticated user run arbitrary OS commands on
OS command injection in Dokploy self-hosted PaaS before 0.29.13 lets an authenticated member with service-deployment per
Command injection in Dokploy self-hostable PaaS before 0.29.13 lets an authenticated user with backup:read permission ru
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
OS command injection in Dokploy (self-hostable PaaS) before 0.29.13 lets an authenticated user holding the backup-restor
Cross-tenant remote command execution in Dokploy (self-hosted PaaS) before 0.29.13 lets any authenticated user holding o
Command injection in Dokploy self-hosted PaaS versions prior to 0.29.13 lets an authenticated user with database-service
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today