UpHeron
All vulnerabilities

Servers and applications

GHSA-hjg5-rhxv-62h2

Saving the git source of an application or compose does not check access to the git provider: a member can point their service at another user's unshared GitHub/GitLab/Gitea/Bitbucket provider or SSH key and clone private repositories with it

Severity
Medium
Published
12 Nov 2026
Last changed
12 Nov 2026
Added to UpHeron
12 Nov 2026
Fixed in
0.31.1
Weakness
Authorization bypass through a user-controlled key (IDOR) (CWE-639)
Sources
Project advisories (GitHub)

Description

The endpoints that save the git source of an application (application.saveGithubProvider, saveGitlabProvider, saveBitbucketProvider, saveGiteaProvider, saveGitProvider, and application.update) and of a compose service (compose.update) only call checkServicePermissionAndAccess(..., { service: ["create"] }). They then write the posted githubId, gitlabId, bitbucketId, giteaId or customGitSSHKeyId straight into the row. Nothing checks that the caller may use that provider, that it belongs to the caller's organization, or that it is shared. The provider routers (github.one, getGithubRepositories, getGithubBranches, ...) do call assertGitProviderAccess, and application.one / compose.one call canEditDeployGitSource (added in PR #4570) but only to return a hasGitProviderAccess = false flag for the UI. At deploy time the clone helpers load the provider by id with no organization or ownership check and clone with its token, app credentials or private key.

From Dokploy/dokploy's security advisory. Shortened; the full text is there.

Affected software

SoftwareAffected versions
DokployServers and applications · github:dokploy/dokploy
  • Every version before 0.31.1

References